Considerations and Issues with IPv6 DNS", Work in
Progress, October 2004.
[KM97] Kent, C., and J. Mogul, "Fragmentation Considered
Harmful". In Proc. SIGCOMM ’87 Workshop on Frontiers in
Computer Communications Technology. August 1987.
[V6SEC] Savola, P., "IPv6 Transition/Co-existence Security
Considerations", Work in Progress, October 2004.
[V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-
IPv4 Tunnels", Work in Progress, December 2004.
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
8. Changes from RFC 2893
The motivation for the bulk of these changes are to simplify the
document to only contain the mechanisms of wide-spread use.
RFC 2893 contains a mechanism called automatic tunneling. But a much
more general mechanism is specified in RFC 3056 [RFC3056] which gives
each node with a (global) IPv4 address a /48 IPv6 prefix i.e., enough
for a whole site.
The following changes have been performed since RFC 2893:
- Removed references to A6 and retained AAAA.
- Removed automatic tunneling and use of IPv4-compatible addresses.
- Removed default Configured Tunnel using IPv4 "Anycast Address"
- Removed Source Address Selection section since this is now covered
by another document ([RFC3484]).
- Removed brief mention of 6over4.
- Split into normative and non-normative references and other
reference cleanup.
- Dropped "or equal" in if (IPv4 path MTU - 20) is less than or
equal to 1280.
- Dropped this: However, IPv6 may be used in some environments where
interoperability with IPv4 is not required. IPv6 nodes that are
designed to be used in such environments need not use or even
implement these mechanisms.
- Described Static MTU and Dynamic MTU cases separately; clarified
that the dynamic path MTU mechanism is OPTIONAL but if it is
implemented it should follow the rules in section 3.2.2.
- Specified Static MTU to default to a MTU of 1280 to 1480 bytes,
and that this may be configurable. Discussed the issues with
using Static MTU at more length.
- Specified minimal rules for IPv4 reassembly and IPv6 MRU to
enhance interoperability and to minimize blacholes.
- Restated the "currently underway" language about Type-of-Service,
and loosely point at [RFC2983] and [RFC3168].
- Fixed reference to Assigned Numbers to be to online version (with
proper pointer to "Assigned Numbers is obsolete" RFC).
- Clarified text about ingress filtering e.g., that it applies to
packet delivered to transport protocols on the decapsulator as
well as packets being forwarded by the decapsulator, and how the
decapsulator’s checks help when IPv4 and IPv6 ingress filtering is
in place.
- Removed unidirectional tunneling; assume all tunnels are
bidirectional, between endpoint addresses (not nodes).
- Removed the guidelines for advertising addresses in DNS as
slightly out of scope, referring to another document for the
details.
- Removed the SHOULD requirement that the link-local addresses
should be formed based on IPv4 addresses.
- Added a SHOULD for implementing a knob to be able to set the
source address of the tunnel, and add discussion why this is
useful.
- Added stronger wording for source address checks: both IPv4 and
IPv6 source addresses MUST be checked, and RPF-like ingress
filtering is optional.
- Rewrote security considerations to be more precise about the
threats of tunneling.
- Added a note about considering using TTL=255 when encapsulating.
- Added more discussion in Section 3.2 why using an "infinite" IPv6
MTU leads to likely interoperability problems.
- Added an explicit requirement that if both MTU determination
methods are used, choosing one should be possible on a per-tunnel
basis.
- Clarified that ICMPv4 error handling is only applicable to dynamic
MTU determination.
- Removed/clarified DNS record filtering; an API is a SHOULD and if
it does not exist, MUST NOT filter anything. Decree ordering out
of scope, but refer to RFC3484.
- Add a note that the destination IPv4 address could also be a
multicast address.
- Make it RECOMMENDED to provide a toggle to perform strict ingress
filtering on an interface.
- Generalize the text on the data in ICMPv4 messages.
- Made a lot of miscellaneous editorial cleanups.
Authors’ Addresses
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Robert E. Gilligan
Intransa, Inc.
2870 Zanker Rd., Suite 100
San Jose, CA 95134 USA
Phone : +1 408 678 8600
Fax : +1 408 678 8800
EMail: bob.gilligan@acm.org
Full 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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.