Network Working Group F. Templin Internet-Draft American Kestrel Consulting Expires: August 21, 2005 February 17, 2005 IPvLX - IP with virtual Link eXtension draft-templin-ipvlx-02.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 become 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 August 21, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 addressing with minimal perturbation of IPv4 networks presents a natural long-term transition and coexistence alternative. This document proposes IPvLX - IP with virtual Link Extension. Templin Expires August 21, 2005 [Page 1] Internet-Draft IPvLX February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 5 4. Encapsulation and Link Adaptation . . . . . . . . . . . . . . 5 4.1 IPvLX Encapsulation . . . . . . . . . . . . . . . . . . . 6 4.2 IPvLX Interface MTU and IPvLX Link Adaptation . . . . . . 7 4.2.1 Segmentation . . . . . . . . . . . . . . . . . . . . . 8 4.2.2 Reassembly . . . . . . . . . . . . . . . . . . . . . . 9 4.3 IPv6 Fragmentation and Reassembly . . . . . . . . . . . . 11 4.4 Header Compression . . . . . . . . . . . . . . . . . . . . 11 4.5 Additional Considerations . . . . . . . . . . . . . . . . 11 5. Virtual Link Extension . . . . . . . . . . . . . . . . . . . . 13 5.1 From the Encapsulator to the Target Enterprise/Site Border . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 From the Target Enterprise/Site Border to the Decapsulator . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 MPLS Label Switching . . . . . . . . . . . . . . . . . . . 15 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Contacting Potential Routers . . . . . . . . . . . . . . . . . 16 8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 12. Appendix A: Other Encapsulation Alternatives . . . . . . . . 19 13. Appendix B: Comparison with Teredo . . . . . . . . . . . . . 19 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14.1 Normative References . . . . . . . . . . . . . . . . . . . 20 14.2 Informative References . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . 27 Templin Expires August 21, 2005 [Page 2] Internet-Draft IPvLX February 2005 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 addressing with minimal perturbation of IPv4 networks presents a natural long-term transition and coexistence alternative. 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 ([RFC1122], section 3.3.4.1). site: the same as defined in ([ISATAP], 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: 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 encapsulated L3 header being decremented. IP with virtual Link eXtension (IPvLX): mechanisms and operational practices (described in this document) used by IPvLX nodes to extend virtual links across enterprise/site boundaries. IPvLX virtual links are edge-to-edge between two routers, as for VPNs. 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 hybrid routing/bridging/firewalling capabilities and determines the addressing plans for its associated hosts. IPvLX gateways occur in exactly the same topological locations as IPv4 NATs, and are really nothing more Templin Expires August 21, 2005 [Page 3] Internet-Draft IPvLX February 2005 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 IPvLX Protocol Data Units (PDUs) as chains of IPvLX packets using IPvLX encapsulation and link adaptation. IPvLX Protocol Data Unit (PDU): an IPvLX interface's logical unit of transfer that consists of an upper layer protocol payload and a trailing checksum (see: section 4.3). IPvLX encapsulation: a method for encapsulating IPvLX PDU segments over IPv4 as the Layer 2 (L2) protocol (see: section 4.1). IPvLX packet: an IPv4 packet created using IPvLX encapsulation and link adaptation. IPvLX link adaptation: a link layer mechanism (see: section 4.2) that segments IPvLX PDUs into chains of IPvLX packets for later reassembly during decapsulation, e.g., to satisfy path MTU restrictions, etc. 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. Initialized as for the IPv6 Flow Label [RFC3697], but may be modified by IPvLX gateways on the path. Templin Expires August 21, 2005 [Page 4] Internet-Draft IPvLX February 2005 IPvLX Flow Header: a "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 [RFC2119]. 3. 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) IPvLX gateways should automatically associate with an IPvLX gateway in a parent enterprise/site 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], etc.) and advertise themselves for discovery by any interior IPvLX gateways on inward-facing interfaces, e.g., by advertising the 6to4 Relay anycast prefix ([RFC3068], section 2.3). 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 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. 4. Encapsulation and Link Adaptation Templin Expires August 21, 2005 [Page 5] Internet-Draft IPvLX February 2005 4.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 protocol (ULP) payloads in IPv4 datagrams with header fields set as for standard IPv6-in-IPv4 encapsulation ([MECH], section 3.5) except that: o bit 1 of the "Flags" field (i.e., "Don't Fragment - DF") is set to '1' in all datagrams. o the 13 "Fragment Offset" and 16 "Identification" bits are configured to identify a Virtual Circuit as specified in the following sections of this document. o the Protocol is set to the IP protocol number assigned for MPLS encapsulation in IP [MPLSIP]. Additionally, in order to provide forwarding between labeled waypoints and flow labeling capabilities, IPvLX nodes encode an MPLS Label Stack [RFC3031][RFC3032] as a "Layer 2.5 shim" header immediately following the 20-byte IPv4 header. They also encode a 4-byte IPvLX Flow Header containing an IPvLX Flow Label immediately after the MPLS Label Stack (or, as the bottom entry in the MPLS Label Stack) and immediately before the ULP payload. IPvLX packets are formatted as shown below: Templin Expires August 21, 2005 [Page 6] Internet-Draft IPvLX February 2005 +-------------------------------+ - | | | | | | ~ ULP Payload (variable length) ~ > Layer 3 | | | | | | +-------------------------------+ - | IPvLX Flow Header (4 bytes) | | +-------------------------------+ | | | | ~ MPLS Label Stack (variable ~ > Layer 2.5 ~ length; multiples of 4 bytes) ~ | | | | +-------------------------------+ - | IPv4 Header (20 bytes) | | | DF = 1 | | | ID; Offset = VC Info | > Layer 2 | Protocol = MPLS-in-IP | | | | | +-------------------------------+ - IPvLX Packet Format 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 low-order 5-bits of the "Fragment Offset" field are treated as a 5-bit Segment ID - see section 4.3.1). The VCI, VPI and IPvLX Flow Identifier are initialized by the encapsulating IPvLX node to values that uniquely identify the flow and may be modified by intermediate IPvLX gateways on the path. An MPLS label stack is initialized by the encapsulating IPvLX node, and may be modified by intermediate IPvLX gateways on the path. Other encapsulation alternatives are discussed in Appendix A. A comparison of IPvLX with [TEREDO] is given in Appendix B. 4.2 IPvLX Interface MTU and IPvLX Link Adaptation All IPv6 interfaces are REQUIRED to support the IPv6 minimum MTU of 1280 bytes, and all IPv4 interfaces SHOULD avoid unnecessary fragmentation in the IPv4 Internet [FRAG]. IPvLX interfaces therefore use a link adaptation scheme similar to both ATM Adaptation Layer 5 (AAL5) [RFC2684] and IEEE 802.11 MAC Sublayer Fragmentation ([WLAN], section 9.4) to segment ULP payloads into chains of IPvLX packets no larger than the IPv4 path MTU. Templin Expires August 21, 2005 [Page 7] Internet-Draft IPvLX February 2005 IPvLX link adaptation uses a Protocol Data Unit (PDU) format similar to the AAL5 CPCS-PDU ([RFC2684], section 4) and the IEEE 802.11 MSDU ([WLAN], section 9.1.4). The IPvLX PDU includes a ULP payload followed by a trailing 4 byte checksum as shown below: +-------------------------------+ | . | | . | | ULP Payload | | . | | . | +-------------------------------+ | CRC (4 bytes) | +-------------------------------+ IPvLX PDU Format Senders calculate the checksum across all ULP payload bytes using 2's compliment Fletcher-32 [STONE][RFC3385]; receivers verify the checksum to detect errors. IPvLX interfaces MUST configure a minimum LinkMTU of 1280 bytes and SHOULD provide a configuration knob to set a larger value up to 9180 bytes, i.e., the MTU for IP over ATM AAL5 [RFC1626]. Since LinkMTU values larger than 1280 bytes may result in ICMPv6 "packet too big" messages due to temporary segmentation restrictions, ULPs SHOULD employ a probing strategy that begins with a smaller payload size (on the order of 1KB) and probes upward [PMTUD]. (Note that this may not be possible for some ULPs.) 4.2.1 Segmentation IPvLX interfaces configure per-flow segment sizes ("SEGSIZE") and use IPvLX link adaptation to segment IPvLX PDUs into chains of IPvLX packets. Ultra-conservative IPvLX interfaces can configure a default SEGSIZE value of (68 - the length of the IPvLX header), since the minimum IPv4 LinkMTU is 68 bytes [RFC0791]. In practice, however, most links in the Internet configure much larger IPv4 LinkMTUs [RFC3150][RFC3819], and larger values for SEGSIZE can often be used. IPvLX link adaptation splits each IPvLX PDU into at most 32 segments and encapsulates each segment in an IPvLX packet header to create a chain of IPvLX packets. The segments MUST be contiguous and non-overlapping, i.e., the final byte of the (i)th segment MUST be the byte that immediately precedes the first byte of the (i+1)th segment. The segments encapsulated in non-final packets in the chain MUST be equal in size; the segment encapsulated in the final packet Templin Expires August 21, 2005 [Page 8] Internet-Draft IPvLX February 2005 in the chain MAY be of different size. IPvLX PDU segments are encapsulated in-order in consecutive IPvLX packets with an increasing Segment ID ("SEGID") value between 0 - 31 encoded in the five low-order bits in the "Fragmentation Offset" field, i.e., the first packet encodes '0', the second packet encodes '1', etc. Each IPvLX packet in a chain except the final one sets the "More Fragments - MF" bit, i.e., the MF bit is set as for ordinary IPv4 fragmentation. The A and B results from the Fletcher-32 checksum calculation are encoded in the trailing 32-bit checksum field of the IPvLX PDU and are therefore encoded as the final 32-bits of the final IPvLX packet in the chain. IPvLX interfaces SHOULD deliver each chain of packets to the link layer in increasing SEGID order, i.e., SEGID 0 first, followed by SEGID 1, etc., up to the final packet in the chain. The link layer SHOULD NOT reorder the packets or introduce artificial delays between packets. IPvLX interfaces MAY increase a flow's SEGSIZE to values larger than the minimum and SHOULD perform path probing to avoid black holes [RFC2923]. IPvLX interfaces probe a candidate SEGSIZE value 'N' by segmenting an IPvLX PDU to be sent over the flow into a chain of two or more packets such that the final packet encapsulates a segment of size N, where N is larger than the size of the segments encapsulated in non-final packets. If the last hop IPvLX gateway returns an IPvLX encapsulated unicast IPv6 Router Advertisement message with an MTU option that encodes the value N (see: section 4.2.2) within a maximum probe delay ("MaxProbeDelay") timeout period, the probe is deemed successful. If no Router Advertisement message is received within MaxProbeDelay, the probe is deemed unsuccessful and the IPvLX PDU used for probing SHOULD be re-segmented to a size no larger than SEGSIZE and re-transmitted. (In case long delays along the return path are anticipated, the sender can instead encode Forward Error Correction (FEC) information before sending the chain at the expense of some added inefficiency.) Following a successful probe, but before advancing SEGSIZE to N, the IPvLX interface SHOULD enter a brief verification phase during which it sends additional probes to detect asymmetric multipath MTU restrictions. Thereafter, the IPvLX interface SHOULD re-probe periodically to confirm that packets with up to SEGSIZE byte segments are still reaching the last hop IPvLX gateway. Additional strategies for SEGSIZE management and black hole detection are found in [PMTUD]. 4.2.2 Reassembly The Length, SEGID, MF and IPvLX Flow identification tuples in the Templin Expires August 21, 2005 [Page 9] Internet-Draft IPvLX February 2005 headers of IPvLX packets in a chain provide sufficient information for the last hop IPvLX gateway to reassemble the original IPvLX PDU with protection for packet reordering in the IPv4 network. Last hop IPvLX gateways MUST configure per-flow reassembly buffers of at least 1280 bytes and SHOULD configure larger per-flow reassembly buffers up to 9180 bytes, i.e., the minimum and maximum IPvLX interface MTUs. Reassemblers use per-flow reassembly buffers to concatenate the IPvLX PDU segments encoded in IPvLX packets received with SEGID 0 through N in increasing numerical order, i.e., SEGID 0, followed by SEGID 1, etc. If the reassembler receives an IPvLX packet chain that is too large to fit in a reassembly buffer, it discards the chain and sends an ICMPv6 "packet too big" message back to the source. The message body includes any headers for the flow that were compressed away (see: section 4.4) followed by the contents of the reassembly buffer up to a total of 1280 bytes, and the MTU value encodes the reassembly buffer size. Otherwise, the reassembler verifies the Fletcher-32 checksum over the ULP payload in the reassembled IPvLX PDU. If at least one segment with vaild IPv4 and IPvLX headers were received, but one or more segments were missing and/or checksum verification failed, the reassembler MAY send an ICMPv6 "parameter problem" message [ICMPv6] with code "reassembly/checksum error" back to the source. The message body includes any headers for the flow that were compressed away (see: section 4.4) followed by the contents of the reassembly buffer up to a total of 1280 bytes, and the pointer identifies either the beginning of the first missing segment or the beginning of the 4 byte checksum field (if no segments were missing). The decision of whether to send the ICMPv6's is FFS. One school of thought would be to send the ICMPs only when congestion is experienced [RFC3168], i.e., in order to provide a congestion indication to the source. Another school of thought would suggest sending ICMPs only when loss is NOT due to congestion, i.e., in order to inform the first-hop IPvLX gateway that increasing the amount of FEC data may result in better performance. When a reassembler receives an IPvLX packet chain used for probing (see: section 4.2.1), it reassembles the IPvLX PDU, verifies the checksum then sends a unicast IPvLX encapsulated IPv6 Router Advertisement message back to the source with an MTU option that encodes the size of the segment encapsulated in the final IPvLX packet in the chain. The first hop IPvLX gateway will receive the Router Advertisement and deem the probe successful. Following successful reassembly and checksum verification, the ULP payload is delivered to upper layers. Templin Expires August 21, 2005 [Page 10] Internet-Draft IPvLX February 2005 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 an edge-to-edge checksum, 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 includes 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. 4.5 Additional Considerations IPvLX encapsulators can segment chains of two or more IPvLX packets in which the final packet is longer than the non-final packets as a general-purpose mechanism for eliciting acknowledgements from the reassembler if improved reliability at the expense of additional overhead is desired. The equal size restriction for non-final segments and non-overlapping restriction for all segments in IPvLX packet chains provides a significant simplification for reassembly algorithms [RFC0815]. 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 [RFC3150] to minimize packet loss and packet reordering. Network middleboxes that do not honor the IPv4 DF bit will cause irreparable damage to the VCI/VPI information encoded in the IPvLX header if IPv4 fragmentation is incurred. For this reason, nodes that must fragment IPv4 packets with the DF bit set (e.g., last-hop links that have an MTU smaller than 68 bytes) must make special Templin Expires August 21, 2005 [Page 11] Internet-Draft IPvLX February 2005 provisions other than IPv4 fragmentation. Network conditions such as load balancing, multi-path routing, spanning tree reconfigurations, etc. can cause a certain degree of reordering of the IPvLX packets in a flow. For instance, Segment 5 of a segmented IPvLX PDU could arrive before Segment 1. The 5-bit segment ID in each IPvLX packet provides protection for reordering among the IPvLX packets of the same IPvLX PDU, but provides no protection for reordering of packets belonging to *different* IPvLX PDUs. A small ID field is therefore needed in each IPvLX packet to differentiate the packets of IPvLX PDUs A and B. Since only 20 bits of the IPvLX Flow Header are needed to encode the Flow Identifier (and 8 bits may be necessary to encode a next-header value), up to 4 bits of the flow header can be used to encode a small IPvLX PDU ID. The question arises as to whether a 4 bit ID field is enough to eliminate potential ambiguity due to packet reordering in the network. Several works conducted by CAIDA (www.caida.org) may provide insights. Since link-layer CRC-32 checks normally occur on each segment in the path, most errors detected during IPvLX PDU reassembly will be due to packet splices and/or errors in the data path between the NIC hardware and the reassembly buffer. The Fletcher-32 checksum algorithm has been shown to provide an effective edge-to-edge error detection capability for such errors [STONE]. The Fletcher-32 checksum is also dissimilar from both CRC-32 and the Internet checksum used by many upper layer protocols, thereby decreasing the likelihood of undetected errors. Prior to any path MTU probing for a flow, IPvLX link adaptation should begin with a conservative minimum SEGSIZE of 44 bytes to assure a maximum IPv4 packet size of 68 bytes (the maximum IPv4 packet size guaranteed to fit over any link in the IPv4 Internet) resulting in a maximum un-probed IPvLX ULP payload of ((44 * 32) - 4) = 1404 bytes for ultra-conservative implementations. But, [RFC3150] suggests a minimum MTU of 296 bytes over the slowest serial links, so a slightly more optimistic implementation could send IPvLX ULP payloads as large as ((296 - 24) * 32) = 8704 bytes (and perhaps a bit larger due to VJ header compression) as long as they arrange for the first few such payloads to generate probe responses from the far-end. For those optimistic implementations, if probe responses consistently arrive after an initial probe and subsequent verification phase, the flow's SEGSIZE can be advanced to the size used for probing. Otherwise, the IPvLX interface can generate IPv6 "packet too big" messages to inform upper packetization layers that smaller IPv6 packets should be sent over this flow for the time being. An optimistic implementation could therefore set the maximum IPvLX interface LinkMTU of 9180 bytes and perform the optimistic Templin Expires August 21, 2005 [Page 12] Internet-Draft IPvLX February 2005 initial probing described above. Some upper layer packetization protocols (e.g., NFS) generate fixed payload sizes and rely on the network layer to deliver the payloads either as whole IP packets or as chains of IP fragments. Those protocols should consider "packet too big" messages coming from the IPvLX interface as an indication to retransmit, since the IP fragmentation layer will have been informed of the smaller MTU for the flow. Subsequent payloads sent over the flow will therefore undergo IP fragmentation and each fragment will be presented to the IPvLX interface for transmission. Since NFS performance (and the performance of other upper layer packetization protocols) is highly sensitive to packet handling overhead [NFSRDMA], IPvLX interfaces should periodically attempt to increase the SEGSIZE through probing even if initial probe attempts fail. Since the RTT paths along various paths may vary from the sub-microsecond level up to hundreds of milliseconds or more, Forward Error Correction (FEC) will clearly be required in some cases (i.e., instead of Automatic Repeat Request (ARQ)) even though efficiency may suffer [RFC3819]. Provisions for enabling adaptive and efficient FEC in the segmentation/reassembly procedures are FFS. The IPvLX Flow Header is sufficiently similar to an MPLS label stack entry [RFC3032] in terms of size and configuration that it should be engineered as part of the MPLS label stack instead of as a seperate entity, e.g., by defining a spare bit in the MPLS label stack entry to indicate: "IPvLX Flow Header". 5. Virtual Link Extension When an IPv6 endpoint sends packets toward a target, and an IPv6 router within an IPvLX gateway that forwards the packets over an IPvLX interface occurs along the path, a virtual link is extended from the encapsulating IPvLX gateway to a decapsulating IPvLX gateway close to the target as long as intermediate IPvLX gateways in the path behave as described in the following sections. (Additionally, intermediate IPvLX gateways SHOULD set the "Reserved Fragmentation (RF)" bit in the IPv4 headers of IPvLX packets they forward.) 5.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 Templin Expires August 21, 2005 [Page 13] Internet-Draft IPvLX February 2005 with an address selected as for ([MECH], section 3.5) 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. 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 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. 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 ([MECH], section 3.5), 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.) Templin Expires August 21, 2005 [Page 14] Internet-Draft IPvLX February 2005 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. 5.3 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)[68] 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 must traverse en-route to the enterprise containing the final destination. 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). Templin Expires August 21, 2005 [Page 15] Internet-Draft IPvLX February 2005 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 SHOULD discard (and MAY process as soft errors) any ICMPv4 messages that cannot be validated. Note that the above method for handling ICMPv4 errors assumes the ability to walk the chain of previous IPvLX gateways backwards to the IPvLX gateway at the head of the virtual link that sent the packet that elicited the error. This may not always be possible, e.g., when a stack of MPLS labels was used to steer the packet through a number of intermediate waypoints across the global Internet backbone. For further study is a method for sending the ICMPv4 message forward to the IPvLX gateway at the tail of the virutal link that would have decapsulated the original packet, and arrange for that gateway to return a suitable error to the IPvLX gateway at the head of the virtual link. See also [RFC3032] for further discussion of such forward error propagation. 7. Contacting Potential Routers When an IPv6 endpoint initiates communications with a target via a first hop IPvLX gateway (e.g., by using the gateway as a recursive DNS resolver), the gateway resolves the target's Fully-Qualified Domain Name (FQDN) and contacts a router on the path to the target as for the Potential Router List procedures in ([ISATAP], sections 8 and 9). If the name service returns a set of IPv6 addresses including one or more 6to4 [RFC3056] address, the first hop IPvLX gateway can consider the IPv4 addresses embedded in the 6to4 prefixes as addresses for the target node's enterprise border IPvLX gateways. The first hop IPvLX gateway can then send IPvLX encapsulated IPv6 Router Solicitation messages to contact an IPvLX gateway on the path to the target with the following addresses: o in the IPv6 source address, a global (or unique local) [CGA] unicast address for the initiating IPv6 endpoint Templin Expires August 21, 2005 [Page 16] o in the IPv6 destination address, a global (or unique local) IPv6 unicast address for the target o in the IPv4 source address, the same as for ([MECH], section 3.5) o in the IPv4 destination address, a 6to4-embedded IPv4 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] parameters for [CGA] proof-of-ownership verification. When the last hop IPvLX gateway before the target that terminates the virtual link 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 perform a reverse name service lookup on the IPv6 source address as a means of authenticating the initiator and send an IPvLX encapsulated Router Advertisement back toward the solicitor with the following addresses: o in the IPv6 source address, a [CGA] 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 ([MECH], 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 reassembly buffer to be used for the flow, 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 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 Templin Expires August 21, 2005 [Page 17] Internet-Draft IPvLX February 2005 embedded IPv4 address in the TLLAO and also verify that the IPv6 addresses in Route Information Options match the IPv6 addresses received from the name service as a means of authorizing the target. 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 (rewritten) 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. 8. 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. 9. IANA Considerations The IANA is instructed to assign a code type for "reassembly/checksum error" under the ICMPv6 Parameter Problem message type in the "ICMPv6 Type Numbers" registry. 10. 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 Templin Expires August 21, 2005 [Page 18] Internet-Draft IPvLX February 2005 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, but host-specific firewalls may not be feasible on small devices. In any case, hosts which are not know to configure hose-specific firewalls MUST be deployed behind IPvLX gateways that do. 11. 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]. 12. Appendix A: Other Encapsulation Alternatives Another possibility for a L2.5 ôshimö layer to encapsulate labels akin 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 virtual link. 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. 13. Appendix B: Comparison with Teredo Using the UDP/IPv4 encapsulation method specified for Teredo [TEREDO] instead of IPvLX encapsulation would entail relatively minor differences to the architecture described in this document. Using Teredo, all of the same virtual link, link adaptation and IPvLX gateway considerations discussed in this document would still apply, except that the 16-bit UDP source port would be used as a per-hop flow designator instead of the IPvLX flow identifier. Templin Expires August 21, 2005 [Page 19] Internet-Draft IPvLX February 2005 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 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 IPv4 NATs in the current IPv4 Internet infrastructure before IPvLX gateways become widely deployed. Indeed, the legacy IPv4 NATs would appear to provide the same link extension capabilities as IPvLX gateways from TeredoÆs perspective. From an idealistic standpoint, this would seem to offer an exciting opportunity in terms of an immediate flag-day rollout. For example, if a large end-host vendor distributed a patch for its 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 100% of the security burden on the end-hosts with 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 the end users might not know how to configure or might not even be aware of. Even worse, unscrupulous vendors could conceal a technology such as 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 a 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 the unscrupulous vendors could certainly roll out their own proprietary ôterrorist toolsö. In that light, Teredo provides the useful contribution of exposing the false sense of security provided by IPv4 NATs and sensitizing the community to the potential for abuse through exploitation. 14. References 14.1 Normative References [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. Templin Expires August 21, 2005 [Page 20] Internet-Draft IPvLX February 2005 [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. 14.2 Informative References [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", Internet-Draft draft-ietf-send-cga, April 2004. [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", Internet-Draft draft-ietf-ipv6-router-selection, January 2005. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNS Security Introduction and Requirements", Internet-Draft draft-ietf-dnsext-dnssec-intro, October 2004. [DSR] Johnson, D., Maltz, D. and Y. Hu, "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", Internet-Draft draft-ietf-manet-dsr, July 2004. [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", Internet-Draft draft-ietf-ipngwg-icmp-v3, November 2004. [ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Internet-Draft draft-ietf-ngtrans-isatap, January 2005. [LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", Internet-Draft draft-ietf-dnsext-mdns, October 2004. [MECH] Nordmark, E. and R. Gilligan, "Transition Mechanisms for IPv6 Hosts and Routers", Internet-Draft draft-ietf-v6ops-mech-v2, September 2004. Templin Expires August 21, 2005 [Page 21] Internet-Draft IPvLX February 2005 [MPLSIP] Worster, T., Rekhter, Y. and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", Internet-Draft draft-ietf-mpls-in-ip-or-gre, June 2004. [NAP] Van de Velde, G., Hain, T., Droms, R., Carpenter, B. and E. Klein, "Network Architecture Protection", Internet-Draft draft-vandevelde-v6ops-nap, January 2005. [NDPROXY] Thaler, D., Talwar, M. and C. Patel, "Bridge-like Neighbor Discovery Proxies (ND Proxy)", Internet-Draft draft-thaler-ipv6-ndproxy, November 2004. [NFSRDMA] Talpey, T. and C. Juszczak, "NFS RDMA Problem Statement", Internet-Draft draft-ietf-nfsv4-nfs-rdma, July 2004. [NODEREQ] Loughney, ed., J., "IPv6 Node Requirements", Internet-Draft draft-ietf-ipv6-node-requirements, August 2004. [PMTUD] Mathis, M., Heffner, J. and K. Lahey, "Path MTU Discovery", Internet-Draft draft-ietf-pmtud-method, October 2004. [RBRIDGE] Perlman, R., Touch, J. and A. Yegin, "RBridges: Transparent Routing", Internet-Draft draft-perlman-rbridge, July 2004. [RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, July 1982. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [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. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. Templin Expires August 21, 2005 [Page 22] Internet-Draft IPvLX February 2005 [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. [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. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 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. [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. Templin Expires August 21, 2005 [Page 23] Internet-Draft IPvLX February 2005 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 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. [RFC3385] Sheinwald, D., Satran, J., Thaler, P. and V. Cavanna, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", RFC 3385, September 2002. [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. Templin Expires August 21, 2005 [Page 24] Internet-Draft IPvLX February 2005 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 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. [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P. Nikander, "Secure Neighbor Discovery (SEND)", Internet-Draft draft-ietf-send-ndopt, July 2004. [STONE] Stone, J., "Checksums in the Internet (Stanford Doctoral Dissertation)", August 2001. [STP] Jeffree, ed., T., "Media Access Control (MAC) Bridges, ANSI/IEEE Std 802.1D, http://standards.ieee.org/getieee802/download/802.1D-1998. pdf". [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", Internet-Draft draft-huitema-v6ops-teredo, January 2005. [UNIQ1] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", Internet-Draft draft-ietf-ipv6-unique-local-addr, January 2005. [UNIQ2] Hinden, R. and B. Haberman, "Centrally Assigned Unique Local IPv6 Unicast Addresses", Internet-Draft draft-ietf-ipv6-ula-central, 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. [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 August 21, 2005 [Page 25] Internet-Draft IPvLX February 2005 Author's Address Fred Lambert Templin American Kestrel Consulting P.O. Box 7593 Menlo Park, CA 94026 USA Email: {sparrowhawk,osprey67}@falcosparverius.org; fltemplin@acm.org Templin Expires August 21, 2005 [Page 26] Internet-Draft IPvLX February 2005 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 (2005). 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 Expires August 21, 2005 [Page 27]