Network Working Group F. Templin Internet-Draft Nokia Expires: February 27, 2005 August 27, 2004 IPvLX: IPv6 Addressing in the IPv4 Internet draft-templin-ipvlx-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 RFC 3668. 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 February 27, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The IPv6 128-bit address space was designed as a solution for the 32-bit limitation of IPv4, but deployment of IPv4 in the global Internet continues via private addressing domains behind Network Address Translators (NATs). For these reasons, use of IPv6 for end node addressing with minimal perturbation of IPv4 networks presents a natural long-term transition and coexistence alternative. This document proposes IP Virtual Link Extension (IPvLX): a new encapsulation method for IPv6 addressing in IPv4 networks. Templin, et al. Expires February 27, 2005 [Page 1] Internet-Draft IPvLX August 2004 1. Introduction The IPv6 128-bit address space was designed as a 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]. For these reasons, use of IPv6 for end node addressing with minimal perturbation of IPv4 networks presents a natural long-term transition and coexistence alternative. The Intra-Site Automatic Tunnel Addressing Protocol [ISATAP] connects IPv6 nodes within a site over an IPv4 network using basic IPv6-in- IPv4 encapsulation (i.e., "ISATAP encapsulation") and a virtual link abstraction similar to the Non-Broadcast, Multiple Access (NBMA) model [RFC2491][RFC2492]. ISATAP nodes that also implement the IP Virtual Link Extension (IPvLX) mechanisms and deployment methods described in this document can extend this virtual link to reach peers in other enterprises/sites and located many IPv4 hops away. 2. Terminology The terminology of [ISATAP][RFC2460][RFC2461] applies to this document. The following additional terms are defined: logical interface: the same as defined in ([STD3], section 3.3.4.1). enterprise: a network entity that has one or more connections to the global IPv4 Internet and consists of one or more sites. site: a network entity that determines its own addressing plan and address assignments, and is a properly contained within an enterprise or parent site. virtual link: the network span over which packets can be forwarded between peers without the Hop Limit field in the IPv6 header being decremented. IP Virtual Link Extension (IPvLX): mechanisms and operational practices (described in this document) used by IPvLX nodes to extend the virtual link between peers across enterprise/site boundaries. Templin, et al. Expires February 27, 2005 [Page 2] Internet-Draft IPvLX August 2004 IPvLX node: an ISATAP node ([ISATAP], 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 relaying, proxying, bridging, and/or service provisioning capabilities, and determines the addressing plans for its associated hosts. Enterprise border IPvLX gateways are 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 IPvLX Protocol Data Units (PDUs) as chains of IPvLX packets using IPvLX encapsulation and link adaptation, but otherwise behaves the same as an ISATAP interface ([ISATAP], section 3). IPvLX Protocol Data Unit (PDU): an IPvLX interface's logical unit of transfer that consists of an upper layer protocol payload followed by a 32-bit CRC (see: section 4.2). IPvLX encapsulation: a method for encapsulating IPvLX PDUs (or PDU segments) within IPv4 headers to create IPvLX packets (see: section 4.1). IPvLX packet: an IPv4 packet created using IPvLX encapsulation. IPvLX link adaptation: a link layer mechanism (see: section 4.2) that segments IPvLX PDUs into chains of IPvLX packets during encapsulation for later reassembly during decapsulation, e.g., to satisfy path MTU restrictions, etc. Templin, et al. Expires February 27, 2005 [Page 3] Internet-Draft IPvLX August 2004 IPvLX Flow (or simply: "flow"): a unidirectional stream of IPvLX packets identified by a tuple consisting of VCI/VPI values, an IPvLX Flow Identifier, and IPv4 source/destination addresses encoded in each packet header (see: sections 4.1 and 4.2). Each flow provides a logical interface for IPvLX. IPvLX Flow Identifier: a 20-bit value encoded in the IPvLX Flow Header and used to identify an IPvLX Flow. Similar to the IPv6 Flow Label [RFC3697], but may be modified by IPvLX gateways on the path. IPvLX Flow Header: a 4-byte "Layer 2.5 shim" header immediately following the 20-byte IPv4 header in IPvLX packets (see: section 4.1). 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 [BCP14]. 3. Autoconfiguration IPvLX nodes should automatically discover the addresses of parent IPvLX gateways, enterprise border IPvLX gateways, DNS recursive name servers, etc. at startup time or when moving to a new link. They should also configure supporting services (e.g., DHCPv4 [RFC2131], DHCPv6 [RFC3315][RFC3633][RFC3736], Mobile IPv6 Home Agent [RFC3775], etc.) and advertise the 6to4 Relay anycast prefix ([RFC3068], section 2.3) for their associated hosts. IPvLX nodes can act as site border IPvLX gateways for their own associated hosts to enable recursively-nested "sites within sites", with scaling properties limited only by enterprise/site addressing plans. IPvLX nodes should register name-to-IPv6 address mappings via secure, dynamic updates to the DNS [RFC2136][DNSSEC]. (IPvLX nodes that do not receive IPv6 address assignments and/or prefix delegations through an autoconfiguration mechanism should configure unique local addresses [UNIQ1][UNIQ2].) 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]. Unification of the MANET protocols with existing routing/bridging protocols (e.g., OSPF [RFC2740], IEEE 802.1D spanning tree [STP], etc.) and an efficient flooding mechanism Templin, et al. Expires February 27, 2005 [Page 4] Internet-Draft IPvLX August 2004 is currently under investigation. 4. IPvLX Encapsulation 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 IPv6-in-IPv4 packet encapsulation ("IPvLX encapsulation") as described in the following subsections: 4.1. IPvLX Packet Header Construction IPvLX encapsulation embeds upper layer protocol data in IPv4 headers ([RFC0791], Section 3.1) with the value '41' encoded in the "Protocol" field and the two least significant bits in the "Flags" field both set to '1'. Setting "Flags" bit 0 ("Reserved Fragmentation - RF") unambiguously distinguishes IPvLX packets from ordinary IPv6-in-IPv4 encapsulated packets. Setting "Flags" bit 1 ("Don't Fragment - DF") frees the 13 "Fragment Offset" and 16 "Identification" bits for use as mutable bits, since IPv4 fragmentation is disabled and since the IPv4 encapsulation header is not included in upper layer pseudo-header checksums. Other IPv4 header fields are set exactly as in ([MECH], section 3.5). IPvLX encapsulation adds a 4-byte IPvLX Flow Header as a "Layer 2.5 shim" immediately following the 20-byte IPv4 header and immediately before the upper layer protocol data. The IPvLX Flow Header is formatted as shown below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Protocol | IPvLX Flow Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version 4-bit version number - value TBA by IANA. Protocol 8-bit protocol number - Identifies the type of header immediately following the IPvLX Flow header using the same values as for the IPv4 "Protocol" and IPv6 "Next Header" fields. IPvLX Flow ID 20-bit identifier - initialized by the encapsulator (possibly to the same value as the IPv6 Flow Label [RFC3967]) and modified by IPvLX gateways. Templin, et al. Expires February 27, 2005 [Page 5] Internet-Draft IPvLX August 2004 When an IPvLX node sends/forwards/receives an IPvLX packet, it treats the 16-bit "Identification" field as a 16-bit virtual circuit identifier (VCI) and the high-order 8-bits of the "Fragment Offset" field as an 8-bit virtual path identifier (VPI). The VCI, VPI and IPvLX Flow Identifier are initialized by the encapsulating IPvLX node to values that uniquely identify the flow and may modified by intermediate IPvLX gateways on the path. 4.2. IPvLX Interface MTU and IPvLX Link Adaptation All IPv6 interfaces are REQUIRED to support the IPv6 minimum MTU of 1280 bytes, i.e., they MUST NOT return ICMPv6 "Packet too Big" errors [RFC1981] for IPv6 packet/fragments smaller than 1280 bytes. Interfaces that use IPv4 as a link layer for IPv6 SHOULD also avoid unnecessary fragmentation in the IPv4 Internet [FRAG]. IPvLX interfaces therefore use a link adaptation layer similar to ATM Adaptation Layer 5 (AAL5) [RFC2684] to segment IPv6 packets/fragments into chains of IPvLX packets no larger than an underlying IPv4 interface's MTU. IPvLX link adaptation uses a Protocol Data Unit (PDU) format similar to the AAL5 CPCS-PDU ([RFC2684], section 4). The IPvLX PDU consists of a Payload field of up to (2^16 - (32 * 4) - 1) = 65407 bytes from the original IPv6 packet/fragment to be segmented/reassembled followed by a 4 byte CRC. Senders calculate the CRC across all bytes of the IPvLX PDU payload using CRC-32 as for AAL5; receivers use the CRC to detect and discard PDUs with bit errors. The format of the IPvLX PDU is shown below: +-------------------------------+ | . | | . | | Payload | | up to 65407 bytes | | . | | . | +-------------------------------+ | CRC (4 bytes) | +-------------------------------+ IPvLX PDU Format IPvLX interfaces configure a default and minimum LinkMTU of 1280 bytes and MAY configure a larger value up to a maximum of 65407 bytes; they MUST NOT configure an MTU value outside of this range. Templin, et al. Expires February 27, 2005 [Page 6] Internet-Draft IPvLX August 2004 4.2.1. Segmentation IPvLX interfaces configure per-flow link adaptation segment sizes ("SEGSIZE") to segment and encapsulate IPvLX PDUs into chains of IPvLX packets that include a 20-byte IPv4 header followed by a 4-byte IPvLX Flow header followed by up to SEGSIZE PDU bytes. The default and minimum per-flow SEGSIZE is 44 bytes. IPvLX link adaptation segments each IPvLX PDU into at most 32 segments and encapsulates each segment in an IPvLX packet header (see: section 4.1) to create a chain of IPvLX packets. Beginning with the first PDU segment, consecutive segments are encapsulated in-order in consecutive IPvLX packets with a Segment ID ("SEGID") between (0 - 31) encoded in the five low-order bits in the "Fragmentation Offset" field in each packet in increasing order, i.e., the first packet encodes '0', the second packet encodes '1', etc. up to the final packet. Each IPvLX packet in a chain sets the "More Fragments - MF" bit as for ordinary IPv4 fragmentation (i.e., MF is set for all IPvLX packets in the chain except the final one). The CRC is encoded in network byte order as the final 4 PDU bytes in the chain. IPvLX packets are formatted as shown below: +-------------------------------+ | IPv4 Header (20 bytes) | | | | RF = DF = 1; MF = [0|1] | | 0 <= SEGID <= 31 | | 24 < Length <= (24 + SEGSIZE) | | | +-------------------------------+ | IPvLX Flow Header (4 bytes) | +-------------------------------| | | ~ Up to SEGSIZE PDU bytes ~ | | +-------------------------------+ IPvLX packets in a chain SHOULD be sent over the wire in increasing SEGID order, i.e., SEGID 0 first, followed by SEGID 1, etc., up to the final packet in the chain. IPvLX PDUs that are too large to be encapsulated within a chain of up to 32 IPvLX packets based on the current SEGSIZE for the flow are discarded, and an ICMPv6 "packet too big" message [RFC1981] is sent to the source subject to rate-limiting ([ICMPV6] section 2.4 f). Templin, et al. Expires February 27, 2005 [Page 7] Internet-Draft IPvLX August 2004 IPvLX interfaces MAY configure per-flow SEGSIZE values larger than 44 bytes, but SHOULD use dynamic probing mechanisms (e.g., sending unicast IPvLX encapsulated Router Solicitations and/or sending redundant data in IPvLX packets larger than the current SEGSIZE to elicit a unicast IPvLX encapsulated Router Advertisement with an MTU option that indicates the largest segment received., etc.) to avoid path MTU black holes [RFC2923] when larger values are used. 4.2.2. Reassembly The Length, SEGID, MF and IPvLX Flow identification tuples in headers of a chain of IPvLX packets provide sufficient information for reassembly with protection for minor packet reordering within a flow in the IPv4 network. Reassembly entails restoration of the original IPvLX PDU based on the arrival of a chain of up to 32 IPvLX packets. PDU segments encoded in IPvLX packets with SEGID 0 through N are concatenated in numerical order (leaving fixed-size holes for any segments that arrive out-of- order) until all segments are received or a timeout occurs. The last hop IPvLX gateway performs CRC-32 verification over the reassembled IPvLX Payload to identify and discard corrupted IPvLX PDUs. Other reassembly algorithm details [RFC0815] are FFS. 4.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 a 32-bit CRC, 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. 4.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 protocol field. Templin, et al. Expires February 27, 2005 [Page 8] Internet-Draft IPvLX August 2004 4.5. Network Administration Considerations The use of IPvLX link adaptation may lead to an overall increase in short chains of small packets in the Internet. Network administrators are advised to follow the recommendations in [BCP48] to minimize packet loss and packet reordering. 4.6. Network Middlebox Considerations Network middleboxes that forward IPvLX packet chains can reassemble and re-segment them into different-sized IPvLX packets if they have sufficient storage/processing resources to avoid packet loss and can deterministically avoid to path MTU black holes. Fulfilling these requirements may be possible for middleboxes near the "edge" of the network, but much more difficult for interior middleboxes. This topic is FFS. 5. Virtual Link Extension When an IPv6 endpoint sends packets toward a target, and an IPv6 router that forwards the packets over an IPvLX interface occurs along the path, the virtual link from the encapsulating IPvLX gateway can be extended to a decapsulating IPvLX gateway close to the target as follows: 5.1. From the Encapsulator to the Target's 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 to the address of the IPv4 interface that will send the packet and rewrites the VCI, VPI and IPvLX Flow Identifier to unique values 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: (VCI(in), VPI(in), IPvLX Flow Identifier(in), IPv4_src(in), IPv4_dst(in)) to: (VCI(out), VPI(out), IPvLX Flow Identifier(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. Templin, et al. Expires February 27, 2005 [Page 9] Internet-Draft IPvLX August 2004 The encapsulator stores the flow identification information along with the IPv6 source and destination addresses to identify the flow's endpoints. 5.2. From the Target's 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 as an IPv6 router would do, 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. 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 IPv4 source address to the address of the IPv4 interface that will send the packet, and rewrites the VCI, VPI and IPvLX Flow Identifier to unique values 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: (VCI(in), VPI(in), IPvLX Flow Identifier(in), IPv4_dst(in)) to: (VCI(out), VPI(out), IPvLX Flow Identifier(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. The decapsulator stores the IPvLX Flow identification information along with the IPv6 source and destination addresses to identify the flow's endpoints. Templin, et al. Expires February 27, 2005 [Page 10] Internet-Draft IPvLX August 2004 6. Error Handling 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. When an intermediate IPvLX gateway receives an ICMPv4 message, it can determine the previous hop IPvLX gateway based on the flow information encoded in the packet-in-error as follows: 1. Locate a flow state entry that matches the flow information in the packet-in-error. If no flow state entry matches, drop the ICMPv4 message. 2. If per-flow rate limiting for the matching flow is exceeded, drop the ICMPv4 message. 3. Perform sanity checks and discard any ICMPv4 error messages for which the packet-in-error contains "suspect" information, e.g., strange MTU values in ICMPv4 "fragmentation needed" messages, strange pointers in ICMPv4 "parameter problem" messages, etc. Next, rewrite the ICMPv4 message's IPv4 source address to IPv4_dst(in) and its IPv4 destination address to IPv4_src(in). Also rewrite the packet-in-error's IPv4 source address to IPv4_dst(in), its IPv4 destination address to IPv4_src(in), its VCI to VCI(in), its VPI to VPI(in), and its IPvLX Flow Identifier to IPvLX Flow Identifier(in). Finally, re-calculate and rewrite the IPv4 header checksums for both the ICMPv4 message and the packet-in-error, and forward the message to the new IPv4 destination. When the first hop IPvLX gateway that encapsulated the original packet receives an ICMPv4 message it locates a flow state entry and validates the message (subject to rate limiting) as for intermediate IPvLX gateways, then uses the flow state information for ICMPv4-to- ICMPv6 error translation [RFC2765]. IPvLX gateways can keep per-flow queues of recently-sent IPvLX packet chains with packets larger than 68 bytes for re-segmentation and retransmission when a valid ICMPv4 "fragmentation needed" message is received, but this may not be possible for some intermediate IPvLX gateways due to storage and/or processing limitations. IPvLX gateways should discard (and may process as soft errors) any Templin, et al. Expires February 27, 2005 [Page 11] Internet-Draft IPvLX August 2004 ICMPv4 messages that cannot be validated. In particular, IPvLX gateways should not implement the per-flow queuing method described above over any flow for which suspect ICMPv4 "fragmentation needed" messages are observed. 7. Discovering a Parent IPvLX Gateway for the Site During IPv4 address autoconfiguration, IPvLX nodes that do not connect directly to the global IPv4 Internet should discover an IPv4 address for a parent IPvLX gateway via, e.g., resolving a Fully- Qualified Domain Name (FQDN) in the site's name service (e.g., [LLMNR]), receiving a DHCPv4 option, etc. IPvLX nodes may instead use the 6to4 Relay anycast address ([RFC3068], section 2.4) when no other mechanisms are available or when the overhead for using other mechanisms is unacceptable. Following IPv4 address discovery, IPvLX nodes should next send IPvLX encapsulated (*) Router Solicitation messages to verify that the parent IPvLX gateway is up and to receive IPv6 autoconfiguration parameters. The Router Solicitation messages should use the following addresses: - in the IPv6 source address, a link-local address (preferably a link-local [CGA] address) - in the IPv6 destination address, a link-local ISATAP address ([ISATAP], section 6.2]) that embeds an IPv4 address for a parent IPvLX gateway - in the IPv4 source address, the same as for ([MECH], section 3.5) - in the IPv4 destination address, the IPv4 address embedded in the IPv6 destination address When a [CGA] source address is used, the Router Solicitation should include SEcure Neighbor Discovery [SEND] parameters for [CGA] proof- of-ownership verification. When the parent IPvLX gateway receives the Router Solicitation, it can send back an IPvLX encapsulated (*) Router Advertisement with the following addresses: - in the IPv6 source address, a link-local address (preferably a link-local [CGA] address) - in the IPv6 destination address, the IPv6 source address received in the Router Solicitation Templin, et al. Expires February 27, 2005 [Page 12] Internet-Draft IPvLX August 2004 - in the IPv4 source address, an equivalent IPv4 unicast address ([RFC3068], section 2.6) - in the IPv4 destination address, the IPv4 source address received in the Router Solicitation When a [CGA] source address is used, the Router Advertisement should include SEcure Neighbor Discovery [SEND] parameters for [CGA] proof- of-ownership verification. The Router Advertisement should also include a SLLAO with an embedded global IPv4 unicast address ([RFC2529], section 5) associated with an enterprise border IPvLX gateway for the site, i.e., a 6to4 router [RFC3056] for the enterprise. (*) If the IPvLX gateway does not receive a Router Advertisement in response to IPvLX encapsulated Router Solicitations, it should instead send ISATAP encapsulated Router Solicitations [ISATAP]. In that case, link-local ISATAP addresses that embed the corresponding IPv4 addresses should be used in Router Solicitation/Advertisement messages instead of [CGA] addresses. 8. Discovering More-Specific Routes When an IPv6 endpoint initiates communications with a target, its first hop IPvLX gateway resolves the target's Fully-Qualified Domain Name (FQDN) using the DNS [RFC1035] or a name service for the site (e.g., [LLMNR]). If the name service returns a set of AAAA records including one with a 6to4 [RFC3056] address, the first hop IPvLX gateway can consider the IPv4 address embedded in the 6to4 prefix as the IPv4 destination address for the target node's enterprise border IPvLX gateway. For target nodes located in other sites/enterprises, the first hop IPvLX gateway can then send IPvLX encapsulated IPv6 Router Solicitation messages to discover a more-specific route for the target [DEFLT] with the following addresses: - in the IPv6 source address, a global (or unique local) [CGA] unicast address for the initiating IPv6 endpoint - in the IPv6 destination address, a global (or unique local) IPv6 unicast address for the target returned by the name service - in the IPv4 source address, the same as for ([MECH], section 3.5) Templin, et al. Expires February 27, 2005 [Page 13] Internet-Draft IPvLX August 2004 - in the IPv4 destination address, the 6to4-embedded IPv4 address The IPvLX encapsulated IPv6 Router Solicitation should include [SEND] parameters for [CGA] proof-of-ownership verification. When the final IPvLX gateway before the target receives a Router Solicitation, it can perform a reverse name service lookup on the IPv6 source address as a means of authenticating the initiator. It can then send an IPvLX encapsulated Router Advertisement back toward the solicitor with the following addresses: - in the IPv6 source address, a [CGA] link-local address - in the IPv6 destination address, the IPv6 source address from the Router Solicitation - in the IPv4 source address, the same as for ([MECH], section 3.5) - in the IPv4 destination address, the IPv4 source address received in the Router Solicitation The IPvLX encapsulated IPv6 Router Advertisement should include a SLLAO with an embedded global IPv4 unicast address ([RFC2529], section 5) associated with an enterprise border IPvLX gateway for the target and [SEND] parameters for [CGA] proof-of-ownership verification. It should also include as many of the target's IPv6 addresses as possible in Route Information Options [DEFLT]. When the solicitor receives a Router Advertisement, it can verify that the IPv6 addresses in Route Information Options match the IPv6 addresses received in AAAA records returned by the name service as a means of authorizing the target. This assumes the name service can be used as a suitable trust anchor for router authorization without the need for ([SEND], section 6) authorization delegation discovery. Following authorization, the solicitor can create IPv6 route cache entries with the link-local ISATAP address constructed from the IPv4 address in the Router Advertisement's SLLAO as the next hop toward the target's IPv6 addresses, and use IPv6 address selection rules to determine the best IPv6 source and destination addresses to choose for communications with the target [RFC3484]. The route cache entries should be managed in conjunction with name service cache entries, i.e., they should be deleted when the lifetime for the corresponding name service cache entry expires. Templin, et al. Expires February 27, 2005 [Page 14] Internet-Draft IPvLX August 2004 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 [SEND][CGA] 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 [SEND][CGA] should be used to provide mobile node location updates to correspondent nodes is FFS. 10. Analysis of Encapsulation Alternatives IPv6 peers that connect to the same physical L2 media segment can use native IPv6 directly over the L2 media. Attachment to the same physical L2 media segment can be detected based on, e.g., passive message snooping, whether/not a neighbor responds to native IPv6 neighbor discovery messages sent over the L2 media, etc. In many cases, IPv6 neighbors will be attached to different physical L2 media segments. To avoid issues associated with bridging dissimilar media (e.g., path MTU black holes) and to support IPv6 neighbor discovery security mechanisms, IPvLX nodes should use either ISATAP encapsulation or IPvLX encapsulation for sending IPv6 packets to neighbors within the same site and use IPvLX encapsulation for sending IPv6 packets to neighbors in different sites. When legacy NAT boxes that do not support the mechanisms described in this document are in the path, IPvLX node should use explicit NAT traversal mechanisms (e.g., [TEREDO]) since they provide a lowest- common denominator approach supported by most legacy NATs. However, the IPv6/UDP/IPv4 encapsulation used by explicit NAT traversal mechanisms requires an extra 8 bytes of overhead for each encapsulated packet; effectively reducing the segment payload for a 68 byte encapsulated packet to only 40 bytes. Templin, et al. Expires February 27, 2005 [Page 15] Internet-Draft IPvLX August 2004 11. Security considerations IPvLX gateways and associated hosts use the securing mechanisms for IPv6 neighbor discovery found in [CGA][SEND] according to the trust model appropriate for the given deployment scenario [RFC3756]. IPvLX gateways and associated hosts use the securing mechanisms for IPv6 nodes found in ([NODEREQ], section 8). 12. Acknowledgments This document represents the author's best effort to anticipate, interpret and describe emerging trends rooted in firm scientific principles. The author acknowledges the many individuals whose many years of effort have helped shape them. Similar concepts to those found in this document appear in [NDPROXY][PMTUD][RBRIDGE][VIRTUAL]. The following are acknowledged for their helpful insights on path MTU discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound, Brian Carpenter, Ralph Droms, Alain Durand, Jim Fleming, Tim Gleeson, Jun- ichiro itojun Hagino, Brian Haberman, Bob Hinden, Christian Huitema, Eddie Kohler, Kevin Lahey, Masataka Ohta, Matt Mathis, Jeff Mogul, Erik Nordmark, Soohong Daniel Park, Chirayu Patel, Charles Perkins, Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave Thaler, Margaret Wasserman, Michael Welzl, Lixia Zhang, and the members of the Nokia NRC/COM Mountain View team. "...and I'm one step ahead of the shoe shine, Two steps away from the county line, Just trying to keep my customers satisfied, Satisfi-i-ied!" - Paul Simon, 1969 Appendix A. The IPv6 minimum MTU The 1280 byte IPv6 minimum MTU was agreed through working group consensus in November 1997 discussions on the IPv6 mailing list. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Templin, et al. Expires February 27, 2005 [Page 16] Internet-Draft IPvLX August 2004 [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. Informative References [BCP48] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001. [STD3] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC0815] Clark, D., "IP Datagram Reassembly Algorithms", RFC 815, July 1982. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 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. [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999. [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999. Templin, et al. Expires February 27, 2005 [Page 17] Internet-Draft IPvLX August 2004 [RFC2507] Degermark, M., Nordgren, B. and S. Pin, "IP Header Compression", RFC 2507, February 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. [RFC2740] Colton, 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. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [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. [RFC3095] Bormann, C. (Ed.), "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 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. Templin, et al. Expires February 27, 2005 [Page 18] Internet-Draft IPvLX August 2004 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Option 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. [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery Trust Models and Threats", RFC 3756, May 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., editor and G. Fairhurst, editor, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [CGA] T. Aura, "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga, Work in Progress, April 2004. [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", draft-ietf-ipv6-router-selection, Work in Progress, August 2004. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro, Work in Progress, July 2004. [DSR] Johnson, D., Malz, D. and Hu, Y., "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", draft-ietf-manet-dsr, Work in Progress, April 2003. [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., and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3, Work in Progress, June 2004. [ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap, Work in Progress, May 2004. Templin, et al. Expires February 27, 2005 [Page 19] Internet-Draft IPvLX August 2004 [LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", draft-ietf-dnsext-mdns, Work in Progress, July 2004. [MECH] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2, Work in Progress, August 2004. [NDPROXY] Thaler, D., Talwar, M. and C. Patel, "Bridge-Like Neighbor Discovery Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy, Work in Progress, February 2004. [NODEREQ] J. Loughney, editor, "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, June 2004. [RBRIDGE] Perlman, R., Touch, J., and A. Yegin, "RBridges: Transparent Routing", draft-perlman-rbridge-00, Work in Progress, April 2004. [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P. Nikander, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ndopt, Work in Progress, July 2004. [STP] T. Jeffree, editor, "Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D, 1998, http://standards.ieee.org/getieee802/download/802.1D-1998.pdf. [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo, Work in Progress, February 2004. [UNIQ1] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr, Work in Progress, June 2004. [UNIQ2] Hinden, R., and B. Haberman, "Centrally Assigned Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central, Work in Progress, June 2004. [VIRTUAL] Touch, J., Wang, Y., Eggert, L. and G. Finn, "Virtual Internet Architecture", Future Developments of Network Architectures (FDNA) at Sigcomm, August 2003. Templin, et al. Expires February 27, 2005 [Page 20] Internet-Draft IPvLX August 2004 Authors' Addresses Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA 94110 US Phone: +1 650 625 2331 EMail: ftemplin@iprg.nokia.com Templin, et al. Expires February 27, 2005 [Page 21] Internet-Draft IPvLX August 2004 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Templin, et al. Expires February 27, 2005 [Page 22]