draft-ietf-v6ops-mech-v2-03.txt   draft-ietf-v6ops-mech-v2-04.txt 
INTERNET-DRAFT E. Nordmark INTERNET-DRAFT E. Nordmark
June 15, 2004 Sun Microsystems, Inc. July 19, 2004 Sun Microsystems, Inc.
Obsoletes: 2893 R. E. Gilligan Obsoletes: 2893 R. E. Gilligan
Intransa, Inc. Intransa, Inc.
Basic Transition Mechanisms for IPv6 Hosts and Routers Basic Transition Mechanisms for IPv6 Hosts and Routers
<draft-ietf-v6ops-mech-v2-03.txt> <draft-ietf-v6ops-mech-v2-04.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This draft expires on December 15, 2004. This draft expires on January 19, 2004.
Abstract Abstract
This document specifies IPv4 compatibility mechanisms that can be This document specifies IPv4 compatibility mechanisms that can be
implemented by IPv6 hosts and routers. Two mechanisms are specified, implemented by IPv6 hosts and routers. Two mechanisms are specified,
"dual stack" and configured tunneling. Dual stack implies providing "dual stack" and configured tunneling. Dual stack implies providing
complete implementations of both versions of the Internet Protocol complete implementations of both versions of the Internet Protocol
(IPv4 and IPv6) and configured tunneling provides a means to carry (IPv4 and IPv6) and configured tunneling provides a means to carry
IPv6 packets over unmodified IPv4 routing infrastructures. IPv6 packets over unmodified IPv4 routing infrastructures.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. Introduction............................................. 3 1. Introduction............................................. 3
1.1. Terminology......................................... 3 1.1. Terminology......................................... 3
2. Dual IP Layer Operation.................................. 5 2. Dual IP Layer Operation.................................. 5
2.1. Address Configuration............................... 5 2.1. Address Configuration............................... 5
2.2. DNS................................................. 5 2.2. DNS................................................. 5
3. Configured Tunneling Mechanisms.......................... 7 3. Configured Tunneling Mechanisms.......................... 6
3.1. Encapsulation....................................... 8 3.1. Encapsulation....................................... 8
3.2. Tunnel MTU and Fragmentation........................ 9 3.2. Tunnel MTU and Fragmentation........................ 8
3.2.1. Static Tunnel MTU.............................. 9 3.2.1. Static Tunnel MTU.............................. 9
3.2.2. Dynamic Tunnel MTU............................. 10 3.2.2. Dynamic Tunnel MTU............................. 10
3.3. Hop Limit........................................... 11 3.3. Hop Limit........................................... 11
3.4. Handling ICMPv4 errors.............................. 12 3.4. Handling ICMPv4 errors.............................. 12
3.5. IPv4 Header Construction............................ 14 3.5. IPv4 Header Construction............................ 14
3.6. Decapsulation....................................... 15 3.6. Decapsulation....................................... 15
3.7. Link-Local Addresses................................ 18 3.7. Link-Local Addresses................................ 18
3.8. Neighbor Discovery over Tunnels..................... 19 3.8. Neighbor Discovery over Tunnels..................... 19
4. Threat Related to Source Address Spoofing................ 20 4. Threat Related to Source Address Spoofing................ 20
skipping to change at page 2, line 41 skipping to change at page 2, line 41
6. Acknowledgments.......................................... 22 6. Acknowledgments.......................................... 22
7. References............................................... 23 7. References............................................... 23
7.1. Normative References................................ 23 7.1. Normative References................................ 23
7.2. Informative References.............................. 23 7.2. Informative References.............................. 23
8. Authors' Addresses....................................... 25 8. Authors' Addresses....................................... 25
9. Changes from RFC 2893.................................... 25 9. Changes from RFC 2893.................................... 25
9.1. Changes from draft-ietf-v6ops-mech-v2-00............ 27 9.1. Changes from draft-ietf-v6ops-mech-v2-00............ 28
9.2. Changes from draft-ietf-v6ops-mech-v2-01............ 29 9.2. Changes from draft-ietf-v6ops-mech-v2-01............ 29
9.3. Changes from draft-ietf-v6ops-mech-v2-02............ 30 9.3. Changes from draft-ietf-v6ops-mech-v2-02............ 30
9.4. Changes from draft-ietf-v6ops-mech-v2-03............ 31
1. Introduction 1. Introduction
The key to a successful IPv6 transition is compatibility with the The key to a successful IPv6 transition is compatibility with the
large installed base of IPv4 hosts and routers. Maintaining large installed base of IPv4 hosts and routers. Maintaining
compatibility with IPv4 while deploying IPv6 will streamline the task compatibility with IPv4 while deploying IPv6 will streamline the task
of transitioning the Internet to IPv6. This specification defines of transitioning the Internet to IPv6. This specification defines
two mechanisms that IPv6 hosts and routers may implement in order to two mechanisms that IPv6 hosts and routers may implement in order to
be compatible with IPv4 hosts and routers. be compatible with IPv4 hosts and routers.
skipping to change at page 6, line 21 skipping to change at page 6, line 21
of the requesting node. of the requesting node.
The issues and operational guidelines for using IPv6 with DNS are The issues and operational guidelines for using IPv6 with DNS are
described at more length in other documents [DNSOPV6]. described at more length in other documents [DNSOPV6].
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
both AAAA and A records. However, when a query locates an AAAA both AAAA and A records. However, when a query locates an AAAA
record holding an IPv6 address, and an A record holding an IPv4 record holding an IPv6 address, and an A record holding an IPv4
address, the resolver library MAY order the results returned to the address, the resolver library MAY order the results returned to the
application in order to influence the version of IP packets used to application in order to influence the version of IP packets used to
communicate with that node -- IPv6 first, or IPv4 first. communicate with that specific node -- IPv6 first, or IPv4 first.
The applications SHOULD be able to specify whether they want IPv4, The applications SHOULD be able to specify whether they want IPv4,
IPv6 or both records [RFC3493]. That defines which address families IPv6 or both records [RFC3493]. That defines which address families
the resolver looks up. If there isn't an application choice, or if the resolver looks up. If there isn't an application choice, or if
the application has requested both, the resolver library MUST NOT the application has requested both, the resolver library MUST NOT
filter out any records. filter out any records.
Since most applications try the addresses in the order they are Since most applications try the addresses in the order they are
returned by the resolver, this can affect the IP version "preference" returned by the resolver, this can affect the IP version "preference"
of applications. of applications.
A resolver library performing ordering of addresses might also want The actual ordering mechanisms are out of scope of this memo.
to take into account external factors such as, whether IPv6 Address selection is described at more length in [RFC3484].
interfaces have been configured on the node.
The decision to order DNS results is implementation specific.
IPv6/IPv4 nodes MAY provide policy configuration to control ordering
of addresses returned by the resolver -- i.e., which order to sort --
or leave the decision entirely up to the application.
This is a bare minimum DNS processing implementation for dual-stack
hosts. The more extensive algorithm is specified in [RFC3484].
3. Configured Tunneling Mechanisms 3. Configured Tunneling Mechanisms
In most deployment scenarios, the IPv6 routing infrastructure will be In most deployment scenarios, the IPv6 routing infrastructure will be
built up over time. While the IPv6 infrastructure is being deployed, built up over time. While the IPv6 infrastructure is being deployed,
the existing IPv4 routing infrastructure can remain functional, and the existing IPv4 routing infrastructure can remain functional, and
can be used to carry IPv6 traffic. Tunneling provides a way to can be used to carry IPv6 traffic. Tunneling provides a way to
utilize an existing IPv4 routing infrastructure to carry IPv6 utilize an existing IPv4 routing infrastructure to carry IPv6
traffic. traffic.
skipping to change at page 11, line 18 skipping to change at page 11, line 12
MTU using IPv4 fragmentation, and when to return an ICMPv6 "packet MTU using IPv4 fragmentation, and when to return an ICMPv6 "packet
too big" message per [RFC1981]: too big" message per [RFC1981]:
if (IPv4 path MTU - 20) is less than 1280 if (IPv4 path MTU - 20) is less than 1280
if packet is larger than 1280 bytes if packet is larger than 1280 bytes
Send ICMPv6 "packet too big" with MTU = 1280. Send ICMPv6 "packet too big" with MTU = 1280.
Drop packet. Drop packet.
else else
Encapsulate but do not set the Don't Fragment Encapsulate but do not set the Don't Fragment
flag in the IPv4 header. The resulting IPv4 flag in the IPv4 header. The resulting IPv4
packet might be fragmented by the IPv4 layer on packet might be fragmented by the IPv4 layer
the encapsulator or by some router along on the encapsulator or by some router along
the IPv4 path. the IPv4 path.
endif endif
else else
if packet is larger than (IPv4 path MTU - 20) if packet is larger than (IPv4 path MTU - 20)
Send ICMPv6 "packet too big" with Send ICMPv6 "packet too big" with
MTU = (IPv4 path MTU - 20). MTU = (IPv4 path MTU - 20).
Drop packet. Drop packet.
else else
Encapsulate and set the Don't Fragment flag Encapsulate and set the Don't Fragment flag
in the IPv4 header. in the IPv4 header.
skipping to change at page 12, line 37 skipping to change at page 12, line 31
determination, even though the functions could be used with static determination, even though the functions could be used with static
MTU tunnels as well. MTU tunnels as well.
The ICMPv4 "packet too big" error messages are handled according to The ICMPv4 "packet too big" error messages are handled according to
IPv4 Path MTU Discovery [RFC1191] and the resulting path MTU is IPv4 Path MTU Discovery [RFC1191] and the resulting path MTU is
recorded in the IPv4 layer. The recorded path MTU is used by IPv6 to recorded in the IPv4 layer. The recorded path MTU is used by IPv6 to
determine if an ICMPv6 "packet too big" error has to be generated as determine if an ICMPv6 "packet too big" error has to be generated as
described in section 3.2.2. described in section 3.2.2.
The handling of other types of ICMPv4 error messages depends on how The handling of other types of ICMPv4 error messages depends on how
much information is included in the "packet in error" field, which much information is available from the encapsulated packet that
holds the encapsulated packet that caused the error. caused the error.
Many older IPv4 routers return only 8 bytes of data beyond the IPv4 Many older IPv4 routers return only 8 bytes of data beyond the IPv4
header of the packet in error, which is not enough to include the header of the packet in error, which is not enough to include the
address fields of the IPv6 header. More modern IPv4 routers are address fields of the IPv6 header. More modern IPv4 routers are
likely to return enough data beyond the IPv4 header to include the likely to return enough data beyond the IPv4 header to include the
entire IPv6 header and possibly even the data beyond that. entire IPv6 header and possibly even the data beyond that.
If the offending packet includes enough data, the encapsulator MAY If sufficient data bytes from the offending packet are available, the
extract the encapsulated IPv6 packet and use it to generate an ICMPv6 encapsulator MAY extract the encapsulated IPv6 packet and use it to
message directed back to the originating IPv6 node, as shown below: generate an ICMPv6 message directed back to the originating IPv6
node, as shown below:
+--------------+ +--------------+
| IPv4 Header | | IPv4 Header |
| dst = encaps | | dst = encaps |
| node | | node |
+--------------+ +--------------+
| ICMPv4 | | ICMPv4 |
| Header | | Header |
- - +--------------+ - - +--------------+
| IPv4 Header | | IPv4 Header |
skipping to change at page 13, line 32 skipping to change at page 13, line 32
+--------------+ ICMPv6 +--------------+ ICMPv6
| | error message | | error message
~ Data ~ back to the source. ~ Data ~ back to the source.
| | | |
- - +--------------+ - - - - +--------------+ - -
ICMPv4 Error Message Returned to Encapsulating Node ICMPv4 Error Message Returned to Encapsulating Node
When receiving ICMPv4 errors as above and the errors are not "packet When receiving ICMPv4 errors as above and the errors are not "packet
too big" it would be useful to log the error as an error related to too big" it would be useful to log the error as an error related to
the tunnel. Also, if sufficient headers are included in the error, the tunnel. Also, if sufficient headers are available, then the
then the originating node MAY send an ICMPv6 error of type originating node MAY send an ICMPv6 error of type "unreachable" with
"unreachable" with code "address unreachable" to the IPv6 source. code "address unreachable" to the IPv6 source. (The "address
(The "address unreachable" code is appropriate since, from the unreachable" code is appropriate since, from the perspective of IPv6,
perspective of IPv6, the tunnel is a link and that code is used for the tunnel is a link and that code is used for link-specific errors
link-specific errors [RFC2463]). [RFC2463]).
Note that when IPv4 path MTU is exceeded, and ICMPv4 errors of only 8 Note that when the IPv4 path MTU is exceeded, and sufficient bytes of
bytes of payload are generated, or ICMPv4 errors do not cause the payload associated with the ICMPv4 errors are not available, or
generation of ICMPv6 errors in case there is enough payload, there ICMPv4 errors do not cause the generation of ICMPv6 errors in case
will be at least two packet drops instead of at least one (the case there is enough payload, there will be at least two packet drops
of a single layer of MTU discovery). Consider a case where an IPv6 instead of at least one (the case of a single layer of MTU
host is connected to an IPv4/IPv6 router, which is connected to a discovery). Consider a case where an IPv6 host is connected to an
network where an ICMPv4 error about too big packet size is generated. IPv4/IPv6 router, which is connected to a network where an ICMPv4
First the router needs to learn the tunnel (IPv4) MTU which causes at error about too big packet size is generated. First the router needs
least one packet loss, and then the host needs to learn the (IPv6) to learn the tunnel (IPv4) MTU which causes at least one packet loss,
MTU from the router which causes at least one packet loss. Still, in and then the host needs to learn the (IPv6) MTU from the router which
all cases there can be more than one packet loss if there are causes at least one packet loss. Still, in all cases there can be
multiple large packets in flight at the same time. more than one packet loss if there are multiple large packets in
flight at the same time.
3.5. IPv4 Header Construction 3.5. IPv4 Header Construction
When encapsulating an IPv6 packet in an IPv4 datagram, the IPv4 When encapsulating an IPv6 packet in an IPv4 datagram, the IPv4
header fields are set as follows: header fields are set as follows:
Version: Version:
4 4
skipping to change at page 23, line 34 skipping to change at page 23, line 34
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998. Specification", RFC 2463, December 1998.
7.2. Informative References 7.2. Informative References
[ASSIGNED] IANA, "Assigned numbers online database", [ASSIGNED] IANA, "Assigned numbers online database",
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
[DNSOPV6] Durand, A., Ihren, J., and Savola P., "Operational [DNSOPV6] Durand, A., Ihren, J., and Savola P., "Operational
Considerations and Issues with IPv6 DNS", draft-ietf-dnsop- Considerations and Issues with IPv6 DNS", draft-ietf-dnsop-
ipv6-dns-issues-07.txt, work-in-progress, May 2004. ipv6-dns-issues-08.txt, work-in-progress, July 2004.
[KM97] Kent, C., and J. Mogul, "Fragmentation Considered Harmful". [KM97] Kent, C., and J. Mogul, "Fragmentation Considered Harmful".
In Proc. SIGCOMM '87 Workshop on Frontiers in Computer In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
Communications Technology. August 1987. Communications Technology. August 1987.
[V6SEC] P. Savola, "IPv6 Transition/Co-existence Security [V6SEC] P. Savola, "IPv6 Transition/Co-existence Security
Considerations", draft-savola-v6ops-security-overview- Considerations", draft-savola-v6ops-security-overview-
02.txt, work-in-progress, February 2004. 02.txt, work-in-progress, February 2004.
[V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-IPv4 [V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-IPv4
skipping to change at page 27, line 34 skipping to change at page 27, line 34
IPv6 MTU leads to likely interoperability problems. IPv6 MTU leads to likely interoperability problems.
- Added an explicit requirement that if both MTU determination - Added an explicit requirement that if both MTU determination
methods are used, choosing one should be possible on a per- methods are used, choosing one should be possible on a per-
tunnel basis. tunnel basis.
- Clarified that ICMPv4 error handling is only applicable to - Clarified that ICMPv4 error handling is only applicable to
dynamic MTU determination. dynamic MTU determination.
- Removed/clarified DNS record filtering; an API is a SHOULD and - Removed/clarified DNS record filtering; an API is a SHOULD and
if it does not exist, MUST NOT filter anything. Refer more if it does not exist, MUST NOT filter anything. Decree ordering
strongly to RFC3484 on the DNS record ordering/processing. out of scope, but refer to RFC3484.
- Add a note that the destination IPv4 address could also be a - Add a note that the destination IPv4 address could also be a
multicast address. multicast address.
- Make it RECOMMENDED to provide a toggle to perform strict - Make it RECOMMENDED to provide a toggle to perform strict
ingress filtering on an interface. ingress filtering on an interface.
- Generalize the text on the data in ICMPv4 messages.
- Made a lot of miscellaneous editorial cleanups. - Made a lot of miscellaneous editorial cleanups.
9.1. Changes from draft-ietf-v6ops-mech-v2-00 9.1. Changes from draft-ietf-v6ops-mech-v2-00
[[ RFC-Editor note: remove the change history between the drafts [[ RFC-Editor note: remove the change history between the drafts
before publication. ]] before publication. ]]
- Clarified in section 2.2 that there is no assumption that the - Clarified in section 2.2 that there is no assumption that the
DNS server knows the IPv4/IPv6 capabilities of the requesting DNS server knows the IPv4/IPv6 capabilities of the requesting
node. node.
skipping to change at page 30, line 46 skipping to change at page 31, line 4
- Refer to separate documents on generic IPv6 security - Refer to separate documents on generic IPv6 security
considerations and IPsec set-up details. considerations and IPsec set-up details.
- Clarify that the IPv4 end-point address can be predictable in - Clarify that the IPv4 end-point address can be predictable in
some situations. some situations.
- Add a note that the destination IPv4 address could also be a - Add a note that the destination IPv4 address could also be a
multicast address. multicast address.
- Make it RECOMMENDED to provide a toggle to perform strict - Make it RECOMMENDED to provide a toggle to perform strict
ingress filtering on an interface. ingress filtering on an interface. sp 2
9.4. Changes from draft-ietf-v6ops-mech-v2-03
- Generalize the text in section 3.4 about the data included in
ICMPv4 messages.
- Decree the address selection ordering mechanism out of scope for
this spec.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/