Network Working Group F. Templin Internet-Draft ISATAP Dot Org Expires: April 25, 2005 October 25, 2004 IPvLX Errata draft-templin-ipvlx-errata-05.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 25, 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 25, 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 errata are to be applied as patches to the base document: 3.1 Title Change Change the document title from: "IPvLX - IPv6 Addressing in the IPv4 Internet", to: "IPvLX - IP with virtual Link eXtension". (Also change all other instances of the IPvLX term expansion in an identical fashion for consistency throughout the document.) 3.2 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.3 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 Templin Expires April 25, 2005 [Page 2] Internet-Draft IPvLX Errata October 2004 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: +-------------------------------+ | . | | . | | 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. Senders MAY write the value 0 in the checksum field of IPvLX PDUs for flows that do not require strong end-to-end data integrity checks below the transport; receivers consider checksums with the value 0 as correct [RFC3358]. 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, 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.)" 3.4 Replacement text for ([IPVLX], Section 4.2.1) Replace the current text of ([IPVLX], Section 4.2.1) with the following: Templin Expires April 25, 2005 [Page 3] Internet-Draft IPvLX Errata October 2004 "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 (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 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 as consecutive 16-bit values in network byte order in the final 4 PDU bytes 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. Upper layers in IPv6 end nodes SHOULD maintain per-flow minimum inter-ULP payload delay timers ("MinInterULPPayloadDelay") to enforce a delay 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 reassembly/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 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 Templin Expires April 25, 2005 [Page 4] Internet-Draft IPvLX Errata October 2004 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, 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]." 3.5 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 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 (minus 4 bytes for the trailing checksum). 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 sends an ICMPv6 "parameter problem" message [ICMPv6] with code "reassembly/checksum error" back to the source. The message body includes any headers for the flow Templin Expires April 25, 2005 [Page 5] Internet-Draft IPvLX Errata October 2004 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). 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.6 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.7 Paragraph Addition for ([IPVLX], Section 4.4) In ([IPVLX], section 4.4), add the following as trailing paragraphs for the section: "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." 3.8 Delete ([IPVLX], Section 4.6) Delete this entire section. 3.9 Replacement text for ([IPVLX], Section 5, first paragraph) Replace the first paragraph of ([IPVLX], Section 5) with the following: "When an IPv6 endpoint sends packets toward a target, and an IPv6 router that forwards the packets over an IPvLX interface occurs along the path, the virtual link from the encapsulating IPvLX gateway can be extended to a decapsulating IPvLX gateway close to the target as long as intermediate IPvLX gateways in the path behave as described Templin Expires April 25, 2005 [Page 6] Internet-Draft IPvLX Errata October 2004 in the following sections. (Additionally, intermediate IPvLX gateways SHOULD set the "Reserved Fragmentation (RF)" bit in the IPv4 headers of IPvLX packets they forward.)" 3.10 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.11 Replacement text for ([IPVLX], Section 6, final 2 paragraphs) Replace the final 2 paragraphs of ([IPVLX], Section 6) with the following single sentence: "IPvLX gateways SHOULD discard (and MAY process as soft errors) any ICMPv4 messages that cannot be validated." 3.12 Delete ([IPVLX], Section 7) Delete this entire section. 3.13 Replacement text for ([IPVLX], Section 8) Replace the current text of ([IPVLX], Section 8) with the following: "8. Contacting Potential Routers When an IPv6 endpoint initiates communications with a target via a first hop IPvLX gateway, 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 a last hop 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 April 25, 2005 [Page 7] Internet-Draft IPvLX Errata October 2004 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 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 Templin Expires April 25, 2005 [Page 8] Internet-Draft IPvLX Errata October 2004 source address of the IPvLX encapsulated packet. It can then discover the address of its own enterprise border by examining the embedded IPv4 address in the TLLAO and 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. (This assumes the name service can be used as a suitable trust anchor for router authorization without the need for ([SEND], section 6) authorization delegation discovery.) Following authorization, the solicitor can create IPv6 route cache entries with the link-local ISATAP address constructed from the IPv4 address in the Router Advertisement's (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." 3.14 New IANA Considerations Section Add a new "IANA Considerations" section immediately before the current ([IPVLX], section 11) as follows: "X. 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.15 New Informative References Add the Informative References that appear in this document to the list of Informative References in [IPVLX]. 3.16 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 25, 2005 [Page 9] Internet-Draft IPvLX Errata October 2004 Hannu Flinck, Dan Forsberg, Mario Gerla, 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, Uttam Shikarpur, Tuomo Sipila, Greg Skinner, Craig Smelser, Jonne Soininen, Timo Soirinsuo, Hesham Soliman, Mark Smith, Mohit Talwar, Chuck Thacker, Dave Thaler, Matt Thomas, Joe Touch, Margaret Wasserman, Michael Welzl, Cedric Westphal, Kathy Wilde, Juha Wiljakka, Aidan Williams, Henry Yang, Vlad Yasevich, Hui Zhang, and Lixia Zhang. Acknowledgements also to those whose names were inadvertently omitted." 3.17 Replacement text for ([IPVLX], Appendix A) Replace the current text of ([IPVLX], Appendix A) with the following: "Appendix A. Design Notes 1. The 1280 byte IPv6 minimum MTU was agreed through working group consensus in November 1997 discussions on the IPv6 mailing list. 2. 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. 3. 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. 4. 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. 5. 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. Templin Expires April 25, 2005 [Page 10] Internet-Draft IPvLX Errata October 2004 6. 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]. 7. 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]. 8. Certain control messages (e.g., Router Solicitations, Router Advertisements and packets with full IPv6 headers intended to establish flow state) require inspection and/or consumption in IPvLX gateways. Use of the IPv6 Router Alert option [RFC2711] is FFS, as it may allow a more efficient mechanism for fast-path processing. 9. Implementations may optionally provide a link-layer retransmission capability for IPvLX packet chains for which valid ICMPv4 "fragmentation needed" messages are received. 10. Prior to any path MTU probing for a flow, IPvLX begins 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 initial probing described above. Note that some upper layer packetization protocols (e.g., NFS) Templin Expires April 25, 2005 [Page 11] Internet-Draft IPvLX Errata October 2004 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 protocol 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." 3.18 Section Renumbering Following application of errata in the preceding subsections, renumber the sections in the merged document as appropriate. 4. Security considerations Security considerations are found in the [IPVLX] base document. 5. Acknowledgements See above. 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 [NFSRDMA] Talpey, T. and C. Juszczak, "NFS RDMA Problem Statement", draft-ietf-nfsv4-nfs-rdma-problem-statement (work in progress), July 2004. [PMTUD] Mathis, M., Heffner, J. and K. Lahey, "Path MTU Discovery", draft-ietf-pmtud-method (work in progress), Templin Expires April 25, 2005 [Page 12] Internet-Draft IPvLX Errata October 2004 June 2004. [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999. [RFC3358] Koodli, R. and R. Ravikanth, "Optional Checksums in Intermediate System to Intermediate System (ISIS)", RFC 3358, August 2002. [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 25, 2005 [Page 13] 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 25, 2005 [Page 14]