Network Working Group F. Templin Internet-Draft ISATAP Dot Com Expires: April 8, 2005 October 08, 2004 IPvLX Errata draft-templin-ipvlx-errata-00.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 April 8, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document provides an errata for 'IPvLX: IPv6 Addressing in the IPv4 Internet'. It is intended as a companion document to be applied as a "patch" to the base document. 1. Introduction This document provides an errata for [IPVLX], version -01, dated August 27, 2004. It is intended as a companion document to be Templin Expires April 8, 2005 [Page 1] Internet-Draft IPvLX Errata October 2004 applied as a "patch" to the base document. 2. Requirements 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. IPvLX Errata The following erratum are to be applied as patches to the base document exactly as specified in the following subsections: 3.1 Replacement text for ([IPVLX], Section 4.1, paragraph 1) Replace the current text of ([IPVLX], Section 4.1, paragraph 1) with the following: "IPvLX encapsulates upper layer protocol data 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 used for the purposes specified in the following sections of this document, since setting "DF" disables IPv4 fragmentation and since the IPv4 encapsulation headers are not included in upper layer checksums. o the IPv4 "Total Length" field adds 4 bytes for the IPvLX Flow Header in all datagrams (see below) and deducts 40 bytes in datagrams that do not include an IPv6 header." 3.2 Replacement text for ([IPVLX], Section 4.2) Replace the current text of ([IPVLX], Section 4.2) with the following: "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 upper layer datagrams into chains of IPvLX packets no larger than the IPv4 path MTU. 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 payload from the Templin Expires April 8, 2005 [Page 2] Internet-Draft IPvLX Errata October 2004 upper layer datagram and a 4 byte checksum as shown below: +-------------------------------+ | . | | . | | Payload | | . | | . | +-------------------------------+ | Checksum (4 bytes) | +-------------------------------+ IPvLX PDU Format Senders calculate the checksum across all IPvLX PDU payload bytes using 2's compliment Fletcher-32 [STONE][RFC3385]; receivers verify the checksum to detect errors. Segmentation restrictions (see: section 4.2.1) allow for IPvLX PDUs up to ((2^16 - 5) * 32) = 2096992 bytes, but such a large LinkMTU for IPvLX interfaces could result in unacceptable levels of undetected errors along many paths. IPvLX interfaces therefore MUST configure a minimum LinkMTU of 1280 bytes and MAY 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 1408 bytes may result in ICMPv6 "packet too big messages" due to temporary segmentation restrictions, upper layers SHOULD employ a maximum datagram size probing strategy [PMTUD] that begins with a smaller datagram size (on the order of 1KB) and probes upward." 3.3 Replacement text for ([IPVLX], Section 4.2.1) Replace the current text of ([IPVLX], Section 4.2.1) with the following: "IPvLX interfaces configure per-flow segment sizes ("SEGSIZE") and use IPvLX link adaptation to segment IPvLX PDUs into chains of IPvLX packets. Due to the 24-byte IPvLX packet header and the IPv4 minimum link MTU of 68 bytes, IPvLX interfaces SHOULD configure default SEGSIZE values of 44 bytes. 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 encapsulated in non-final packets in the chain MUST be equal in size. The segment encapsulated in the final packet in the chain will be no larger than the segment size for non-final packets unless the chain has been configured as a SEGSIZE probe (see below). IPvLX PDU segments are encapsulated in-order in consecutive IPvLX Templin Expires April 8, 2005 [Page 3] Internet-Draft IPvLX Errata October 2004 packets with a Segment ID ("SEGID") between 0 - 31 encoded in the five low-order bits in the "Fragmentation Offset" field. SEGIDs are assigned 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 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 as consecutive 16-bit values in network byte order in the final 4 PDU bytes in the chain; note that these values will not occur on natural 16-bit word alignments for IPvLX PDU payloads with odd lengths. 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 interfaces on first-hop IPvLX gateways MUST maintain a per-flow minimum inter-PDU delay value ("MinInterPDUDelay") that records the time the interface must wait between sending the final IPvLX packet for the previous IPvLX PDU and the first IPvLX packet for the current IPvLX PDU. MinInterPDUDelay SHOULD be initialized to a small value and dynamically adjusted based on whether valid IPvLX encapsulated ICMPv6 "parameter problem" messages with code "TBA - checksum error" (see: section 4.2.2) are arriving for the flow. In particular, MinInterPDUDelay SHOULD be increased while checksum error messages are arriving and MAY be decreased when the messages subside. IPvLX interfaces MAY increase a flow's SEGSIZE to values larger than 44 bytes, but SHOULD probe the path with the new value first to avoid black holes [RFC2923]. IPvLX interfaces probe a candidate SEGSIZE value 'N' by configuring a chain of two or more packets to be sent over the flow 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. Following a successful probe and advancement of SEGSIZE to N, the IPvLX interface SHOULD re-probe the current SEGSIZE periodically as above 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]." Templin Expires April 8, 2005 [Page 4] Internet-Draft IPvLX Errata October 2004 3.4 Replacement text for ([IPVLX], Section 4.2.2) Replace the current text of ([IPVLX], Section 4.2.2) with the following: "The Length, SEGID, MF and IPvLX Flow identification tuples in the headers of a chain of IPvLX packets 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 1284 bytes and SHOULD configure larger per-flow reassembly buffers up to 9184 bytes, i.e., the minimum and maximum IPvLX MTUs plus 4 bytes for the trailing checksum. Reassemblers use per-flow reassembly buffers to concatenate the IPvLX PDU segments encoded in IPvLX packets with SEGID 0 through N in numerical order. After all packets in the chain have arrived, the Fletcher-32 checksum is verified over the reassembled IPvLX PDU. If checksum verification fails (or, if reassembly fails due to missing segments) the reassembler sends an IPvLX encapsulated ICMPv6 "parameter problem" message with code "TBA - checksum error" back to the first hop IPvLX gateway. Since link-layer CRC-32 checks normally occur on each hop 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 end-to-end error detection capability for such errors [STONE]. When a reassembler receives an IPvLX packet chain used for probing (see: section 4.2.1), it reassembles the 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." 3.5 Update for ([IPVLX], Section 4.3) In ([IPVLX], section 4.3), replace the string: "a 32-bit CRC" with: "an end-to-end checksum". 3.6 Paragraph Addition for ([IPVLX], Section 4.4) In ([IPVLX], section 4.4), add the following as a trailing paragraph for the section: "IPvLX encapsulated IPv6 neighbor discovery messages MUST NOT omit the IPv6 header." Templin Expires April 8, 2005 [Page 5] Internet-Draft IPvLX Errata October 2004 3.7 Delete ([IPVLX], Section 4.6) Delete this entire section. 3.8 Update for ([IPVLX], Sections 5.1, 5.2) In ([IPVLX], sections 5.1 and 5.2), replace the string: "rewrites the IPvLX packet's IPv4 source address to the address of the IPv4 interface that will send the packet" with the string: "rewrites the IPvLX packet's IPv4 source address with an address selected as for ([MECH], section 3.5)". 3.9 Paragraph Deletion for ([IPVLX], Section 6) In ([IPVLX], section 6), delete the following paragraph: "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." 3.10 New IANA Considerations Section Renumber the current ([IPVLX], sections 11 and 12) as sections 12 and 13, respectively, and create a new section 11 as follows: "11. IANA Considerations The IANA is instructed to assign a code type for "checksum error" under the ICMPv6 Parameter Problem message type in the "ICMPv6 Type Numbers" registry." 3.11 New Informative References Add the Informative References that appear in this document to the list of Informative References in [IPVLX]. 3.12 Replacement text for ([IPVLX], acknowledgements, paragraph 2) Replace the second paragraph of "acknowledgements" with: "The following are acknowledged for their various helpful insights on path MTU discovery: Tom Anderson, Jari Arkko, Iljitsch van Beijnum, Jim Bound, Roy Brabson, Brian Carpenter, Chran-Ham Chang, Jeff Chase, Alex Conta, Paul Cormier, Steve Deering, Barbara Denny, Vijay Devarapalli, Rich Draves, Ralph Droms, Alain Durand, John Dustin, Phil Dykstra, Robert Elz, Domenico Ferrari, Kent Ferson, Jim Fleming, Templin Expires April 8, 2005 [Page 6] Internet-Draft IPvLX Errata October 2004 Hannu Flinck, Dan Forsberg, Timothy Joseph Gleeson, Fred Glover, Jason Goldschmidt, Lea Gottfredsen, Jun-ichiro itojun Hagino, Brian Haberman, Tony Hain, Bill Hawe, Jarmo Hillo, Bob Hinden, Christian Huitema, Raj Jain, Chet Juszczak, Reijo Juvonen, Cyndi Jung, Krishna Kant, Timothy Kniveton, Eddie Kohler, Paul Koning, Rajeev Koodli, Kevin Lahey, Mark Lewis, John Loughney, Ira Machefsky, Jari Malinen, Keith Moore, Masataka Ohta, Richard Ogier, Hilarie Orman, Bob Owens, Matt Mathis, Jeff Mogul, Erik Nordmark, Larry Palmer, Soohong Daniel Park, Chirayu Patel, Charles Perkins, Radia Perlman, Jarno Rajahalme, K. K. Ramakrishnan, Michael Richardson, Meghana Sahasrabudhe, Ambatipudi Sastry, Markku Savela, Pekka Savola, Tuomo Sipila, Greg Skinner, Craig Smelser, Jonne Soininen, Hesham Soliman, Mark Smith, Mohit Talwar, Chuck Thacker, Dave Thaler, Margaret Wasserman, Michael Welzl, Cedric Westphal, Cathy Wilde, Juha Wiljakka, Henry Yang, Vlad Yasevich, Hui Zhang, and Lixia Zhang. Acknowledgements also to those whose names were inadvertently omitted." 4. Security considerations Security considerations are found in the [IPVLX] base document. 5. Acknowledgements Acknowledgements are found in the [IPVLX] base document. 6. References 6.1 Normative References [IPVLX] Templin, F., "IPvLX: IPv6 Addressing in the IPv4 Internet", draft-templin-ipvlx (work in progress), August 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2 Informative References [PMTUD] Mathis, M., Heffner, J. and K. Lahey, "Path MTU Discovery", draft-ietf-pmtud-method (work in progress), June 2004. [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. [STONE] Stone, J., "Checksums in the Internet (Stanford Doctoral Templin Expires April 8, 2005 [Page 7] Internet-Draft IPvLX Errata October 2004 Dissertation)", August 2001. [WLAN] Society, I., "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Computer Society, ANSI/IEEE 802.11, 1999 Edition.". Author's Address Fred L. Templin ISATAP Dot Com 333 Ravenswood Ave. Menlo Park, CA 94025 USA Phone: +1 650 859 2000 EMail: osprey67@yahoo.com Templin Expires April 8, 2005 [Page 8] Internet-Draft IPvLX Errata October 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 Expires April 8, 2005 [Page 9]