Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Informational May 10, 2007 Expires: November 11, 2007 The IPvLX Architecture draft-templin-ipvlx-08.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on November 11, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The IETF has embraced IPv6 as the next-generation Internet protocol, but global IPv4 deployment continues in private addressing domains behind Network Address Translators (NATs). This document envisions a long-term IPv6/IPv4 coexistence, with IPv6 addresses serving as identifiers (and sometimes also locators) and IPv4 addresses serving as locators (and sometimes also identifiers). This document proposes an architectural framework for IPv6/IPv4 coexistence called: "IPvLX (IP with virtual Link Extension)". Templin Expires November 11, 2007 [Page 1] Internet-Draft IPvLX May 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Abbreviations and Conventions . . . . . . . . . . . . . . . . 5 4. Routing and Addressing Assumptions . . . . . . . . . . . . . . 6 5. DNS Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 6. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 7 7. Virtual Link Extension . . . . . . . . . . . . . . . . . . . . 8 7.1. Mapping and VL Establishment . . . . . . . . . . . . . . . 8 7.1.1. Forward Mapping . . . . . . . . . . . . . . . . . . . 8 7.1.2. Reverse Mapping . . . . . . . . . . . . . . . . . . . 9 7.1.3. VL Confidentiality using IKE and IPSec . . . . . . . . 10 7.1.4. Referrals . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Encapsulation and Link Adaptation . . . . . . . . . . . . 11 7.2.1. IPvLX Encapsulation . . . . . . . . . . . . . . . . . 11 7.2.2. IPvLX Interface MTU and IPvLX Link Adaptation . . . . 12 7.2.3. IPv6 Fragmentation and Reassembly . . . . . . . . . . 12 7.2.4. Header Compression . . . . . . . . . . . . . . . . . . 12 7.3. Virtual Link Traversal . . . . . . . . . . . . . . . . . . 13 7.3.1. From the ITR to the Target EBR . . . . . . . . . . . . 13 7.3.2. From the Target EBR to the ETR . . . . . . . . . . . . 13 7.4. MPLS Label Switching . . . . . . . . . . . . . . . . . . . 14 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. IPv4 Backward Compatibility . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 14. Appendix A: Other Encapsulation Alternatives . . . . . . . . . 16 15. Appendix B: Comparison with Teredo . . . . . . . . . . . . . . 16 16. Appendix C: Changes . . . . . . . . . . . . . . . . . . . . . 17 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 17.2. Informative References . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Templin Expires November 11, 2007 [Page 2] Internet-Draft IPvLX May 2007 1. Introduction The IPv6 128-bit addressing architecture was designed as a solution for the 32-bit limitation of IPv4 and offers the promise of scalable addressing. But the proliferation of IPv4 in the global Internet continues via private addressing domains behind Network Address Translators (NATs) [RFC1918][RFC2993]. This document therefore envisions a long-term IPv6/IPv4 coexistence, with IPv6 addresses serving as identifiers (and sometimes also locators) and IPv4 addresses serving as locators (and sometimes also identifiers). It is well known that IP addresses have heretofore embodied both the identity and (topological) location of an end system (or, to be more precise, an end system interface). But, a growing consensus in the modern literature has postulated an "identity/locator split" in which identity and location are maintained in separate addressing entities. This document proposes a natural identity/locator split methodology by treating IPv6 addresses as end system interface identifiers and IPv4 addresses as routing locators in a manifestation of the "map- and-encaps" architectural framework [RFC1955]. This document proposes an architectural framework for IPv6/IPv4 coexistence known as: "IPvLX (IP with virtual Link eXtension)" with goals of limiting core routing table growth while supporting scaling to arbitrarily large numbers of end systems and restoring global Internet transparency. The scheme uses IPv6 for end system interface identification and simple network middleboxes to extend virtual links (VLs) across one or more IPv4 networks. This document is being published to capture a stable snapshot of a next-generation Internet architecture proposal, and to provide operational insight into a widely-deployed IPv6 transition mechanism known as "teredo" [RFC4380]. Similar proposals appear in [RFC1955][RFC1992][RFC3056][I-D.wang-ietf-efit][I-D.farinacci-lisp]. 2. Terminology The terminology of [RFC2460][RFC2461][RFC4214][I-D.farinacci-lisp][I- D.ietf-autoconf-manetarch] applies; the following terms are (re)defined within the scope of this document: site the terms "site" and "MANET" are used synonymously throughout this document. Traditional literature commonly uses the term "site" to refer to relatively fixed networks (e.g., the wired links of a campus LAN), but such "static" networks are really only a special case of a MANET. Sites connect to other networks via IPvLX nodes Templin Expires November 11, 2007 [Page 3] Internet-Draft IPvLX May 2007 that act as site border routers (SBRs). Mobile Ad-hoc Network (MANET) a set of links that may have asymmetric reachability characteristics (see: [RFC2461], Section 2.2) and are connected by IPvLX nodes (acting as MANET routers) that maintain a routing structure among themselves. A MANET may be as large as an enterprise or as small as an individual site, and may also be a subnetwork of a larger site. An IPvLX node and its downstream- attached links is a "site" unto itself, and a MANET is therefore a "site-of-sites". enterprise a connected set of MANETs/sites that connects to the global Internet via IPvLX nodes configured as enterprise border routers (EBRs). An enterprise is normally represented as a single Autonomous System (AS). virtual link (VL) a path over which IPv6 packets are forwarded between IPvLX nodes acting as an ingress tunnel router (ITR) and egress tunnel router (ETR) across potentially many IPv4 networks without the Hop Limit field in the IPv6 header being decremented. IP with virtual Link eXtension (IPvLX) an architectural framework of mechanisms and operational practices used by IPvLX nodes to extend VLs between sites. IPvLX node an ISATAP node ([RFC4214], Section 3) that also acts as a MANET router and supports IPvLX. IPvLX nodes serve as IPv6 routers for their own internal virtual interfaces and physical or virtual interfaces of devices on downstream-attached links. IPvLX interface an IPvLX node's virtual interface that sends and receives IPv6 packets using IPvLX link adaptation and encapsulation. Templin Expires November 11, 2007 [Page 4] Internet-Draft IPvLX May 2007 IPvLX link adaptation a Sub-IP layer mechanism specified in [I-D.templin-linkadapt] that splits IPv6 packets into chains of segments that are no larger than the path MTU of the VL. IPvLX encapsulation a method used by an ITR to encapsulate the packet segments created by link adaptation in an IPvLX Flow Header and IPv4 header for transmission on an IPv4 interface and later reassembly during decapsulation by an ETR. IPvLX Flow Header a header that is inserted between the IPv6 packet segment and the 20-byte IPv4 header in IPvLX packets. IPvLX Flow Identifier a value encoded in the IPvLX Flow Header that identifies a flow and may be modified by IPvLX nodes on the path. IPvLX Flow (or simply: "flow") a unidirectional stream of IPvLX encapsulated packets identified by a tuple consisting of an IPvLX Flow identifier, and IPv4 source/destination addresses encoded the header of each IPvLX encapsulated packet. 3. Abbreviations and Conventions With reference to Section 2, IPvLX nodes are referred to by one or more of the following abbreviations (depending on their operational orientation) throughout the document: SBR (Site Border Router) - an IPvLX node that connects a site to other networks EBR (Enterprise Border Router) - an IPvLX node that connects an enterprise to the global Internet ITR (Ingress Tunnel Router) - an IPvLX node that encapsulates packets for transmission over a VL ETR (Egress Tunnel Router) - an IPvLX node that decapsulates packets that arrive on a VL Templin Expires November 11, 2007 [Page 5] Internet-Draft IPvLX May 2007 Additionally, an IPvLX node has physical interfaces that attach to networks that provide transit to the global Internet, and physical or virtual interfaces that attach to stub networks for which they are SBRs. The convention adopted by this document is to refer to the former as "upstream" interfaces and the latter as "downstream" interfaces. 4. Routing and Addressing Assumptions IPv4 addresses in the current Internet combine both identifier and locator attributes; they are typically assigned to interfaces and provide both an identity for the end system and a routable entity that routing can use for packet forwarding decisions. IPvLX assumes that IPv6 addresses need only be treated as identifiers on a global basis (not as locators), but that they may also be routable within a limited topology such as an end site. As for IPv4 addresses, IPv6 addresses are assigned to physical or virtual interfaces. Each IPvLX node includes an IPv6 router entity that provides a nexus for forwarding packets on behalf of local IPv6 addresses as well as for IPv6 addresses that reside within sites for which the IPvLX node serves as a SBR. IPvLX nodes can therefore serve as both network middleboxes and end systems. The IPv6 router entity of an IPvLX node terminates VLs instead of providing transit for the link as a bridge would do, therefore IPv6 routers occur at the near and far end IPvLX nodes of all VLs as the logical points of termination. The near and far end of a VL are known throughout this document as the Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR), respectively. 5. DNS Assumptions The global DNS [RFC1035] today maintains resource records for Fully Qualified Domain Names (FQDNs) with global IPv4 addresses for traditional Internet services, and by design anticipates that their FQDN-to-address mappings will change relatively infrequently. IPvLX asks only that the global DNS also maintain resource records for addresses of ETRs - again, under the assumption that those FQDN-to- address mappings will change infrequently. IPvLX further assumes a DNS-like "site-local" name resolution service (e.g., LLMNR [RFC4795]) that is separate from the global DNS and records the FQDN-to-IPv6-address mappings for IPv6 application endpoints within a site. Unlike the global DNS, IPvLX nodes assume that the FQDN-to-IPv6-address mappings within the site local name service may change dynamically as IPv6 application endpoints come into existence, move to new locations and terminate. Templin Expires November 11, 2007 [Page 6] Internet-Draft IPvLX May 2007 Given these assumptions, the global DNS provides IPvLX nodes with a means for determining the next IPv6 hop toward the final destination (i.e., the ETR). In particular, for a destination FQDN: "peer.example.com", IPvLX nodes assume that the name of the ETR is formed by concatenating the well-known prefix "isatap" with the FQDN suffix, e.g., "isatap.example.com" [RFC4214]. Following next-hop resolution, the address of the final destination can be determined by consulting the next-hop's site-specific local name resolution service. 6. Autoconfiguration IPvLX nodes serve as SBRs through which all packets entering or leaving the site must pass. At startup time, or when moving to a new link, IPvLX nodes should automatically discover (e.g., via DHCP) an IPv4 address and domain name associated with at least one upstream interface. They should then discover SBRs on upstream interfaces by resolving the FQDN "isatap.example.com" within each upstream site's name service and sending IPv6-in-IPv4 encapsulated Router Solicitations (RSs) to elicit Router Advertisements (RAs) as specified in [RFC4214]. They should also configure supporting services (e.g., DHCP [RFC2131][RFC3315][RFC3633], DNS server, etc.) and advertise themselves for discovery by nodes on downstream interfaces by configuring an entry for themselves in the downstream site's ISATAP Potential Router List (PRL). IPvLX nodes also serve as SBRs for sites connected on their downstream interfaces to enable recursively-nested sites-within-sites ("it's turtles all the way down" [RFC1992]). IPvLX nodes that do not receive IPv6 address assignments and/or prefix delegations through an autoconfiguration mechanism should configure unique local addresses [RFC4193]. They can then (optionally) downstream-delegate portions of those prefixes to other IPvLX nodes and/or advertise them for stateless address autoconfiguration on attached IPv6 devices. IPvLX nodes should register themselves as potential ETRs via secure, dynamic updates to the global DNS [RFC2136][RFC4033]. The names should be formed from concatenating the prefix "isatap" and a FQDN suffix for one of the IPvLX node's upstream interfaces, e.g., "isatap.example.com". The addresses must be ISATAP addresses that include an IPv6 prefix served by the IPvLX node with an embedded global IPv4 address of an EBR, and are registered as AAAA records in the DNS. All IPvLX nodes within a site should respond to local-scope name-to-IPv6 address resolution requests for the downstream IPv6 endpoints they connect, e.g., via a mechanism such as LLMNR. IPvLX nodes should provide basic packet forwarding services if Templin Expires November 11, 2007 [Page 7] Internet-Draft IPvLX May 2007 possible within constraints such as memory, battery power, RF link quality, etc. IPvLX nodes that connect to links with asymmetric reachability characteristics should also engage in a MANET routing protocol (e.g., [I-D.ietf-manet-dymo][I-D.ietf-manet-olsrv2]) as well as a distributed site-scoped multicast flooding service (e.g., SMF [I-D.ietf-manet-smf]). 7. Virtual Link Extension When an application initiates a connection with a target peer in a remote site, it resolves a FQDN to get back a set of addresses. Applications should prefer and use IPv4 addresses whenever they are available, since packets can be sent directly without using the virtual link extension mechanisms specified in this section. When no IPv4 addresses are available, IPv6 addresses must be discovered and a virtual link (VL) must be established between an ITR and an ETR before packets can flow (note that an existing VL between an ITR and ETR may be used if one is already available). Packets can then be forwarded toward the target peer across the VL (which may extend across many IPv4 networks) as long as IPvLX nodes in the path behave as follows: 7.1. Mapping and VL Establishment Applications resolve FQDNs (e.g., "peer.example.com") via an on-link IPvLX node that acts as both a (default) router and a DNS server on that link, but also acts as an ordinary DNS recursive resolver on an upstream interface. The IPvLX node resolves the FQDN locally as a server if possible; otherwise, it resolves the FQDN as a client of an upstream DNS server. If the name resolution returns A records with IPv4 addresses, the application can connect directly to the peer using IPv4 instead of IPv6. Otherwise, the following mapping and VL establishment operations are performed: 7.1.1. Forward Mapping If no A records for the FQDN are returned when the IPvLX node attempts to resolve the FQDN "peer.example.com", it next tries to discover an ETR for the target by resolving the FQDN "isatap.example.com". If the DNS returns a set of AAAA records, the IPvLX node considers them as ISATAP addresses with an IPv6 prefix corresponding to the ETR and an IPv4 address corresponding to an EBR for the ETR's enterprise embedded in the interface identifier. It then creates IPv6 routing table entries for the /64 prefixes carried in the ISATAP addresses. Each routing table entry points to the VL and has as its next hop a link-local ISATAP address that embeds an Templin Expires November 11, 2007 [Page 8] Internet-Draft IPvLX May 2007 IPv4 address of an EBR, i.e., so that the unidirectional forward VL toward the ETR is established. Next, the IPvLX node (acting as an ITR) prepares an IPvLX- encapsulated (see: Section 7.2) IPv6 Node Information Query (NI Query) [RFC4620] to be sent to the ETR. The body of the message includes an ICMP Type 139 (NI Query), Code 1 (Data field contains name), Qtype 3 (Node Addresses), Flags set to TBD to indicate Unique Local Addresses, an appropriate Nonce value, and the FQDN "peer.example.com" in the data field. The following addresses are included in the IPv6 and IPv4 headers: o in the IPv6 source address, an IPv6 address assigned to an interface of the ITR that is connected to the same link as the application o in the IPv6 destination address, the ISATAP address for the ETR as returned by the DNS o in the IPv4 source address, the same as for ([RFC4213], Section 3.5) o in the IPv4 destination address, the global IPv4 address embedded in the ISATAP address The ITR then sends the IPvLX-encapsulated NI Query using IPv4 routing based on the IPv4 destination address, which will direct the query to an EBR for the peer's enterprise. 7.1.2. Reverse Mapping When an ITR's NI Query arrives at an EBR, IPvLX nodes on the path to the ETR use IPv6 routing within the peer's site based on the destination address in the encapsulated IPv6 header, which will direct the query to the ETR. When the ETR receives the NI Query, it resolves the FQDN "peer.example.com" in its site-local name resolution service (e.g., LLMNR) to obtain a set of AAAA records. It then creates an IPv6 routing table entry for the /64 prefix carried in the NI Query IPv6 source address that points to the VL and has as its next hop a link-local ISATAP address that embeds the NI Query's IPv4 source address, i.e., so that the unidirectional reverse VL toward the ITR is established without the need for an explicit reverse mapping. Templin Expires November 11, 2007 [Page 9] Internet-Draft IPvLX May 2007 Next, the ETR returns an IPvLX encapsulated (see: Section 7.2) IPv6 Node Information Query reply (NI Reply) to the ITR. The message should include an ICMP Type 140 (NI Reply), Code 0 (indicates successful reply), Qtype 3 (Node Addresses), Flags set to TBD to indicate Unique Local Addresses, the Nonce value that was supplied in the NI Query, and a set of zero or more IPv6 addresses in the data field that were returned in the AAAA records from the site-local name resolution of "peer.example.com". The following addresses are included in the IPv6 and IPv4 headers: o in the IPv6 source address, the IPv6 destination address from the NI Query o in the IPv6 destination address, the IPv6 source address from the NI Query o in the IPv4 source address, the same as for ([RFC4213], Section 3.5) o in the IPv4 destination address, the IPv4 source address from the NI Query When the ITR receives the NI Reply with IPv6 addresses, it wraps the IPv6 addresses in DNS AAAA resource records and returns them to the application as though it were responding as an ordinary DNS server. 7.1.3. VL Confidentiality using IKE and IPSec Following the forward and reverse mapping and VL establishment phases described above, the ITR and ETR can optionally perform an IKE exchange to establish IPSec security associations as described in "Using IPSec to Secure IPv6-in-IPv4 Tunnels" [I-D.ietf-v6ops-ipsec-tunnels]. 7.1.4. Referrals Some applications rely on referrals in which a broker informs a correspondent node of a third party to contact. When such referrals include an FQDN for the third party, mapping and VL establishment are performed exactly as in the above subsections. It is FFS whether referrals that include an IP address for the third party (instead of a FQDN) can be easily accommodated. Templin Expires November 11, 2007 [Page 10] Internet-Draft IPvLX May 2007 7.2. Encapsulation and Link Adaptation 7.2.1. IPvLX Encapsulation As for ordinary IPv4 NATs, IPvLX nodes determine the IPv4 addressing plans for their downstream-attached sites, which may include IPvLX nodes that in turn determine the IPv4 addressing plans in child sites. Since these recursively-nested IPv4 addressing plans may be topologically disjoint, IPvLX nodes must rewrite certain packet header fields to relay/proxy the packets they forward between sites. To support this header rewriting, IPvLX nodes use a special form of encapsulation ("IPvLX encapsulation") that encapsulates IPv6 packets in IPv4 datagrams as for standard IPv6-in-IPv4 encapsulation [RFC4213] except that an IPvLX flow header is inserted between the IPv4 header and the IPv6 header. The IPvLX flow header provides a virtual circuit identifier that labels the flow, and forwarding capabilities between labeled waypoints via an optional MPLS Label Stack [RFC3031][RFC3032] as shown below: +-------------------------------+ | | ~ IPv6 Packet (variable length) ~ | | +-------------------------------+ | | ~ MPLS Label Stack (variable ~ | length; multiples of 4 bytes) | +-------------------------------+ | IPvLX Flow Header (4/8 bytes) | +-------------------------------+ | | | IPv4 Header (20 bytes) | | | +-------------------------------+ IPvLX Packet Format When an IPvLX node sends/forwards/receives an IPvLX encapsulated packet, it treats the IPvLX Flow Identifier in the flow header as a Virtual Circuit (VC) number similar to that used for ATM [RFC2492]. The Flow Identifier is initialized by the ITR, and may be modified by intermediate IPvLX nodes on the path. Additionally, an MPLS label stack may be inserted by the ITR and may be modified by intermediate IPvLX nodes on the path. The IPvLX Flow Header is sufficiently similar to an MPLS label stack entry [RFC3032] in terms of size and configuration such that it would Templin Expires November 11, 2007 [Page 11] Internet-Draft IPvLX May 2007 be desirable to engineer it as part of the MPLS label stack instead of as a separately defined entity, e.g., by specifying a spare bit in the MPLS label stack entry to indicate: "IPvLX Flow Header". In that case, the Protocol field in the IPv4 header could be set to the IP protocol number assigned for MPLS encapsulation in IP [RFC4023]. Other IPvLX Flow Header encapsulation alternatives are discussed in Appendix A, and a comparison of IPvLX with Teredo [RFC4380] is given in Appendix B. 7.2.2. IPvLX Interface MTU and IPvLX Link Adaptation All IPv6 interfaces are required to support the IPv6 minimum MTU of 1280 bytes (and should support larger MTUs if possible) while all IPv4 interfaces should avoid unnecessary fragmentation in the IPv4 Internet [FRAG]. IPvLX interfaces therefore use the link adaptation scheme specified in [I-D.templin-linkadapt] (which is similar to both ATM Adaptation Layer 5 [RFC2684] and IEEE 802.11 MAC Sublayer Fragmentation [WLAN]) to segment IPvLX-encapsulated IPv6 packets into chains of IPv4 packets no larger than the IPv4 path MTU. 7.2.3. IPv6 Fragmentation and Reassembly IPv6 endpoints can use host-based IPv6 fragmentation (e.g., by setting the "USE_MINIMUM_MTU" socket option [RFC3542]) to avoid ICMPv6 "packet too big" messages. Since IPvLX link adaptation provides an edge-to-edge checksum [I-D.templin-linkadapt], IPv6 reassembly implementations can provide improved robustness and efficiency (e.g., for applications that use UDP-Lite [RFC3828]) by replacing any missing IPv6 fragments with replicated data from IPv6 fragments received in valid IPvLX packet chains rather than discarding the entire packet. 7.2.4. Header Compression The initial packet for a flow must include a full IPv6 header ([RFC2460], Section 3) to allow IPvLX nodes along the path to the destination to initialize flow state. Subsequent packets in the flow may omit the IPv6 header and instead encode the same protocol value that would have appeared in the IPv6 "Next Header" field in the IPvLX Flow Header. IPvLX encapsulated IPv6 neighbor discovery messages must not omit the IPv6 header. Compression methods for additional upper-layer protocol headers and/or IPv6 options beyond the IPv6 header are out of scope, but may be specified in other documents. Templin Expires November 11, 2007 [Page 12] Internet-Draft IPvLX May 2007 7.3. Virtual Link Traversal 7.3.1. From the ITR to the Target EBR When an intermediate IPvLX node along the path from the ITR to the target's EBR receives an IPvLX packet for a new IPvLX Flow, it creates a flow state entry with a lifetime value as specified in [RFC3697]. When it forwards the packet across site boundaries, the IPvLX node also rewrites the IPvLX packet's IPv4 source address with an address selected as for ([RFC4213], Section 3.5) and rewrites the Flow Identifier (FI) to a unique value for the new IPv4 source and original IPv4 destination addresses. (The IPv4 header checksum is also recalculated and rewritten, but the IPv4 destination address is not rewritten since it already provides the topologically-correct address necessary to direct the packet toward the target EBR.) Intermediate IPvLX node flow state entries store the mapping from: (FI(in), IPv4_src(in), IPv4_dst(in)) to: (FI(out), IPv4_src(out), IPv4_dst(out)) during a flow's lifetime. They use the mapping to forward both non-initial packets and ICMPv4 error messages (see: Section 8) for the flow. (Note that this flow state is analogous to the session state maintained by IPv4 NATs.) The ITR stores the flow identification information along with the IPv6 source and destination addresses to identify the flow's endpoints. 7.3.2. From the Target EBR to the ETR For the initial IPvLX packets for an IPvLX Flow that arrive at an EBR, each intermediate IPvLX node along the path toward the ETR should examine the encapsulated IPv6 packet headers and use some form of static/dynamic IPv6 route discovery to determine the next hop IPvLX node among those connected on downstream links. (Possible route discovery mechanisms include static prefix delegations, routes learned via dynamic routing protocols, etc.) Intermediate IPvLX nodes should not decapsulate the packet (unless they are configured to act as an IPv6 router for this particular IPvLX Flow), but instead relay the packet to the next hop IPvLX node via IPv4, leaving the "Hop Limit" field in the IPv6 header unchanged. The ETR is the last hop IPvLX node in the path, which decapsulates the packet and may also perform firewall/filtering functions. To support this relaying, when an intermediate IPvLX node along the path from the EBR to the ETR receives an IPvLX packet for a new IPvLX Flow, it creates a flow state entry with a lifetime value as specified in [RFC3697]. When it forwards the packet across site boundaries, the IPvLX node also rewrites the IPv4 destination address Templin Expires November 11, 2007 [Page 13] Internet-Draft IPvLX May 2007 to the IPv4 address of the next hop IPvLX node, rewrites the IPvLX packet's IPv4 source address with an address selected as for ([RFC4213], Section 3.5), and rewrites the Flow Identifier (FI) to a unique value for the new IPv4 source and destination addresses. (The IPv4 header checksum is also recalculated and rewritten.) Intermediate IPvLX node flow state entries store the mapping from: (FI(in), IPv4_src(in), IPv4_dst(in)) to: (FI(out), IPv4_src(out), IPv4_dst(out)) during a flow's lifetime. They use the mapping to forward both non-initial packets and ICMPv4 error messages (see: Section 8) for the flow. (Note that this flow state is analogous to the session state maintained by IPv4 NATs.) The ETR stores the IPvLX Flow identification information along with the IPv6 source and destination addresses to identify the flow's endpoints. 7.4. MPLS Label Switching IPvLX nodes forward IPvLX packets to the next-hop Label Switching Router (LSR) [RFC3031] within the MPLS Domain as told by the MPLS label stack carried in each packet. In the case of IPvLX Flows that span the global IPv4 Internet, the MPLS domain could include the entire IPv4 Internet and the MPLS label stack could be used to direct the order of autonomous systems the packet will traverse en-route to the enterprise containing the final destination. 8. Error Handling IPvLX nodes may receive valid ICMPv4 messages that include an outer IPv4 header with the IPv4 source address of the IPv4 node reporting the error, an inner IPv4 header from the IPvLX packet-in-error, and at least the first 8 bytes of the encapsulated IPv6 packet segment including the IPvLX flow header. The intermediate node must arrange for the error message to be directed toward the ITR that originated the packet-in-error. However, it may not always be possible to walk the chain of previous-hop IPvLX nodes backward from a point in the middle of a VL, e.g., when a stack of MPLS labels was used to steer the packet through a number of intermediate waypoints. Since reverse path forwarding from within the (unidirectional) VL is not always possible, an intermediate IPvLX node must encapsulate the ICMPv4 message within IPvLX and send it forward toward the ETR. The ETR must then recognize the ICMPv4 message as an error that occurred within the VL, and return a suitable error message back to the ITR (see also: [I-D.templin-linkadapt]). Templin Expires November 11, 2007 [Page 14] Internet-Draft IPvLX May 2007 9. Mobility When an IPvLX node moves to a new site within its home enterprise, it will receive new IPv4 autoconfiguration information and discover new upstream SBRs. But, it should be able to retain its IPv6 address/ prefix delegations such that localized mobility management is handled seamlessly by network-based mechanisms (e.g., a routing protocol) within the enterprise. When an IPvLX node moves to a different enterprise, however, it must inform a rendezvous server in its home enterprise of the move, since the DNS service cannot be updated on the granularity of node mobility. For Mobile IPv6 [RFC3775], a rendezvous server capability is manifested by the MIPv6 Home Agent, while HIP [RFC4423] defines its own rendezvous server capability. Rendezvous server capability for IPvLX are FFS. 10. IPv4 Backward Compatibility In such instances, IPv6 only endpoints may require IPv4 backward- compatibility services in upstream IPvLX nodes such as [DSTM]. 11. IANA Considerations This document introduces no IANA Considerations. 12. Security Considerations IPvLX nodes use the securing mechanisms for IPv6 nodes found in ([RFC4294], Section 8). IPvLX sites need Network Architecture Protection [I-D.ietf-v6ops-nap] to protect people and assets from harmful communications. Firewalls on all IPvLX nodes are therefore needed. These firewalls may be host-specific (such as when the IPvLX node resides on an end host), but host-specific firewalls may not be feasible on small devices. In any case, hosts which are not able to configure host-specific firewalls must be deployed behind IPvLX nodes that do. 13. Acknowledgments This work has benefited from helpful discussions with many colleagues, friends and family; recent discussions in the IETF RAM and IRTF RRG groups have been particularly helpful. Templin Expires November 11, 2007 [Page 15] Internet-Draft IPvLX May 2007 14. Appendix A: Other Encapsulation Alternatives Another possible construct for use as an IPvLX flow header is an IPv4 option. IPv4 options are variable length, and can accommodate more than one waypoint (i.e., as for IPv4 strict/loose source and record route). But, IPv4 options have the disadvantage that the first 16- bits of the option are consumed by bookkeeping bits that are essentially "bricks" in the packet's "knapsack" as it traverses the VL. A more significant disadvantage is that IPv4 options need to be examined by all IPv4 forwarding nodes in the path, including those in legacy sections of the infrastructure, which can cause slow path processing. UDP/IPv4 encapsulation has the distinct advantage that it works over unmodified IPv4 NAT boxes. In comparison with the other alternatives, it has the disadvantage that 6 of the 8 bytes of the UDP header are "bricks in the knapsack". Also, only 16-bits (the UDP source port) are available for encoding a Flow Identifier, and multiple nested UDP encapsulations would be necessary to simulate an MPLS label stack. 15. Appendix B: Comparison with Teredo If the UDP encapsulation specified for Teredo [RFC4380] were used instead of IPvLX encapsulation, the considerations discussed in this document would apply in a corresponding fashion except that the 16- bit UDP source port would be used as a per-hop flow designator instead of the IPvLX flow identifier, and classical IPv4 NATs would be used instead of IPvLX nodes. As such, this document can in some sense be viewed as an informational/applicability overview for Teredo. Using Teredo, the number of distinct flows that can be supported are limited due to the 16-bit UDP source port, and recursively nested sites-within-sites (i.e., recursively-nested NATs) may be somewhat more difficult to achieve in practice. Still, Teredo provides the option to support peer-to-peer operation between end systems located behind legacy NATs in the current IPv4 Internet infrastructure before true IPvLX nodes become widely deployed. From an idealistic standpoint, Teredo would seem to offer an opportunity for large scale incremental deployment. For example, Microsoft Windows Vista ships with Teredo enabled by default such that end-to-end operations between IPv6 peers can be supported with no changes to the network. From a practical standpoint, however, this places a new security burden on the end systems. The security would then be limited to the quality of any host-specific firewalls Templin Expires November 11, 2007 [Page 16] Internet-Draft IPvLX May 2007 on the end systems, which end users might not know how to configure or might not even be aware of. A more pressing concern would be unscrupulous "vendors" concealing a technology similar to Teredo (e.g., in a routine patch distribution) which opens holes in NATs to expose end-user devices that were previously hidden due to the opaque nature of the NAT's private IPv4 addressing domain. This could allow the unscrupulous vendors to do harmful things such as locate end-users, take control of end-users devices, turn off end-users devices, etc. In light of the above, the Teredo specification provides the necessary contribution of sensitizing the community to the false sense of security afforded by IPv4 NATs and underscores the need for Network Architecture Protection [I-D.ietf-v6ops-nap] in IPv6 end systems and networks. This is particularly true now that Teredo is shipping as on-by-default in widely-deployed implementations. 16. Appendix C: Changes (Note to RFC Editor - please delete this section before publication as an RFC.) Changes since -07: o Rephrased as an architecture document (as oposed to specification) o Defined scope in Introduction o Updated acknowledgements Changes since -06: o Simplified and clarified text by introducing ITR/ETR/EBR/SBR terminology o Replaced RS/RA mapping mechanism with NI Query/Reply o introduced identifier/locator split terminology o numerous other clarifications/updates Changes since -04, -05: o updated references Changes since -03: Templin Expires November 11, 2007 [Page 17] Internet-Draft IPvLX May 2007 o minor wording changes in Addressing, DNS and Autoconfiguration sections o simplified sections on encapsulation and link adaptation o minor wording changes in appendix B 17. References 17.1. Normative References [I-D.templin-linkadapt] Templin, F., "Link Adaptation for IPv6-in-(foo)-in-IPv4 Tunnels", draft-templin-linkadapt-05 (work in progress), May 2007. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005. 17.2. Informative References [DSTM] Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism (DSTM)", draft-bound-dstm-exp (work in progress), October 2005. [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful, In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology.", August 1987. [I-D.farinacci-lisp] Templin Expires November 11, 2007 [Page 18] Internet-Draft IPvLX May 2007 Farinacci, D., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-00 (work in progress), January 2007. [I-D.ietf-autoconf-manetarch] Chakeres, I., "Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-01 (work in progress), March 2007. [I-D.ietf-manet-dymo] Perkins, C. and I. Chakeres, "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-09 (work in progress), May 2007. [I-D.ietf-manet-olsrv2] Clausen, T., "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007. [I-D.ietf-manet-smf] Macker, J., "Simplified Multicast Forwarding for MANET", draft-ietf-manet-smf-04 (work in progress), March 2007. [I-D.ietf-v6ops-ipsec-tunnels] Savola, P., "Using IPsec to Secure IPv6-in-IPv4 Tunnels", draft-ietf-v6ops-ipsec-tunnels-05 (work in progress), January 2007. [I-D.ietf-v6ops-nap] Velde, G., "Local Network Protection for IPv6", draft-ietf-v6ops-nap-06 (work in progress), January 2007. [I-D.wang-ietf-efit] Massey, D., "A Proposal for Scalable Internet Routing & Addressing", draft-wang-ietf-efit-00 (work in progress), February 2007. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. [RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996. Templin Expires November 11, 2007 [Page 19] Internet-Draft IPvLX May 2007 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999. [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. Templin Expires November 11, 2007 [Page 20] Internet-Draft IPvLX May 2007 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006. [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007. [WLAN] Society, I., "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Computer Society, ANSI/IEEE 802.11, 1999 Edition.". Author's Address Fred L. Templin (editor) Boeing Phantom Works P.O. Box 3707 Seattle, WA 98124 USA Email: fred.l.templin@boeing.com Templin Expires November 11, 2007 [Page 21] Internet-Draft IPvLX May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Templin Expires November 11, 2007 [Page 22]