INTERNET-DRAFT F. Templin Nokia Expires 19 April 2003 19 October 2002 Router Affiliation Protocol for IPv6-over-(foo)-over-IPv4 draft-templin-router-affiliation-00.txt Abstract This document proposes a router affiliation protocol 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 detect router failures. 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 19 April 2003 [Page 1] INTERNET-DRAFT Router Affiliation 19 October 2002 1. Introduction The author anticipates a long-term requirement for [IPv6] operation over IPv6-over-(foo)-over-IPv4 links. IPv6 nodes that affiliate with IPv6 routers over such links will need to make the most efficient, robust and secure use of the intervening [IPv4] paths as possible. The author believes that this will require a connection-oriented link-layer mechanism, where IPv4 is treated as a link layer for IPv6-over-(foo). IPv6 nodes and IPv6 routers will need to establish security associa- tions, determine and dynamically re-adjust maximum transmission units, and detect router failures using an IPv4 intranet or internet as the link layer. Although IPv4 fragmentation is considered harmful [FRAG][FOLK], the author believes that strategically 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 association between IPv6 nodes and routers to provide a feedback loop. Although these associations take on certain aspects of connection-oriented proto- cols, the author prefers the term "router affiliation". 2. Applicability Statement - proposes a router 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: router affiliation: a lightweight association between a node and router 4. Router Affiliation IPv6 nodes obtain prefix and default router information by sending Router Solicitaion (RS) message and receiving Router Advertisement (RA) messages as specified in [DISC]. But, when an IPv4 path inter- venes between the node and router, the path must be treated as a link layer for IPv6. [FRAG, 3.4] speaks favorably for the use of transpar- ent fragmentation, i.e., the use of reliable fragmentation and Templin Expires 19 April 2003 [Page 2] INTERNET-DRAFT Router Affiliation 19 October 2002 reassembly at a layer below IP. What is proposed here is not a firm reliance on such link layer fragmentation, but judicious and minimal use so that network utilization can be maximized while fragmentation is minimized. Additionally, when multiple IPv4 hops intervene between a node and router, [DISC] provides no trust basis nor any clear means for the node to monitor the router's liveliness. Consider that all IPv6 nodes on IPv6-over-(foo)-over-IPv4 links can be thought of as "routers" if one considers the IPv6 stack to be a node within the IPv6-over-(foo)-over-IPv4 node. Then, all IPv6 nodes on such links can send RA messages, given a proper specification. Since the intervening IPv4 path between the nodes is likely to be unicast-only, we consider only the use of unicast RA/RS messages for now. The proposal entails the following roughly-specified algorithm: 1) The affiliating node creates a unicast IPv6 RS and wraps it in a (foo)/IPv4 header. The IPv4 length is artificially inflated to the size of the outgoing link's physical MTU (the packet is NULL-padded beyond the encapsulated RS), and the DF flag is NOT set in the IPv4 header. The affiliating node then sends the RS to the router and transitions from the "CLOSED" state to the "RS-SENT" state 2) The router looks for IPv4 first-fragments arriving by any means necessary. If the first-fragment contains a unicast RS, the length of the fragment indicates the path MTU from the affiliating node to the router. (Any other fragments arriving for the IPv4 packet can be discarded.) The router treats the IP_ID in the enclosing IPv4 header as a sequence number. It transitions from the "LISTEN" state to the "RS-RECEIVED" state, then sends a unicast RA to the host with an MTU option that includes the path MTU calculated from above and also contains this sequence number. The RA is artificially inflated to the size of the router's outgoing link, as was done for the RS in 1) 3) The affiliating host receives the RA, by snooping incoming IPv4 first-fragments as described above, places the length from the MTU option in the destination cache, and transitions from the "RS-SENT" state to the "ESTABLISHED" state. It then creates a RA message (as in 2) which it sends to the router; placing the length of the first-fragment in the MTU option and the IP_ID from the RA in some sort of sequence number field 4) The router receives the RA message and transitions from the "RS-RECEIVED" state to the "ESTABLISED" state. It writes the value in the MTU option into a destination cache entry for Templin Expires 19 April 2003 [Page 3] INTERNET-DRAFT Router Affiliation 19 October 2002 the host. The router and host have now established a bi-directional link, using the exact mechanism specified in [TCP, 3.4] Left to consider is the fact that "keepalives" are needed to keep the affiliation strong. This is done through data packets sent between the node and router. The packets from the node to the router need to carry the "last_heard" IP_ID from packets it has received from the router, while the packets from the router to the node need to carry the "last_heard" IP_ID from the node. When no data packets occur for some time, or if arriving data packets are showing the SAME "last_heard" even though packets were sent, unsolicited RAs can be sent as keepalives if the association needs to be maintained. Other- wise, the association can be dropped when the affiliating node no longer needs to remain affiliated with the router. Lastly, but most importantly, *all* packets are sent with the DF flag NOT set; if either end of the affiliation detects fragmentation, an unsolicited RA is sent with the newly-detected (reduced) path MTU in the MTU option to inform the peer. Routers 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 affili- ation protocol described above is not abused by malicious nodes. Can- didate mechanisms might be an adaptation of TCP "syn cookies" [refer- ence needed] or a shared secret between the ISATAP hosts and routers. The latter may even allow for expansion of ISATAP applicability beyond the intra-site scope. 5. IANA considerations TBD 6. Security considerations TBD Acknowledgements The author claims no original ideas in this work. The author recog- nizes that ideas similar to those in this document may have already been presented by others and wishes to acknowledge any other such contributors. As a special acknowledgement, the term "router affiliation" is Templin Expires 19 April 2003 [Page 4] INTERNET-DRAFT Router Affiliation 19 October 2002 directly derived from earlier works done by SRI International. Two SRI researchers who participated in this effort were Barbara Denny and Bob Gilligan. A future version of this document will provide formal reference. 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. 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" 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 19 April 2003 [Page 5]