One document matched: draft-ietf-ipatm-ipv6nd-01.txt
Differences from draft-ietf-ipatm-ipv6nd-00.txt
Internet-Draft Grenville Armitage
Bellcore
February 22nd, 1996
IPv6 and Neighbour Discovery over ATM
<draft-ietf-ipatm-ipv6nd-01.txt>
Status of this Memo
This document was submitted to the IETF IP over ATM WG. Publication
of this document does not imply acceptance by the IP over ATM WG of
any ideas expressed within. Comments should be submitted to the ip-
atm@matmos.hpl.hp.com mailing list.
Distribution of this memo is unlimited.
This memo is an internet draft. Internet Drafts are working documents
of the Internet Engineering Task Force (IETF), its Areas, and its
Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the
"lid-abstracts.txt" listing contained in the Internet-Drafts shadow
directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document describes preliminary ideas on running IPv6 over ATM,
and identifies open issues that require resolution by one or more
IETF working groups. The frame formats for unicast and multicast
transmission of IPv6 packets in a UNI3.1 based ATM environment are
specified. Some issues regarding the construction of IPv6 link-local
addresses are identified, a format for source and target link-layer
address options in Neighbour Discovery messages is suggested, and the
interactions between IPv6 Neighbour Discovery and existing IP over
ATM models are outlined.
This revision is intended as a placeholder prior the LA IETF in March
Armitage Expires August 22nd, 1996 [Page 1]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
1996. Important work is been presented to a joint IPATM/IPNG/ROLC
meeting in LA which will lead to substantial revision, rewriting, or
removal of this document.
Further discussion of the issues raised in this document is
requested, as not all questions are currently answered
satisfactorily.
1. Introduction.
This document deals with a number of issues associated with running
IPv6 [1] over UNI3.1 [2] based ATM services. These may be
characterised as:
- Packet framing and multicasting.
- Link Local address specification.
- Neighbour Discovery source/target link-layer address option.
- Interactions between ND and underlying IP/ATM architectures.
Packet framing is dealt with in section 2, applying the newly
assigned IPv6 Ethertype [3] to the encapsulation models developed for
IPv4 unicast [4] and multicast [5]. Section 2 will also note the
specific behaviour required of an IPv6-ATM interface when using the
MARS protocol defined in [5] to support IPv6 multicast over UNI3.1
ATM networks.
Section 3 outlines the requirements for the structure of IPv6 Link
Local addresses [6], and provides pointers to some current ideas on
the creation of link-local tokens.
The format of the source and target link-layer address options in
Neighbour Discovery [7] messages is described in section 4.
Section 5 is a placeholder for the wider discussion of how the IPv6
Neighbour Discovery service and/or protocol may be applied to ATM
environments. Primarily it points to two ongoing pieces of work
addressing this issue.
[Editors note: Further discussion of the issues raised in this
document is requested, as not all questions are currently answered
satisfactorily.]
2. Packet framing, and multicasting with MARS.
Armitage Expires August 22nd, 1996 [Page 2]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
2.1 Unicast packets.
The Ethertype assigned to IPv6 is 0x86DD. Following the convention of
RFC1483 for IPv4 unicast transmissions, the default encapsulation for
IPv6 packet SHALL be:
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
(LLC) (OUI) (PID)
Local administrators MAY choose to discard the LLC/SNAP encapsulation
and use 'VC multiplexing'. In this case an IPv6 packet is placed
directly into an AAL5 AAL_SDU.
2.2 Multicast packets.
Multicasting is an integral part of IPv6. However, UNI3.0/3.1 based
ATM networks do not provide suffucient support to allow a trivial
mapping. The IP-ATM working group is nearing completion of a
convergence function, known as the 'MARS model' [5], which builds the
required multicast support using the UNI3.0/3.1 point to multipoint
model. When using this approach the encapsulation for multicast IPv6
packets SHALL be:
[0xAA-AA-03][0x00-00-5E][0x00-01][CMI][0x86-DD][IPv6 packet]
(LLC) (OUI) (PID)
(The 2 octet CMI - Cluster Member ID - field is defined in [5].)
Local administrators MAY choose to discard the LLC/SNAP encapsulation
and use 'VC multiplexing'. In this case the [CMI][0x86-DD][IPv6
packet] is placed directly into an AAL5 AAL_SDU.
2.3 Using MARS for multicast support.
The encapsulation of MARS control messages (between MARS and MARS
Clients) remains the same:
[0xAA-AA-03][0x00-00-00][0x08-06][MARS control message]
(LLC) (OUI) (PID)
The mar$afn field in MARS messages remains 0x0F.
The ma$pro field in MARS messages SHALL be 0x86DD.
The ar$spln and ar$tpln fields (where relevant) are either 0 (for
null or non-existent information) or 16 (for the full IPv6
protocol address).
Armitage Expires August 22nd, 1996 [Page 3]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
When a host starts up it SHALL issue a single group MARS_JOIN for the
following groups:
- Its derived Solicited-node address(es) with link-local scope.
- The All-nodes address with link-local scope.
- Other multicast groups with at least link-local scope.
For example the IPv6 node with address 4037::01:800:200E:8C6C would
issue the following MARS_JOIN to register as a member of its
Solicited-Node multicast group:
MARS_JOIN(FF02::1:200E:8C6C, FF02::1:200E:8C6C)
Joining or leaving a multicast group with node-local scope (scope 1)
MUST NOT cause MARS_JOIN or MARS_LEAVE messages to be transmitted.
(The smallest scope managed by a MARS is scope 2 (link-local), and so
this is the smallest scope that MARS message are issued for.)
IPv6 mrouters may be considered to be built of two parts - a
forwarding engine, and an endpoint. The forwarding engine needs to be
listening promiscuously across all multicast groups that need
forwarding outside the link scope. The endpoint within a router needs
to listen only on specific groups that have scope of link-local or
larger.
To support the forwarding engine:
- IPv6 mrouters SHALL perform a block MARS_JOIN for the range(s)
of IPv6 multicast addresses they require each ATM interface to
listen on (described in section 9 of [5] for IPv4).
- They MUST NOT issue a block join for multicast addresses with
scope of 1 (node-local) or 2 (link-local).
To support any internal endpoints, IPv6 mrouters SHALL perform a
single group MARS_JOIN for the following groups:
- Their derived Solicited-node address(es).
- The All-nodes address with link-local scope.
- The All-routers address with link-local scope.
- Other multicast groups to which endpoints within the mrouter
belong with at least link-local scope.
The use of MARS for supporting the general case of IPv6 multicasting
is independent of how Neighbour Discovery is implemented (section 5).
Armitage Expires August 22nd, 1996 [Page 4]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
3. IPv6 Link-Local address.
IPv6 nodes are required to generate a unique Link-Local IPv6 address
for every link layer interface they have [6, 9]. Constructing these
addresses requires an interface ID (or link-local token) that is at
least unique amongst all the interfaces attached to the same link.
Routers are not allowed to forward packets with Link-Local
destinations, so it is not necessary for the interface ID to be
unique across multiple independent links.
3.1 A Logical Link Group.
The ATM environment complicates the sense of the word 'link' in much
the same way as it complicated the sense of 'subnet' in the IPv4
case. For IPv4 this required the definition of the Logical IP Subnet
- an administratively constrained set of hosts that would share the
same routing prefixes (network and subnetwork masks).
For want of a better term this document considers the IPv6 analog to
be a Logical Link Group - LLG.
An LLG consists of nodes administratively configured to be 'on
link' with respect to each other.
Sets of hosts that are members of the same MARS Cluster [5] SHOULD be
considered to form an LLG. (This is the analog of the current
restriction that an IPv4 MARS Cluster is constructed from the
multicast capable members of an LIS.)
[Editors note - I'd be more than happy to be given some new text
here, or even a pointer to a previously established IPv6 terminology
that captures the sense of the LLG.]
3.2 Choice of Interface ID.
The choice of interface ID is a compromise. You need to uniquely
identify IPv6 interfaces that share the same Link, and a number space
large enough to keep down the probability of different IPv6
interfaces generating identical Link-Local addresses. On the other
hand, you want to keep the width (in bits) of the interface ID down
because it impinges on the number of bits remaining to use as routing
prefixes. It is preferable to choose the smallest unique identifier
possible to maximise our ability to build hierarchy into the routing
prefixes.
The IPv6 over Ethernet world suggests that a 48 bit interface ID is
large enough for uniqueness and small enough to leave a useful
routing prefix width. This 48 bit value is taken directly from the 48
Armitage Expires August 22nd, 1996 [Page 5]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
bit MAC address associated with a node's Ethernet interface - each
Ethernet interface supporting a single IPv6 interface. However, in
the ATM environment it is usual to find logical IP intefaces layered
over a single physical ATM interface. If these logical IP interfaces
are members of the same IPv6 Link (e.g. virtual hosts on a single
machine) then each needs a different interface ID in order to
generate a different Link-Local address.
This is currently a contentious issue. The previous version of this
ID proposed an oversized interface ID of 8 octets to cover all the
possible ATM based virtual interfaces. This is likely to be replaced,
but is described in Appendix A for reference.
The final solution is still TBD, but will likely evolve from
discussions based on [10], [11], and [12]. Readers are encouraged to
review these documents.
4. ND link-layer address options.
Neighbour Discovery defines two options for carrying link-layer
specific source and target addresses. In this case these options must
carry full ATM addresses.
The source and target link-layer address options must carry any one
of the three possibilities, and indicate which one it is.
The format for these two options when in an ATM environment is
adapted from the MARS [] and NHRP [] specs, and SHALL be:
[Type][Length][NTL][STL][..ATM Number..][..ATM Subaddress..]
| Fixed || Link layer address |
[Type] is a one octet field.
1 for Source link-layer address. 2 for Target link-layer address.
[Length] is a one octet field.
The total length of the option in multiples of 8 octets. Zeroed
bytes are added to the end of the option to ensure its length is a
multiple of 8 octets. (For example, a single ATM address in NSAPA
format would result in 24 bytes of real data, require no padding,
and result in [Length] being set to 3.)
[NTL] is a one octet 'Number Type & Length' field.
Armitage Expires August 22nd, 1996 [Page 6]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
Defines the type and length of the ATM number immediately
following the [STL] field. The format is as follows:
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| length |
+-+-+-+-+-+-+-+-+
The most significant bit is reserved and MUST be set to zero. The
second most significant bit (x) is a flag indicating whether the
ATM number is in:
ATM Forum NSAPA format (x = 0).
Native E.164 format (x = 1).
The bottom 6 bits is an unsigned integer value indicating the
length of the associated ATM address in octets.
The [STL] is a one octet 'Subaddress Type & Length' field.
Format is the same as the [NTL] field. Defines the length of the
subaddress field, if it exists. If it does not exist this entire
octet field MUST be zero. If the subaddress exists it will be in
NSAPA format, so flag x SHALL be zero.
[ATM Number] is a variable length field. It is always present.
[ATM Subaddress] is a variable length field. It may or may not be
present. When it is not, the option ends after the [ATM Number] (or
any additional padding for 8 byte alignment).
5. The wider implications of Neighbour Discovery.
The assumptions behind Neighbour Discovery interact in interesting
ways with two broad areas of IP over ATM work - multicast support and
'cut through' unicast routing.
In its most general form Neighbour Discovery (and IPv6 in general)
relies on the underlying IPv6/link-layer interface to support
multicasting.
Multicast needs to be emulated in UNI3.1 environments. The 'on-
link/off-link' distinction for neighbours lends itself to a Classical
IP model of IPv6 over ATM, where nodes are grouped into Logical Link
Groups (LLGs). However, as for IPv4, such administrative boundaries
need to be 'cut through' to provide maximal use of the underlying ATM
service.
Armitage Expires August 22nd, 1996 [Page 7]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
A simplistic approach to Neighbour Discovery would be to treat ones
MARS based IP/ATM driver as a black box that magically supports IP
multicasting. Thus ND will appear to 'work' as designed. This is
described for completeness in Appendix B. Examination of this
approach reveals two substantial limitations - it is rather complex
(layering an address discovery service over an address discovery
service), and it does not offer a way to achieve 'cut through'
resolutions.
5.1 Neighbour Discovery and 'cut through' routing.
IPv6 contains a concept of on-link and off-link. Neighbours are those
nodes that are considered on-link and whose link-layer addresses may
therefore be located using Neighbour Discovery. Borrowing from the
terminology definitions in the ND text:
on-link - an address that is assigned to a neighbor's interface on
a shared link. A host considers an address to be on-link
if:
- it is covered by one of the link's prefixes, or
- a neighboring router specifies the address as the
target of a Redirect message, or
- a Neighbor Advertisement message is received for the
target address, or
- a Router Advertisement message is received from the
address.
off-link - the opposite of "on-link"; an address that is not
assigned to any interfaces attached to a shared link.
Off-link nodes are considered to only be accessible through one of
the routers directly attached to the link.
(Using the terminology of section 3, in the ATM environment a 'link'
is an LLG.)
Solutions are being developed to allow 'cut through' routing to be
integrated with Neighbour Discovery's concept of 'neighbour'.
Questions needing to be answered include:
How do you perform Duplicate Address Detection?
How do you decide who is on or off link (or LLG)?
How do you keep the ND service of allowing the targetted neighbour
to return different link layer addresses to every ND query?
The following documents describe more complete solutions being
Armitage Expires August 22nd, 1996 [Page 8]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
proposed within the IETF at the time of writing - [10], [11], and
[12]. Readers are encouraged to study them.
[Editors note: This entire section is really TBD, based on evolving
consensus of IPATM/IPNG/ROLC working groups.]
Security Consideration
Security considerations are not addressed in this memo.
Acknowledgments
Sue Thomson (Bellcore) patiently answered my more inane questions
during the initial stages of version 00. Peter Schulter, Ran Atkins,
and others have ensured that the issues are being studied carefully
within the wider IETF environment. Unless noted otherwise, errors are
my own.
Author's address
Grenville Armitage
Internetworking Research Group,
Bellcore.
445 South Street
Morristown, NJ, 07960-6438
USA
Email: gja@thumper.bellcore.com
References.
[1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", INTERNET DRAFT, draft-ietf-ipngwg-ipv6-spec-02.txt,
IPNG WG, June 1995.
[2] ATM Forum, "ATM User Network Interface (UNI) Specification
Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs,
NJ, June 1995.
[3] S. Deering, email to ipng@sunroof.Eng.Sun.COM, Friday 16 Jun
1995.
[4] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaption Layer
5", RFC 1483, USC/Information Science Institute, July 1993.
[5] G.J. Armitage, "Support for Multicast over UNI 3.1 based ATM
Armitage Expires August 22nd, 1996 [Page 9]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
Networks", INTERNET DRAFT, draft-ietf-ipatm-ipmc-06.txt, IP-over-ATM
WG, August 1995.
[6] S. Deering, R. Hinden, "IP Version 6 Addressing Architecture",
INTERNET DRAFT, draft-ietf-ipngwg-addr-arch-03.txt, IPNG WG, June
1995.
[7] T. Narten, E. Nordmark, W.A. Simpson, "Neighbour Discovery for IP
Version 6 (IPv6)", INTERNET DRAFT, draft-ietf-ipngwg-discovery-
01.txt, July 1995.
[8] D. Katz, D. Piscitello, "NBMA Next Hop Resolution Protocol
(NHRP)", INTERNET DRAFT, draft-ietf-rolc-nhrp-04.txt, ROLC WG, May
1995.
[9] S. Thomson, "IPv6 Stateless Address Autoconfiguration", INTERNET
DRAFT, draft-ietf-addrconf-ipv6-auto-03.txt, ADDRCONF WG, July 1995.
[10] Randall Atkinson, Dimitry Haskin, James Luciani, "IPv6 over NBMA
Networks",INTERNET DRAFT, draft-ahl-ipv6-nbma-00.txt, February 1996.
[11] Peter Schulter, "A Framework for IPv6 Over ATM", INTERNET DRAFT,
draft-schulter-ipv6atm-framework-01.txt, February 1996.
[12] Robert Elz, "Identifying Interfaces in IPv6 link-local
addresses", INTERNET DRAFT, draft-ietf-ipngwg-iid-00.txt, December
1995.
Armitage Expires August 22nd, 1996 [Page 10]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
Appendix A: A deprecated form of Interface ID generation.
An interface to an LLG is itself logical, and is supported by a
logical ATM interface. The ATM Forum allows three possible variations
of ATM addresses. These are:
- Native E.164 number.
- 20 byte ATM Forum NSAP format number.
- Native E.164 number with NSAP format subaddress.
When NSAP format addresses are in use, logical ATM interfaces are
constructed over physical ATM interfaces by using different SEL
within the context of a given ESI, or even having multiple ESIs route
to the same physical interface. When native E.164 addresses are in
use, each logical ATM interface requires its own E.164 number.
Therefore, the unique interface ID for the construction of Link-Local
IPv6 addresses SHALL be 8 octets wide and be constructed in one of
two ways:
If the link interface has an NSAPA assigned, the 7 byte ESI+SEL
value of the logical ATM interface being used by the IPv6 node is
extracted and placed into the rightmost octets of the 8 octet
interface ID. The leftmost octet is reserved and MUST be set to
zero.
If the link interface has only a native E.164 number assigned to
it then a 7.5 octet BCD encoded version of the E.164 number is
used to fill the 8 octet field. The semi-octet 0000 is used to
begin the BCD stream, and the semi-octet value 1111 is used to pad
out the field in cases where the E.164 number was less than the
maximum 15 digits.
The Link-Local IPv6 address thus appears as:
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+
54 zero bits pad out the IPv6 address between the interface ID and
the 10 bit Link-Local prefix.
[Editors note: suggestions for a smaller interface ID are welcome.
Based on the ' smallest width' criterion, and the association of LLGs
and Clusters, the 16 bit Cluster Member ID (CMI) suggests itself.
However, another valuable attribute of the interface ID is that it be
Armitage Expires August 22nd, 1996 [Page 11]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
long lasting. The CMI would potentially change everytime the node
re-registered itself with the MARS - an event of unpredictable
occurence.]
Appendix B. Using MARS multicast support.
B.1 Simple discovery.
When a Neighbour Solicitation needs to be multicast, the ND entity
simply passes down the ICMPv6 packet for transmission. The MARS based
IP/ATM driver would query the MARS for the destination Solicited-node
multicast address and establish the outgoing VC as per [5]. Having
received the solicitation, the appropriate target node unicasts their
Neighbour Advertisement back (using the source link-layer address
carried along with the solicitation) and the process is complete.
This will certainly work. However, it does raise some questions about
whether this is the most effective use of the available resources.
B.2 Optimising discovery.
The MARS already knows what link-layer address(es) are associated
with every Solicited-node IPv6 multicast group address registered in
your Logical Link Group (LLG, or Cluster). Assume that your LLG is
such that each node's addresses map to a unique Solicited-node
multicast group. In this case the MARS will have only one ATM address
associated with every mapping. We thus know that the Neighbour
Solicitation sent using the 'black box' approach described above will
reach only one node.
If the ATM address registered as the mapping in the MARS is the same
as the one that the node would return in its Neighbour Advertisement,
we might consider the optimisation of skipping the actual VC setup
and NS/NA exchange. The ATM address returned in the MARS_MULTI could
be copied into a locally generated Neighbour Advertisement and passed
back up to the local ND entity.
A number of assumptions exist in the preceding idea. The most
important one is that no MCS has been configured to support that
particular group (otherwise the MARS would return the ATM address of
the MCS rather than the target node).
The second assumption is that only one node maps to each Solicited-
node multicast group. If this is not true then the 'black box'
approach to will need to be followed, letting the multiple recipients
of the Neighbour Solicitation decide whether to respond. This
assumption will be true if the interface IDs of all the nodes in your
LLG are unique in their bottom 32 bits. However, this may not always
Armitage Expires August 22nd, 1996 [Page 12]
Internet Draft draft-ietf-ipatm-ipv6nd-01.txt February 22nd, 1996
be the case.
Finally, we assumed that the ATM address registered with the MARS was
the one that the node would have wanted to return to a Neighbour
Solicitation. This may not necessarily be the case, as Neighbour
Discovery allows nodes to associate multiple link-layer interfaces
with a single IPv6 address (and hence a single Solicited-node
multicast group). The intention is that the node itself can load-
share unicast traffic amongst these link-layer interfaces by
responding differently each time it receives a Neighbour
Solicitation.
Further research needs to be done on the validity of these
assumptions, and whether they allow us to introduce some
optimisations to the basic Neighbour Discovery mechanism when running
over a MARS based IP/ATM interface.
Armitage Expires August 22nd, 1996 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 03:25:45 |