draft-ietf-v6ops-mech-v2-05.txt   draft-ietf-v6ops-mech-v2-06.txt 
INTERNET-DRAFT E. Nordmark INTERNET-DRAFT E. Nordmark
August 25, 2004 Sun Microsystems, Inc. September 1, 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-05.txt> <draft-ietf-v6ops-mech-v2-06.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 34
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 February 25, 2004. This draft expires on March 1, 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 3, line 4 skipping to change at page 2, line 46
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............ 28 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 9.4. Changes from draft-ietf-v6ops-mech-v2-03............ 31
9.5. Changes from draft-ietf-v6ops-mech-v2-04............ 31 9.5. Changes from draft-ietf-v6ops-mech-v2-04............ 31
9.6. Changes from draft-ietf-v6ops-mech-v2-05............ 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 4, line 40 skipping to change at page 4, line 40
The technique of encapsulating IPv6 packets within IPv4 The technique of encapsulating IPv6 packets within IPv4
so that they can be carried across IPv4 routing so that they can be carried across IPv4 routing
infrastructures. infrastructures.
Configured tunneling: Configured tunneling:
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint
address(es) are determined by configuration information address(es) are determined by configuration information
on tunnel endpoints. All tunnels are assumed to be on tunnel endpoints. All tunnels are assumed to be
bidirectional. At the IPv6 layer the tunnel provides a bidirectional. The tunnel provides a (virtual) point-
(virtual) point-to-point link, the lower layer endpoints to-point link to the IPv6 layer, using the configured
of which are the configured IPv4 addresses. IPv4 addresses as the lower layer endpoint addresses.
Other transition mechanisms, including other tunneling mechanisms, Other transition mechanisms, including other tunneling mechanisms,
are outside the scope of this document. are outside the scope of this document.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119]. document, are to be interpreted as described in [RFC2119].
2. Dual IP Layer Operation 2. Dual IP Layer Operation
skipping to change at page 7, line 45 skipping to change at page 7, line 45
the IPv4 header, and processes the received IPv6 packet. the IPv4 header, and processes the received IPv6 packet.
- The encapsulator may need to maintain soft state information for - The encapsulator may need to maintain soft state information for
each tunnel recording such parameters as the MTU of the tunnel each tunnel recording such parameters as the MTU of the tunnel
in order to process IPv6 packets forwarded into the tunnel. in order to process IPv6 packets forwarded into the tunnel.
In configured tunneling, the tunnel endpoint addresses are determined In configured tunneling, the tunnel endpoint addresses are determined
in the encapsulator from configuration information stored for each in the encapsulator from configuration information stored for each
tunnel. When an IPv6 packet is transmitted over a tunnel, the tunnel. When an IPv6 packet is transmitted over a tunnel, the
destination and source addresses for the encapsulating IPv4 header destination and source addresses for the encapsulating IPv4 header
are set based on that information as described in Section 3.5. are set as described in Section 3.5.
The determination of which packets to tunnel is usually made by The determination of which packets to tunnel is usually made by
routing information on the encapsulator. This is usually done via a routing information on the encapsulator. This is usually done via a
routing table, which directs packets based on their destination routing table, which directs packets based on their destination
address using the prefix mask and match technique. address using the prefix mask and match technique.
The decapsulator matches the received protocol-41 packets to the The decapsulator matches the received protocol-41 packets to the
tunnels it has configured, and allows only the packets where IPv4 tunnels it has configured, and allows only the packets where IPv4
source addresses match the tunnels configured on the decapsulator. source addresses match the tunnels configured on the decapsulator.
Therefore the operator must ensure that the tunnel's IPv4 address Therefore the operator must ensure that the tunnel's IPv4 address
skipping to change at page 15, line 16 skipping to change at page 15, line 16
Protocol: Protocol:
41 (Assigned payload type number for IPv6). 41 (Assigned payload type number for IPv6).
Header Checksum: Header Checksum:
Calculate the checksum of the IPv4 header. [RFC791] Calculate the checksum of the IPv4 header. [RFC791]
Source Address: Source Address:
An IPv4 address of the encapsulator: either manually An IPv4 address of the encapsulator: either configured
configured or an address of the outgoing interface. by the administrator or an address of the outgoing
interface.
Destination Address: Destination Address:
IPv4 address of the tunnel endpoint. IPv4 address of the tunnel endpoint.
When encapsulating the packets, the node must ensure that it will use When encapsulating the packets, the node must ensure that it will use
the correct source address so that the packets are acceptable to the the correct source address so that the packets are acceptable to the
decapsulator as described in Section 3.6. This may be a problem with decapsulator as described in Section 3.6. Configuring the source
multi-addressed, and in particular, multi-interface nodes, especially address is appropriate particularly in cases in which automatic
when the routing is changed from a stable condition, as the source selection of source address may produce different results in a
address selection may be adversely affected. Therefore, it SHOULD be certain period of time. This is often the case with multiple
possible to administratively specify the source address of a tunnel. addresses, and multiple interfaces, or when routes may change
frequently. Therefore, it SHOULD be possible to administratively
specify the source address of a tunnel.
3.6. Decapsulation 3.6. Decapsulation
When an IPv6/IPv4 host or a router receives an IPv4 datagram that is When an IPv6/IPv4 host or a router receives an IPv4 datagram that is
addressed to one of its own IPv4 addresses or a joined multicast addressed to one of its own IPv4 addresses or a joined multicast
group address, and the value of the protocol field is 41, the packet group address, and the value of the protocol field is 41, the packet
is potentially a tunnel packet and needs to be verified to belong to is potentially a tunnel packet and needs to be verified to belong to
one of the configured tunnel interfaces (by checking one of the configured tunnel interfaces (by checking
source/destination addresses), reassembled (if fragmented at the IPv4 source/destination addresses), reassembled (if fragmented at the IPv4
level), have the IPv4 header removed and the resulting IPv6 datagram level), have the IPv4 header removed and the resulting IPv6 datagram
skipping to change at page 17, line 31 skipping to change at page 17, line 31
Decapsulating IPv6 from IPv4 Decapsulating IPv6 from IPv4
The decapsulator performs IPv4 reassembly before decapsulating the The decapsulator performs IPv4 reassembly before decapsulating the
IPv6 packet. IPv6 packet.
When decapsulating the packet, the IPv6 header is not modified. When decapsulating the packet, the IPv6 header is not modified.
(However, see [RFC2983] and [RFC3168] section 9.1 for issues relating (However, see [RFC2983] and [RFC3168] section 9.1 for issues relating
to the Type of Service byte and tunneling.) If the packet is to the Type of Service byte and tunneling.) If the packet is
subsequently forwarded, its hop limit is decremented by one. subsequently forwarded, its hop limit is decremented by one.
If the payload is not at least 40 bytes in length (i.e., the minimum The encapsulating IPv4 header is discarded, and the resulting packet
IPv6 packet), the packet MUST be discarded. Likewise, if the the is checked for validity when submitted to the IPv6 layer. When
version encoded in the first 4 bits of the encapsulated packet is not reconstructing the IPv6 packet the length MUST be determined from the
"6", the packet MUST be discarded. IPv6 payload length since the IPv4 packet might be padded (thus have
a length which is larger than the IPv6 packet plus the IPv4 header
The encapsulating IPv4 header is discarded. When reconstructing the being removed).
IPv6 packet the length MUST be determined from the IPv6 payload
length since the IPv4 packet might be padded (thus have a length
which is larger than the IPv6 packet plus the IPv4 header being
removed).
After the decapsulation the node MUST silently discard a packet with After the decapsulation the node MUST silently discard a packet with
an invalid IPv6 source address. The list of invalid source addresses an invalid IPv6 source address. The list of invalid source addresses
SHOULD include at least: SHOULD include at least:
- all multicast addresses (FF00::/8) - all multicast addresses (FF00::/8)
- the loopback address (::1) - the loopback address (::1)
- all the IPv4-compatible IPv6 addresses [RFC3513] (::/96), - all the IPv4-compatible IPv6 addresses [RFC3513] (::/96),
skipping to change at page 27, line 44 skipping to change at page 27, line 44
out of scope, but refer to RFC3484. 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. - Generalize the text on the data in ICMPv4 messages.
- Require that IP version of the data is 6, and that the payload
is at least 40 bytes.
- 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 31, line 17 skipping to change at page 31, line 17
- Generalize the text in section 3.4 about the data included in - Generalize the text in section 3.4 about the data included in
ICMPv4 messages. ICMPv4 messages.
- Decree the address selection ordering mechanism out of scope for - Decree the address selection ordering mechanism out of scope for
this spec. this spec.
9.5. Changes from draft-ietf-v6ops-mech-v2-04 9.5. Changes from draft-ietf-v6ops-mech-v2-04
- Reword the definition of a configured tunnel to be more up-to- - Reword the definition of a configured tunnel to be more up-to-
todate, and to specify that the tunnel is between addresses, not date, and to specify that the tunnel is between addresses, not
hosts. hosts.
- Spell out that the source address is expected to be the - Spell out that the source address is expected to be the
encapsulator's IPv4 address. encapsulator's IPv4 address.
- Require that IP version of the data is 6, and that the length is - Require that IP version of the data is 6, and that the length is
at least 40 bytes. at least 40 bytes.
- Some minor editorial clarifications. - Some minor editorial clarifications.
9.6. Changes from draft-ietf-v6ops-mech-v2-05
- Removed the requirement for IP version = 6 and the length checks
in *this* memo.
- Editorial clarifications.
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/