Network Working Group F. Templin Internet-DRAFT Nokia Expires March 11, 2003 September 11, 2002 ISATAP interactions with TSP draft-templin-interact-00.txt 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. Abstract This document discusses possible interactions between the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) and the Tunnel Setup Protocol (TSP). 1. Introduction This document is submitted as a matter of professional responsibility to the IETF community; not as a means for promoting personal inter” ests or the proprietary interests of any commercial enterprise(s). While it anticipates possible directions, the document in no way expresses preference for any of several possible conclusions. Instead, the material is presented to inform the community and help Templin Expires March 11, 2003 [Page 1] ^L Internet Draft ISATAP Interactions with TSP September 11, 2002 guide them in the decision-making process. The Tunnel Setup Protocol [TSP] sets up IPv6 or IPv4 tunnels between nodes. The protocol may also set up optional security associations between tunnel endpoints and provide autoconfiguration options including prefix delegation, DNS delegation, etc. [ISATAP] is an automatic tunneling mechanism intended for Enterprise/Managed net” works that requires no pre-arranged configuration between tunnel end” points. It normally operates in a stateless fashion behind a corpo” rate firewall or security gateway and may also be applicable in other transition scenarios. Although stateless, ISATAP may in some instances benefit from the use of stateful autoconfiguration services of TSP. Thus, this document discusses possible interactions between ISATAP and TSP in any appropriate deployment scenario. 2. Motivation The automatic tunneling mechanism used by ISATAP has several key advantages over configured tunnels. ISATAP configures a single auto” matic tunnel interface in system kernel data structures. (In some instances, finite soft-state caching is also used for per-destination information.) Conversely, configured tunnels require per-destination hard-state that grows linearly with the number of destinations. Thus, automatic tunnels do not suffer from finite state scaling limitations and loss due to single point of failure as in the configured tunnels case. Also unlike configured tunnels, automatic tunnels derive IPv4 tunnel endpoint addresses directly from information encoded in IPv6 addresses. Thus, communicating nodes can use automatic IPv6-in-IPv4 encapsulation to send packets directly to one another without going through a tunnel endpoint server, i.e., route optimization is auto” matically enabled. Finally, the system's IPv6 routing table requires a single route for an automatic tunnel interface, whereas the routing table grows linearly with the number of active destinations when con” figured tunnels are used. Therefore, ISATAP satisfies deployment scenarios not satisfied by configured tunnels when arbitrarily-large numbers of heterogeneous IPv6-in-IPv4 tunnel endpoints (including handheld terminals, personal computers, servers, dedicated routers, etc.) are deployed and/or when efficient routing performance is needed. It would seem that a stateful configured tunnel setup protocol such as TSP would have no application for a stateless automatic tunneling mechanism such as ISATAP. But, in addition to tunnel setup, TSP may also provide an autoconfiguration environment useful for ISATAP as well as a method for determining packet sizing parameters for the tunnel endpoints. Thus, the following section presents ISATAP Templin Expires March 11, 2003 [Page 2] ^L Internet Draft ISATAP Interactions with TSP September 11, 2002 interactions with TSP. 3. ISATAP Interactions with TSP The interactions of ISATAP with TSP discussed by this document are similar to any that might already exist for configured IPv6-in-IPv4 tunnels, with the exception that ISATAP defines a new TUNNELTYPE "auto" to indicate that NO configured tunnel hard state is needed in the kernel. When an ISATAP host resolves the Potential Router List (as specified by [ISATAP, 5.2.1] or through some other means), it may issue a TSP connection request to router(s) in the PRL. The host may negotiate with the ISATAP router(s) as to whether SECURE or TRUSTING modes are used. If SECURE mode is used, the router and host may arrange a secu” rity association and each end may place the other's IPv4 address in a security data structure (e.g., interface access list) for the auto” matic tunnel interface on which the connection arrived. In both the SECURE and TRUSTING cases, the router will send prefix and default router information - either in a form specified by TSP or as RFC 2461 router advertisements. The router and host may also exchange packet sizing parameters for their respective network interfaces. When an ISATAP host connects to another ISATAP host on the same link, it may/may not somehow be transparently directed to engage in a TSP session before both sides can communicate. Again, NO configured tun” nel hard state is set in the kernel. As with the router example above, packet sizing parameters may be exchanged but no router adver” tisements are sent. Also as for the router case, TRUSTING and SECURE modes are supported. The above processes inferred for TSP may entail a continuous feedback loop between tunnel endpoints to: - periodically refresh prefix and default router information - periodically refresh packet sizing parameters - send indications of packets that are too big Other autoconfiguration aspects of TSP may be used, but DHCP may pro” vide a suitable alternative. Finally, some simple guidelines to determine the degree to which ISATAP and TSP need to interact are suggested below: - if a site is being administered responsibly, TSP's SECURE mode may not be needed - if a site's infrastructure consists of (mostly) homogeneous network interfaces, packet sizing parameters and packet too Templin Expires March 11, 2003 [Page 3] ^L Internet Draft ISATAP Interactions with TSP September 11, 2002 big indications from TSP may not be needed - if both cases are true, the vanilla features of [ISATAP] alone may provide a sufficient deployment 4. IANA Considerations The TUNNELTYPE "auto" is registered for this document. 5. Security Considerations TBD Acknowledgments TBD References [ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-04.txt, (work in progress). [TSP] Blanchet, M. "Tunnel Setup Protocol", July 2002, (work in progress). Author's Address: Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 USA Phone: (650)-625-2331 Email: ftemplin@iprg.nokia.com Templin Expires March 11, 2003 [Page 4] ^L