Internet Draft IPng Working Group A. Conta (Lucent) INTERNET-DRAFT July 1997 IPv6 Inverse Neighbor Discovery for IPv6 and IPv4 Tunnels Specification draft-conta-ipv6-inv-nd-tun-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 an extension mechanism to the IPv6 Neighbor Dis- covery and IPv6 Inverse Neighbor Discovery [IND] that applies to IPv6 and IPv4 tunnels. The mechanism can be used to advertise the parame- ters of a tunnel to its exit point node, and to create a reverse tun- nel path between the exit point and entry point nodes of a unidirec- tional tunnel. If such a bidirectional tunnel already exists, the mechanism can be used to learn the IPv6 address of the tunnel pseudo- interface of the exit-point node, as well as the reverse tunnel path parameters. Conta Expires in six months [Page 1] INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997 1. Introduction This document defines an extension mechanism to the IPv6 Neighbor Discovery and IPv6 Inverse Neighbor Discovery to advertise the param- eters of an IPv6 or IPv4 tunnel to the exit point node. The mechanism can be used at the time of configuring a tunnel, to create a reverse tunnel path, from the exit-point node to the entry-point node, i.e. a bidirectional tunnel. If the reverse tunnel path already exists, the mechanism can be used to learn the IPv6 address of the tunnel pseudo- interface of the exit-point node, as well as the reverse tunnel path parameters. The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119. 2. Inverse Neighbor Discovery Messages The Inverse Neighbor Discovery Messages defined by [IND], with the TLEN, an additional option defined later in this document, are employed with IPv6 tunnels as follows: 2.1. Inverse Neighbor Discovery Solicitation Message Format A tunnel entry-point node sends an Inverse Neighbor Discovery Solici- tation to the exit-point node to request the IPv6 address correspond- ing to the virtual link-layer address represented by the IPv6 address configured as exit-point node address. The sender node provides its own virtual link-layer address to the target, as well as additional parameters such as MTU and Tunnel Nested Encapsulation Limit (IPv6). A tunnel Inverse Neighbor Discov- ery Solicitation is a virtual link-layer unicast message. The message is sent as a tunnel packet, i.e. encapsulated in an IPv6 or IPv4 tun- nel header that has as source and destination the tunnel entry-point and exit-point node addresses. 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 ... +-+-+-+-+-+-+-+-+-+-+-+- Conta Expires in six months [Page 2] INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997 IP Fields: Source Address An IPv6 address assigned to the tunnel pseudo- interface from which this message is sent. Destination Address The solicited-node multicast address of the exit- point node - built based on the exit-point node IP address. Alternatively, the all-node multicast address could be used. Hop Limit 255 Priority 15 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destina- tion address (entry and exit point node addresses), then the sender SHOULD include this header. ICMP Fields: Type 135 or [TBD] if considered a new message Code 0 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 IPv6 or IPv4 address configured as tunnel entry-point node address, which plays the role of the sender's virtual link-layer address. Target link-layer address The IPv6 or IPv4 address configured as tunnel exit- point node address, which plays the role of the receiver's virtual link-layer address. Possible options: Conta Expires in six months [Page 3] INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997 MTU The MTU of this link (tunnel MTU). TNEL The configured value of the Tunnel Nested Encapsulation Limit (IPv6 only). 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 tunnel exit-point node sends Inverse Neighbor Discovery Advertise- ments in response to Inverse Neighbor Discovery Solicitations if it ? created a reverse tunnel, i.e. a bidirectional tunnel, or if a reverse tunnel path exists. The message is send as a tunnel packet, i.e. encapsulated in a tunnel header that has as source and destination the reverse tunnel entry- point and exit-point node addresses. 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 IPv6 address assigned to the tunnel pseudo-interface from which the advertisement is sent. Conta Expires in six months [Page 4] INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997 Destination Address The IPv6 Source Address of the invoking 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. ICMP Fields: Type 136 Code 0 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. O Override flag. When set, the O-bit indicates that the advertisement should override an existing cache entry and update the cached virtual link-layer to IPv6 address mapping. When it is not set the advertisement will not update a cached virtual link-layer address to IPv6 address mapping though it will update an existing Neighbor Cache entry for which no IPv6 address is known. 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 5] INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997 Target Address The IPv6 or IPv4 address of the tunnel exit-point node 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 or IPv4 address whose virtual link-layer address to IPv6 address mapping has changed. Mandatory options: Target link-layer address The virtual link-layer address of the target, i.e., the IPv6 or IPv4 address of the tunnel exit-point node, sender of the advertisement. Source link-layer address The virtual link-layer address of the source, i.e., the IPv6 or IPv4 address of the tunnel entry-point node, receiver of the advertisement. Possible options: MTU The MTU of this link (tunnel virtual link). TNEL The configured value for the Tunnel Nested Encapsulation Limit. For IPv6 only. This is the value for the reverse tunnel. 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.3. Tunnel Nested Encapsulation Limit. This is an option to be sued with IPv6 tunnels only [TUNNEL]. 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 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TNEL | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Conta Expires in six months [Page 6] INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997 Fields: Type 5 Length 1 Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. TNEL The configured value for the Tunnel Nested Encapsulation Limit. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 3. Conceptual Model An IPv6 or an IPv4 for IPv6 transition tunnel is configured at the tunnel entry-point node as a virtual link to the tunnel exit-point node. This leaves a tunnel exit-point unaware of the existence of a tunnel terminating at that node. Although tunnel entry-point and exit-point addresses pin-point the virtual link end points, the reverse path from the exit-point node to the entry point node may be completely different than the direct path, unless both are specified as direct strict source route and respectively its reversed strict source route. This implies that a tunnel is unidirectional. The end-point nodes addresses are used to fill the source and desti- nation fields in the tunnel header prepended to a packet sent through the tunnel, similarly to a link-layer encapsulation. The tun- nel virtual link is virtually terminated in tunnel pseudo-interfaces at both ends. These pseudo-interfaces have their own IPv6 addresses. A tunnel entry-point pseudo-interface IPv6 address may appear as original packet source address if a packet originated at the tunnel entry-point node is forwarded through the tunnel towards its destina- tion. Knowing and using as destination the IPv6 address of the tun- nel pseudo-interface of the exit-point node may result in packets sent through the tunnel only if the forwarding path to that destina- tion is configured so. The entry-point node can advertise to the exit-point node the config- uring of a tunnel by way of Inverse Neighbor Discovery Solicitation messages. As a result, the exit-point node learning about the tunnel may optionally create a reverse path tunnel, hence creating the effect of a bidirectional tunnel, with potentially different direct and reverse paths. Additionally, by responding with Inverse Neighbor Discovery Advertising messages, the exit-point node notifies the Conta Expires in six months [Page 7] INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997 bidirectional tunnel effect to the entry-point node. 4. Security Considerations The creation of a reverse tunnel path raises security issues which need be discussed. At this early stage this memo does not address those security issues. 5. Acknowledgments This draft is a result of a discussion with Steve Deering about the applicability and benefits of Neighbor Discovery for IPv6 tunnels. After more thinking and in combination with IPv6 Inverse Neighbor Discovery things seemed to fall into place. The IPv4 part was quickly added after Dan Harrington suggested that it would be a good idea to have it. Thanks to Thomas Narten and Erik Nordmakr for discussing the idea = of this memo. 6. References [RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 Speci- fication" [RFC-1885] A. Conta, and S. Deering "Internet Control Message Proto- col for the Internet Protocol Version 6 (IPv6)" [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" Conta Expires in six months [Page 8] INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997 [IND] A. Conta "IPv6 Inverse Neighbor Discovery. 7. Authors' Addresses Alex Conta Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742 +1-508-287-2800/ext 2842 email: aconta@lucent.com Conta Expires in six months [Page 9]