draft-ietf-v6ops-mech-v2-04.txt   draft-ietf-v6ops-mech-v2-05.txt 
INTERNET-DRAFT E. Nordmark INTERNET-DRAFT E. Nordmark
July 19, 2004 Sun Microsystems, Inc. August 25, 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-04.txt> <draft-ietf-v6ops-mech-v2-05.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 33 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 January 19, 2004. This draft expires on February 25, 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 45
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............ 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
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 38 skipping to change at page 4, line 38
IPv6-over-IPv4 tunneling: IPv6-over-IPv4 tunneling:
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 is determined by configuration information on address(es) are determined by configuration information
the encapsulator. All tunnels are assumed to be on tunnel endpoints. All tunnels are assumed to be
bidirectional, behaving as virtual point-to-point links. bidirectional. At the IPv6 layer the tunnel provides a
(virtual) point-to-point link, the lower layer endpoints
of which are the configured IPv4 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 41 skipping to change at page 7, line 41
encapsulating IPv4 header and transmits the encapsulated packet. encapsulating IPv4 header and transmits the encapsulated packet.
- The exit node of the tunnel (the decapsulator) receives the - The exit node of the tunnel (the decapsulator) receives the
encapsulated packet, reassembles the packet if needed, removes encapsulated packet, reassembles the packet if needed, removes
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 address is determined In configured tunneling, the tunnel endpoint addresses are determined
from configuration information in the encapsulator. For each tunnel, in the encapsulator from configuration information stored for each
the encapsulator must store the tunnel endpoint address. When an tunnel. When an IPv6 packet is transmitted over a tunnel, the
IPv6 packet is transmitted over a tunnel, the tunnel endpoint address destination and source addresses for the encapsulating IPv4 header
configured for that tunnel is used as the destination address for the are set based on that information as described in Section 3.5.
encapsulating IPv4 header.
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
tunnels it has configured, and allows only the packets where IPv4
source addresses match the tunnels configured on the decapsulator.
Therefore the operator must ensure that the tunnel's IPv4 address
configuration is the same both at the encapsulator and the
decapsulator.
3.1. Encapsulation 3.1. Encapsulation
The encapsulation of an IPv6 datagram in IPv4 is shown below: The encapsulation of an IPv6 datagram in IPv4 is shown below:
+-------------+ +-------------+
| IPv4 | | IPv4 |
| Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| IPv6 | | IPv6 | | IPv6 | | IPv6 |
| Header | | Header | | Header | | Header |
skipping to change at page 8, line 41 skipping to change at page 9, line 4
too big" error back to the source. too big" error back to the source.
- How to reflect ICMPv4 errors from routers along the tunnel path - How to reflect ICMPv4 errors from routers along the tunnel path
back to the source as ICMPv6 errors. back to the source as ICMPv6 errors.
Those issues are discussed in the following sections. Those issues are discussed in the following sections.
3.2. Tunnel MTU and Fragmentation 3.2. Tunnel MTU and Fragmentation
Naively the encapsulator could view encapsulation as IPv6 using IPv4 Naively the encapsulator could view encapsulation as IPv6 using IPv4
as a link layer with a very large MTU (65535-20 bytes to be exact; 20 as a link layer with a very large MTU (65535-20 bytes at most; 20
bytes "extra" are needed for the encapsulating IPv4 header). The bytes "extra" are needed for the encapsulating IPv4 header). The
encapsulator would only need to report ICMPv6 "packet too big" errors encapsulator would only need to report ICMPv6 "packet too big" errors
back to the source for packets that exceed this MTU. However, such a back to the source for packets that exceed this MTU. However, such a
scheme would be inefficient or non-interoperable for three reasons scheme would be inefficient or non-interoperable for three reasons
and therefore MUST NOT be used: and therefore MUST NOT be used:
1) It would result in more fragmentation than needed. IPv4 layer 1) It would result in more fragmentation than needed. IPv4 layer
fragmentation should be avoided due to the performance problems fragmentation should be avoided due to the performance problems
caused by the loss unit being smaller than the retransmission caused by the loss unit being smaller than the retransmission
unit [KM97]. unit [KM97].
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:
IPv4 address of outgoing interface of the encapsulator An IPv4 address of the encapsulator: either manually
or an administratively specified address as described configured or an address of the outgoing interface.
below.
Destination Address: Destination Address:
IPv4 address of the tunnel endpoint. IPv4 address of the tunnel endpoint.
When encapsulating the packets, the nodes must ensure that they will When encapsulating the packets, the node must ensure that it will use
use the source address that the tunnel peer has configured, so that the correct source address so that the packets are acceptable to the
the source addresses are acceptable to the decapsulator. This may be decapsulator as described in Section 3.6. This may be a problem with
a problem with multi-addressed, and in particular, multi-interface multi-addressed, and in particular, multi-interface nodes, especially
nodes, especially when the routing is changed from a stable when the routing is changed from a stable condition, as the source
condition, as the source address selection may be adversely affected. address selection may be adversely affected. Therefore, it SHOULD be
Therefore, it SHOULD be possible to administratively specify the possible to administratively specify the source address of a tunnel.
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 part of a tunnel 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
be submitted to the IPv6 layer code on the node. be submitted to the IPv6 layer code on the node.
The decapsulator MUST verify that the tunnel source address is The decapsulator MUST verify that the tunnel source address is
correct before further processing packets, to mitigate the problems correct before further processing packets, to mitigate the problems
with address spoofing (see section 4). This check also applies to with address spoofing (see section 4). This check also applies to
packets which are delivered to transport protocols on the packets which are delivered to transport protocols on the
decapsulator. This is done by verifying that the source address is decapsulator. This is done by verifying that the source address is
the IPv4 address of the other end of a tunnel configured on the node. the IPv4 address of the encapsulator, as configured on the
decapsulator. Packets for which the IPv4 source address does not
Packets for which the IPv4 source address does not match MUST be match MUST be discarded and an ICMP message SHOULD NOT be generated;
discarded and an ICMP message SHOULD NOT be generated; however, if however, if the implementation normally sends an ICMP message when
the implementation normally sends an ICMP message when receiving an receiving an unknown protocol packet, such an error message MAY be
unknown protocol packet, such an error message MAY be sent (e.g., sent (e.g., ICMPv4 Protocol 41 Unreachable).
ICMPv4 Protocol 41 Unreachable).
A side effect of this address verification is that the node will A side effect of this address verification is that the node will
silently discard packets with a wrong source address, and packets silently discard packets with a wrong source address, and packets
which were received by the node but not directly addressed to it which were received by the node but not directly addressed to it
(e.g., broadcast addresses). (e.g., broadcast addresses).
Independent of any other forms of IPv4 ingress filtering the Independent of any other forms of IPv4 ingress filtering the
administrator of the node may have configured to perform, the administrator of the node may have configured, the implementation MAY
implementation MAY perform ingress filtering, i.e., check that the perform ingress filtering, i.e., check that the packet is arriving
packet is arriving from the interface in the direction of the route from the interface in the direction of the route towards the tunnel
towards the tunnel end-point, similar to a Strict Reverse Path end-point, similar to a Strict Reverse Path Forwarding (RPF) check
Forwarding (RPF) check [RFC3704]. As this may cause problems on [RFC3704]. As this may cause problems on tunnels which are routed
tunnels which are routed through multiple links, it is RECOMMENDED through multiple links, it is RECOMMENDED that this check, if done,
that this check, if done, is disabled by default. The packets caught is disabled by default. The packets caught by this check SHOULD be
by this check SHOULD be discarded; an ICMP message SHOULD NOT be discarded; an ICMP message SHOULD NOT be generated by default.
generated by default.
The decapsulator MUST be capable of having, on the tunnel interfaces, The decapsulator MUST be capable of having, on the tunnel interfaces,
an IPv6 MRU of at least the maximum of of 1500 bytes and the largest an IPv6 MRU of at least the maximum of of 1500 bytes and the largest
(IPv6) interface MTU on the decapsulator. (IPv6) interface MTU on the decapsulator.
The decapsulator MUST be capable of reassembling an IPv4 packet that The decapsulator MUST be capable of reassembling an IPv4 packet that
is (after the reassembly) the maximum of 1500 bytes and the largest is (after the reassembly) the maximum of 1500 bytes and the largest
(IPv4) interface MTU on the decapsulator. The 1500 byte number is a (IPv4) interface MTU on the decapsulator. The 1500 byte number is a
result of encapsulators that use the static MTU scheme in section result of encapsulators that use the static MTU scheme in section
3.2.1, while encapsulators that use the dynamic scheme in section 3.2.1, while encapsulators that use the dynamic scheme in section
skipping to change at page 17, line 23 skipping to change at page 17, line 23
| Layer | ===> | Layer | | Layer | ===> | Layer |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
~ Data ~ ~ Data ~ ~ Data ~ ~ Data ~
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
Decapsulating IPv6 from IPv4 Decapsulating IPv6 from IPv4
The decapsulator performs IPv4 reassembly before decapsulating the
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.
The decapsulator performs IPv4 reassembly before decapsulating the If the payload is not at least 40 bytes in length (i.e., the minimum
IPv6 packet. IPv6 packet), the packet MUST be discarded. Likewise, if the the
version encoded in the first 4 bits of the encapsulated packet is not
"6", the packet MUST be discarded.
The encapsulating IPv4 header is discarded. When reconstructing the The encapsulating IPv4 header is discarded. When reconstructing the
IPv6 packet the length MUST be determined from the IPv6 payload IPv6 packet the length MUST be determined from the IPv6 payload
length since the IPv4 packet might be padded (thus have a length length since the IPv4 packet might be padded (thus have a length
which is larger than the IPv6 packet plus the IPv4 header being which is larger than the IPv6 packet plus the IPv4 header being
removed). 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:
skipping to change at page 21, line 26 skipping to change at page 21, line 26
being 255 and/or the addresses being link-local for ensuring that a being 255 and/or the addresses being link-local for ensuring that a
packet originated on-link, in a semi-trusted environment. Tunnels packet originated on-link, in a semi-trusted environment. Tunnels
are more vulnerable to a breach of this assumption than physical are more vulnerable to a breach of this assumption than physical
links, as an attacker anywhere in the Internet can send an IPv6-in- links, as an attacker anywhere in the Internet can send an IPv6-in-
IPv4 packet to the tunnel decapsulator, causing injection of an IPv4 packet to the tunnel decapsulator, causing injection of an
encapsulted IPv6 packet to the configured tunnel interface unless the encapsulted IPv6 packet to the configured tunnel interface unless the
decapsulation checks are able to discard packets injected in such a decapsulation checks are able to discard packets injected in such a
manner. manner.
Therefore, this memo specifies that the decapsulators make these Therefore, this memo specifies that the decapsulators make these
steps to mitigate this threat: steps (as described in Section 3.6) to mitigate this threat:
- IPv4 source address of the packet MUST be the same as configured - IPv4 source address of the packet MUST be the same as configured
for the tunnel end-point, for the tunnel end-point,
- Independent of any IPv4 ingress filtering the administrator may - Independent of any IPv4 ingress filtering the administrator may
have configured, the implementation MAY perform IPv4 ingress have configured, the implementation MAY perform IPv4 ingress
filtering to check that the IPv4 packets are received from an filtering to check that the IPv4 packets are received from an
expected interface (but as this may cause some problems, it may expected interface (but as this may cause some problems, it may
be disabled by default), be disabled by default),
skipping to change at page 22, line 38 skipping to change at page 22, line 38
for other protocols may hint that the IPv6 stack (or the protocol 41 for other protocols may hint that the IPv6 stack (or the protocol 41
tunneling processing) has been enabled -- the behaviour should be tunneling processing) has been enabled -- the behaviour should be
consistent on how the implementation otherwise behaves to be consistent on how the implementation otherwise behaves to be
transparent to probing. transparent to probing.
6. Acknowledgments 6. Acknowledgments
We would like to thank the members of the IPv6 working group, the We would like to thank the members of the IPv6 working group, the
Next Generation Transition (ngtrans) working group, and the v6ops Next Generation Transition (ngtrans) working group, and the v6ops
working group for their many contributions and extensive review of working group for their many contributions and extensive review of
this document. Special thanks are due to Jim Bound, Ross Callon, Bob this document. Special thanks are due to (in alphabetical order) Jim
Hinden, Bill Manning, John Moy, Mohan Parthasarathy, Pekka Savola, Bound, Ross Callon, Tim Chown, Alex Conta, Bob Hinden, Bill Manning,
Fred Templin, Chirayu Patel, and Tim Chown for many helpful John Moy, Mohan Parthasarathy, Chirayu Patel, Pekka Savola, and Fred
suggestions. Pekka Savola helped in editing the final revisions of Templin for many helpful suggestions. Pekka Savola helped in editing
the specification. the final revisions of the specification.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981.
[RFC1191] Mogul, J., and S. Deering., "Path MTU Discovery", RFC 1191, [RFC1191] Mogul, J., and S. Deering., "Path MTU Discovery", RFC 1191,
November 1990. November 1990.
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-08.txt, work-in-progress, July 2004. ipv6-dns-issues-09.txt, work-in-progress, August 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
Tunnels", draft-tschofenig-v6ops-secure-tunnels-00.txt, Tunnels", draft-tschofenig-v6ops-secure-tunnels-01.txt,
work-in-progress, June 2004. work-in-progress, July 2004.
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989. Layers", STD 3, RFC 1122, October 1989.
[RFC1435] S. Knowles, "IESG Advice from Experience with Path MTU [RFC1435] S. Knowles, "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993. Discovery", RFC 1435, March 1993.
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812,
June 1995. June 1995.
skipping to change at page 26, line 48 skipping to change at page 26, line 48
- Fixed reference to Assigned Numbers to be to online version - Fixed reference to Assigned Numbers to be to online version
(with proper pointer to "Assigned Numbers is obsolete" RFC). (with proper pointer to "Assigned Numbers is obsolete" RFC).
- Clarified text about ingress filtering e.g. that it applies to - Clarified text about ingress filtering e.g. that it applies to
packet delivered to transport protocols on the decapsulator as packet delivered to transport protocols on the decapsulator as
well as packets being forwarded by the decapsulator, and how the well as packets being forwarded by the decapsulator, and how the
decapsulator's checks help when IPv4 and IPv6 ingress filtering decapsulator's checks help when IPv4 and IPv6 ingress filtering
is in place. is in place.
- Removed unidirectional tunneling; assume all tunnels are - Removed unidirectional tunneling; assume all tunnels are
bidirectional. bidirectional, between endpoint addresses (not nodes).
- Removed the guidelines for advertising addresses in DNS as - Removed the guidelines for advertising addresses in DNS as
slightly out of scope, referring to another document for the slightly out of scope, referring to another document for the
details. details.
- Removed the SHOULD requirement that the link-local addresses - Removed the SHOULD requirement that the link-local addresses
should be formed based on IPv4 addresses. should be formed based on IPv4 addresses.
- Added a SHOULD for implementing a knob to be able to set the - Added a SHOULD for implementing a knob to be able to set the
source address of the tunnel, and add discussion why this is source address of the tunnel, and add discussion why this is
useful. useful.
- Added stronger wording for source address checks: both IPv4 and - Added stronger wording for source address checks: both IPv4 and
IPv6 source addresses MUST be checked, and RPF-like ingress IPv6 source addresses MUST be checked, and RPF-like ingress
filtering is optional. filtering is optional.
- Rewrote security considerations to be more precise about the - Rewrote security considerations to be more precise about the
threats of tunneling. threats of tunneling.
- Added a note that using TTL=255 when encapsulating might be - Added a note about considering using TTL=255 when encapsulating.
useful for decapsulation security checks later on.
- Added more discussion in Section 3.2 why using an "infinite" - Added more discussion in Section 3.2 why using an "infinite"
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.
skipping to change at page 27, line 45 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 4 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. sp 2 ingress filtering on an interface.
9.4. Changes from draft-ietf-v6ops-mech-v2-03 9.4. Changes from draft-ietf-v6ops-mech-v2-03
- 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
- Reword the definition of a configured tunnel to be more up-to-
todate, and to specify that the tunnel is between addresses, not
hosts.
- Spell out that the source address is expected to be the
encapsulator's IPv4 address.
- Require that IP version of the data is 6, and that the length is
at least 40 bytes.
- Some minor 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/