draft-ietf-v6ops-mech-v2-02.txt   draft-ietf-v6ops-mech-v2-03.txt 
INTERNET-DRAFT E. Nordmark INTERNET-DRAFT E. Nordmark
January 30, 2004 Sun Microsystems, Inc. June 15, 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-02.txt> <draft-ietf-v6ops-mech-v2-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, I certify that any applicable
of Section 10 of RFC2026. 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
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 July 30, 2004. This draft expires on December 15, 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 19 skipping to change at page 2, line 19
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.......................... 7
3.1. Encapsulation....................................... 8 3.1. Encapsulation....................................... 8
3.2. Tunnel MTU and Fragmentation........................ 9 3.2. Tunnel MTU and Fragmentation........................ 9
3.2.1. Static Tunnel MTU.............................. 10 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........................................... 12 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..................... 18 3.8. Neighbor Discovery over Tunnels..................... 19
4. Threat Related to Source Address Spoofing................ 19 4. Threat Related to Source Address Spoofing................ 20
5. Security Considerations.................................. 20 5. Security Considerations.................................. 21
6. Acknowledgments.......................................... 22 6. Acknowledgments.......................................... 22
7. References............................................... 22 7. References............................................... 23
7.1. Normative References................................ 22 7.1. Normative References................................ 23
7.2. Non-normative References............................ 22 7.2. Informative References.............................. 23
8. Authors' Addresses....................................... 24 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............ 27
9.2. Changes from draft-ietf-v6ops-mech-v2-01............ 28 9.2. Changes from draft-ietf-v6ops-mech-v2-01............ 29
9.3. Changes from draft-ietf-v6ops-mech-v2-02............ 30
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 5, line 9 skipping to change at page 5, line 9
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
The most straightforward way for IPv6 nodes to remain compatible with The most straightforward way for IPv6 nodes to remain compatible with
IPv4-only nodes is by providing a complete IPv4 implementation. IPv6 IPv4-only nodes is by providing a complete IPv4 implementation. IPv6
nodes that provide a complete IPv4 and IPv6 implementations are nodes that provide complete IPv4 and IPv6 implementations are called
called "IPv6/IPv4 nodes." IPv6/IPv4 nodes have the ability to send "IPv6/IPv4 nodes." IPv6/IPv4 nodes have the ability to send and
and receive both IPv4 and IPv6 packets. They can directly receive both IPv4 and IPv6 packets. They can directly interoperate
interoperate with IPv4 nodes using IPv4 packets, and also directly with IPv4 nodes using IPv4 packets, and also directly interoperate
interoperate with IPv6 nodes using IPv6 packets. with IPv6 nodes using IPv6 packets.
Even though a node may be equipped to support both protocols, one or Even though a node may be equipped to support both protocols, one or
the other stack may be disabled for operational reasons. Here we use the other stack may be disabled for operational reasons. Here we use
a rather loose notion of "stack". A stack being enabled has IP a rather loose notion of "stack". A stack being enabled has IP
addresses assigned etc, but whether or not any particular application addresses assigned etc, but whether or not any particular application
is available on the stacks is explicitly not defined. Thus IPv6/IPv4 is available on the stacks is explicitly not defined. Thus IPv6/IPv4
nodes may be operated in one of three modes: nodes may be operated in one of three modes:
- With their IPv4 stack enabled and their IPv6 stack disabled. - With their IPv4 stack enabled and their IPv6 stack disabled.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
2.2. DNS 2.2. DNS
The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map
between hostnames and IP addresses. A new resource record type named between hostnames and IP addresses. A new resource record type named
"AAAA" has been defined for IPv6 addresses [RFC3596]. Since "AAAA" has been defined for IPv6 addresses [RFC3596]. Since
IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 IPv6/IPv4 nodes must be able to interoperate directly with both IPv4
and IPv6 nodes, they must provide resolver libraries capable of and IPv6 nodes, they must provide resolver libraries capable of
dealing with IPv4 "A" records as well as IPv6 "AAAA" records. Note dealing with IPv4 "A" records as well as IPv6 "AAAA" records. Note
that the lookup of A versus AAAA records is independent of whether that the lookup of A versus AAAA records is independent of whether
the DNS packets are carried in IPv4 or IPv6 packets, and that there the DNS packets are carried in IPv4 or IPv6 packets, and that there
is no assumption that the DNS server know the IPv4/IPv6 capabilities is no assumption that the DNS servers know the IPv4/IPv6 capabilities
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 filter or order the results address, the resolver library MAY order the results returned to the
returned to the application in order to influence the version of IP application in order to influence the version of IP packets used to
packets used to communicate with that node. In terms of filtering, communicate with that node -- IPv6 first, or IPv4 first.
the resolver library has three alternatives:
- Return only the IPv6 address(es) to the application.
- Return only the IPv4 address(es) to the application.
- Return both types of addresses to the application.
If it returns only the IPv6 address(es), the application will
communicate with the node using IPv6. If it returns only the IPv4
address(es), the application will communicate with the node using
IPv4. If it returns both types of addresses, the application will
have the choice which address to use, and thus which IP protocol to
employ.
If it returns both, the resolver MAY elect to order the addresses -- The applications SHOULD be able to specify whether they want IPv4,
IPv6 first, or IPv4 first. Since most applications try the addresses IPv6 or both records [RFC3493]. That defines which address families
in the order they are returned by the resolver, this can affect the the resolver looks up. If there isn't an application choice, or if
IP version "preference" of applications. the application has requested both, the resolver library MUST NOT
filter out any records.
A resolver library performing filtering or ordering of addresses Since most applications try the addresses in the order they are
might also want to take into account external factors such as, returned by the resolver, this can affect the IP version "preference"
whether IPv6 interfaces have been configured on the node. of applications.
The decision to filter or order DNS results is implementation A resolver library performing ordering of addresses might also want
specific. IPv6/IPv4 nodes MAY provide policy configuration to to take into account external factors such as, whether IPv6
control filtering or ordering of addresses returned by the resolver interfaces have been configured on the node.
-- i.e., which addresses to filter or which order to sort -- or leave
the decision entirely up to the application.
An implementation MUST allow the application to control whether or The decision to order DNS results is implementation specific.
not such filtering takes place. 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.
More details on the relative preferences of IPv4 and IPv6 addresses This is a bare minimum DNS processing implementation for dual-stack
are specified in the default address selection document [RFC3484]. 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 12, line 23 skipping to change at page 12, line 15
The single-hop model is implemented by having the encapsulators and The single-hop model is implemented by having the encapsulators and
decapsulators process the IPv6 hop limit field as they would if they decapsulators process the IPv6 hop limit field as they would if they
were forwarding a packet on to any other datalink. That is, they were forwarding a packet on to any other datalink. That is, they
decrement the hop limit by 1 when forwarding an IPv6 packet. (The decrement the hop limit by 1 when forwarding an IPv6 packet. (The
originating node and final destination do not decrement the hop originating node and final destination do not decrement the hop
limit.) limit.)
The TTL of the encapsulating IPv4 header is selected in an The TTL of the encapsulating IPv4 header is selected in an
implementation dependent manner. The current suggested value is implementation dependent manner. The current suggested value is
published in the "Assigned Numbers" RFC [RFC3232][ASSIGNED]. The published in the "Assigned Numbers" RFC [RFC3232][ASSIGNED]. The
implementations MAY also consider using the value 255, as it could be implementations MAY also consider using the value 255.
used as a hint in the decapsulation checks in the future [GTSM].
Implementations MAY provide a mechanism to allow the administrator to Implementations MAY provide a mechanism to allow the administrator to
configure the IPv4 TTL as the IP Tunnel MIB [RFC2667]. configure the IPv4 TTL as the IP Tunnel MIB [RFC2667].
3.4. Handling ICMPv4 errors 3.4. Handling ICMPv4 errors
In response to encapsulated packets it has sent into the tunnel, the In response to encapsulated packets it has sent into the tunnel, the
encapsulator might receive ICMPv4 error messages from IPv4 routers encapsulator might receive ICMPv4 error messages from IPv4 routers
inside the tunnel. These packets are addressed to the encapsulator inside the tunnel. These packets are addressed to the encapsulator
because it is the IPv4 source of the encapsulated packet. because it is the IPv4 source of the encapsulated packet.
skipping to change at page 15, line 46 skipping to change at page 15, line 33
the source addresses are acceptable to the decapsulator. This may be the source addresses are acceptable to the decapsulator. This may be
a problem with multi-addressed, and in particular, multi-interface a problem with multi-addressed, and in particular, multi-interface
nodes, especially when the routing is changed from a stable nodes, especially when the routing is changed from a stable
condition, as the source address selection may be adversely affected. condition, as the source address selection may be adversely affected.
Therefore, it SHOULD be possible to administratively specify the Therefore, it SHOULD be 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, and the value of the addressed to one of its own IPv4 addresses or a joined multicast
protocol field is 41, the packet is potentially part of a tunnel and group address, and the value of the protocol field is 41, the packet
needs to be verified to belong to one of the configured tunnel is potentially part of a tunnel and needs to be verified to belong to
interfaces (by checking source/destination addresses), reassembled one of the configured tunnel interfaces (by checking
(if fragmented at the IPv4 level), have the IPv4 header removed and source/destination addresses), reassembled (if fragmented at the IPv4
the resulting IPv6 datagram be submitted to the IPv6 layer code on level), have the IPv4 header removed and the resulting IPv6 datagram
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 other end of a tunnel configured on the node.
Packets for which the IPv4 source address does not match MUST be Packets for which the IPv4 source address does not match MUST be
discarded and an ICMP message SHOULD NOT be generated; however, if discarded and an ICMP message SHOULD NOT be generated; however, if
the implementation normally sends an ICMP message when receiving an the implementation normally sends an ICMP message when receiving an
unknown protocol packet, such an error message MAY be sent (e.g., unknown protocol packet, such an error message MAY be 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).
In addition, the node MAY perform ingress filtering [RFC2827] on the Independent of any other forms of IPv4 ingress filtering the
IPv4 source address, i.e., check that the packet is arriving from the administrator of the node may have configured to perform, the
interface in the direction of the route towards the tunnel end-point, implementation MAY perform ingress filtering, i.e., check that the
similar to a Strict Reverse Path Forwarding (RPF) check [BCP38UPD]. packet is arriving from the interface in the direction of the route
If done, it is RECOMMENDED that this check is disabled by default. towards the tunnel end-point, similar to a Strict Reverse Path
The packets caught by this check SHOULD be discarded; an ICMP message Forwarding (RPF) check [RFC3704]. As this may cause problems on
SHOULD NOT be generated by default. tunnels which are routed through multiple links, it is RECOMMENDED
that this check, if done, is disabled by default. The packets caught
by this check SHOULD be discarded; an ICMP message SHOULD NOT be
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 18, line 4 skipping to change at page 18, line 4
- 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),
excluding the unspecified address for Duplicate Address excluding the unspecified address for Duplicate Address
Detection (::/128) Detection (::/128)
- all the IPv4-mapped IPv6 addresses (::ffff:0:0/96) - all the IPv4-mapped IPv6 addresses (::ffff:0:0/96)
In addition, the node should perform ingress filtering [RFC2827] on In addition, the node should be configured to perform ingress
the IPv6 source address, similar to on any of its interfaces, e.g.: filtering [RFC2827][RFC3704] on the IPv6 source address, similar to
on any of its interfaces, e.g.:
- if the tunnel is towards the Internet, check that the site's 1) if the tunnel is towards the Internet, the node should be
IPv6 prefixes are not used as the source addresses, or configured to check that the site's IPv6 prefixes are not used
as the source addresses, or
- if the tunnel is towards an edge network, check that the source 2) if the tunnel is towards an edge network, the node should be
address belongs to that edge network. configured to check that the source address belongs to that edge
network.
The prefix lists in the former typically need to be manually
configured; the latter could be verified automatically, e.g., by
using a strict unicast RPF check, as long as an interface can be
designated to be towards an edge.
It is RECOMMENDED that the implementations provide a single knob to
make it easier to for the administrators to enable strict ingress
filtering towards edge networks.
3.7. Link-Local Addresses 3.7. Link-Local Addresses
The configured tunnels are IPv6 interfaces (over the IPv4 "link The configured tunnels are IPv6 interfaces (over the IPv4 "link
layer") and thus MUST have link-local addresses. The link-local layer") and thus MUST have link-local addresses. The link-local
addresses are used by, e.g., routing protocols operating over the addresses are used by, e.g., routing protocols operating over the
tunnels. tunnels.
The interface identifier [RFC3513] for such an interface may be based The interface identifier [RFC3513] for such an interface may be based
on the 32-bit IPv4 address of an underlying interface, or formed on the 32-bit IPv4 address of an underlying interface, or formed
using some other means, as long as it's unique from the other tunnel using some other means, as long as it's unique from the other tunnel
endpoint with a reasonably high probability. endpoint with a reasonably high probability.
Note that it may be desirable to form the link-local address in a
fashion that minimizes the probability and the effect of having to
renumber the link-local address in the event of a topology or
hardware change.
If an IPv4 address is used for forming the IPv6 link-local address, If an IPv4 address is used for forming the IPv6 link-local address,
the interface identifier is the IPv4 address, prepended by zeros. the interface identifier is the IPv4 address, prepended by zeros.
Note that the "Universal/Local" bit is zero, indicating that the Note that the "Universal/Local" bit is zero, indicating that the
interface identifier is not globally unique. The link-local address interface identifier is not globally unique. The link-local address
is formed by appending the interface identifier to the prefix is formed by appending the interface identifier to the prefix
FE80::/64. FE80::/64.
When the host has more than one IPv4 address in use on the physical When the host has more than one IPv4 address in use on the physical
interface concerned, an administrative choice of one of these IPv4 interface concerned, a choice of one of these IPv4 addresses is made
addresses is made when forming the link-local address. by the administrator or the implementation when forming the link-
local address.
+-------+-------+-------+-------+-------+-------+------+------+ +-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 | | FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+ +-------+-------+-------+-------+-------+-------+------+------+
| 00 00 00 00 | IPv4 Address | | 00 00 00 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+ +-------+-------+-------+-------+-------+-------+------+------+
3.8. Neighbor Discovery over Tunnels 3.8. Neighbor Discovery over Tunnels
Configured tunnel implementations MUST at least accept and respond to Configured tunnel implementations MUST at least accept and respond to
skipping to change at page 19, line 26 skipping to change at page 19, line 40
- the sender of Neighbor Discovery packets SHOULD NOT include - the sender of Neighbor Discovery packets SHOULD NOT include
Source Link Layer Address options or Target Link Layer Address Source Link Layer Address options or Target Link Layer Address
options on the tunnel link. options on the tunnel link.
- the receiver MUST, while otherwise processing the Neighbor - the receiver MUST, while otherwise processing the Neighbor
Discovery packet, silently ignore the content of any Source Link Discovery packet, silently ignore the content of any Source Link
Layer Address options or Target Link Layer Address options Layer Address options or Target Link Layer Address options
received on the tunnel link. received on the tunnel link.
Not using a link layer address options is consistent with how Not using a link layer address options is consistent with how
Deighbor Discovery is used on other point-to-point links. Neighbor Discovery is used on other point-to-point links.
4. Threat Related to Source Address Spoofing 4. Threat Related to Source Address Spoofing
The specification above contains rules that apply tunnel source The specification above contains rules that apply tunnel source
address verification in particular and ingress filtering address verification in particular and ingress filtering
[RFC2827][BCP38UPD] in general to packets before they are [RFC2827][RFC3704] in general to packets before they are
decapsulated. When IP-in-IP tunneling (independent of IP versions) decapsulated. When IP-in-IP tunneling (independent of IP versions)
is used it is important that this can not be used to bypass any is used it is important that this can not be used to bypass any
ingress filtering in use for non-tunneled packets. Thus the rules in ingress filtering in use for non-tunneled packets. Thus the rules in
this document are derived based on should ingress filtering be used this document are derived based on should ingress filtering be used
for IPv4 and IPv6, the use of tunneling should not provide an easy for IPv4 and IPv6, the use of tunneling should not provide an easy
way to circumvent the filtering. way to circumvent the filtering.
In this case, without specific ingress filtering checks in the In this case, without specific ingress filtering checks in the
decapsulator, it would be possible for an attacker to inject a packet decapsulator, it would be possible for an attacker to inject a packet
with: with:
skipping to change at page 20, line 25 skipping to change at page 21, line 7
The solution to this is to have the decapsulator only accept The solution to this is to have the decapsulator only accept
encapsulated packets from the explicitly configured source address encapsulated packets from the explicitly configured source address
(i.e., the other end of the tunnel) as specified in section 3.6. (i.e., the other end of the tunnel) as specified in section 3.6.
While this does not provide complete protection in the case ingress While this does not provide complete protection in the case ingress
filtering has not been deployed, it does provide a significant filtering has not been deployed, it does provide a significant
increase in security. The issue and the remainder threats are increase in security. The issue and the remainder threats are
discussed at more length in Security Considerations. discussed at more length in Security Considerations.
5. Security Considerations 5. Security Considerations
Generic security considerations of using IPv6 are discussed in a
separate document [V6SEC].
An implementation of tunneling needs to be aware that while a tunnel An implementation of tunneling needs to be aware that while a tunnel
is a link (as defined in [RFC2460]), the threat model for a tunnel is a link (as defined in [RFC2460]), the threat model for a tunnel
might be rather different than for other links, since the tunnel might be rather different than for other links, since the tunnel
potentially includes all of the Internet. potentially includes all of the Internet.
Several mechanisms (e.g., Neighbor Discovery) depend on Hop Count Several mechanisms (e.g., Neighbor Discovery) depend on Hop Count
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 strict checks to mitigate this threat: Therefore, this memo specifies that the decapsulators make these
steps 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,
- IPv4 ingress filtering MAY be implemented to check that the IPv4 - Independent of any IPv4 ingress filtering the administrator may
packets are received from an expected interface, have configured, the implementation MAY perform IPv4 ingress
filtering to check that the IPv4 packets are received from an
expected interface (but as this may cause some problems, it may
be disabled by default),
- IPv6 packets with several, obviously invalid IPv6 source - IPv6 packets with several, obviously invalid IPv6 source
addresses MUST be discarded (see Section 3.6 for details), and addresses received from the tunnel MUST be discarded (see
Section 3.6 for details), and
- IPv6 ingress filtering should be performed, to check that the - IPv6 ingress filtering should be performed (typically requiring
configuration from the operator), to check that the tunneled
IPv6 packets are received from an expected interface. IPv6 packets are received from an expected interface.
Especially the first verification is vital: to avoid this check, the Especially the first verification is vital: to avoid this check, the
attacker must be able to know the source of the tunnel (difficult) attacker must be able to know the source of the tunnel (ranging from
and be able to spoof it (easier). difficult to predictable) and be able to spoof it (easier).
If the remainder threats of tunnel source verification are considered If the remainder threats of tunnel source verification are considered
to be significant, a tunneling scheme with authentication should be to be significant, a tunneling scheme with authentication should be
used instead, for example IPsec [RFC2401] (preferable) or Generic used instead, for example IPsec [RFC2401] (preferable) or Generic
Routing Encapsulation with a pre-configured secret key [RFC2890]. As Routing Encapsulation with a pre-configured secret key [RFC2890]. As
the configured tunnels are set up more or less manually, setting up the configured tunnels are set up more or less manually, setting up
the keying material is probably not a problem. the keying material is probably not a problem. However, setting up
secure IPsec IPv6-in-IPv4 tunnels is described in another document
[V64IPSEC].
If the tunneling is done inside an administrative domain, proper If the tunneling is done inside an administrative domain, proper
ingress filtering at the edge of the domain can also eliminate the ingress filtering at the edge of the domain can also eliminate the
threat from outside of the domain. Therefore shorter tunnels are threat from outside of the domain. Therefore shorter tunnels are
preferable to longer ones, possibly spanning the whole Internet. preferable to longer ones, possibly spanning the whole Internet.
Additionally, an implementation must treat interfaces to different Additionally, an implementation MUST treat interfaces to different
links as separate e.g. to ensure that Neighbor Discovery packets links as separate, e.g., to ensure that Neighbor Discovery packets
arriving on one link does not effect other links. This is especially arriving on one link does not effect other links. This is especially
important for tunnel links. important for tunnel links.
When dropping packets due to failing to match the allowed IPv4 source When dropping packets due to failing to match the allowed IPv4 source
addresses for a tunnel the node should not "acknowledge" the addresses for a tunnel the node should not "acknowledge" the
existence of a tunnel, otherwise this could be used to probe the existence of a tunnel, otherwise this could be used to probe the
acceptable tunnel endpoint addresses. For that reason, the acceptable tunnel endpoint addresses. For that reason, the
specification says that such packets MUST be discarded, and an ICMP specification says that such packets MUST be discarded, and an ICMP
error message SHOULD NOT be generated, unless the implementation error message SHOULD NOT be generated, unless the implementation
normally sends ICMP destination unreachable messages for unknown normally sends ICMP destination unreachable messages for unknown
skipping to change at page 22, line 38 skipping to change at page 23, line 27
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2460] Deering, S., and Hinden, R. "Internet Protocol, Version 6 [RFC2460] Deering, S., and Hinden, R. "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2463] A. Conta, S. Deering, "Internet Control Message Protocol [RFC2463] A. Conta, S. Deering, "Internet Control Message Protocol
(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. Non-normative 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
[BCP38UPD] Baker, F., and Savola P., "Ingress Filtering for Multihomed
Networks", draft-savola-bcp38-multihoming-update-03.txt,
work-in-progress, December 2003.
[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-04.txt, work-in-progress, January 2004. ipv6-dns-issues-07.txt, work-in-progress, May 2004.
[GTSM] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", draft-gill-gtsh-04.txt, work-
in-progress, October 2003.
[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
Considerations", draft-savola-v6ops-security-overview-
02.txt, work-in-progress, February 2004.
[V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-IPv4
Tunnels", draft-tschofenig-v6ops-secure-tunnels-00.txt,
work-in-progress, June 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.
[RFC1812] Kent, S., Atkinson, R., "Security Architecture for the [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2461] Narten, T., Nordmark, E., and Simpson, W. "Neighbor [RFC2461] Narten, T., Nordmark, E., and Simpson, W. "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462] Thomson, S., and Narten, T. "IPv6 Stateless Address [RFC2462] Thomson, S., and Narten, T. "IPv6 Stateless Address
Autoconfiguration," RFC 2462, December 1998. Autoconfiguration," RFC 2462, December 1998.
[RFC2667] D. Thaler, "IP Tunnel MIB", RFC 2667, August 1999. [RFC2667] D. Thaler, "IP Tunnel MIB", RFC 2667, August 1999.
skipping to change at page 24, line 16 skipping to change at page 24, line 51
[RFC3168] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of [RFC3168] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168, Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001. September 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an
On-line Database", RFC 3232, January 2002. On-line Database", RFC 3232, January 2002.
[RFC3484] R. Draves, "Default Address Selection for IPv6", RFC 3484, [RFC3484] R. Draves, "Default Address Selection for IPv6", RFC 3484,
February 2003. February 2003.
[RFC3493] Gilligan, R., et al, "Basic Socket Interface Extensions for
IPv6", RFC 3493, February 2003.
[RFC3513] Hinden, R., and S. Deering, "IP Version 6 Addressing [RFC3513] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003. Architecture", RFC 3513, April 2003.
[RFC3596] Thomson, S., C. Huitema, V. Ksinant, and M. Souissi, "DNS [RFC3596] Thomson, S., C. Huitema, V. Ksinant, and M. Souissi, "DNS
Extensions to support IP version 6", RFC 3596, October 2003. Extensions to support IP version 6", RFC 3596, October 2003.
[RFC3704] Baker, F., and Savola P., "Ingress Filtering for Multihomed
Networks", RFC 3704, BCP 84, March 2004.
8. Authors' Addresses 8. Authors' Addresses
Erik Nordmark Erik Nordmark
Sun Microsystems Laboratories Sun Microsystems Laboratories
180, avenue de l'Europe 180, avenue de l'Europe
38334 SAINT ISMIER Cedex, France 38334 SAINT ISMIER Cedex, France
Tel : +33 (0)4 76 18 88 03 Tel : +33 (0)4 76 18 88 03
Fax : +33 (0)4 76 18 88 88 Fax : +33 (0)4 76 18 88 88
Email : erik.nordmark@sun.com Email : erik.nordmark@sun.com
skipping to change at page 26, line 45 skipping to change at page 27, line 30
- Added a note that using TTL=255 when encapsulating might be - Added a note that using TTL=255 when encapsulating might be
useful for decapsulation security checks later on. 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.
- Removed/clarified DNS record filtering; an API is a SHOULD and
if it does not exist, MUST NOT filter anything. Refer more
strongly to RFC3484 on the DNS record ordering/processing.
- 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.
- 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 29, line 12 skipping to change at page 30, line 9
- Added a note that using TTL=255 when encapsulating might be - Added a note that using TTL=255 when encapsulating might be
useful for decapsulation security checks later on. 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.
- Specified Static MTU to default to a MTU of 1280 to 1480 bytes, - Specified Static MTU to default to a MTU of 1280 to 1480 bytes,
and that this may be configurable. Discussed the issues with and that this may be configurable. Discussed the issues with
using Static MTU at more length. using Static MTU at more length.
- Specified minimal rules for IPv4 reassembly and IPv6 MRU to - Specified minimal rules for IPv4 reassembly and IPv6 MRU to
enhance interoperability and to minimize blacholes. enhance interoperability and to minimize blacholes.
-
- Made a lot of miscellaneous editorial cleanups. - Made a lot of miscellaneous editorial cleanups.
9.3. Changes from draft-ietf-v6ops-mech-v2-02
- Removed DNS record filtering, and made it a SHOULD NOT;
summarized the DNS record ordering.
- Further clarified the usage of IPv6 RPF checks, as they
typically require manual configuration.
- Add a note on link-local address formation strategy to point out
that minimizing the probability of renumbering may be desirable.
- Clarify that with multiple IPv4 addresses, and the link-local
address formed based on one of them, the selection can be done
administratively or by the implementation.
- Refer to separate documents on generic IPv6 security
considerations and IPsec set-up details.
- Clarify that the IPv4 end-point address can be predictable in
some situations.
- 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.
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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