Network Working Group F. Templin
Internet-Draft ISATAP Dot Org
Expires: April 15, 2005 October 15, 2004
IPvLX Errata
draft-templin-ipvlx_errata-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 April 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document provides 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 errata for [IPVLX], version -01, dated August
27, 2004. It is intended as a companion document to be applied as a
Templin Expires April 15, 2005 [Page 1]
Internet-Draft IPvLX Errata October 2004
"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:
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 (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 as specified in the following sections of this
document.
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 ULP payloads 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 a ULP payload
followed by a trailing 4 byte checksum as shown below:
Templin Expires April 15, 2005 [Page 2]
Internet-Draft IPvLX Errata October 2004
+-------------------------------+
| . |
| . |
| ULP Payload |
| . |
| . |
+-------------------------------+
| Checksum (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. Segmentation restrictions (see: section
4.2.1) allow for ULP payloads up to (((2^16 - 5) * 32) - 4) = 2096988
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 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,
upper layers SHOULD employ a maximum ULP payload size probing
strategy [PMTUD] that begins with a smaller payload 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
MUST be contiguous and non-overlapping, i.e., the final byte of the
ith segment MUST be the byte that immediately precedes the first byte
of the (i+1)th segment in the IPvLX PDU. 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 MAY be of different
size.
IPvLX PDU segments are encapsulated in-order in consecutive IPvLX
Templin Expires April 15, 2005 [Page 3]
Internet-Draft IPvLX Errata October 2004
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 as consecutive 16-bit values in
network byte order in the final 4 PDU bytes in the chain.
IPvLX packets in a chain SHOULD be presented 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; they SHOULD be sent
back-to-back, i.e., with minimum inter-packet delay. The link layer
SHOULD NOT reorder the IPvLX packets in a chain or introduce
artificial delays between packets.
Upper layers in IPv6 end nodes SHOULD maintain per-flow minimum
inter-ULP payload delay timers ("MinInterULPPayloadDelay") that
record the time to wait between sending consecutive ULP payloads over
a flow. MinInterULPPayloadDelay SHOULD be initialized to a small
value and dynamically adjusted based on whether valid ICMPv6
"parameter problem" messages with code "reassembly/checksum error"
(see: sections 4.2.2) are arriving for the flow. In particular,
MinInterULPPayloadDelay 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 segmenting 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 15, 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 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
1284 bytes and SHOULD configure larger per-flow reassembly buffers up
to 9184 bytes, i.e., the minimum and maximum IPvLX interface 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
increasing numerical order, i.e., SEGID 0, followed by SEGID 1, etc.
If an IPvLX packet chain that is too large to fit in a reassembly
buffer is received, the reassembler discards the chain and sends an
ICMPv6 "packet too big" message back to the source with an MTU option
that encodes the reassembly buffer size.
After all packets in the chain have arrived, the reassembler verifies
the Fletcher-32 checksum over the ULP payload in the reassembled
IPvLX PDU. If checksum verification fails, or if one or more
segments other than SEGID 0 are missing, the reassembler sends an
ICMPv6 "parameter problem" message [ICMPv6] with code
"reassembly/checksum error" back to the source. The message body
includes the contents of the reassembly buffer up to the end of the
IPvLX PDU (to a maximum of 1280 bytes). The pointer identifies
either the beginning of the 4 byte trailing checksum field (in the
case of checksum failure) or the beginning of the first missing
segment if one or more segments are missing. The message should
include the following addresses:
o in the IPv6 source address, a link-local address (preferably a
link-local [CGA] address)
o in the IPv6 destination address, the IPv6 source address for the
flow
o in the IPv4 source address, the same as for ([MECH], section 3.5)
o in the IPv4 destination address, the IPv4 source address from the
headers of IPvLX packets in the chain
When a [CGA] source address is used, the ICMPv6 Parameter Problem
message should include SEcure Neighbor Discovery [SEND] parameters
for [CGA] proof- of-ownership verification immediately following the
message body.
Templin Expires April 15, 2005 [Page 5]
Internet-Draft IPvLX Errata October 2004
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 4 byte
checksum field in the IPvLX PDU is discarded and the ULP payload is
delivered to upper layers."
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."
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."
Templin Expires April 15, 2005 [Page 6]
Internet-Draft IPvLX Errata October 2004
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 an IP version number for IPvLX in
the "IP Version Numbers" registry.
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."
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,
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, Joe Touch, Margaret
Wasserman, Michael Welzl, Cedric Westphal, Cathy Wilde, Juha
Wiljakka, Aidan Williams, Henry Yang, Vlad Yasevich, Hui Zhang, and
Lixia Zhang. Acknowledgements also to those whose names were
inadvertently omitted."
Templin Expires April 15, 2005 [Page 7]
Internet-Draft IPvLX Errata October 2004
3.13 Replacement text for ([IPVLX], Appendix A)
Replace the current text of ([IPVLX], Appendix A) with the following:
"Appendix A. Design Notes
The 1280 byte IPv6 minimum MTU was agreed through working group
consensus in November 1997 discussions on the IPv6 mailing list.
Since IPvLX packets always set the "DF" bit to disable IPv4
fragmentation, and since the IPv4 encapsulation headers are not
included in upper layer checksums, the "Fragment Offset" and
"Identification" bits in the IPv4 header are available for use as
specified in this document.
The 16-bit A and B parts of the Fletcher-32 checksum will not occur
on natural 16-bit word alignments for IPvLX PDU payloads with odd
lengths.
MinInterULPPayloadDelay enforcement within the source node may be
required at both the application level and within the IPv6 stack,
e.g., within the IPv6 fragmentation engine.
Senders can use 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].
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]."
4. Security considerations
Security considerations are found in the [IPVLX] base document.
5. Acknowledgements
See above.
Templin Expires April 15, 2005 [Page 8]
Internet-Draft IPvLX Errata October 2004
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
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 Org
333 Ravenswood Ave.
Menlo Park, CA 94025
USA
Phone: +1 650 859 2000
EMail: osprey67@yahoo.com
Templin Expires April 15, 2005 [Page 9]
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 15, 2005 [Page 10]