IPng Working Group A. Conta (Lucent) INTERNET-DRAFT July 1997 IPv6 Neighbor Discovery Extensions for Inverse Discovery Specification draft-conta-ipv6-nd_ext_ind-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing 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 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This memo describes a mechanism that can be seen as an extension to the IPv6 Neighbor Discovery. It allows a node to solicit and be advertized an IPv6 address corresponding to a given link-layer address. Because the known parameter is the link layer address, the mechanism is called Inverse Neighbor Discovery. It specifically applies to Frame Relay nodes that may have a Data Link Connection Identifier (DLCI), the Frame Relay equivalent of a link-layer address, associated with an established Permanent Virtual Circuit (PVC), but do not know the IPv6 address of the node at the other end of the circuit. It may also apply to other networks with similar behavior. Conta Expires in six months [Page 1] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997 1. Introduction This document defines an extension mechanism to the IPv6 Neighbor Discovery that will allow a node to solicit and be advertised an IPv6 address corresponding to a given link-layer address. Because the input parameter is the link layer address, the mechanism is called Inverse Neighbor Discovery. The Inverse Neighbor Discovery (IND) specifically applies to Frame Relay nodes. Frame Relay permanent virtual circuits (PVCs) and switched virtual circuits (SVCs) are identified by each node in a Frame Relay network through a Data Link Connection Identifier (DLCI). Each DLCI defines for a Frame Relay node a single virtual connection through the wide area network (WAN) and is the Frame Relay equivalent to a link-layer address. Through specific signaling messages, a Frame Relay network may announce to a node a new virtual circuit with its corresponding DLCI. However, the announcement being made at link-layer level and com- pletely independent of the IPv6 protocol does not include IPv6 addressing information. The node receiving such an announcement learns about the new connection, and it is able to address the other end of the virtual circuit at link layer level, but, a configuration or mechanism for discovering an IPv6 address of the other end of the virtual circuit is necessary. The IPv6 Inverse Neighbor Discovery (IND) will allow a Frame Relay node to discover dynamically an IPv6 address of a node associated with a virtual circuit. These extensions can be used with other links that similar to Frame Relay provide destination data link-layer addresses without indicating corresponding IPv6 addresses. The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119. There is a good number of similarities but also differences between the mechanisms described here and those defined for InARP for IPv4 in RFC 1293, and the updating "draft-ietf-ion-inarp-update-01.txt". 2. Inverse Neighbor Discovery Messages The following messages are defined: Conta Expires in six months [Page 2] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997 2.1. Inverse Neighbor Discovery Solicitation Message Nodes send Inverse Neighbor Discovery Solicitations to request an IPv6 address corresponding to a link-layer address of the target node while also providing their own link-layer address to the target. Inverse Neighbor Discovery Solicitations are link-layer unicast mes- sages, but IPv6 multicasts, since the destination IPv6 address is not known. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An IPv6 address assigned to the interface from which this message is sent. Destination Address The solicited-node multicast address. It contains the 24 bit normalised value of the DLCI. Hop Limit 255 Priority 15 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destina- tion link-layer address, then the sender SHOULD include this header. ICMP Fields: Type 135 or [TBD] if considered as new message Code 0 Conta Expires in six months [Page 3] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997 Checksum The ICMP checksum. See [ICMPv6]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Required options: Source link-layer address The link-layer address of the sender. For Frame Relay, the sender link-layer address is filled in by the receiver of this message. Destination link-layer address The link-layer address of the receiver. For Frame Relay, both the above addresses are in Q.922 format (DLCI), which can have 10 (default), 17, or 24 significant addressing bits. The option length (link-layer address) is expressed in 8 octet units, therefore, the DLCI will have to be extracted from the 8 bytes based on the EA field (bit 0) of the second, third, or forth octet (EA = 1). The C/R, FECN, BECN, DE fields do not have any significance for IND [IPv6FR]. MTU The MTU configured for this link (circuit). Future versions of this protocol may add other option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. 2.2 Inverse Neighbor Discovery Advertisement Message Format A node sends Inverse Neighbor Discovery Advertisements in response to Inverse Neighbor Discovery Solicitations and sends unsolicited Neigh- bor Advertisements in order to (unreliably) propagate new information quickly. Conta Expires in six months [Page 4] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An address assigned to the interface from which the advertisement is sent. Destination Address For solicited advertisements, the Source Address of an invoking Neighbor Solicitation. For unsolicited advertisements typically the all-nodes multicast address. Hop Limit 255 Priority 15 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type 136 Code 0 Conta Expires in six months [Page 5] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997 Checksum The ICMP checksum. See [ICMPv6]. R Router flag. When set, the R-bit indicates that the sender is a router. The R-bit is used by Neighbor Unreachability Detection to detect a router that changes to a host. S Solicited flag. When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection. It MUST NOT be set in multicast advertisements or in unsolicited unicast advertisements. Note that a Frame Relay link is a virtual circuit, which if brakes, all participants to the circuit receive appropriate link layer sig- naling, which can be propagated to the upper layers, including IPv6. Consequently, Neighbor Unreachability Detection is a mechanism that doubles this function of the Frame Relay link, and as such it is less useful than in datagram oriented links. O Override flag. When set, the O-bit indicates that the advertisement should override an existing cache entry and update the cached link-layer to IPv6 address mapping. When it is not set the advertise- ment will not update a cached link-layer address to IPv6 address mapping though it will update an existing Neighbor Cache entry for which no IPv6 address is known. It SHOULD NOT be set in solicited advertisements for anycast addresses and in solicited proxy advertisements. It SHOULD be set in other solicited advertisements and in unso- licited advertisements. Reserved 29-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Target Address For solicited advertisements, the IPv6 address corresponding to the Target Link-Layer Address in the Inverse Neighbor Discover Solicitation message that prompted this advertisement. For an unso- licited advertisement, the IPv6 address whose link- layer address to IPv6 address mapping has changed. The Target Address MUST NOT be a multicast address. Conta Expires in six months [Page 6] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997 Required options: Target link-layer address The link-layer address of the target, i.e., the sender of the advertisement [IPV6FR]. Source link-layer address The link-layer address of the source, i.e., the receiver of the advertisement [IPv6FR]. MTU The MTU configured for this link (circuit). Future versions of this protocol may add other option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. 3. Inverse Neighbor Discovery Conceptual Algorithm IND operates essentially the same as IPv6 ND with the exception that IND uses the link-layer address of the destination node which is already known, instead of a link-layer multicast. A soliciting node formats an IND solicitation message as defined above, encapsulates the packet for the specific link-layer and sends it directly to the target node. Upon receiving an IND solicitation, a Frame Relay node fills in the source link-layer address field with the DLCI from the frame link- layer header. This is necessary for the correct functioning of the Frame Relay mechanism. Further the receiver node may put the sender's IPv6 address/link-layer address mapping into its ND cache as it would for a ND solicitation. However, unlike in the case of ND, all IND solicitations are destined and sent to the receiving node. For every IND solicitation, the receiving node may format in response a proper advertisment using the link-layer source and target address pair as well as the IPv6 source address from the solicitation. If a node is unable or unwilling to advertise, it ignores the solicita- tion. Because IPv6 nodes may have multiple IPv6 addresses per interface, a node responding to an IND solicitation MAY select the IPv6 address which has the same prefix as the solicitor's node IPv6 address. When the soliciting node receives the IND advertisment, it resolves the link-layer address to IPv6 address mapping in the ND cache. Conta Expires in six months [Page 7] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997 Note: Although IND applies to circuit oriented links, like Frame Relay, for which a broken physical connectivity is detected in a timely fashion by the link layer, and consequently the change of state is passed to upper layer protocols such as IPv6, under certain circumstances, information learned via IND may be aged or invalidated, and the IPv6 Neighbor Unreachability Detection may be used as an additional mecha- nism to refresh the link-layer to IPv6 address mapping. 4. Acknowledgments Thanks to Thomas Narten and Eric Nordmark who spent time discussing the idea of Inverse Neighbor Discovery. Also thanks to Dan Harring- ton, Milan Merhar, and Martin Mueller for a thorough reviewing. 5. Security Considerations Security issues are not addressed in this memo at this time. 6. References [RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 Speci- fication" [RFC-1970] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for IP Version 6 (IPv6)" [RFC-1825] R. Atkinson, "Security Architecture for the Internet Pro- tocol" [RFC-1826] R. Atkinson, "IP Authentication Header" [RFC-2200] J. Reynolds, J. Postel, "Assigned Numbers" [RFC-1293] T. Bradley, C. Brown, "Inverse Address Resolution Proto- col", 1/1992 Conta Expires in six months [Page 8] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997 8. Authors' Addresses Alex Conta Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742 +1-508-287-2842 email: aconta@lucent.com Conta Expires in six months [Page 9]