draft-ietf-v6ops-unmaneval-01.txt   draft-ietf-v6ops-unmaneval-02.txt 
INTERNET DRAFT C. Huitema INTERNET DRAFT C. Huitema
<draft-ietf-v6ops-unmaneval-01.txt> Microsoft <draft-ietf-v6ops-unmaneval-02.txt> Microsoft
February 4, 2004 R. Austein May 19, 2004 R. Austein
Expires August 4, 2004 Bourgeois Dilettante Expires November 19, 2004 Bourgeois Dilettante
S. Satapati S. Satapati
Cisco Systems, Inc. Cisco Systems, Inc.
R. van der Pol R. van der Pol
NLnet Labs NLnet Labs
Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 10, line ? skipping to change at page 10, line ?
2.1 Comparing automatic and configured solutions 2.1 Comparing automatic and configured solutions
It is possible to broadly classify tunneling solutions as either It is possible to broadly classify tunneling solutions as either
"automatic" or "configured". In an automatic solution, a host or a "automatic" or "configured". In an automatic solution, a host or a
router builds an IPv6 address or an IPv6 prefix by combining a pre- router builds an IPv6 address or an IPv6 prefix by combining a pre-
defined prefix with some local attribute, such as local IPv4 address defined prefix with some local attribute, such as local IPv4 address
[6TO4] or the combination of an address and a port number [Teredo]. [6TO4] or the combination of an address and a port number [Teredo].
Another typical and very important characteristic of an automatic Another typical and very important characteristic of an automatic
solution is they aim to work with a minimal amount of support or solution is they aim to work with a minimal amount of support or
infrastructure for IPv6 in the local or remote ISPs. In a configured infrastructure for IPv6 in the local or remote ISPs.
solution, a host or a router identifies itself to a tunneling
service to set up a "configured tunnel" with an explicitly defined In a configured solution, a host or a router identifies itself to a
Huitema et al. [Page 2] Huitema et al. [Page 2]
"tunnel router". tunneling service to set up a "configured tunnel" with an explicitly
defined "tunnel router". The amount of actual configuration may vary
from manually configured static tunnels to dynamic tunnel services
requiring only the configuration of a "tunnel broker".
Configured tunnels have many advantages over automatic tunnels. The Configured tunnels have many advantages over automatic tunnels. The
client is explicitly identified and can obtain a stable IPv6 client is explicitly identified and can obtain a stable IPv6
address. The service provider is also well identified and can be address. The service provider is also well identified and can be
held responsible for the quality of the service. It is possible to held responsible for the quality of the service. It is possible to
route multicast packets over the established tunnel. There is a route multicast packets over the established tunnel. There is a
clear address delegation path, which enables easy support for clear address delegation path, which enables easy support for
reverse DNS lookups. reverse DNS lookups.
Automatic tunnels generally cannot provide the same level of Automatic tunnels generally cannot provide the same level of
skipping to change at page 10, line ? skipping to change at page 10, line ?
the tunnel end-points close to the client, i.e., mostly on the the tunnel end-points close to the client, i.e., mostly on the
direct path between the client and its peers. direct path between the client and its peers.
2.1.2 Automatic tunnels and relays 2.1.2 Automatic tunnels and relays
The economics arguments related to path optimization favor either The economics arguments related to path optimization favor either
configured tunnels provided by the local ISP or automatic tunneling configured tunnels provided by the local ISP or automatic tunneling
regardless of the co-operation of ISPs. However, automatic solutions regardless of the co-operation of ISPs. However, automatic solutions
require that relays be configured throughout the Internet. If a host require that relays be configured throughout the Internet. If a host
that obtained connectivity through an automatic tunnel service wants that obtained connectivity through an automatic tunnel service wants
to communicate with a "native" host, it will need to use a relay to communicate with a "native" host or with a host using a
service, and someone will have to provide and pay for that service. configured tunnel, it will need to use a relay service, and someone
We cannot escape economic considerations for the deployment of these
relays.
Huitema et al. [Page 3] Huitema et al. [Page 3]
will have to provide and pay for that service. We cannot escape
economic considerations for the deployment of these relays.
It is desirable to locate these relays close to the "native host". It is desirable to locate these relays close to the "native host".
During the transition period, the native ISPS have an interest in During the transition period, the native ISPS have an interest in
providing a relay service for use by their native subscribers. Their providing a relay service for use by their native subscribers. Their
subscribers will enjoy better connectivity, i.e., will be happier. subscribers will enjoy better connectivity, i.e., will be happier.
Providing the service does not result in much extra bandwidth Providing the service does not result in much extra bandwidth
requirement: the packets are exchanged between the local subscribers requirement: the packets are exchanged between the local subscribers
and the Internet; they are simply using a v6-v4 path instead of a and the Internet; they are simply using a v6-v4 path instead of a
v6-v6 path. (The native ISP do not have an incentive to provide v6-v6 path. (The native ISP do not have an incentive to provide
relays for general use; they are expected to restrict access to relays for general use; they are expected to restrict access to
these relays to their customers.) these relays to their customers.)
skipping to change at page 10, line ? skipping to change at page 10, line ?
different structure. There are two relays, one for each direction of different structure. There are two relays, one for each direction of
communication. The native host sends its packets through the nearest communication. The native host sends its packets through the nearest
6to4 router, i.e., the closest router advertising the 2002::/16 6to4 router, i.e., the closest router advertising the 2002::/16
prefix through the IPv6 routing tables; the 6to4 network sends its prefix through the IPv6 routing tables; the 6to4 network sends its
packet through a 6to4 relay that is either explicitly configured or packet through a 6to4 relay that is either explicitly configured or
discovered through the 6to4 anycast address 192.88.99.1 discovered through the 6to4 anycast address 192.88.99.1
[6To4ANYCAST]. The experience so far is that simple 6to4 routers are [6To4ANYCAST]. The experience so far is that simple 6to4 routers are
easy to deploy, but 6to4 relays are scarce. If there are too few easy to deploy, but 6to4 relays are scarce. If there are too few
relays, these relays will create a bottleneck. The communications relays, these relays will create a bottleneck. The communications
between 6to4 and native networks will be slower than the direct between 6to4 and native networks will be slower than the direct
Huitema et al. [Page 4]
communications between 6to4 hosts. This will create an incentive for communications between 6to4 hosts. This will create an incentive for
native hosts to somehow "multi-home" to 6to4, de facto creating two native hosts to somehow "multi-home" to 6to4, de facto creating two
parallel Internets, 6to4 and native. This risk will only be parallel Internets, 6to4 and native. This risk will only be
Huitema et al. [Page 4]
mitigated if there is a sufficient deployment of 6to4 relays. mitigated if there is a sufficient deployment of 6to4 relays.
The configured tunnels solutions do not carry this type of risk.
2.1.4 Lifespan of transition technologies 2.1.4 Lifespan of transition technologies
A related issue is the lifespan of the transition solutions. Since A related issue is the lifespan of the transition solutions. Since
automatic tunneling technologies enable an automatic deployment, automatic tunneling technologies enable an automatic deployment,
there is a risk that some hosts never migrate out of the transition. there is a risk that some hosts never migrate out of the transition.
The risk is arguably less for explicit tunnels: the ISPS who provide The risk is arguably less for explicit tunnels: the ISPS who provide
the tunnels have an incentive to replace them with a native solution the tunnels have an incentive to replace them with a native solution
as soon as possible. as soon as possible.
Many implementations of automatic transition technologies Many implementations of automatic transition technologies
skipping to change at page 10, line ? skipping to change at page 10, line ?
types of technologies, some "NAT capable" and some not. An types of technologies, some "NAT capable" and some not. An
important question is also which kinds of NAT boxes one should be important question is also which kinds of NAT boxes one should be
able to traverse. One should probably also consider whether it is able to traverse. One should probably also consider whether it is
necessary to build an IPv6 specific NAT traversal mechanism, or necessary to build an IPv6 specific NAT traversal mechanism, or
whether it is possible to combine an existing IPv4 NAT traversal whether it is possible to combine an existing IPv4 NAT traversal
mechanism with some form of IPv6 in IPv4 tunneling. There are many mechanism with some form of IPv6 in IPv4 tunneling. There are many
IPv4 NAT traversal mechanisms; thus one may ask whether these need IPv4 NAT traversal mechanisms; thus one may ask whether these need
re-invention, especially when they are already complex. re-invention, especially when they are already complex.
A related question is whether the NAT traversal technology should A related question is whether the NAT traversal technology should
Huitema et al. [Page 5]
use automatic tunnels or configured tunnels. We saw in the previous use automatic tunnels or configured tunnels. We saw in the previous
section that one can argue both sides of this issue. In fact, there section that one can argue both sides of this issue. In fact, there
are already deployed automatic and configured solutions, so the are already deployed automatic and configured solutions, so the
reality is that we will probably see both. reality is that we will probably see both.
Huitema et al. [Page 5]
2.2.1 Cost of NAT traversal 2.2.1 Cost of NAT traversal
NAT traversal technologies generally involve encapsulating IPv6 NAT traversal technologies generally involve encapsulating IPv6
packets inside a transport protocol that is known to traverse NAT, packets inside a transport protocol that is known to traverse NAT,
such as UDP or TCP. These transport technologies require such as UDP or TCP. These transport technologies require
significantly more overhead than the simple tunneling over IPv4 used significantly more overhead than the simple tunneling over IPv4 used
in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on
UDP require the frequent transmission of "keep alive" packets to UDP require the frequent transmission of "keep alive" packets to
maintain a "mapping" in the NAT; solutions based on TCP may not maintain a "mapping" in the NAT; solutions based on TCP may not
require such mechanism, but they incur the risk of "head of queue require such mechanism, but they incur the risk of "head of queue
skipping to change at page 10, line ? skipping to change at page 10, line ?
prevent this type of transmission. Some models will allow UDP prevent this type of transmission. Some models will allow UDP
transmission, while other may only allow TCP, or possibly HTTP. transmission, while other may only allow TCP, or possibly HTTP.
The automatic solutions have to rely on a "lower common denominator" The automatic solutions have to rely on a "lower common denominator"
that is likely to be accepted by most models of NAT. In practice, that is likely to be accepted by most models of NAT. In practice,
this common denominator is UDP. UDP based NAT traversal is required this common denominator is UDP. UDP based NAT traversal is required
by many applications, e.g., networked games or voice over IP. The by many applications, e.g., networked games or voice over IP. The
experience shows that most recent "home routers" are designed to experience shows that most recent "home routers" are designed to
support these applications. In some edge cases, the automatic support these applications. In some edge cases, the automatic
solutions will require explicit configuration of a port in the home solutions will require explicit configuration of a port in the home
router, using the so-called "DMZ" functions. router, using the so-called "DMZ" functions; however, these
functions are hard to use in an "unmanaged network" scenario.
2.2.3 Reuse of existing mechanisms 2.2.3 Reuse of existing mechanisms
NAT traversal is not a problem for IPv6 alone. Many IPv4 NAT traversal is not a problem for IPv6 alone. Many IPv4
applications have developed solutions, or kludges, to enable applications have developed solutions, or kludges, to enable
Huitema et al. [Page 6]
communication across a NAT. communication across a NAT.
Virtual Private Networks are established by installing tunnels Virtual Private Networks are established by installing tunnels
between VPN clients and VPN servers. These tunnels are designed between VPN clients and VPN servers. These tunnels are designed
today to carry IPv4, but in many cases could easily carry IPv6. For today to carry IPv4, but in many cases could easily carry IPv6. For
example, the IETF standard, L2TP, includes a PPP layer that can example, the IETF standard, L2TP, includes a PPP layer that can
Huitema et al. [Page 6]
encapsulate IPv6 as well as IPv4. Several NAT models are explicitly encapsulate IPv6 as well as IPv4. Several NAT models are explicitly
designed to pass VPN traffic, and several VPN solutions have special designed to pass VPN traffic, and several VPN solutions have special
provisions to traverse NAT. When we study the establishment of provisions to traverse NAT. When we study the establishment of
configured tunnels through NAT, it makes a lot of sense to consider configured tunnels through NAT, it makes a lot of sense to consider
existing VPN solutions. existing VPN solutions.
[STUN] is a protocol designed to facilitate the establishment of UDP [STUN] is a protocol designed to facilitate the establishment of UDP
associations through NAT, by letting nodes behind NAT discover their associations through NAT, by letting nodes behind NAT discover their
"external" address. The same function is required for automatic "external" address. The same function is required for automatic
tunneling through NAT, and one could consider reusing the STUN tunneling through NAT, and one could consider reusing the STUN
skipping to change at page 10, line ? skipping to change at page 10, line ?
3 Meeting case A requirements 3 Meeting case A requirements
In case A, isolated hosts need to acquire some form of connectivity. In case A, isolated hosts need to acquire some form of connectivity.
In this section, we first evaluate how mechanisms already defined or In this section, we first evaluate how mechanisms already defined or
being worked on in the IETF meet this requirement. We then consider being worked on in the IETF meet this requirement. We then consider
the "remaining holes" and recommend specific developments. the "remaining holes" and recommend specific developments.
3.1 Evaluation of connectivity mechanisms 3.1 Evaluation of connectivity mechanisms
Huitema et al. [Page 7]
In case A, IPv6 capable hosts seek IPv6 connectivity in order to In case A, IPv6 capable hosts seek IPv6 connectivity in order to
communicate with applications in the global IPv6 Internet. The communicate with applications in the global IPv6 Internet. The
connectivity requirement can be met using either configured tunnels connectivity requirement can be met using either configured tunnels
or automatic tunnels. or automatic tunnels.
Huitema et al. [Page 7]
If the host is located behind a NAT, the tunneling technology should If the host is located behind a NAT, the tunneling technology should
be designed to traverse NAT; tunneling technologies that do not be designed to traverse NAT; tunneling technologies that do not
support NAT traversal can obviously be used if the host is not support NAT traversal can obviously be used if the host is not
located behind a NAT. located behind a NAT.
When the local ISP is willing to provide a configured tunnel When the local ISP is willing to provide a configured tunnel
solution, we should make it easy for the host in case A to use it. solution, we should make it easy for the host in case A to use it.
An automatic solution like Teredo appears to be a good fit for An automatic solution like Teredo appears to be a good fit for
providing IPv6 connectivity to hosts behind NAT, in case A of IPv6 providing IPv6 connectivity to hosts behind NAT, in case A of IPv6
skipping to change at page 10, line ? skipping to change at page 10, line ?
mechanism. If no precaution is taken, there is a risk of exposing to mechanism. If no precaution is taken, there is a risk of exposing to
the global Internet some applications and services that only the global Internet some applications and services that only
expected to serve local hosts, e.g., those located behind the NAT expected to serve local hosts, e.g., those located behind the NAT
when a NAT is present. Developers and administrators should make when a NAT is present. Developers and administrators should make
sure that the global IPv6 connectivity is restricted to only those sure that the global IPv6 connectivity is restricted to only those
applications that are expressly designed for global Internet applications that are expressly designed for global Internet
connectivity. The users should be able to configure which connectivity. The users should be able to configure which
applications can get IPv6 connectivity to the Internet and which applications can get IPv6 connectivity to the Internet and which
should not. should not.
Any solution to the NAT traversal problem is likely to involve
relays. There are concerns that improperly designed protocols or
improperly managed relays could open new avenues for attacks against
Internet services. This issue should be addressed and mitigated in
the design of the NAT traversal protocols and in the deployment
guides for relays.
4 Meeting case B requirements 4 Meeting case B requirements
In case B, we assume that the gateway and the ISP are both dual- In case B, we assume that the gateway and the ISP are both dual-
stack. The hosts on the local network may be IPv4-only, dual-stack, stack. The hosts on the local network may be IPv4-only, dual-stack,
or IPv6-only. The main requirements are: prefix delegation, and name or IPv6-only. The main requirements are: prefix delegation, and name
resolution. We also study the potential need for communication resolution. We also study the potential need for communication
between IPv4 and IPv6 hosts, and conclude that a dual-stack approach between IPv4 and IPv6 hosts, and conclude that a dual-stack approach
is preferable. is preferable.
4.1 Connectivity 4.1 Connectivity
Huitema et al. [Page 8]
The gateway must be able to acquire an IPv6 prefix, delegated by the The gateway must be able to acquire an IPv6 prefix, delegated by the
ISP. This can be done through explicit prefix delegation (e.g., ISP. This can be done through explicit prefix delegation (e.g.,
DHCPv6), or if the ISP is advertising a /64 prefix on the link, such DHCPv6), or if the ISP is advertising a /64 prefix on the link, such
a link can be extended by the use of ND proxy or a bridge. a link can be extended by the use of ND proxy or a bridge.
An ND proxy can also be used to extend a /64 prefix to multiple An ND proxy can also be used to extend a /64 prefix to multiple
physical links of different properties (e.g, an Ethernet and a PPP physical links of different properties (e.g, an Ethernet and a PPP
link). link).
4.1.1 Extending a Subnet to Span Multiple Links 4.1.1 Extending a Subnet to Span Multiple Links
A /64 subnet can be extended to span multiple physical links using a A /64 subnet can be extended to span multiple physical links using a
bridge or ND proxy. Bridges can be used when bridging multiple bridge or ND proxy. Bridges can be used when bridging multiple
Huitema et al. [Page 8]
similar media (mainly, Ethernet segments). On the other hand, ND similar media (mainly, Ethernet segments). On the other hand, ND
proxy must be used if a /64 prefix has to be shared across media proxy must be used if a /64 prefix has to be shared across media
(e.g., an upstream PPP link and a downstream Ethernet), or if an (e.g., an upstream PPP link and a downstream Ethernet), or if an
interface cannot be put into promiscuous mode (e.g., an upstream interface cannot be put into promiscuous mode (e.g., an upstream
wireless link). wireless link).
Extending a single subnet to span from the ISP to the all of the Extending a single subnet to span from the ISP to the all of the
unmanaged network is not recommended, and prefix delegation should unmanaged network is not recommended, and prefix delegation should
be used when available. However, sometimes it is unavoidable. In be used when available. However, sometimes it is unavoidable. In
addition, sometimes it's necessary to extend a subnet in the addition, sometimes it's necessary to extend a subnet in the
skipping to change at page 10, line ? skipping to change at page 10, line ?
Several networks have already started using an explicit prefix Several networks have already started using an explicit prefix
delegation mechanism using DHCPv6. In this mechanism, the gateway delegation mechanism using DHCPv6. In this mechanism, the gateway
uses a DHCP request to obtain an adequate prefix from a DHCP server uses a DHCP request to obtain an adequate prefix from a DHCP server
managed by the Internet Service Provider. The DHCP request is managed by the Internet Service Provider. The DHCP request is
expected to carry proper identification of the gateway, which expected to carry proper identification of the gateway, which
enables the ISP to implement prefix delegation policies. It is enables the ISP to implement prefix delegation policies. It is
expected that the ISP assigns a /48 to the customer. The gateway expected that the ISP assigns a /48 to the customer. The gateway
should automatically assign /64s out of this /48 to its internal should automatically assign /64s out of this /48 to its internal
links. links.
The basic use of DHCP is insecure. This may be a problem if the link DHCP is insecure unless authentication is used. This may be a
between gateway and ISP is shared by multiple subscribers. DHCP particular problem if the link between gateway and ISP is shared by
specification includes authentication options, but does not describe multiple subscribers. DHCP specification includes authentication
the task of managing the keys, and how the information would be options, but the operational procedures for managing the keys and
shared between the customer and the ISP. To be useful in such methods for sharing the required information between the customer
environment in practice, the practical details of managing the DHCP and the ISP are unclear. To be secure in such environment in
authentication need to be analyzed. practice, the practical details of managing the DHCP authentication
Huitema et al. [Page 9]
need to be analyzed.
4.1.3 Recommendation 4.1.3 Recommendation
The ND proxy and DHCP methods appear to have different domains of The ND proxy and DHCP methods appear to have complementary domains
application. ND proxy is a simple method that corresponds well to of application. ND proxy is a simple method that corresponds well to
"informal sharing" of a link, while explicit delegation provides "informal sharing" of a link, while explicit delegation provides
strong administrative control. Both methods require development: strong administrative control. Both methods require development:
specify the interaction with neighbor discovery for ND proxy; specify the interaction with neighbor discovery for ND proxy;
provide security guidelines for explicit delegation. provide security guidelines for explicit delegation.
4.2 Communication between IPv4-only and IPv6-capable nodes 4.2 Communication between IPv4-only and IPv6-capable nodes
During the transition phase from IPv4 to IPv6 there will be IPv4- During the transition phase from IPv4 to IPv6 there will be IPv4-
Huitema et al. [Page 9]
only, dual-stack and IPv6-only nodes. In theory, there may be a need only, dual-stack and IPv6-only nodes. In theory, there may be a need
to provide some interconnection services so that IPv4-only and IPv6- to provide some interconnection services so that IPv4-only and IPv6-
only hosts can communicate. However, it is hard to develop a only hosts can communicate. However, it is hard to develop a
translation service that does not have unwanted side effects on the translation service that does not have unwanted side effects on the
efficiency or the security of communications. As a consequence, the efficiency or the security of communications. As a consequence, the
authors recommend that, if a device has a requirement to communicate authors recommend that, if a device has a requirement to communicate
with IPv4-only hosts, this device implements an IPv4 stack. The only with IPv4-only hosts, this device implements an IPv4 stack. The only
devices that should only have IPv6 connectivity are those that are devices that should only have IPv6 connectivity are those that are
intended to only communicate with IPv6 hosts. intended to only communicate with IPv6 hosts.
skipping to change at page 10, line ? skipping to change at page 10, line ?
4.3.1 Provisioning the address of a DNS resolver 4.3.1 Provisioning the address of a DNS resolver
In an unmanaged environment, IPv4 hosts usually obtain the address In an unmanaged environment, IPv4 hosts usually obtain the address
of the local DNS resolver through DHCPv4; the DHCPv4 service is of the local DNS resolver through DHCPv4; the DHCPv4 service is
generally provided by the gateway. The gateway will also use DHCPv4 generally provided by the gateway. The gateway will also use DHCPv4
to obtain the address of a suitable resolver from the local Internet to obtain the address of a suitable resolver from the local Internet
service provider. service provider.
The DHCPv4 solution will suffice in practice for the gateway and The DHCPv4 solution will suffice in practice for the gateway and
also for the dual-stack hosts. There is evidence that even the also for the dual-stack hosts. There is evidence that DNS servers
simple DNS resolvers present in small gateways can relay arbitrary accessed over IPv4 can serve arbitrary DNS records, including AAAA
DNS requests and serve arbitrary DNS records, including AAAA
records. records.
Just using DHCPv4 will not be an adequate solution for IPv6-only Just using DHCPv4 will not be an adequate solution for IPv6-only
local hosts. The DHCP working group has defined how to use local hosts. The DHCP working group has defined how to use
(stateless) DHCPv6 to obtain the address of the DNS server (stateless) DHCPv6 to obtain the address of the DNS server
[DNSDHCPV6]. DHCPv6 and several other possibilities are being looked [DNSDHCPV6]. DHCPv6 and several other possibilities are being looked
at in the DNSOP Working Group. at in the DNSOP Working Group.
4.3.2 Publishing IPv6 addresses to the Internet 4.3.2 Publishing IPv6 addresses to the Internet
skipping to change at page 12, line 33 skipping to change at page 12, line 47
IPv4 address, i.e., with a direct connection to the IPv4 Internet. IPv4 address, i.e., with a direct connection to the IPv4 Internet.
This host will be able to use the same tunneling mechanisms as a This host will be able to use the same tunneling mechanisms as a
gateway. gateway.
5.1 Connectivity 5.1 Connectivity
Connectivity in case C requires some form of tunneling of IPv6 over Connectivity in case C requires some form of tunneling of IPv6 over
IPv4. The various tunneling solutions are discussed in section 2. IPv4. The various tunneling solutions are discussed in section 2.
The requirements of case C can be solved by an automatic tunneling The requirements of case C can be solved by an automatic tunneling
mechanism such as 6to4 [6TO4]. An alternative may be the use of a mechanism such as 6to4 [6TO4]. An alternative may be the use of a
configured tunnels mechanism [TUNNELS], but as the local ISP does is configured tunnels mechanism [TUNNELS], but as the local ISP is not
not IPv6-enabled this may not be feasible. The practical conclusion IPv6-enabled this may not be feasible. The practical conclusion of
of our analysis is that "upgraded gateways" will probably support our analysis is that "upgraded gateways" will probably support the
the 6to4 technology, and will have an optional configuration option 6to4 technology, and will have an optional configuration option for
for "configured tunnels". "configured tunnels".
The tunnel broker technology should be augmented, to include support The tunnel broker technology should be augmented, to include support
for some form of automatic configuration. for some form of automatic configuration.
Due to concerns with potential overload of public 6to4 relays, the Due to concerns with potential overload of public 6to4 relays, the
6to4 implementations should include a configuration option that let 6to4 implementations should include a configuration option that let
user take advantage of specific relays. user take advantage of specific relays.
6 Meeting the case D requirements 6 Meeting the case D requirements
skipping to change at page 13, line 10 skipping to change at page 13, line 22
We expect IPv6 addressing in case D to proceed similarly to case B, We expect IPv6 addressing in case D to proceed similarly to case B,
i.e., use either ND proxy or explicit prefix delegation through i.e., use either ND proxy or explicit prefix delegation through
DHCPv6 to provision an IPv6 prefix on the gateway. DHCPv6 to provision an IPv6 prefix on the gateway.
6.2 IPv4 connectivity requirements 6.2 IPv4 connectivity requirements
Local IPv4 capable hosts may want to still access IPv4-only Local IPv4 capable hosts may want to still access IPv4-only
services. The proper way to do this for dual-stack nodes in the services. The proper way to do this for dual-stack nodes in the
unmanaged network is to develop a form of "IPv4 over IPv6" unmanaged network is to develop a form of "IPv4 over IPv6"
tunneling. This tunneling protocol need to be standardized. Part of tunneling. There are no standardized solutions and has been very
the standardization will have to cover configuration issues, i.e., little effort devoted by the IETF to this issue, although there is
how to provision the IPv4 capable hosts with the address of the ongoing work with [DSTM] and [TSP]. A solution needs to be
local IPv4 tunnel servers. standardized. The standardization will have to cover configuration
issues, i.e., how to provision the IPv4 capable hosts with the
address of the local IPv4 tunnel servers.
6.3 Naming requirements 6.3 Naming requirements
Naming requirements are similar to case B, with one difference: the Naming requirements are similar to case B, with one difference: the
gateway cannot expect to use DHCPv4 to obtain the address of the gateway cannot expect to use DHCPv4 to obtain the address of the DNS
DNS resolver recommended by the ISP. resolver recommended by the ISP.
7 Provisional recommendations 7 Recommendations
After a careful analysis of the possible solutions, we can list a After a careful analysis of the possible solutions, we can list a
set of recommendations for the V6OPS working group: set of recommendations for the V6OPS working group:
1- To meet case A and case C requirements, we need to develop, or 1- To meet case A and case C requirements, we need to develop, or
continue to develop, four types of tunneling technologies: automatic continue to develop, four types of tunneling technologies: automatic
tunnels without NAT traversal such as [6TO4], automatic tunnels with tunnels without NAT traversal such as [6TO4], automatic tunnels with
NAT traversal such as [TEREDO], configured tunnels without NAT NAT traversal such as [TEREDO], configured tunnels without NAT
traversal such as [TUNNELS] and configured tunnels with NAT traversal such as [TUNNELS, TSP] and configured tunnels with NAT
traversal. traversal.
2- To meet case B "informal prefix sharing" requirements, we would 2- To facilitate the use of configured tunnels, we need a
standardized way for hosts or gateways to discover the tunnel server
or tunnel broker that may have been configured by the local ISP.
3- To meet case B "informal prefix sharing" requirements, we would
need a standardized way to perform "ND proxy", possibly as part of a need a standardized way to perform "ND proxy", possibly as part of a
"multi-link subnet" specification. (The explicit prefix delegation "multi-link subnet" specification. (The explicit prefix delegation
can be accomplished through [PREFIXDHCPV6].) can be accomplished through [PREFIXDHCPV6].)
4- To meet case B naming requirements we need to proceed with the
3- To meet case B naming requirements we need to proceed with the
standardization of LLMNR. (The provisioning of DNS parameters can be standardization of LLMNR. (The provisioning of DNS parameters can be
accomplished through [DNSDHCPV6].) accomplished through [DNSDHCPV6].)
4- To meet case D IPv4 connectivity requirement, we need to 5- To meet case D IPv4 connectivity requirement, we need to
standardize an IPv4 over IPv6 tunneling mechanism, as well as the standardize an IPv4 over IPv6 tunneling mechanism, as well as the
associated configuration services. associated configuration services.
8 Security considerations 8 Security considerations
This memo describes the general requirements for transition This memo describes the general requirements for transition
mechanisms. Specific security issues should be studied and addressed mechanisms. Specific security issues should be studied and addressed
during the development of the specific mechanisms. during the development of the specific mechanisms.
When hosts which have been behind a NAT are exposed to IPv6, the When hosts which have been behind a NAT are exposed to IPv6, the
security assumptions may change radically. This is mentioned in security assumptions may change radically. This is mentioned in
sections 3.2 and 4.4. One way to cope with that is to have a sections 3.2 and 4.4. One way to cope with that is to have a
default firewall with NAT-like access configuration; one might also default firewall with NAT-like access configuration; however, any
restrict applications which can benefit from global IPv6 such firewall configuration should allow for easy authorization of
those applications that actually need global connectivity. One might
also restrict applications which can benefit from global IPv6
connectivity on the nodes. connectivity on the nodes.
Security policies should be consistent between IPv4 and IPv6. A
policy which prevents use of v6 while allowing v4 will discourage
migration to v6 without significantly improving security.
Developers and administrators should make sure that global Internet
connectivity through either IPv4 or IPv6 is restricted to only those
applications that are expressly designed for global Internet
connectivity.
Several transition technologies require relays. There are concerns
that improperly designed protocols or improperly managed relays
could open new avenues for attacks against Internet services. This
issue should be addressed and mitigated in the design of the
transition technologies and in the deployment guides for relays.
9 IANA Considerations 9 IANA Considerations
This memo does not include any request to IANA. This memo does not include any request to IANA.
10 Copyright 10 Copyright
The following copyright notice is copied from RFC 2026 [Bradner, The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this 1996], Section 10.4, and describes the applicable copyright for this
document. document.
skipping to change at page 15, line 20 skipping to change at page 16, line 4
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
12 Acknowledgements 12 Acknowledgements
This memo has benefited from comments of Margaret Wasserman, Pekka This memo has benefited from comments of Margaret Wasserman, Pekka
Savola, Chirayu Patel and Tony Hain. Tim Chown provided a lot of the Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms, Bill
Sommerfeld and Fred Templin. Tim Chown provided a lot of the
analysis for the tunneling requirements work. analysis for the tunneling requirements work.
13 References 13 References
Normative references Normative references
[UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der [UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol. "Unmanaged Networks IPv6 Transition Scenarios", Work in Pol. "Unmanaged Networks IPv6 Transition Scenarios", Work in
progress. progress.
skipping to change at page 15, line 49 skipping to change at page 16, line 34
[6TO4ANYCAST] C. Huitema. "An Anycast Prefix for 6to4 Relay [6TO4ANYCAST] C. Huitema. "An Anycast Prefix for 6to4 Relay
Routers", RFC 3068, June 2001. Routers", RFC 3068, June 2001.
[TEREDO] C. Huitema. "Teredo: Tunneling IPv6 over UDP through NATs." [TEREDO] C. Huitema. "Teredo: Tunneling IPv6 over UDP through NATs."
Work in progress. Work in progress.
[TUNNELS] Durand, A., Fasano, P., and I. Guardini. IPv6 Tunnel [TUNNELS] Durand, A., Fasano, P., and I. Guardini. IPv6 Tunnel
Broker. RFC 3053, January 2001 Broker. RFC 3053, January 2001
[TSP] M. Blanchet, "IPv6 Tunnel Broker with the Tunnel Setup
Protocol(TSP)". work in progress.
[DSTM] J. Bound, "Dual Stack Transition Mechanism". Work in
progress.
[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
M. Carney. "Dynamic Host Configuration Protocol for IPv6 M. Carney. "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)."RFC 3315, July 2003. (DHCPv6)."RFC 3315, July 2003.
[DNSDHCPV6] R. Droms. "DNS Configuration options for DHCPv6." RFC [DNSDHCPV6] R. Droms. "DNS Configuration options for DHCPv6." RFC
3646, December 2003. 3646, December 2003.
[PREFIXDHCPV6] Troan, O. and R. Droms. "IPv6 Prefix Options for [PREFIXDHCPV6] Troan, O. and R. Droms. "IPv6 Prefix Options for
DHCPv6." RFC 3633, December 2003. DHCPv6." RFC 3633, December 2003.
skipping to change at page 17, line 24 skipping to change at page 18, line 24
2.2 Cost and benefits of NAT traversal ............................ 5 2.2 Cost and benefits of NAT traversal ............................ 5
2.2.1 Cost of NAT traversal ....................................... 6 2.2.1 Cost of NAT traversal ....................................... 6
2.2.2 Types of NAT ................................................ 6 2.2.2 Types of NAT ................................................ 6
2.2.3 Reuse of existing mechanisms ................................ 6 2.2.3 Reuse of existing mechanisms ................................ 6
2.3 Development of transition mechanisms .......................... 7 2.3 Development of transition mechanisms .......................... 7
3 Meeting case A requirements ..................................... 7 3 Meeting case A requirements ..................................... 7
3.1 Evaluation of connectivity mechanisms ......................... 7 3.1 Evaluation of connectivity mechanisms ......................... 7
3.2 Security considerations in case A ............................. 8 3.2 Security considerations in case A ............................. 8
4 Meeting case B requirements ..................................... 8 4 Meeting case B requirements ..................................... 8
4.1 Connectivity .................................................. 8 4.1 Connectivity .................................................. 8
4.1.1 Extending a Subnet to Span Multiple Links ................... 8 4.1.1 Extending a Subnet to Span Multiple Links ................... 9
4.1.2 Explicit prefix delegation .................................. 9 4.1.2 Explicit prefix delegation .................................. 9
4.1.3 Recommendation .............................................. 9 4.1.3 Recommendation .............................................. 10
4.2 Communication between IPv4-only and IPv6-capable nodes ........ 9 4.2 Communication between IPv4-only and IPv6-capable nodes ........ 10
4.3 Resolution of names to IPv6 addresses ......................... 10 4.3 Resolution of names to IPv6 addresses ......................... 10
4.3.1 Provisioning the address of a DNS resolver .................. 10 4.3.1 Provisioning the address of a DNS resolver .................. 10
4.3.2 Publishing IPv6 addresses to the Internet ................... 10 4.3.2 Publishing IPv6 addresses to the Internet ................... 11
4.3.3 Resolving the IPv6 addresses of local hosts ................. 11 4.3.3 Resolving the IPv6 addresses of local hosts ................. 11
4.3.4 Recommendations for name resolution ......................... 11 4.3.4 Recommendations for name resolution ......................... 12
4.4 Security considerations in case B ............................. 11 4.4 Security considerations in case B ............................. 12
5 Meeting case C requirements ..................................... 12 5 Meeting case C requirements ..................................... 12
5.1 Connectivity .................................................. 12 5.1 Connectivity .................................................. 12
6 Meeting the case D requirements ................................. 12 6 Meeting the case D requirements ................................. 13
6.1 IPv6 addressing requirements .................................. 12 6.1 IPv6 addressing requirements .................................. 13
6.2 IPv4 connectivity requirements ............................... 13 6.2 IPv4 connectivity requirements ............................... 13
6.3 Naming requirements ........................................... 13 6.3 Naming requirements ........................................... 13
7 Provisional recommendations ..................................... 13 7 Recommendations ................................................. 13
8 Security considerations ......................................... 13 8 Security considerations ......................................... 14
9 IANA Considerations ............................................. 14 9 IANA Considerations ............................................. 14
10 Copyright ...................................................... 14 10 Copyright ...................................................... 14
11 Intellectual Property .......................................... 14 11 Intellectual Property .......................................... 15
12 Acknowledgements ............................................... 15 12 Acknowledgements ............................................... 15
13 References ..................................................... 15 13 References ..................................................... 16
14 Authors' Addresses ............................................. 16 14 Authors' Addresses ............................................. 17
 End of changes. 

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