Internet-Draft Grenville Armitage Bellcore August 28th, 1995 IPv6 and Neighbour Discovery over ATM 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 specifies the frame formats for unicast and multicast transmission of IPv6 packets in a UNI3.1 based ATM environment. It discusses the construction of IPv6 link-local addresses, and the formats of the source and target link-layer address options carried by Neighbour Discovery messages. Finally, it begins to describe the interactions between IPv6 Neighbour Discovery and evolving address resolution models in the ATM arena. Further discussion of the issues raised in this document is requested, as not all questions are currently answered satisfactorily. Armitage Expires February 28th, 1996 [Page 1] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 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 will describe the requirements for the structure of IPv6 Link Local addresses [6], and suitable sources of link specific interface IDs. The format of the source and target link-layer address options in Neighbour Discovery [7] messages is described in section 4. Section 5 will open up the wider issues regarding the definition of ATM networks as being 'multicast' or 'shared media' links for the purposes of Neighbour Discovery, and how this impacts on the leveraging of current IPv4 work on 'cut through' routing models. [Editors note: Further discussion of the issues raised in this document is requested, as not all questions are currently answered satisfactorily.] 2. Framing unicast and multicast IPv6 packets. The Ethertype assigned to IPv6 is 0x86DD. Following the convention of RFC1483 for IPv4 unicast transmissions, the encapsulation for IPv6 packet SHALL be: [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] (LLC) (OUI) (PID) Multicasting is an integral part of IPv6. However, the service interface provided by UNI3.1 ATM networks do not support the concept of link-layer group addressing (which would have made the Armitage Expires February 28th, 1996 [Page 2] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 specification of IPv6 multicast over ATM trivial). An additional convergence function is required between UNI3.1 ATM services and the IP layer to emulate a multicast-capable ATM link layer. The IP-ATM working group is nearing completion of such a convergence function, known as the 'MARS model' [5]. 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].) Additionally, when using the MARS for IPv6 multicast support: MARS message encapsulation remains the same: [0xAA-AA-03][0x00-00-00][0x08-06][MARS message] (LLC) (OUI) (PID) The ar$hrd field in MARS messages remains 0x13. The ar$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). 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 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 its is not strictly necessary for the interface ID to be unique across multiple independent links. The ATM environment complicates the sense of the word 'link' somewhat, 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 we might consider the IPv6 analog to be a Logical Link Group - LLG. Armitage Expires February 28th, 1996 [Page 3] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 An LLG consists of nodes administratively configured to be IPv6 neighbours. Sets of hosts that are members of the same MARS Cluster [5] SHOULD be considered to form an LLG. [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.] The width of the interface ID affects the width of routing prefixes that may then be applied to those portions of the IPv6 internet built over the given link technology. It is preferable to choose the smallest unique identifier possible. 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: Armitage Expires February 28th, 1996 [Page 4] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 | 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 long lasting. The CMI would potentially change everytime the node re-registered itself with the MARS - an event of unpredictable occurence.] 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 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. Defines the type and length of the ATM number immediately Armitage Expires February 28th, 1996 [Page 5] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 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 February 28th, 1996 [Page 6] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 5.1 Using MARS multicast support. 5.1.1 Initialisation. The 'black box' approach to IPv6 over ATM is to just use a MARS based IP/ATM interface in a straightforward manner. 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 routers 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 routers SHALL perform a block MARS_JOIN for the range(s) of IPv6 multicast addresses they require each ATM interface to listen on (as described in section 9 of [5]). - They MUST NOT issue a block join for multicast addresses with scope of 1 (node-local) or 2 (link-local). To support their internal endpoints, IPv6 routers SHALL perform a single group MARS_JOIN for the following groups: - Its 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 the endpoint within the router belongs with at least link-local scope. Armitage Expires February 28th, 1996 [Page 7] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 5.1.2 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. 5.1.3 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 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 Armitage Expires February 28th, 1996 [Page 8] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 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. 5.2 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.) It is not clear at this stage how mechanisms such as 'cut through' routing are best integrated with Neighbour Discovery. In the IPv6 case cut through routing explicitly allows a node to treat off-link nodes as neighbours. This could lead an IPv6 node to have 3 categories of outbound paths: - on-link, directly accessible at link-layer. - pseudo on-link, directly accessible at link-layer, technically off-link. - off-link, access is through an on-link router. Armitage Expires February 28th, 1996 [Page 9] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 A key issue to be addressed is how an IPv6 node learns the link-layer address of an ostensibly off-link target. Related on-going work in the IPv4 area is the ROLC working group's Next Hop Resolution Protocol, NHRP [8]. How this work may be applied to ND is still to be defined. One possible application of NHRP style technology would be similar to the optimisation mentioned in section 5.1 when using the MARS. The IPv6/ATM interface driver could trap outgoing Neighbour Solicitations, convert them into NHRP requests, and the use NHRP replies to generate 'fake' Neighbour Advertisements. The following questions then need to be addressed: - How NHSs learn of the existence of nodes, - How we maintain the ability of a target node to return different link-layer addresses per Neighbour Solicitation for load balancing, - How the sending node adjusts its Neighbour Cache, Destination Cache, Prefix List, and Default Router List. [Editors note: "..still to be defined" is my code phrase meaning "I'd love to have some suggested text to go here 'cos I cant think of any really good stuff myself". Contributions welcome.] 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 this draft. Subsequent errors are my own. Author's address Grenville Armitage Internetworking Research Group, Bellcore. 445 South Street Morristown, NJ, 07960-6438 USA Phone: +1 201 829 2635 Email: gja@thumper.bellcore.com Armitage Expires February 28th, 1996 [Page 10] Internet Draft IPv6 Neighbour Discovery over ATM August 28th, 1995 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 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. Armitage Expires February 28th, 1996 [Page 11]