Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Standards Track October 23, 2006 Expires: April 26, 2007 IPvLX - IP with virtual Link eXtension draft-templin-ipvlx-06.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 April 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The IPv6 128-bit addressing architecture was designed as a successor for IPv4. But, IPv4 deployment in the global Internet continues via private addressing domains behind Network Address Translators (NATs) such that long-term coexistence with IPv6 addressing and minimal perturbation of IPv4 networks is emerging as the dominant strategy. This document proposes a long-term IPv6/IPv4 coexistence scheme called: IPvLX - IP with virtual Link Extension. Templin Expires April 26, 2007 [Page 1] Internet-Draft IPvLX October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Addressing and Routing Assumptions . . . . . . . . . . . . . . 5 4. DNS Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 5. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 6 6. Encapsulation and Link Adaptation . . . . . . . . . . . . . . 7 6.1. IPvLX Encapsulation . . . . . . . . . . . . . . . . . . . 7 6.2. IPvLX Interface MTU and IPvLX Link Adaptation . . . . . . 9 6.3. IPv6 Fragmentation and Reassembly . . . . . . . . . . . . 9 6.4. Header Compression . . . . . . . . . . . . . . . . . . . . 9 7. Virtual Link Extension . . . . . . . . . . . . . . . . . . . . 9 7.1. Virtual Link Establishment . . . . . . . . . . . . . . . . 10 7.2. Virtual Link Confidentiality . . . . . . . . . . . . . . . 11 7.3. Virtual Link Traversal . . . . . . . . . . . . . . . . . . 12 7.3.1. From the Encapsulator to the Target Enterprise/Site Border . . . . . . . . . . . . . . . . 12 7.3.2. From the Target Enterprise/Site Border to the Decapsulator . . . . . . . . . . . . . . . . . . . . . 12 7.4. MPLS Label Switching . . . . . . . . . . . . . . . . . . . 13 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. IPv4 Backward Compatibility . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 14. Appendix A: Other Encapsulation Alternatives . . . . . . . . . 15 15. Appendix B: Comparison with Teredo . . . . . . . . . . . . . . 15 16. Appendix C: Changes . . . . . . . . . . . . . . . . . . . . . 16 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17.1. Normative References . . . . . . . . . . . . . . . . . . . 17 17.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Templin Expires April 26, 2007 [Page 2] Internet-Draft IPvLX October 2006 1. Introduction The IPv6 128-bit addressing architecture was designed as a replacement solution for the 32-bit limitation of IPv4 and offers the promise of scalable end to end addressing. But the proliferation of IPv4 in the global Internet continues via private addressing domains behind Network Address Translators (NATs) [RFC1918][RFC2993]. Therefore, use of IPv6 for addressing with minimal perturbation of IPv4 networks is emerging as the dominant long-term transition and coexistence strategy. This document proposes IPvLX (IP with virtual Link eXtension) with goals of fostering growth and restoring global transparency for peer- to-peer communications. The scheme uses IPv6 for addressing and simple network middleboxes (which are really just IPv4 NATs with minor enhancements) to extend secure IP virtual links (VLs) across one or more IPv4 networks. In this way, IPv6 is seen as an addressing protocol used to establish and control virtual links while IPv4 is seen as a link layer (L2) protocol for carrying L3 data packets. 2. Terminology The terminology of [RFC4214][RFC2460][RFC2461] applies to this document. The following additional terms are defined: logical interface: the same as defined in ([RFC1122], section 3.3.4.1). site: the same as defined in ([RFC4214], section 3). enterprise: a network entity that contains one or more sites and has zero or more border gateways connected to the global IPv4 Internet. virtual link (VL): a path over which IPv4-encapsulated L3 packets can be forwarded between an encapsulating and decapsulating node separated by potentially many IPv4 networks without the Hop Limit field in the L3 header being decremented. Templin Expires April 26, 2007 [Page 3] Internet-Draft IPvLX October 2006 IP with virtual Link eXtension (IPvLX): mechanisms and operational practices (described in this document) used by IPvLX nodes to extend VLs across enterprise/site boundaries. IPvLX virtual links are edge-to-edge between two routers, as for VPNs. IPvLX node: an ISATAP node ([RFC4214], section 3) that supports IPvLX. IPvLX nodes also serve as IPv6 routers for co-located IPv6 endpoints and endpoints on attached IPv6-only links. IPvLX nodes that support IPv6 endpoints are IPvLX gateways. IPvLX gateway: an IPvLX node that provides hybrid routing/bridging/firewalling capabilities and determines the addressing plans for its associated hosts. IPvLX gateways occur in exactly the same topological locations as would an IPv4 NAT, and are really nothing more than IPv4 NATs with minor enhancements. Enterprise border IPvLX gateways occur in exactly the same topological locations as 6to4 routers [RFC3056]. associated host: an IPvLX node or IPv6-only node that associates with a parent IPvLX gateway. IPvLX nodes that are associated hosts within parent sites can also serve as IPvLX gateways for their own associated hosts in child sites. IPvLX interface: an IPvLX node's IPv6 interface that transmits Upper Layer Payloads (ULPs) as chains of IPv4 packets using IPvLX encapsulation and link adaptation. IPvLX encapsulation: a method for encapsulating segments of ULPs over IPv4 as the Layer 2 (L2) protocol. IPvLX packet: an IPv4 packet created using IPvLX encapsulation and link adaptation. Templin Expires April 26, 2007 [Page 4] Internet-Draft IPvLX October 2006 (IPvLX) link adaptation: a link layer mechanism specified in [ADAPT] that segments ULPs into chains of IPv4 packets for later reassembly during decapsulation, e.g., to satisfy path MTU restrictions, etc. 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 in each IPvLX packet header. Each flow provides a logical interface for IPvLX. IPvLX Flow Identifier: a value encoded in the IPvLX Flow Header that identifies a flow and may be modified by IPvLX gateways on the path. IPvLX Flow Header: a "Layer 2.5 shim" header immediately following the 20-byte IPv4 header in IPvLX packets. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Addressing and Routing Assumptions While IPv4 addresses in the current Internet are typically assigned to devices, IPvLX assumes that IPv6 addresses will also be assigned to application endpoints and data objects [NAME]. This new model would provide greater flexibility such that each end-node might host many different IPv6 application endpoints and data objects, and that those entities could migrate to other end-nodes. In this model, each IPv6 addressable entity would access other endpoints via an IPv6 router. IPvLX sees IPv6 routers as logical forwarding engines that can reside within both network middleboxes and end computing devices. They provide a nexus for forwarding packets on behalf of their own IPv6 addresses as well as for IPv6 addresses that reside within sites for which they serve as gateways. Even if forwarding occurs between IPv6 addresses within the same physical box, the net effect is still that of IPv6 routing. IPv6 routers terminate links instead of providing transit for the link as a bridge would do, therefore IPv6 routers occur at the near and far end IPvLX gateways of all VLs as the Templin Expires April 26, 2007 [Page 5] Internet-Draft IPvLX October 2006 logical points of termination. 4. 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 IPvLX gateways to provide tunnel endpoint addresses - 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]) 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 assumes 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. Given these assumptions, the global DNS provides IPvLX gateways with a means for determining the next IPv6 hop toward the final destination. In particular, for a destination FQDN: "peer.example.com", IPvLX assumes that the name of the next-hop toward the destination will be formed by concatenating a well-known prefix 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. 5. Autoconfiguration IPvLX gateways provide the border points of reference for forming enterprise/site networks; they also serve as the border gateways through which all packets entering or leaving the enterprise/site must pass. Therefore, at startup time (or when moving to a new link) interior IPvLX gateways should automatically associate with a parent IPvLX gateway and automatically discover DNS recursive name servers on at least one outward-facing interface. They should also configure supporting services (e.g., DHCPv4 [RFC2131], DHCPv6 [RFC3315][RFC3633][RFC3736], Mobile IPv6 Home Agent [RFC3775], DSTM border router and server [DSTM], etc.) and advertise themselves for discovery by associated hosts on inward-facing interfaces, e.g., by advertising the 6to4 Relay anycast prefix ([RFC3068], section 2.3). Templin Expires April 26, 2007 [Page 6] Internet-Draft IPvLX October 2006 IPvLX nodes within an enterprise/site also provide site border gateways for their own associated hosts on inward-facing interfaces to enable recursively-nested "sites within sites". IPvLX nodes that do not receive IPv6 address assignments and/or prefix delegations through an autoconfiguration mechanism should configure unique local address prefixes [RFC4193]. They can then (optionally) downstream- delegate portions of those prefixes to associated IPvLX gateways and/or advertise them for address autoconfiguration on associated hosts. IPvLX gateways that do not move and/or change their addresses frequently should register name-to-address mappings for themselves via secure, dynamic updates to the global DNS [RFC2136][RFC4033]. The names should be formed from a well-known prefix and a FQDN suffix for one of the IPvLX gateway's outward facing interfaces, e.g., "isatap.example.com" [RFC4214]. The addresses should include A records with global IPv4 address(es) of border gateways for the IPvLX gateway's enterprise, and AAAA records with global IPv6 address(es) for the IPvLX gateway itself. All IPvLX nodes within an enterprise/ site should respond to local-scope name-to-IPv6 address resolution requests for the application endpoints they support, e.g., via a mechanism such as [LLMNR]. IPvLX nodes should provide basic packet forwarding services if possible within constraints such as memory, battery power, RF link quality, etc. They should also use efficient dynamic route discovery protocols, e.g., a hybrid combination of IETF MANET protocols [RFC3561][RFC3626][RFC3684][DSR][DYMO]. Unification of a hybrid MANET protocol and efficient flooding mechanism with existing routing/bridging protocols (e.g., OSPF [RFC2740], IS-IS [RFC1142], IEEE 802.1D spanning tree [STP], etc.) is currently under investigation within the IETF community. 6. Encapsulation and Link Adaptation 6.1. IPvLX Encapsulation As for ordinary IPv4 NATs, IPvLX gateways determine the IPv4 addressing plans for their associated hosts, which can in turn serve as IPvLX gateways that determine the IPv4 addressing plans for their own associated hosts in child sites. Since these recursively-nested IPv4 addressing plans may be topologically disjoint, IPvLX gateways 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 upper layer Templin Expires April 26, 2007 [Page 7] Internet-Draft IPvLX October 2006 payloads (ULPs) in IPv4 datagrams as for standard IPv6-in-IPv4 encapsulation [RFC4213] except that an IPvLX flow header (i.e., a "layer 2.5 shim" header) is inserted between the IPv4 header and the ULP. 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: +-------------------------------+ - | | \ ~ ULP Payload (variable length) ~ } Layer 3 | | / +-------------------------------+ - | | \ ~ MPLS Label Stack (variable ~ | | length; multiples of 4 bytes) | } Layer 2.5 +-------------------------------+ | | IPvLX Flow Header (4/8 bytes) | / +-------------------------------+ - | | \ | IPv4 Header (20 bytes) | } Layer 2 | | / +-------------------------------+ - 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 first IPvLX gateway on the path, and may be modified by intermediate IPvLX gateways on the path. Additionally, an MPLS label stack may be inserted by the encapsulating IPvLX node and may be modified by intermediate IPvLX gateways 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 be desireable 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 layer 2.5 encapsulation alternatives are discussed in Appendix A and a comparison of IPvLX with TEREDO [RFC4380] is given in Appendix B. Templin Expires April 26, 2007 [Page 8] Internet-Draft IPvLX October 2006 6.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 [ADAPT] (which is similar to both ATM Adaptation Layer 5 [RFC2684] and IEEE 802.11 MAC Sublayer Fragmentation [WLAN]) to segment ULP payloads into chains of IPvLX packets no larger than the IPv4 path MTU. 6.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 [ADAPT], 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. 6.4. Header Compression The initial packet for a flow MUST include a full IPv6 header ([RFC2460], section 3) to allow IPvLX gateways 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 ULP headers and/or IPv6 options beyond the IPv6 header are out of scope, but MAY be specified in other documents. 7. Virtual Link Extension When an IPv6 endpoint initiates a connection with a target peer in a remote site, a virtual link (VL) must be established between local and remote IPvLX gateways before packets can flow. The packets can then be forwarded toward the target peer across a VL extended across many IPv4 networks as long as IPvLX gateways in the path behave as follows: Templin Expires April 26, 2007 [Page 9] Internet-Draft IPvLX October 2006 7.1. Virtual Link Establishment IPv6 application endpoints resolve FQDNs such as "peer.example.com" to obtain one or more IPv6 addresses via a first-hop IPvLX gateway acting as a recursive resolver. When the first hop IPvLX gateway resolves the FQDN, it first discovers an IPv6 router for the target by resolving a tunnel endpoint FQDN, e.g., "isatap.example.com". If the name service returns a set of AAAA records, the first hop IPvLX gateway can consider them as ISATAP addresses with an IPv6 prefix corresponding to the IPv6 router and an IPv4 address corresponding to the target's enterprise border embedded in the interface identifier. The first hop IPvLX gateway can then send IPvLX encapsulated IPv6 Router Solicitation messages to contact the IPv6 router with the following addresses: o in the IPv6 source address, a Cryptographically Generated Address (CGA) [RFC3972] with an IPv6 prefix for the initiating IPvLX gateway o in the IPv6 destination address, the ISATAP address for the target's IPv6 router 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 IPvLX encapsulated IPv6 Router Solicitation should include a Source Link Layer Address Option (SLLAO) ([RFC2461], section 4.6.1) with an embedded IPv4 unicast address ([RFC2529], section 5) associated with the solicitor, a Target Link Layer Address Option (TLLAO) (([RFC2461], section 4.6.1) with an embedded IPv4 unicast address that matches the IPv4 destination address, and SEND [RFC3971] parameters for CGA [RFC3972] proof-of-ownership verification. When the last hop IPvLX gateway before the target that terminates the VL receives the Router Solicitation, it should first rewrite the IPv4 unicast address embedded in the SLLAO with the IPv4 source address of the IPvLX encapsulated packet. It can then use SEND mechanisms to verify address ownership for the initiator. Next, it can send an IPvLX encapsulated Router Advertisement back toward the solicitor with the following addresses: Templin Expires April 26, 2007 [Page 10] Internet-Draft IPvLX October 2006 o in the IPv6 source address, a CGA [RFC3972] link-local address o in the IPv6 destination address, the IPv6 source address from the Router Solicitation o in the IPv4 source address, the same as for ([RFC4213], section 3.5) o in the IPv4 destination address, the (rewritten) IPv4 address embedded in the Router Solicitation's SLLAO, i.e., the link layer address in the Neighbor Cache The IPvLX encapsulated IPv6 Router Advertisement should include a SLLAO with an embedded IPv4 unicast address associated with the advertiser, a TLLAO with an embedded IPv4 unicast address that matches the IPv4 destination address, an MTU option ([RFC2461], section 4.6.4) that encodes the size of the IPvLX gateway's reassembly buffer, and SEND [RFC3971] parameters for CGA [RFC3972] proof-of-ownership verification and router certification. It should also include as many of the target's IPv6 addresses as possible in Route Information Options [RFC4191]. When the solicitor receives a Router Advertisement, it should first rewrite the IPv4 unicast address embedded in the SLLAO with the IPv4 source address of the IPvLX encapsulated packet. It can then discover the address of its own enterprise border by examining the embedded IPv4 address in the TLLAO and use SEND mechanisms to verify address ownership and router certificate chains. Following authorization, the soliciting IPvLX gateway can create IPv6 route cache entries with the link-local ISATAP address constructed from the IPv4 address in the Router Advertisement's (rewritten) SLLAO as the next hop toward the target's IPv6 addresses, and return the addresses to the initiating application endpoint. The application endpoint can then use IPv6 address selection rules to determine the best IPv6 source and destination addresses to choose for communications with the target [RFC3484]. 7.2. Virtual Link Confidentiality During VL establishment, the local and remote IPvLX gateways also arrange for the confidential exchange of packets across the link. This requires a key exchange protocol for establishing IPSec security associations allowing the local IPvLX gateway to encrypt packets sent Templin Expires April 26, 2007 [Page 11] Internet-Draft IPvLX October 2006 over the VL and for the remote IPvLX gateway to decrypt them. The Internet Key Exchange Protocol [RFC4306] is used for this purpose. 7.3. Virtual Link Traversal 7.3.1. From the Encapsulator to the Target Enterprise/Site Border When an intermediate IPvLX gateway along the path from the encapsulator to the target's enterprise/site border 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 into a topologically disjoint IPv4 addressing region, the IPvLX gateway 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 enterprise.) Intermediate IPvLX gateway 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 6) for the flow. (Note that this flow state is analogous to the session state maintained by IPv4 NATs.) The encapsulator 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 Enterprise/Site Border to the Decapsulator For the initial IPvLX packets for an IPvLX Flow that enter an enterprise/site, each intermediate IPvLX gateway along the path toward the decapsulator should examine the encapsulated IPv6 packet headers and use some form of static/dynamic IPv6 route discovery to determine the next hop IPvLX gateway among their associated hosts. (Possible route discovery mechanisms include static prefix delegations, routes learned via dynamic routing protocols, etc.) Intermediate IPvLX gateways 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 gateway via IPv4, leaving the "Hop Limit" field in the IPv6 header unchanged. The last hop IPvLX gateway in the path will be an IPv6 router before the target that decapsulates the packet. Note that the decapsulating gateway may perform firewall/filtering functions. Templin Expires April 26, 2007 [Page 12] Internet-Draft IPvLX October 2006 To support this relaying, when an intermediate IPvLX gateway along the path from the enterprise/site border to the decapsulator 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 into a topologically disjoint IPv4 addressing region, the IPvLX gateway also rewrites the IPv4 destination address to the IPv4 address of the next hop IPvLX gateway, 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 gateway 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 6) for the flow. (Note that this flow state is analogous to the session state maintained by IPv4 NATs.) The decapsulator 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 For IPvLX packets that include an MPLS label stack, enterprise/site border gateways make provisions to forward the packet to the Label Switching Router (LSR) [RFC3031] named at the top of the stack within the MPLS Domain. 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 Intermediate IPvLX gateways 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 gateway must arrange for the error message to be directed toward the IPvLX gateway at the head of the VL that originated the packet-in- error. However, it may not always be possible to walk the chain of previous-hop IPvLX gateways 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. Templin Expires April 26, 2007 [Page 13] Internet-Draft IPvLX October 2006 Since reverse path forwarding from within the VL is not always possible, the intermediate IPvLX gateway must encapsulate the ICMPv4 message within IPvLX and send it forward toward the IPvLX gateway that would have decapsulated the packet at the far end of the VL. The IPvLX gateway at the far end must then recognize the ICMPv4 message as an error that occurred within the virtual link, and return a suitable error message back to the gateway that originated the packet-in-error (see also: [ADAPT]). 9. Mobility When an IPvLX node moves to a different network point of attachment, it will receive new IPv4 autoconfiguration information and discover a new parent IPvLX gateway that potentially resides in a different enterprise. Upon reattachment, the mobile IPvLX node should send IPv6 Router Solicitation messages using secure neighbor discovery mechanisms [RFC3971][RFC3972] to its home enterprise border IPvLX gateway (i.e., its home 6to4 router) to update the router's neighbor cache and dynamic routing information in any intermediate IPvLX gateways. IPv6 nodes can use the features of Mobile IPv6 [RFC3775] to support movement to foreign enterprises or to different IPv6 prefix regions within the home enterprise. The Mobile IPv6 home agent function can be deployed on IPvLX gateways to support associated hosts that have moved to a different network point of attachment. Whether the binding update mechanisms of Mobile IPv6, or [ICMPv6] Redirect messages using secure neighbor discovery mechanisms [RFC3971][RFC3972] should be used to provide mobile node location updates to correspondent nodes is FFS. 10. IPv4 Backward Compatibility For the near term, there will be many instances in which DNS resolution for FQDNs such as "peer.example.com" will still return global IPv4 addresses, meaning that the peer can be reached directly via the global Internet. In such instances, IPv6 endpoints may require backward-compatibility services in upstream IPvLX gateways such as [DSTM] and NATPT [RFC2766]. 11. IANA Considerations This document introduces no IANA Considerations. Templin Expires April 26, 2007 [Page 14] Internet-Draft IPvLX October 2006 12. Security Considerations IPvLX gateways and associated hosts use the securing mechanisms for IPv6 neighbor discovery found in [RFC3971][RFC3972] and the securing mechanisms for IPv6 nodes found in ([NODEREQ], section 8). IPvLX sites need Network Architecture Protection [NAP] to protect people and assets from harmful communications. Firewalls on all IPvLX gateways are therefore needed. These firewalls may be host- specific (such as when the IPvLX gateway resides on an end host), but host-specific firewalls may not be feasible on small devices. In any case, hosts which are not know to configure host-specific firewalls MUST be deployed behind IPvLX gateways that do. 13. Acknowledgments This work documents the mindshare of many contributers. Similar proposals appear in [NDPROXY][PMTUD][RBRIDGE][VIRTUAL]. 14. Appendix A: Other Encapsulation Alternatives Another possibility for a layer 2.5 "shim" to encapsulate labels similar to MPLS 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, all considerations discussed in this document would apply in an identical fashion except that the 16-bit Templin Expires April 26, 2007 [Page 15] Internet-Draft IPvLX October 2006 UDP source port would be used as a per-hop flow designator instead of the IPvLX flow identifier and legacy IPv4 NATs would be used instead of IPvLX gateways. As such, this document can 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 hosts located behind legacy NATs in the current IPv4 Internet infrastructure before true IPvLX gateways become widely deployed. From an idealistic standpoint, Teredo would seem to offer an opportunity for immediate IPv6 flag-day rollout. For example, if a large end-host software vendor distributed a new major release (or a patch release for its already-deployed products) that enabled Teredo, peer-to-peer operations could commence immediately with no changes to the network. From a practical standpoint, however, this would place all of the security burden on the end-hosts with little/no protection from firewalls in the network. The security would then be limited to the quality of any host-specific firewalls on the end-nodes, 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 in a routine patch distribution with an ulterior motive of exposing end-user devices that were previously hidden behind the opaque (yet brittle) protection afforded as an unwarranted side-effect of IPv4 NATs. 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. Such "vendors" would essentially be using "TereDo" to "Do Terror", yet even without a published interoperability specification such as Teredo unscrupulous "vendors" could still roll out their own proprietary "terrorist tools" to exploit IPv4 NAT weaknesses. 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 underscoring the need for Network Architecture Protection [NAP] in IPv6. Whether it also provides a flag day deployment mechanism for IPv6 is beyond the scope of this document. 16. Appendix C: Changes Changes since -04, -05: Templin Expires April 26, 2007 [Page 16] Internet-Draft IPvLX October 2006 o updated references Changes since -03: 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 [ADAPT] Templin, F., "Link Adaptation for IPv6-in-IPv4 Tunnels", draft-templin-linkadapt (work in progress), September 2005. [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 [DSR] Johnson, D., Maltz, D., and Y. Hu, "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", draft-ietf-manet-dsr (work in progress), July 2004. [DSTM] Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism (DSTM)", draft-bound-dstm-exp (work in progress), Templin Expires April 26, 2007 [Page 17] Internet-Draft IPvLX October 2006 October 2005. [DYMO] Chakeres, I., Belding-Royer, E., and C. Perkins, "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo (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. [ICMPV6] Conta, A., Deering, S., and M. Gupta, ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3 (work in progress), July 2005. [LLMNR] Esibov, L., Aboba, B., and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", draft-ietf-dnsext-mdns (work in progress), October 2005. [NAME] Balakrishnan, H. and et. al., "A Layered Naming Architecture for the Internet, SIGCOMM 2004, Aug. 30 - Sep. 2, 2004.". [NAP] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Network Architecture Protection", draft-vandevelde-v6ops-nap (work in progress), October 2005. [NDPROXY] Thaler, D., Talwar, M., and C. Patel, "Bridge-like Neighbor Discovery Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy (work in progress), October 2005. [NODEREQ] Loughney, ed., J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements (work in progress), August 2004. [PMTUD] Mathis, M., Heffner, J., and K. Lahey, "Path MTU Discovery", draft-ietf-pmtud-method (work in progress), February 2005. [RBRIDGE] Perlman, R., Touch, J., and A. Yegin, "RBridges: Transparent Routing", draft-perlman-rbridge (work in progress), May 2005. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Templin Expires April 26, 2007 [Page 18] Internet-Draft IPvLX October 2006 [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [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. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999. [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [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. Templin Expires April 26, 2007 [Page 19] Internet-Draft IPvLX October 2006 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 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. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [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 Templin Expires April 26, 2007 [Page 20] Internet-Draft IPvLX October 2006 (UDP-Lite)", RFC 3828, July 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 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. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [VIRTUAL] Touch, J., Wang, Y., Eggert, L., and G. Finn, "Virtual Internet Architecture, Future Developments of Network Architectures (FDNA) at Sigcomm", August 2003. [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.". Templin Expires April 26, 2007 [Page 21] Internet-Draft IPvLX October 2006 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 April 26, 2007 [Page 22] Internet-Draft IPvLX October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 April 26, 2007 [Page 23]