HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 03:24:14 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 07 Apr 1998 05:53:41 GMT ETag: "2e7ad7-5191-3529bf65" Accept-Ranges: bytes Content-Length: 20881 Connection: close Content-Type: text/plain ION/IPng Working Groups A. Conta (Lucent) INTERNET-DRAFT December 1997 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification draft-ietf-ion-ipv6-ind-00.txt Status of this Memo This document 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 ``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 extensions to the IPv6 Neighbor Discovery that allow a node to solicit and be advertised an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery. They specifically apply to Frame Relay networks but they may also apply to other networks with similar behavior. 1. Introduction This document defines extensions to the IPv6 Neighbor Discovery (ND) that allow a node to solicit and be advertised an IPv6 address Conta Expires in six months [Page 1] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery December 18, 1997 corresponding to a known link-layer address. The extensions are 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 in a Frame Relay network by a Data Link Connection Identifier (DLCI). Each DLCI defines for a Frame Relay node a single virtual connection through the wide area network (WAN). By way of specific signaling messages, a Frame Relay network may announce to a node a new virtual circuit with its corresponding DLCI. The DLCI identifies to a node a virtual circuit, and can be considered the equivalent of a remote node link-layer address, allowing a node to address at link layer level the node at the other end of the virtual circuit. However, the signaling message does not contain information about the identifier used by a remote node to identify the node, which would be the equivalent of the local link- layer address. Furthermore, the message being transmitted at link- layer level and completely independent of the IPv6 protocol does not include any IPv6 addressing information. Therefore it seems to be useful to define a protocol that allows a Frame Relay node to discover the equivalent of a local link layer address, that is, the identifier by way of which remote nodes address the node, and more importantly discover based on a known remote link layer address an IPv6 address of a node at the other end of the virtual circuit. The IPv6 Inverse Neighbor Discovery (IND) protocol defined by this document allows a Frame Relay node to discover dynamically the DLCI by way of which a remote node identifies the virtual circuit as well an IPv6 address of a remote node associated with a virtual circuit. These mechanisms can be used with other links that similar to Frame Relay provide to nodes information equivalent to destination (remote) data link-layer addresses without indicating the 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 number of similarities and differences between the mechanisms described here and those defined for InARP for IPv4 in RFC 1293, or its replacing documents. 2. Inverse Neighbor Discovery Messages The following messages are defined: Conta Expires in six months [Page 2] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery December 18, 1997 2.1. Inverse Neighbor Discovery Solicitation Message A node sends an Inverse Neighbor Discovery Solicitation message to request an IPv6 address corresponding to a link-layer address of the target node while also providing its own link-layer address to the target. Since the remote node IPv6 addresses are not known, Inverse Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node multicasts. However, at link layer level, an IND Solicitation is sent directly to the target node, identified by the known link-layer address. 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 IPv6 all-node 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 link-layer address, then the sender SHOULD include this header. ICMP Fields: Type [TBD] Code 0 Conta Expires in six months [Page 3] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery December 18, 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 may have no knowledge of the information that indicates to the remote node the equivalent of the link-layer address of the source of this message. Therefore prior to any Inverse Neighbor Discovery processing, the receiver of this message replaces this field, whether filled in or not by the sender, with information carried by the Frame Relay header in the DLCI field. The field is encoded in DLCI format as defined by [IPv6FR]. Target Link-Layer Address The link-layer address of the target node. For Frame Relay, this field is filled with the value known to the sender as the equivalent of the target node link-layer address, encoded in DLCI format [IPv6FR]. Note: For Frame Relay, both the above addresses are in Q.922 format (DLCI), which can have 10 (default), 17, or 23 significant addressing bits [IPv6FR]. 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 in the Q.922 address have no significance for IND and are set to 0 [IPv6FR]. Options: MTU The MTU configured for this link [ND] For Frame Relay is the MTU for this virtual circuit [IPv6FR]. Future versions of this protocol may add other option types. Conta Expires in six months [Page 4] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery December 18, 1997 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. 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 The Source Address of an invoking Inverse Discovery Neighbor Solicitation. 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. Conta Expires in six months [Page 5] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery December 18, 1997 ICMP Fields: Type [TBD] Code 0 Checksum The ICMP checksum. See [ICMPv6]. R Router flag. Defined for compatibility with Neighbor Discovery advertisement messages. It is not used. It MUST be clear. S Solicited flag. Defined for compatibility with Neighbor Discovery advertisement messages. It is used mostly with Neighbor Unreachability Detection. It is not used by IND. It MUST be clear. Note: In case of Frame Relay, this message is sent on a virtual circuit, which acts like a virtual-link. If it brakes, all participants to the circuit receive appropriate link layer signaling messages, which can be propagated to the upper layers, including IPv6. Consequently, Neighbor Unreachability Detection is a mechanism that is superfluous and therefore less useful than for 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 mapping of the link- layer address to IPv6 address. When it is not set the advertisement 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 be set. Note: For Frame Relay, the Inverse Neighbor Discovery Advertisement messages unlike the Neighbor Discovery Advertisement messages carrying DLCI format link-layer addresses, SHOULD have a "O" bit set to 1. Reserved 29-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Conta Expires in six months [Page 6] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery December 18, 1997 Target Address The IPv6 address corresponding to the Target Link- Layer Address in the Inverse Neighbor Discover Solicitation message that prompted this advertisement. Required options: Source Link-Layer Address The link-layer address of the sender of this message. For Frame Relay, the sender link-layer address is filled with the DLCI value of the virtual circuit known to the sender of this message. The field is in DLCI format as defined by [IPv6FR]. Target Link-Layer Address The link-layer address of the sender of this message. For Frame Relay, this field is copied from the Inverse Neighbor Discovery Solicitation Target link-layer address field. It is encoded in DLCI format [IPv6FR]. Options MTU The MTU configured for this link (virtual circuit) [ND]. 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 Protocol IND operates essentially the same as ND. The solicitor of a target IP address sends a solicitation message, the target node responds with an advertisement message containing the information requested. 3.1 Sender Node Processing A soliciting node formats an IND solicitation message as defined in a previous section, encapsulates the packet for the specific link-layer [IPv6FR] and sends it directly to the target node. Although the Conta Expires in six months [Page 7] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery December 18, 1997 destination IP address is the all-node multicast address, the message is sent only to the target node. In the case of Frame Relay, the target node is the known remote node on the link represented by the virtual circuit. The significant fields for the IND protocol are the Source IP address, the Source link-layer address, the Target link- layer address, and the MTU. The latter can be used to set the optimum value of the MTU for the link. 3.2 Receiver Node Processing A Frame Relay node, before further processing, is replacing in the Source link-layer address the existent DLCI value with the DLCI value from the Frame Relay header of the frame containing the message. The DLCI value has to be formated appropriately in the Source link-layer address field [IPv6FR]. This operation is required to allow a correct interpretation of the fields in the further processing of the IND solicitation message. For every IND solicitation, the receiving node may format in response a proper IND advertisement using the link-layer source and target address pair as well as the IPv6 source address from the IND solicitation message. If a node is unable or unwilling to advertise, it ignores the solicitation. Further, the receiver node may put the sender's IPv6 address/link- layer address mapping - i.e. the source IP address and the Source link-layer address from the solicitation message - into its ND cache as it would for a ND solicitation. For a Frame Relay node, the MTU value from the solicitation message MAY be used to set the receiver's MTU to a value that is more optimal, in case that was not already done at the interface configuration time. 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. 4. Security Considerations Being employed on point to point virtual circuits Inverse Neighbor Discovery messages are not sensitive to impersonation attacks from on-link nodes. Like Neighbor Discovery, the protocol reduces the exposure to threats Conta Expires in six months [Page 8] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery December 18, 1997 from off-link nodes in the absence of authentication by ignoring IND packets received from off-link senders. The Hop Limit field of all received packets is verified to contain 255, the maximum legal value. Because routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor. Inverse Neighbor Discovery protocol packet exchanges can be authenticated using the IP Authentication Header [RFC 1826]. A node SHOULD include an Authentication Header when sending Inverse Neighbor Discovery packets if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol. Received Authentication Headers in Neighbor Discovery packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored. It SHOULD be possible for the system administrator to configure a node to ignore any Inverse Neighbor Discovery messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. Such a switch SHOULD default to allowing unauthenticated messages. Confidentiality issues are addressed by the IP Security Architecture and the IP Encapsulating Security Payload documents [RFC 1825, RFC 1827]. 5. Acknowledgments Thanks to Thomas Narten and Eric Nordmark who spent time discussing the idea of Inverse Neighbor Discovery. Also thanks to Dan Harrington, Milan Merhar, and Martin Mueller for a thorough reviewing. 6. References [IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6 Specification" [ND] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for IP Version 6 (IPv6)" Conta Expires in six months [Page 9] INTERNET-DRAFT IPv6 Inverse Neighbor Discovery December 18, 1997 [IPv6FR] A. Conta, A. Malis, M. Mueller, "Transmission of IPv6 Packets over Frame Relay networks" [RFC-1825] R. Atkinson, "Security Architecture for the Internet Protocol" [RFC-1826] R. Atkinson, "IP Authentication Header" [RFC-1827] R. Atkinson. "IP Encapsulating Security Payload (ESP)". [RFC-2200] J. Reynolds, J. Postel, "Assigned Numbers" [ENCAPS]C. Brown, A. Malis, "Multiprotocol Interconnect over Frame Relay", . [RFC-1293] T. Bradley, C. Brown, "Inverse Address Resolution Protocol", 1/1992 7. 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 10] 590