INTERNET-DRAFT F. Templin Nokia Expires 18 April 2003 18 October 2002 Proposed Solutions for ISATAP Operational Issues draft-templin-isatap-issues-00.txt Abstract This document proposes solutions for the operational issues identified in the current ISATAP draft. The proposed solutions are both simple and necessary to address potential problems in anticipated deployment scenarios. The document invites discussion from the community to help refine/revise the proposed solutions. 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 18 April 2003 [Page 1] INTERNET-DRAFT Proposed Solutions for ISATAP Issues 18 October 2002 1. Introduction The current ISATAP specification [ISATAP] identifies operational issues for anticipated deployment scenarios. This document is intended as a living framework for addressing these issues and invites open discussion from the community (to include members of the relevant v6ops design teams). The solutions developed in this process will fold into a future version of the ISATAP specification once the community has reached agreement as to their readiness. (Such solu- tions may also provide useful input for other documents.) When full agreement is reached on all proposed solutions, and no operational issues remain, this document's purpose will be fulfilled. 2. Applicability Statement - proposes solutions for operational issues identified in [ISATAP] - invites discussion from the community - may provide benefits for other documents 3. Terminology The terminology of [IPv6] and [ISATAP] apply to this document. The following additional term is defined: affiliation: an established relationship between a pair of nodes (in the case of this document, between a host and router) 4. Proposed Solutions to Operational Issues This document must be read with strict reference to the operational issues identified in [ISATAP], i.e., the issues are not re-iterated here in exacting detail for sake of brevity. The following subsec- tions propose solutions to the current set of operational issues: 4.1. Operational Issue #1: The specifications in [MECH,3.1-3.4] are currently undergoing exten- sive revision, and the mailing list discussions relating to these specifications are still underway. ISATAP will continue to track these discussions and make the necessary adjustments when RFC Templin Expires 18 April 2003 [Page 2] INTERNET-DRAFT Proposed Solutions for ISATAP Issues 18 October 2002 2893(bis) approaches last-call status. 4.2. Operational Issue #2: The ISATAP interface identifier construction currently specifies a 32-bit "token" for the purpose of identifying ISATAP addresses. In practice, it has been found that the choice of statically assigning as many as 32 bits provides little/no operational advantage and pre- cludes other potential applications. In the author's opinion, as few as 2 bits could be tagged for static assignment. The author invites discussion as to applications which may benefit from the use of up to 30 spare bits and which may justify a change to the specification (noting that proposed solutions to other operational issues may sug- gest MANDATORY changes to the specification.) 4.3. Operational Issues #3, #7: The Potential Routers List is nothing more than a list of IPv4 addresses corresponding to ISATAP routers that a node MAY affiliate with. But, the Potential Router List gives no information about the status of any such affiliations. The second validity check in [ISA- TAP, 4.5] MUST be changed to require the examination of a router affiliation state cache instead of the Potential Routers List (see Operational Issues #4.1, #4.2, below). 4.4. Operational Issues #4.1, #4.2: The static computation for address resolution used by [ISATAP, 5.1] does not trigger the neighbor solicitation/neighbor advertisement reachability detection mechanisms specified in [DISC, 7.3.3]. This condition can cause black holes, i.e., packets sent to non-existent nodes (or lost en-route to existing nodes) with no failure indication returned. This condition may cause operational issues for peer-peer communications between ISATAP hosts, but [DISC, 7.3.1] provides a means for communicating peers to assess "forward progress" without having to consult the neighbor cache. On the other hand, the black hole condition will definitely cause operational issues for communications from an ISATAP host to a remote peer that must traverse an ISATAP router. In particular, the ISATAP router and ISATAP host MUST be able to, e.g., receive ICMPv6 messages from each other even when no peer-peer communications exist that may indicate "forward progress". The only way for this to happen is for ISATAP hosts to form a strong affiliation with their ISATAP router(s); a method for achieving this is proposed below: Templin Expires 18 April 2003 [Page 3] INTERNET-DRAFT Proposed Solutions for ISATAP Issues 18 October 2002 Consider the router and host specifications in [ISATAP 5.2.3 - 5.2.4]. The operations specified provide a means for unicast RS/RA exchanges between hosts and routers. As specified in [DISC], no cache state is created based on RS/RA exchanges. But, since ISATAP defines an NBMA mechanism that essentially extends the [DISC] specification, it is free to define new operations. Consider now that RS/RA messages for ISATAP can be thought of as moral equivalents of NS/NA messages, since they are unicast between neighbor nodes. We now have the basis for an algorithm for strong host-router affiliation as follows: 1) The ISATAP host sends a unicast RS to an ISATAP router and creates a cache entry for the router in the "INCOMPLETE" state 2) The router receives the RS, creates a cache entry for the host in the "INCOMPLETE" state, and sends a unicast RA to the host 3) The host receives the RA, sets the router's cache entry in the "REACHABLE" state, and sends a Neighbor Advertisement message to the router with the "Solicited" bit set. 4) The router receives the NA message and sets its cache entry to the "REACHABLE" state. The router and host have now estab- lished a bi-directional link. It should be noted that the "cache" mentioned above may be one and the same with the neighbor cache if the neighbor cache isn't being used for other purposes. But, a preferred implementation might create a private cache relative to the ISATAP device driver and police the cache in exactly the same manner as [DISC]. This cache could be called the "affiliation state cache", inferred in "Operational issue #3 above. It should also be noted that the process could equally well be initiated by the router sending an unsolicited unicast RA, but the above algorithm would need to specify the progressions for that case. Left to consider is the fact that "keepalives" are needed to keep the affiliation strong. But, since no "forward progress" indications may be assumed, the above affiliation algorithm MUST be reiterated once every N seconds to reaffirm the bidirectional link. A reasonable choice for N might be the 30sec neighbor REACHABLE_TIME timer speci- fied in [DISC]. Finally, it MUST be noted that the algorithm cited above is nothing new and has been well-tested for decades in the Internet. The algo- rithm is exactly the "three-way handshake" used for establishing TCP sessions [TCP], albeit with slightly dissimilar purposes intended. Templin Expires 18 April 2003 [Page 4] INTERNET-DRAFT Proposed Solutions for ISATAP Issues 18 October 2002 4.5. Operational Issue #5 Since the router affiliation protocol above requires frequent keepalives, control message overhead explosion will result if hosts poll EVERY router in the PRL and the PRL is long. Instead, each host should execute a strategy to poll a reduced number of nodes in the PRL, perhaps choosing to affiliate with an even smaller subset of the routers polled. Many possible strategies exist, including: 1) Poll only the first router in the list 2) Poll a router randomly chosen from the list 3) Poll a subset of the routers in the list, but only affiliate with the "topologically closest" as told by the TTL in returned unicast RAs 4) etc. Similarly, ISATAP routers may employee a strategy for allowing/ dis- allowing particular affiliations, e.g., a router may choose not to answer a solicitation from a new host if its state cache is nearly full. In this way, the PRL becomes a mechanism for fault tolerance and load balancing moreso than aimless proliferation of routers throughout a site as for the current ISATAP specification. 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. 4.6. Operational Issue #6 Sites that enable NATs internally may open themselves to operational issues for ISATAP. The ISATAP IPv6/IPv4 encapsulation will not tra- verse standard NATs, and the only way to guarantee no NATs in the path is through careful operational practices. A better long- term solution may be to modify ISATAP to use UDP/IPv6/IPv4 encapsulation as is currently done for Teredo [TEREDO]. Such a modification would draw ISATAP and Teredo even closer such that merging the two proto- cols may procude the best possible transition mechanisms. Templin Expires 18 April 2003 [Page 5] INTERNET-DRAFT Proposed Solutions for ISATAP Issues 18 October 2002 5. IANA considerations IANA considerations are the same as for [ISATAP]. 6. Security considerations Security considerations are the same as for [ISATAP]. Acknowledgements The author claims no original ideas in this work; the proposed solu- tions should be obvious to any with background in Internetworking given a clearly-articulated problem statement. The author recognizes that ideas similar to those in this document may have already been presented by others and wishes to acknowledge any other such contrib- utors. As a special acknowledgement, the term "router affiliation" is 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 [ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-05.txt, (work-in-progress). [IP] 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. [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-ietf-ngtrans-shipworm-08.txt, Templin Expires 18 April 2003 [Page 6] INTERNET-DRAFT Proposed Solutions for ISATAP Issues 18 October 2002 (work-in-progress) 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 18 April 2003 [Page 7]