[10] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC1122, October 1989.
[11] Kent, C. and J. Mogul, "Fragmentation Considered Harmful". In
Proc. SIGCOMM '87 Workshop on Frontiers in Computer
Communications Technology. August 1987.
[12] Callon, R. and D. Haskin, "Routing Aspects of IPv6 Transition",
RFC2185, September 1997.
[13] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", RFC2267, January 1998.
[14] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.
[15] Rechter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and
E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[17] Thaler, D., "IP Tunnel MIB", RFC2667, August 1999.
[18] Baker, F., "Requirements for IP Version 4 Routers", RFC1812,
June 1995.
10. Changes from RFC1933
- Deleted section 3.1.1 (IPv4 loopback address) in order to prevent
it from being mis-construed as requiring routers to filter the
address ::127.0.0.1, which would put another test in the
forwarding path for IPv6 routers.
- Deleted section 4.4 (Default Sending Algorithm). This section
allowed nodes to send packets in "raw form" to IPv4-compatible
destinations on the same datalink. Implementation experience has
shown that this adds complexity which is not justified by the
minimal savings in header overhead.
- Added definitions for operating modes for IPv6/IPv4 nodes.
- Revised DNS section to clarify resolver filtering and ordering
options.
- Re-wrote the discussion of IPv4-compatible addresses to clarify
that they are used exclusively in conjunction with the automatic
tunneling mechanism. Re-organized document to place definition of
IPv4-compatible address format with description of automatic
tunneling.
- Changed the term "IPv6-only address" to "IPv6-native address" per
current usage.
- Updated to algorithm for determining tunnel MTU to reflect the
change in the IPv6 minimum MTU from 576 to 1280 bytes [4].
- Deleted the definition for the term "IPv6-in-IPv4 encapsulation."
It has not been widely used.
- Revised IPv4-compatible address configuration section (5.2) to
recognize multiple interfaces.
- Added discussion of source address selection when using IPv4-
compatible addresses.
- Added section on the combination of the default configured
tunneling technique with hosts using automatic tunneling.
- Added prohibition against automatic tunneling to IPv4 broadcast or
multicast destinations.
- Clarified that configured tunnels can be unidirectional or
bidirectional.
- Added description of bidirectional virtual links as another type
of tunnels. Nodes MUST respond to NUD probes on such links and
SHOULD send NUD probes.
- Added reference to [16] specification as an alternative for
tunneling over a multicast capable IPv4 cloud.
- Clarified that IPv4-compatible addresses are assigned exclusively
to nodes that support automatic tunnels i.e. nodes that can
receive such packets.
- Added text about formation of link-local addresses and use of
Neighbor Discovery on tunnels.
- Added restriction that decapsulated packets not be forwarded
unless the source address is acceptable to the decapsulating
router.
- Clarified that decapsulating nodes MUST be capable of reassembling
an IPv4 packet that is 1300 bytes (1280 bytes plus IPv4 header).
- Clarified that when using a default tunnel to an IPv4 "anycast
address" the network must either have an IPv4 MTU of least 1300
bytes (to avoid fragmentation of minimum size IPv6 packets) or be
configured to avoid frequent changes to IPv4 routing to the
"anycast address" (to avoid different IPv4 fragments arriving at
different tunnel endpoints).
- Using A6/AAAA instead of AAAA to reference IPv6 address records in
the DNS.
- Specified when to put IPv6 addresses in the DNS.
- Added reference to the tunnel mib for TTL specification for the
tunnels.
- Added a table of contents.
- Added recommendations for use of source and target link layer
address options for the tunnel links.
- Added checks in the decapsulation checking both an IPv4-compatible
IPv6 source address and the outer IPv4 source addresses for
multicast, broadcast, all-zeros etc.
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.