INTERNET-DRAFT F. Templin Nokia Expires 25 April 2003 25 October 2002 Neighbor Affiliation Protocol for IPv6-over-(foo)-over-IPv4 draft-templin-v6v4-ndisc-00.txt Abstract This document proposes extensions to IPv6 Neighbor Discovery for IPv6-over-(foo)-over-IPv4 links, where (foo) is either an encapsulating layer (e.g., UDP) or a NULL layer. It is essentially a lightweight, link-layer mechanism for nodes and routers to establish security associations, discover and dynamically re-adjust maximum transmission units, and perform neighbor unreachability detection. The protocol makes no attempt to ensure reliable message delivery; this function is performed by higher-layer protocols, e.g. TCP. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Templin Expires 25 April 2003 [Page 1] INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002 1. Introduction The author anticipates a long-term requirement for [IPv6] operation over IPv6-over-(foo)-over-IPv4 links, where IPv4 is treated as a link layer for IPv6-over-(foo). Neighbors that exchange data over such links will need to make the most efficient, robust and secure use of the intervening [IPv4] paths possible. The author believes that this will require link-layer specific extensions to enable a hybrid proac- tive/on-demand neighbor discovery mechanism using bi-directional links. IPv6 nodes and IPv6 routers will need to establish security associa- tions, determine and dynamically re-adjust maximum transmission units, and perform neighbor unreachability detection using an IPv4 intranet or internet as the link layer. Although IPv4 fragmentation is considered harmful [FRAG][FOLK], the author believes that strate- gically adapting to, and minimizing, fragmentation can provide a superior solution to strict fragmentation avoidance. Central to the design goals is the ability to establish and maintain lightweight, link-layer associations between IPv6 neighbors to provide a feedback loop. Although these associations take on certain aspects of connec- tion-oriented protocols, the author prefers the term "neighbor affil- iation". 2. Applicability Statement - proposes a neighbor affiliation protocol for IPv6 nodes and routers - may be useful for IPv6 operations in certain deployment scenarios 3. Terminology The terminology of [IPv4] and [IPv6] apply to this document. The fol- lowing additional term is defined: neighbor affiliation: a lightweight association between IPv6 neighbors 4. Neighbor Affiliation [DISC] specifies mechanisms for IPv6 nodes to discover and maintain reachability information about active neighbors. Neighbor Solicitaion (NS) and Neighbor Advertisement (NA) messages are normally used for this purpose on multiple access, broadcast media. But, when an IPv4 Templin Expires 25 April 2003 [Page 2] INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002 intranet/internet is used as the link layer, the underlying network is treated as a non-broadcast multiple access (NBMA) media for IPv6, and the standard usage for NS and NA messages specified in [DISC] does not apply. Thus, an adaptation for the use of these messages for IPv6-over-(foo)-over-IPv4 links is specified in this document. When multiple IPv4 hops intervene between nodes, [DISC] provides no trust basis nor any clear means for the node to monitor the router's liveliness, i.e., multicast is not supported. Additionally, the path MTU between any two nodes may differ considerably. [FRAG, 3.4] speaks favorably for the use of transparent fragmentation, i.e., the use of reliable fragmentation and reassembly at a layer below IP. What is proposed here is not a firm reliance on such link layer fragmenta- tion, but judicious and minimal use so that network utilization can be maximized while fragmentation is minimized. Since the intervening IPv4 path between nodes is likely to be uni- cast-only, we consider only the use of unicast NS/NA messages for now. These messages are formatted as specified in [DISC, 4.3-4] and always include the source/target link layer address options as appro- priate for unicast operation. But, as permitted in [DISC, 4.6.1], this document specifies the content and format of the link-layer address for IPv6-over-(foo)-over-IPv4. The neighbor affiliation proposal entails the following roughly-spec- ified algorithm: 1) The source node creates a unicast IPv6 NS and wraps it in a (foo)/IPv4 header. The IPv4 length MAY BE artificially inflated to the size of the outgoing link's physical MTU if path probing is needed (i.e., the packet is NULL-padded beyond the encapsulated RS). The the DF flag is NOT set in the IPv4 header. The source link layer address field contains a "SYN" indication (format TBD). The NS is then sent to the target node, and a state variable for the target transitions from "CLOSED" to "NS-SENT" 2) The target node looks for either full IPv6 NS's or IPv4 first-fragments arriving in the reassembly cache (by any means necessary). If the first-fragment contains a unicast NS, and if the "SYN" bit is set, the IPv4 length of the fragment indicates the path MTU from the initiating neighbor. (Any other fragments arriving for the IPv4 packet can be discarded.) The receiver (which was in the "LISTEN" state) creates a state variable in the "NS-RECEIVED" for the initiator, then sends a unicast NA to the host with a "Source->Target Path MTU" value and a "SYN/ACK" indication encoded in the target link layer address (format TBD) using the first fragment's length Templin Expires 25 April 2003 [Page 3] INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002 as the path MTU value. The IPv4 length MAY BE artificially inflated to the size of the target's outgoing link (as for the NS in step 1) if path probing is needed 3) The source node receives the NA, by snooping incoming IPv4 first-fragments as described above, looks for the "SYN/ACK" indication, places the length from the "Source->Target Path MTU" field in the destination cache for the target, and transitions from the "NS-SENT" state to the "ESTABLISHED" state. It then creates a NA message (as in 2) which it sends to the target; placing the length of the first-fragment in the "Target->Source Path MTU" field and an "ACK" indication encoded in the source/target link layer address option (format TBD). 4) The target receives the NA message and transitions from the "NS-RECEIVED" state to the "ESTABLISED" state. It writes the value in the Target->Source Path MTU option into a destination cache entry for the source. The target and source have now established a bi-directional link, using the exact mechanism specified in [TCP, 3.4] NOTES: - If either end of the affiliation is unable to "snoop" the reassembly cache in the manner specified above, it must return a minimum path MTU value to the peer that is no smaller than the IPv6 MINMTU of 1280 and no larger than can be reasonably expected to avoid fragmentation (TBD) - If either end of the affiliation chooses not to probe the path, it should set a "not probing" indication in the NS/NA message (TBD) - If either end of the affiliation detects fragmentation of data packets at any time, it must send a "fragmentation experienced' indication in an unsolicited NA message to inform the other end of the new path MTU - If fragmentation continues, "fragmentation experienced" messages are scheduled to avoid congestion on the return path (i.e., they are sent according to some TBD scheduling algorithm; not on receipt of each fragmented packet) Left to consider is the fact that "keepalives" are needed to keep the affiliation strong. This is done through data packets sent between the source and target. Packets between the source and target need to carry a "RECENTLY_HEARD" indication signifying that each end of the Templin Expires 25 April 2003 [Page 4] INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002 affiliation is hearing periodic messages from the other. When one end of the affiliation has no data packets to send within a "NEIGH- BOR_KEEPALIVE" timeout, it sends an unsolicited NA to the other end if it wishes to keep the affiliation alive. When one end of the affi- laition ceases to hear periodic messages from the other end for a "NEIGHBOR_LOST" timeout period, it enters the CLOSED state and either sends a new NS to re-establish the affiliation or remains quiet unless/until new data packet are Lastly, but most importantly, *all* packets are sent with the DF flag NOT set; if either end of the affiliation detects fragmentation, an unsolicited NA is sent with the newly-detected (reduced) path MTU in the MTU option to inform the peer. Nodes may employee a strategy for allowing/disallowing particular affiliations, e.g., a router may choose not to answer a solicitation from a new host if its state cache is nearly full. Finally, security measures should be taken to ensure that the affiliation protocol described above is not abused by malicious nodes. Candidate mecha- nisms might be an adaptation of TCP "syn cookies" [reference needed] or a shared secret between the neighbors. 5. IANA considerations TBD 6. Security considerations TBD Acknowledgements The proposal herin is nearly identical to some presented on the [TCP- IP] [MTUDWG] mailing lists, roughly between the period of May 1997 through May 1990. The original proposal that most closely matches the one herein was offered by Charles Lynn on November 17, 1987. Earlier works from SRI International propsed a "router affiliation" protocol. The term "affiliation" as used in this document was directly derived from its use in those earlier works. Two SRI researchers who participated in this effort were Barbara Denny and Bob Gilligan. The author would finally like to acknowledge the founding architects of the DARPA Internet protocols, who created the technologies used by the millions of nodes on the Internet today and the billions more to come in the forseeable future. Templin Expires 25 April 2003 [Page 5] INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002 Normative References [IPv4] Postel, J., "Internet Protocol", RFC 791. [TCP] Postel, J., "Transmission Control Protocol", RFC 793. [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460. [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [FRAG] Kent, C., and J. Mogul, "Fragmentation Considered Harmful", December, 1987 [FOLK] Shannon, C., Moore, D. and k claffy, "Beyond Folklore: Observations on Fragmented Traffic" [PROBE] Mogul, J., Kent, C., Partridge, C., and K. McCloughrie, "IP MTU Discovery Options", RFC 1063, July 1988. [PMTUD] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [MTUDWG] IETF MTU Discovery Working group mailing list, gatekeeper.dec.com/pub/DEC/WRL/mogul/mtudwg-log, November 1989 - February 1995. [TCP-IP] TCP-IP Mailing list archives, http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip, May 1987 - May 1990. Informative References Authors Addresses Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA, USA Phone: (650)-625-2331 Email: ftemplin@iprg.nokia.com Templin Expires 25 April 2003 [Page 6]