draft-ietf-v6ops-unmaneval-00.txt   draft-ietf-v6ops-unmaneval-01.txt 
INTERNET DRAFT C. Huitema INTERNET DRAFT C. Huitema
<draft-ietf-v6ops-unmaneval-00.txt> Microsoft <draft-ietf-v6ops-unmaneval-01.txt> Microsoft
June 3, 2003 R. Austein February 4, 2004 R. Austein
Expires December 3, 2003 Bourgeois Dilettante Expires August 4, 2004 Bourgeois Dilettante
S. Satapati S. Satapati
Cisco Systems, Inc. Cisco Systems, Inc.
Ronald van der Pol R. van der Pol
NLnet Labs NLnet Labs
Evaluation of 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
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 10, line ? skipping to change at page 10, line ?
reference material or to cite them other than as "work in progress." reference 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.
Abstract Abstract
In a companion paper we defined the "unmanaged networks" scope, In a companion paper we defined the "unmanaged networks", which
which typically corresponds to home networks or small office typically correspond to home networks or small office networks, and
networks, and the requirements for IPv6 transition mechanism in that the requirements for transition mechanisms in various scenarios of
scope. We start from this analysis and evaluate here the suitability transition to IPv6. We start from this analysis and evaluate here
of mechanisms defined in the NGTRANS working group. the suitability of mechanisms that have already been specified,
proposed or deployed.
1 Introduction 1 Introduction
In a companion paper [UNMANREQ] we defined the "unmanaged networks" This document analyses the issues involved in the transition from
scope, which typically correspond to home networks or small office IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the
networks, and the requirements for IPv6 transition mechanism in that "unmanaged networks", which typically correspond to home networks or
scope. We start from this analysis and evaluate here the suitability small office networks, and the requirements for transition
of mechanisms defined in the NGTRANS working group. mechanisms in various scenarios of transition to IPv6.
The requirements for unmanaged networks are expressed by analyzing The requirements for unmanaged networks are expressed by analyzing
four classes of application: local, client, peer to peer, and four classes of application: local, client, peer to peer, and
servers, and considering four cases of deployment. These are: servers, and considering four cases of deployment. These are:
A) a gateway which does not provide IPv6 at all;
Huitema et al. [Page 1] Huitema et al. [Page 1]
B) a dual-stack gateway connected to a dual stack ISP; A) a gateway which does not provide IPv6 at all;
C) a dual stack gateway connected to an IPV4-only ISP; and B) a dual-stack gateway connected to a dual-stack ISP;
C) a dual-stack gateway connected to an IPv4-only ISP; and
D) a gateway connected to an IPv6-only ISP. D) a gateway connected to an IPv6-only ISP.
This document analyses the issues involved in the transition from During the transition phase from IPv4 to IPv6 there will be IPv4-
IPv4 to IPv6. One of the most important issues is that of naming and only, dual-stack or IPv6-only nodes. In this document, we make the
addressing. hypothesis that the IPv6-only nodes do not need to communicate with
IPv4-only nodes; devices that want to communicate with both IPv4 and
During the transition phase from IPv4 to IPv6 there will be IPv4 IPv6 nodes are expected to implement both IPv4 and IPv6, i.e., be
only, dual stack or IPv6 only nodes. In this document, we make the dual-stack.
hypothesis that the IPv6 only nodes do not need to communicate with
IPv4 only nodes; devices that want to communicate with both IPv4 and
IPv6 nodes are expected to implement both IPv4 and IPv6, i.e. be
dual stack.
The issues involved are described in the next chapters. This The issues involved are described in the next sections. This
analysis outlines two types of requirements: connectivity analysis outlines two types of requirements: connectivity
requirements, i.e. how to ensure that nodes can exchange IP packets, requirements, i.e., how to ensure that nodes can exchange IP
and naming requirements, i.e. how to ensure that nodes can resolve packets, and naming requirements, i.e., how to ensure that nodes can
each-other's names. resolve each-other's names. The connectivity requirements often
require tunneling solutions. We devote the first section of this
memo to an evaluation of various tunneling solutions.
2 Meeting case A requirements 2 Evaluation of Tunneling Solutions
In case A, isolated hosts located behind a NAT need to acquire some In the case A and case C scenarios described in [UNMANREQ], the
form of connectivity. In this section, we first evaluate how unmanaged network cannot obtain IPv6 service, at least natively,
mechanisms already defined or being worked on in the IETF meet this from its ISP. In these cases, the IPv6 service will have to be
requirement. We then consider the "remaining holes" and recommend provided through some form of tunnel. There have been multiple
specific developments. proposals on different ways to tunnel IPv6 through an IPv4 service.
We believe that these proposals can be categorized according to two
important properties:
2.1 Evaluation of connectivity mechanisms * Is the deployment automatic, or does it require explicit
configuration or service provisioning?
In case A, IPv6 capable hosts seek IPv6 connectivity in order to * Does the proposal allow for the traversal of a NAT [NAT-T]?
participate to applications in the global IPv6 Internet. The
connectivity requirement can be met in two ways: Teredo, or UDP
tunnels. (We will not discuss here the case where there is no NAT;
this will be considered as a subset of case C.)
2.1.1 TEREDO These two questions divide the solution space into four broad
classes. Each of these classes has specific advantages and risks,
which we will now develop.
TEREDO is a mechanism designed to provide IPv6 connectivity to hosts 2.1 Comparing automatic and configured solutions
behind NATs. Hosts use servers to find out a "mapped" IPv4 address
and UDP port; they build an IPv6 address that includes the IPv4
address of their preferred server, and their own mapped IPv4 address
and mapped port. A mechanism of bubbles, relayed by the servers, is
used for establishing contacts between Teredo nodes, or for
discovering the appropriate Teredo relay serving an IPv6 peer; the
actual IPv6 packets are carried in UDP packets exchanged directly
between the nodes, or exchanged through the relay serving an IPv6
peer.
2.1.2 Simple UDP tunnel It is possible to broadly classify tunneling solutions as either
"automatic" or "configured". In an automatic solution, a host or a
router builds an IPv6 address or an IPv6 prefix by combining a pre-
defined prefix with some local attribute, such as local IPv4 address
[6TO4] or the combination of an address and a port number [Teredo].
Another typical and very important characteristic of an automatic
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
solution, a host or a router identifies itself to a tunneling
service to set up a "configured tunnel" with an explicitly defined
Huitema et al. [Page 2] Huitema et al. [Page 2]
An alternative to TEREDO is to simply establish a tunnel to a "tunnel router".
"tunnel broker" outside the unmanaged network; in order to traverse
the NAT, the IPv6 packets would be carried over UDP. This solution
was described in a draft that has now expired, and is also mentioned
as a possible alternative to the bubble mechanism in the TEREDO
specification.
2.1.3 Comparison of TEREDO and tunnel solution Configured tunnels have many advantages over automatic tunnels. The
client is explicitly identified and can obtain a stable IPv6
address. The service provider is also well identified and can be
held responsible for the quality of the service. It is possible to
route multicast packets over the established tunnel. There is a
clear address delegation path, which enables easy support for
reverse DNS lookups.
The TEREDO and tunnel solutions differ in terms of complexity and Automatic tunnels generally cannot provide the same level of
operation. service. The IPv6 address is only as stable as the underlying IPv4
address, the quality of service depends on relays operated by third
parties, there is typically no support for multicast, and there is
often no easy way to support reverse DNS lookups (although some
workarounds are probably possible). However, automatic tunnels have
other advantages. They are obviously easier to configure, since
there is no need of an explicit relation with a tunnel service. They
may also be in some case more efficient, as they allow for "path
optimization".
A first difference is the cost of operating the server. TEREDO is 2.1.1 Path optimization in automatic tunnels
designed to minimize the cost of operating the server, which only
processes small bubbles and never relays traffic; on the other hand,
a tunnel server will relay all the packets going to and from the
Teredo host. This implies a very different amount of traffic.
To gauge the difference, we consider the case of a host engaging in In automatic tunnels like [Teredo] and [6to4], the bulk of the
Voice over IP: it will maintain its address reachable all the time, traffic between two nodes using the same technology is exchanged on
and it will send a large amount of traffic whenever it is engaged in a direct path between the endpoints, using the IPv4 services to
a conversation. According to classic figures collected by AT&T, the which the endpoints already subscribe. By contrast, the configured
average duration of a conversation is around 100 seconds, and a tunnel servers carry all the traffic exchanged by the tunnel client.
business telephone is likely to be engaged in a conversation about
10% of the time, which implies starting a conversation on average
every 1000 seconds. The average load sent by a tunnel client to the
tunnel server will be 10% of the average data rate of the client;
assuming a 16kbps codec and 50 packets per second, the data rate of
the client sums up to about 51 kbps, hence an average load on the
tunnel server of 5 kbps. The load sent by the tunnel client to the
tunnel server will be about one exchange of bubble per minute, to
defend the address, plus one bubble exchange at the beginning of
each session with a new peer; adding all headers, the bubble size is
about 144 bytes, which results in about 20 bps of traffic on the
server. In short, the amount of traffic seen by the Teredo server is
250 times less that the traffic seen by a Teredo client.
The tunnel approach is more expensive to provide, because the tunnel Path optimization is not a big issue if the tunnel server is close
server will have to carry a much larger amount of traffic. It is to the client, on the natural path between the client and its peers.
unclear that a tunnel service can be provided as an almost free However, if the tunnel server is operated by a third party, this
"supporting infrastructure", except perhaps if the service was third party will have to bear the cost of provisioning the bandwidth
directly provided by the same ISP that already provides IPv4 used by the client. The associated costs can be significant.
connectivity to the unmanaged network.
The two approaches have much in common: both need to parameterize a These costs are largely inexistent when the tunnels are configured
client with the name of a server and with sufficient credentials; by the same ISP that provides the IPv4 service. The ISP can place
the encapsulation is similar; both use the same encapsulation the tunnel end-points close to the client, i.e., mostly on the
mechanism; and both will use router solicitations to obtain an direct path between the client and its peers.
address prefix. The main difference is the handling of bubbles in
Teredo, which are used to defend the address and to initiate 2.1.2 Automatic tunnels and relays
sessions with peers. This is obviously more complex than sending the
packet without any processing, but the complexity is only marginally The economics arguments related to path optimization favor either
configured tunnels provided by the local ISP or automatic tunneling
regardless of the co-operation of ISPs. However, automatic solutions
require that relays be configured throughout the Internet. If a host
that obtained connectivity through an automatic tunnel service wants
to communicate with a "native" host, it will need to use a relay
service, and someone will have to provide and pay for that service.
We cannot escape economic considerations for the deployment of these
relays.
Huitema et al. [Page 3] Huitema et al. [Page 3]
higher than the discovery of link layer addresses using neighbor It is desirable to locate these relays close to the "native host".
discovery. In short, Teredo is more complex, but the complexity is During the transition period, the native ISPS have an interest in
not overwhelming. providing a relay service for use by their native subscribers. Their
subscribers will enjoy better connectivity, i.e., will be happier.
Providing the service does not result in much extra bandwidth
requirement: the packets are exchanged between the local subscribers
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
relays for general use; they are expected to restrict access to
these relays to their customers.)
An advantage of the tunnel server approach over Teredo is that it We should note however that different automatic tunneling techniques
will work regardless of the type and number of NAT between the have different deployment conditions.
client and the tunnel server. In contrast, Teredo will not work
across a "symmetric" NAT, and communication may be impossible
between two Teredo clients located behind the same NAT.
Another potential advantage of the tunnel server approach is that it 2.1.3 The risk of several parallel IPv6 Internets
could provide clients with stable IPv6 addresses. This is only a
potential advantage, since the server may prefer to delegate
addresses on a session per session basis, or may want to operate in
a stateless manner.
2.1.4 Recommendation In an early deployment of the Teredo service by Microsoft, the
relays are provided by the native (or 6to4) hosts themselves. The
native or 6to4 hosts are de-facto multi-homed to native and Teredo,
although they never publish a Teredo address in the DNS or
otherwise. When a native host communicates with a Teredo host, the
first packets are exchanged through the native interface and relayed
by the Teredo server, while the subsequent packets are tunneled
"end-to-end" over IPv4 and UDP. This enables deployment of Teredo
without having to field an infrastructure of relays in the network.
Teredo appears to be a good fit for providing IPv6 connectivity to This type of solution carries the implicit risk of developing two
hosts behind NAT, in case A of IPv6 deployment. The service is parallel IPv6 Internets, one native and one using Teredo: in order
designed for minimizing the cost of deploying the server, which to communicate with a Teredo-only host, a native IPv6 host has to
matches the requirement of minimizing the cost of the "supporting implement a Teredo interface. The Teredo implementations try to
infrastructure" for peer-to-peer applications. mitigate this risk by always preferring native paths when available,
but a true mitigation requires that native hosts do not have to
implement the transition technology. This requires cooperation from
the IPv6 ISP, who will have to support the relays. An IPv6 ISP that
really wants to isolate its customers from the Teredo technology can
do that by providing native connectivity and a Teredo relay. The
ISP's customers will not need to implement their own relay.
There are however two situations in which a tunnel service makes Communication between 6to4 networks and native networks uses a
sense: when the cost of bandwidth is not a concern, and when the different structure. There are two relays, one for each direction of
unmanaged network is located behind a symmetric NAT. In these two communication. The native host sends its packets through the nearest
cases, using a tunnel service is preferred over using Teredo. 6to4 router, i.e., the closest router advertising the 2002::/16
prefix through the IPv6 routing tables; the 6to4 network sends its
packet through a 6to4 relay that is either explicitly configured or
discovered through the 6to4 anycast address 192.88.99.1
[6To4ANYCAST]. The experience so far is that simple 6to4 routers are
easy to deploy, but 6to4 relays are scarce. If there are too few
relays, these relays will create a bottleneck. The communications
between 6to4 and native networks will be slower than the direct
communications between 6to4 hosts. This will create an incentive for
native hosts to somehow "multi-home" to 6to4, de facto creating two
parallel Internets, 6to4 and native. This risk will only be
The most reasonable solution would be to develop a tunnel service Huitema et al. [Page 4]
specification that is compatible with Teredo, so that a given host mitigated if there is a sufficient deployment of 6to4 relays.
could be configured to use either Teredo or the tunnel service,
depending on the server configured in the dual stack host.
2.2 Security considerations in case A 2.1.4 Lifespan of transition technologies
A characteristic of case A is that a host located behind a NAT A related issue is the lifespan of the transition solutions. Since
acquires global IPv6 connectivity, using either Teredo or an automatic tunneling technologies enable an automatic deployment,
alternative tunneling mechanism. If no precaution is taken, there is there is a risk that some hosts never migrate out of the transition.
a risk of exposing to the global Internet some applications and The risk is arguably less for explicit tunnels: the ISPS who provide
services that only expected to serve local hosts, located behind the the tunnels have an incentive to replace them with a native solution
NAT. Developers and administrators should make sure that the global as soon as possible.
IPv6 connectivity is restricted to only those applications that are
expressly designed for global Internet connectivity.
3 Meeting case B requirements Many implementations of automatic transition technologies
incorporate an "implicit sunset" mechanism: the hosts will not
configure a transition technology address if they have native
connectivity; the address selection mechanisms will prefer native
addresses when available. The transition technologies will stop
being used eventually, when native connectivity has been deployed
everywhere. However, the "implicit sunset" mechanism does not
provide any hard guarantee that transition will be complete at a
certain date.
In case B, we assume that the gateway and the ISP are both dual Yet, the support of transition technologies has a cost for the
stack. The hosts on the local network may be IPv4 only, dual stack, entire network: native IPv6 ISPS have to support relays in order to
or IPv6 only. The main requirements are: prefix delegation, and name provide good performance and avoid the "parallel Internet" syndrome.
resolution. We also study the potential need for communication These costs may be acceptable during an initial deployment phase,
between IPv4 and IPv6 hosts, and conclude that a dual stack approach but they can certainly not be supported for an indefinite period.
The "implicit sunset" mechanisms may not be sufficient to guarantee
a finite lifespan of the transition.
Huitema et al. [Page 4] 2.2 Cost and benefits of NAT traversal
During the transition, some hosts will be located behind IPv4 NATs.
In order to participate in the transition, these hosts will have to
use a tunneling mechanism designed to traverse NAT.
We may ask whether NAT traversal should be a generic property of any
transition technology, or whether it makes sense to develop two
types of technologies, some "NAT capable" and some not. An
important question is also which kinds of NAT boxes one should be
able to traverse. One should probably also consider whether it is
necessary to build an IPv6 specific NAT traversal mechanism, or
whether it is possible to combine an existing IPv4 NAT traversal
mechanism with some form of IPv6 in IPv4 tunneling. There are many
IPv4 NAT traversal mechanisms; thus one may ask whether these need
re-invention, especially when they are already complex.
A related question is whether the NAT traversal technology should
use automatic tunnels or configured tunnels. We saw in the previous
section that one can argue both sides of this issue. In fact, there
are already deployed automatic and configured solutions, so the
reality is that we will probably see both.
Huitema et al. [Page 5]
2.2.1 Cost of NAT traversal
NAT traversal technologies generally involve encapsulating IPv6
packets inside a transport protocol that is known to traverse NAT,
such as UDP or TCP. These transport technologies require
significantly more overhead than the simple tunneling over IPv4 used
in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on
UDP require the frequent transmission of "keep alive" packets to
maintain a "mapping" in the NAT; solutions based on TCP may not
require such mechanism, but they incur the risk of "head of queue
blocking", which may translate in poor performances. Given the
difference in performance, it makes sense to consider two types of
transition technologies, some capable of traversing NAT and some
aiming at the best performance.
2.2.2 Types of NAT
There are many kinds of NAT on the market. Different models
implement different strategies for address and port allocations, and
also different types of timers. It is desirable to find solutions
that cover "almost all" models of NAT.
A configured tunnel solution will generally make fewer hypotheses on
the behavior of the NAT than an automatic solution. The configured
solutions only need to establish a connection between an internal
node and a server; this communication pattern is supported by pretty
much all NAT configurations. The variability will come from the type
of transport protocols that the NAT support, especially when the NAT
also implements "firewall" functions. Some models will allow
establishment of a single "protocol 41" tunnel, while some may
prevent this type of transmission. Some models will allow UDP
transmission, while other may only allow TCP, or possibly HTTP.
The automatic solutions have to rely on a "lower common denominator"
that is likely to be accepted by most models of NAT. In practice,
this common denominator is UDP. UDP based NAT traversal is required
by many applications, e.g., networked games or voice over IP. The
experience shows that most recent "home routers" are designed to
support these applications. In some edge cases, the automatic
solutions will require explicit configuration of a port in the home
router, using the so-called "DMZ" functions.
2.2.3 Reuse of existing mechanisms
NAT traversal is not a problem for IPv6 alone. Many IPv4
applications have developed solutions, or kludges, to enable
communication across a NAT.
Virtual Private Networks are established by installing tunnels
between VPN clients and VPN servers. These tunnels are designed
today to carry IPv4, but in many cases could easily carry IPv6. For
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
designed to pass VPN traffic, and several VPN solutions have special
provisions to traverse NAT. When we study the establishment of
configured tunnels through NAT, it makes a lot of sense to consider
existing VPN solutions.
[STUN] is a protocol designed to facilitate the establishment of UDP
associations through NAT, by letting nodes behind NAT discover their
"external" address. The same function is required for automatic
tunneling through NAT, and one could consider reusing the STUN
specification as part of an automatic tunneling solution. However,
the automatic solutions also require a mechanism of bubbles to
establish the initial path through a NAT. This mechanism is not
present in STUN. It is not clear that a combination of STUN and a
bubble mechanism would have a technical advantage over a solution
specifically designed for automatic tunneling through NAT.
2.3 Development of transition mechanisms
The previous sections make the case for the development of four
transition mechanism, covering the following 4 configuration:
- Configured tunnel over IPv4 in the absence of NAT;
- Automatic tunnel over IPv4 in the absence of NAT;
- Configured tunnel across a NAT;
- Automatic tunnel across a NAT.
Teredo is an example of already designed solution for automatic
tunnel across a NAT; 6to4 is an example of solution for automatic
tunnel over IPv4 in the absence of NAT.
All solutions should be designed to meet generic requirements such
as security, scalability, support for reverse name lookup, or simple
management. In particular, automatic tunneling solutions may need to
be augmented with a special purpose reverse DNS lookup mechanism,
while configured tunnel solutions would benefit from an automatic
service configuration mechanism.
3 Meeting case A requirements
In case A, isolated hosts need to acquire some form of connectivity.
In this section, we first evaluate how mechanisms already defined or
being worked on in the IETF meet this requirement. We then consider
the "remaining holes" and recommend specific developments.
3.1 Evaluation of connectivity mechanisms
In case A, IPv6 capable hosts seek IPv6 connectivity in order to
communicate with applications in the global IPv6 Internet. The
connectivity requirement can be met using either configured tunnels
or automatic tunnels.
Huitema et al. [Page 7]
If the host is located behind a NAT, the tunneling technology should
be designed to traverse NAT; tunneling technologies that do not
support NAT traversal can obviously be used if the host is not
located behind a NAT.
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.
An automatic solution like Teredo appears to be a good fit for
providing IPv6 connectivity to hosts behind NAT, in case A of IPv6
deployment. The service is designed for minimizing the cost of
deploying the server, which matches the requirement of minimizing
the cost of the "supporting infrastructure".
3.2 Security considerations in case A
A characteristic of case A is that an isolated host acquires global
IPv6 connectivity, using either Teredo or an alternative tunneling
mechanism. If no precaution is taken, there is a risk of exposing to
the global Internet some applications and services that only
expected to serve local hosts, e.g., those located behind the NAT
when a NAT is present. Developers and administrators should make
sure that the global IPv6 connectivity is restricted to only those
applications that are expressly designed for global Internet
connectivity. The users should be able to configure which
applications can get IPv6 connectivity to the Internet and which
should not.
4 Meeting case B requirements
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,
or IPv6-only. The main requirements are: prefix delegation, and name
resolution. We also study the potential need for communication
between IPv4 and IPv6 hosts, and conclude that a dual-stack approach
is preferable. is preferable.
3.1 Prefix delegation 4.1 Connectivity
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. The possible mechanisms are RA proxy and explicit prefix ISP. This can be done through explicit prefix delegation (e.g.,
delegation. 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.
3.1.1 RA proxy 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
link).
The implicit delegation mechanism assumes that the gateway is 4.1.1 Extending a Subnet to Span Multiple Links
connected to the ISP by a point-to-point link. Examples of such
point to point links are various types of configured tunnels and
serial links, for example using PPP. The principle of RA proxy is
simple: the gateway issues a "router solicitation" message on the
serial link, receives a "router advertisement", learns a network
prefix from the advertisement, and advertises the same prefix on the
unmanaged network.
The RA proxy method results in the sharing of the same prefix over A /64 subnet can be extended to span multiple physical links using a
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
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
interface cannot be put into promiscuous mode (e.g., an upstream
wireless link).
Extending a single subnet to span from the ISP to the all of the
unmanaged network is not recommended, and prefix delegation should
be used when available. However, sometimes it is unavoidable. In
addition, sometimes it's necessary to extend a subnet in the
unmanaged network, at the "customer-side" of the gateway, and
changing the topology using routing might require too much
expertise.
The ND proxy method results in the sharing of the same prefix over
several links, a procedure generally known as "multi-link subnet". several links, a procedure generally known as "multi-link subnet".
This sharing has effects on neighbor discovery protocols, and This sharing has effects on neighbor discovery protocols, and
possibly also on other protocols such as LLMNR that rely on "link possibly also on other protocols such as LLMNR [LLMNR] that rely on
local multicast". These effects need to be carefully studied. "link local multicast". These effects need to be carefully studied.
3.1.2 Explicit prefix delegation 4.1.2 Explicit prefix delegation
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. enables the ISP to implement prefix delegation policies. It is
expected that the ISP assigns a /48 to the customer. The gateway
should automatically assign /64s out of this /48 to its internal
links.
The basic use of DHCP is insecure. This may be a problem if the link The basic use of DHCP is insecure. This may be a problem if the link
between gateway and ISP is shared by multiple subscribers. In that between gateway and ISP is shared by multiple subscribers. DHCP
case, some security procedure will have to be used, to ensure at a specification includes authentication options, but does not describe
minimum that DHCP requests and replies are properly authenticated. the task of managing the keys, and how the information would be
shared between the customer and the ISP. To be useful in such
environment in practice, the practical details of managing the DHCP
authentication need to be analyzed.
3.1.3 Recommendation 4.1.3 Recommendation
The RA proxy and DHCP methods appear to have different domains of The ND proxy and DHCP methods appear to have different domains of
application. RA proxy is a simple method that corresponds well to 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 RA proxy; specify the interaction with neighbor discovery for ND proxy;
provide security guidelines for explicit delegation. Proceeding with provide security guidelines for explicit delegation.
standardization of at least one method, and possibly both, is quite
urgent.
3.2 Communication between IPv4-only and IPv6-capable nodes 4.2 Communication between IPv4-only and IPv6-capable nodes
Huitema et al. [Page 5]
During the transition phase from IPv4 to IPv6 there will be IPv4- During the transition phase from IPv4 to IPv6 there will be IPv4-
only, dual stack and IPv6-only nodes. In theory, there may be a need
Huitema et al. [Page 9]
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, as indicated in a companion only hosts can communicate. However, it is hard to develop a
document, it is hard to develop a translation service that does not translation service that does not have unwanted side effects on the
have unwanted side effects on the efficiency or the security of efficiency or the security of communications. As a consequence, the
communications. As a consequence, the authors recommend that, if a authors recommend that, if a device has a requirement to communicate
device has a requirement to communicate with IPv4 only hosts, this with IPv4-only hosts, this device implements an IPv4 stack. The only
device implements an IPv4 stack. The only devices that should only devices that should only have IPv6 connectivity are those that are
have IPv6 connectivity are those that are intended to only intended to only communicate with IPv6 hosts.
communicate with IPv6 hosts.
3.3 Resolution of names to IPv6 addresses 4.3 Resolution of names to IPv6 addresses
There are three types of name resolution services that should be There are three types of name resolution services that should be
provided in case B: local IPv6 capable hosts must be able to obtain provided in case B: local IPv6 capable hosts must be able to obtain
the IPv6 addresses of correspondent hosts on the Internet; they the IPv6 addresses of correspondent hosts on the Internet; they
should be able to publish their address if they want to be accessed should be able to publish their address if they want to be accessed
from the Internet; and they should be able to obtain the IPv6 from the Internet; and they should be able to obtain the IPv6
address of other local IPv6 hosts. These three problems are address of other local IPv6 hosts. These three problems are
described in the next sections. described in the next sections. Operational considerations and
issues with IPv6 DNS are analyzed in [DNSOPV6].
3.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 even the
simple DNS resolvers present in small gateways can relay arbitrary simple DNS resolvers present in small gateways can relay arbitrary
DNS request and serve arbitrary DNS records, including AAAA records. DNS requests and serve arbitrary DNS records, including AAAA
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. Three solutions have been envisaged for these hosts: local hosts. The DHCP working group has defined how to use
either using DHCPv6 to obtain the address of the DNS server; sending (stateless) DHCPv6 to obtain the address of the DNS server
the DNS requests to a well known IPv6 address; or sending the DNS [DNSDHCPV6]. DHCPv6 and several other possibilities are being looked
requests to the IPv6 address of the gateway itself. at in the DNSOP Working Group.
3.3.2 Publishing IPv6 addresses to the Internet 4.3.2 Publishing IPv6 addresses to the Internet
IPv6 capable hosts may be willing to provide services accessible IPv6 capable hosts may be willing to provide services accessible
from the global Internet. They will thus need to document their from the global Internet. They will thus need to document their
address in a server that is publicly available. IPv4 hosts in address in a server that is publicly available. IPv4 hosts in
unmanaged networks have a similar problem today, which they solve unmanaged networks have a similar problem today, which they solve
using one of three possible solutions: using one of three possible solutions:
* Manual configuration of a stable address in a DNS server; * Manual configuration of a stable address in a DNS server;
* Dynamic configuration using the standard dynamic DNS protocol; * Dynamic configuration using the standard dynamic DNS protocol;
* Dynamic configuration using an ad hoc protocol. * Dynamic configuration using an ad hoc protocol.
Huitema et al. [Page 6]
Manual configuration of stable addresses is not satisfactory in an Manual configuration of stable addresses is not satisfactory in an
unmanaged IPv6 network: the prefix allocated to the gateway may or unmanaged IPv6 network: the prefix allocated to the gateway may or
may not be stable, and in any case copying long binary addresses may not be stable, and in any case copying long hexadecimal strings
through a manual procedure is error prone. through a manual procedure is error prone.
Dynamic configuration using the same type of ad hoc protocols that Dynamic configuration using the same type of ad hoc protocols that
are common today is indeed possible, but the IETF should encourage are common today is indeed possible, but the IETF should encourage
the use of standard solutions based on DDNS. the use of standard solutions based on Dynamic DNS (DDNS).
3.3.3 Resolving the IPv6 addresses of local hosts 4.3.3 Resolving the IPv6 addresses of local hosts
There are two possible ways of resolving the IPv6 addresses of local There are two possible ways of resolving the IPv6 addresses of local
hosts: one may either publish the IPv6 addresses in a DNS server for hosts: one may either publish the IPv6 addresses in a DNS server for
the local domain, or one may use a peer-to-peer address resolution the local domain, or one may use a peer-to-peer address resolution
protocol such as LLMNR. protocol such as LLMNR.
When a DNS server is used, this server could in theory be located When a DNS server is used, this server could in theory be located
anywhere on the Internet. There is however a very strong argument anywhere on the Internet. There is however a very strong argument
for using a local server, which will remain reachable even if the for using a local server, which will remain reachable even if the
network connectivity is down. network connectivity is down.
The use of a local server requires that IPv6 capable hosts discover The use of a local server requires that IPv6 capable hosts discover
this server, as explained in 3.3.1, and then that they use a this server, as explained in 4.3.1, and then that they use a
protocol such as DDNS to publish their IPv6 addresses to this protocol such as DDNS to publish their IPv6 addresses to this
server. In practice, the DNS address discovered in 3.3.1 will often server. In practice, the DNS address discovered in 4.3.1 will often
be the address of the gateway itself, and the local server will thus be the address of the gateway itself, and the local server will thus
be the gateway. Implementing a dynamic DNS server on the gateway may be the gateway.
be problematic, as many of these gateways are very small devices
with limited memory and limited processing power.
An alternative to using a local server is LLMNR, which uses a An alternative to using a local server is LLMNR, which uses a
multicast mechanism to resolve DNS requests. LLMNR does not require multicast mechanism to resolve DNS requests. LLMNR does not require
any service from the gateway, and also does not require that hosts any service from the gateway, and also does not require that hosts
use DDNS. LLMNR relies on multicast for its operation. There are use DDNS. An important problem is that some networks only have
scaling issues with using multicast, as the procedure may become limited support for multicast transmission: for example, multicast
very chatty in large networks; but this is not a practical problem transmission on 802.11 network is error prone. However, unmanaged
in most unmanaged networks. A more important problem is that some networks also use multicast for neighbor discovery [NEIGHBOR]; the
networks only have limited support for multicast transmission: for requirements of ND and LLMNR are similar; if a link technology
example, multicast transmission on 802.11 network is error prone. supports use of ND, it can also enable use of LLMNR.
However, unmanaged networks also use multicast for neighbor
discovery; the requirements of ND and LLMNR are similar; if a link
technology supports use of ND, it will also enable use of LLMNR.
3.3.4 Recommendations for name resolution 4.3.4 Recommendations for name resolution
The IETF should quickly provide a recommended procedure for The IETF should quickly provide a recommended procedure for
provisioning the DNS resolver in IPv6 only hosts, either by provisioning the DNS resolver in IPv6-only hosts, either by
standardizing the proper DHCPv6 subset, or by recommending an standardizing the proper DHCPv6 subset, or by recommending an
alternate convention. alternate convention.
The most plausible candidate for local name resolution appears to be The most plausible candidate for local name resolution appears to be
LLMNR; the IETF should quickly proceed to the standardization of
Huitema et al. [Page 7]
LLMNR; the IETF should quickly proceed to the standardization fo
that protocol. that protocol.
3.4 Security considerations in case B 4.4 Security considerations in case B
The case B solutions provide global IPv6 connectivity to the local The case B solutions provide global IPv6 connectivity to the local
hosts. Removing the limit to connectivity imposed by NAT is both a hosts. Removing the limit to connectivity imposed by NAT is both a
feature and a risk. Implementations should carefully limit global feature and a risk. Implementations should carefully limit global
IPv6 connectivity to only those applications that are specifically IPv6 connectivity to only those applications that are specifically
designed to operate on the global Internet. Local applications, for designed to operate on the global Internet. Local applications, for
example, could be restricted to only use link-local addresses, or example, could be restricted to only use link-local addresses, or
addresses whose most significant bits match the prefix of the local addresses whose most significant bits match the prefix of the local
subnet. subnet, e.g., a prefix advertised as "on link" in a local router
advertisement. There is a debate as to whether such restrictions
should be "per-site" or "per-link", but this is not a serious issue
when an unmanaged network is composed of a single link.
4 Meeting case C requirements 5 Meeting case C requirements
Case C is very similar to case B, the difference being that the ISP Case C is very similar to case B, the difference being that the ISP
is not dual stack. The gateway must thus use some form of tunneling is not dual-stack. The gateway must thus use some form of tunneling
mechanism to obtain IPv6 connectivity, and an address prefix. mechanism to obtain IPv6 connectivity, and an address prefix.
A simplified form of case B occurs is a single host with a global A simplified form of case B occurs is a single host with a global
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.
4.1 Tunneling mechanisms 5.1 Connectivity
4.1.1 6to4
The [6TO4] technology allows routers to derive a global scope IPv6
prefix from a global IPv4 address. This technology is a very good
fit for the second phase of the transition, as it can be programmed
in the "upgraded gateway", and can provide value to the gateway
users without requiring explicit support from the ISP. This
technology has however a clear limitation: it requires that the
gateway obtains at least one global IPv4 address from the local ISP.
Another potential limitation of the technology is the reliance on
publicly accessible "6to4 relay routers" that accept packets from
6to4 routers and relay them to the "regular" IPv6 Internet. These
relays all listen to the same IPv4 anycast address [6TO4ANYCAST],
which enables gateways to start operating as 6to4 routers without
requiring any explicit configuration. As the deployment of IPv6
progresses, a growing fraction of the traffic originating from 6to4
routers will have to be carried through these relays, potentially
leading to severe congestion of the relays.
There are three possible ways to alleviate this congestion. First,
one can hope that many actors will deploy 6to4 relay routers, in
order to facilitate the deployment of IPv6; congestion would be
alleviated by the provision of a large number of gateways. Second,
one could develop some "route optimization" process, so that the
Huitema et al. [Page 8]
traffic would flow through a "shortcut path" rather than through the
6to4 relays; the relays would then avoid congestion by carrying only
a small fraction of the traffic. Third, if neither the first nor the
second solution materializes, some gateways may enter into
contractual agreements with relay service providers; in this case,
the 6to4 technology would become merely a variant of the configured
tunnel technologies.
4.1.2 Tunnel broker
Configured tunnels require a contractual agreement with an IPv6
provider, which comes in addition to the existing agreement with the
IPv4 provider; different technologies have different domains of
application.
Many tunnel technologies use a global IPv4 address to identify the
"client end" of the tunnel, thus inheriting the same "global IPv4
address" requirement as 6TO4. A variant of the [TEREDO] technology
could be used to establish tunnels over UDP when the client is
behind a NAT; this variant is however not standardized.
Practical deployment of tunnel technologies requires the
introduction of accounting/billing functions; the existing tunnel
broker specification, [TUNNELS], does not describe how these
functions should be implemented. (However, the use of public relays
in the 6to4 technology may raise a similar issue.)
Configured tunnels are in practice an intermediate solution between
the "automatic configuration" provided by 6to4, and the "ISP
support" that characterizes case B.
4.1.3 ISATAP
The ISATAP protocol [ISATAP] enables the construction of IPv6
addresses by combining a subnet prefix with an identifier derived
from an IPv4 address. Hosts in an ISATAP subnet exchange IPv6
packets by an automatic tunneling mechanism: the IPv6 packets are
tunneled over IPv4 towards the IPv4 address specified in the
identifier part of the address. Hosts in the ISATAP tunnel
communicate with the IPv6 Internet by sending packets to the ISATAP
subnet routers. In practical deployments, ISATAP hosts are
configured with the IPv4 address or the DNS name of an ISATAP
router.
In theory, ISATAP could be used to provide hosts in an unmanaged
network with IPv6 connectivity; the gateway might function as an
ISATAP router. However, in a single subnet deployment, this solution
is markedly inferior to native IPv6: it incurs more overhead, and is
not easier to deploy.
One may also consider using the ISATAP technology to provide IPv6
connectivity to the gateway itself. However, ISATAP only derives a
Huitema et al. [Page 9]
single IPv6 address from an IPv4 address. ISATAP can thus only be
used in the degenerate case when the unmanaged network consists of a
single host. This will only be interesting if this single host does
not obtain a global IPv4 address from the ISP; if it did, it could
use 6TO4, which is easier to configure. An ISP that provides hosts
with non-global IPv4 address could set up an ISATAP router, so that
each of these hosts could obtain an IPv6 address.
4.1.4 Recommendations
The practical conclusion of the previous analysis is that "upgraded Connectivity in case C requires some form of tunneling of IPv6 over
gateways" will probably support the 6TO4 technology, and will have IPv4. The various tunneling solutions are discussed in section 2.
an optional configuration option for "configured tunnels". The The requirements of case C can be solved by an automatic tunneling
ISATAP technology appears to have very limited applicability in this mechanism such as 6to4 [6TO4]. An alternative may be the use of a
scenario. configured tunnels mechanism [TUNNELS], but as the local ISP does is
not IPv6-enabled this may not be feasible. The practical conclusion
of our analysis is that "upgraded gateways" will probably support
the 6to4 technology, and will have an optional configuration option
for "configured tunnels".
The tunnel broker technology should be augmented, to include support The tunnel broker technology should be augmented, to include support
for accounting and billing functions. 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.
4.2 Naming requirements in case C 6 Meeting the case D requirements
Naming requirements are similar to case B.
4.3 Security considerations in case C
The security issues in case C combines the issues already mentioned
in case B, plus the specific issues related to the use of tunneling
technologies. The main concern with tunneling technologies is the
possibility for attackers to spoof the source address of IPv6
packets sent inside a tunnel, and use this spoofing as the basis for
various attacks. Attacks on 6TO4 tunnels are documented in
[6TO4SECU]. Configured tunnels that do not use per packet
authentication can also be subject to spoofing attacks, if the
attacker is able to spoof the source IPv4 address of either a tunnel
server or a tunnel client.
5 Meeting the case D requirements
In case D, the ISP only provides IPv6 services. In case D, the ISP only provides IPv6 services.
5.1.1 IPv6 addressing requirements 6.1 IPv6 addressing requirements
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 RA proxy or explicit configuration to provision an i.e., use either ND proxy or explicit prefix delegation through
IPv6 prefix on the gateway. DHCPv6 to provision an IPv6 prefix on the gateway.
5.1.2 IPv4 connectivity requirements 6.2 IPv4 connectivity requirements
Local IPv4 capable hosts may want to still access IPv4 only
services. The proper way to do this for dual stack nodes in the Local IPv4 capable hosts may want to still access IPv4-only
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. This tunneling protocol need to be standardized. Part of
the standardization will have to cover configuration issues, i.e. the standardization will have to cover configuration issues, i.e.,
how to provision the IPv4 capable hosts with the address of the how to provision the IPv4 capable hosts with the address of the
local IPv4 tunnel servers. local IPv4 tunnel servers.
5.2 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 DNS gateway cannot expect to use DHCPv4 to obtain the address of the
resolver recommended by the ISP. This problem is similar to the DNS resolver recommended by the ISP.
provision of DNS parameters to an IPv6 only host in case B, and the
same mechanisms can be used.
5.3 Security requirements
Security requirements in case D are analogous to those of case B.
The use of a tunneling mechanism to provide IPv4 connectivity may
introduce its own security issues, but the analysis of these issues
can only be performed after this tunneling mechanism is fully
designed.
6 Provisional recommendations
This draft is still a draft, but we can already list a set of
recommendations for the V6OPS working group:
1- To meet case A requirements, we need to develop and standardize 7 Provisional recommendations
the Teredo or similar technology.
2- To meet case B prefix delegation requirements, we need a After a careful analysis of the possible solutions, we can list a
standardized IPv6 prefix delegation mechanism set of recommendations for the V6OPS working group:
3- To meet case B "informal prefix sharing" requirements, we would 1- To meet case A and case C requirements, we need to develop, or
need a standardized way to perform "RA proxy", possibly as part of a continue to develop, four types of tunneling technologies: automatic
"multi-link subnet" specification tunnels without NAT traversal such as [6TO4], automatic tunnels with
NAT traversal such as [TEREDO], configured tunnels without NAT
traversal such as [TUNNELS] and configured tunnels with NAT
traversal.
4- To meet case B naming requirements, we need to standardize a way 2- To meet case B "informal prefix sharing" requirements, we would
to provision a DNS resolver address in IPv6 only hosts, and we need need a standardized way to perform "ND proxy", possibly as part of a
to proceed with the standardization of LLMNR. "multi-link subnet" specification. (The explicit prefix delegation
can be accomplished through [PREFIXDHCPV6].)
5- To meet case C connectivity requirement, we need to continue 3- To meet case B naming requirements we need to proceed with the
standardization of the 6to4 mechanism. standardization of LLMNR. (The provisioning of DNS parameters can be
accomplished through [DNSDHCPV6].)
6- To meet case D IPv4 connectivity requirement, we need to 4- 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.
7 Security consideration 8 Security considerations
The present document does not define any specific technology, and
thus is not believed to introduce any new security issue. The
security requirement of each specific transition case are described
as part of the analysis of that case.
8 IANA Considerations This memo describes the general requirements for transition
mechanisms. Specific security issues should be studied and addressed
during the development of the specific mechanisms.
When hosts which have been behind a NAT are exposed to IPv6, the
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
default firewall with NAT-like access configuration; one might also
restrict applications which can benefit from global IPv6
connectivity on the nodes.
9 IANA Considerations
This memo does not include any request to IANA. This memo does not include any request to IANA.
9 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.
Copyright (C) The Internet Society July 12, 2001. All Rights Copyright (C) The Internet Society June 3, 2003. All Rights
Reserved. Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
skipping to change at page 12, line 46 skipping to change at page 14, line 43
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10 Intellectual Property 11 Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996], The following notice is copied from RFC 2026 [Bradner, 1996],
Section 10.4, and describes the position of the IETF concerning Section 10.4, and describes the position of the IETF concerning
intellectual property claims made against this document. intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
skipping to change at page 13, line 21 skipping to change at page 15, line 17
to obtain a general license or permission for the use of such to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
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.
11 Acknowledgements 12 Acknowledgements
This fractional and preliminary memo has benefited from comments of This memo has benefited from comments of Margaret Wasserman, Pekka
Margaret Wasserman and Tony Hain. Savola, Chirayu Patel and Tony Hain. Tim Chown provided a lot of the
analysis for the tunneling requirements work.
12 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.
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[STATELESS] Narten, T., and S. Thomson, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains via [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[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
[ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in
progress.
[PREFIXDHCPV6] Troan, O., and R. Droms. "IPv6 Prefix Options for
DHCPv6." Work in progress.
[SIIT] E. Nordmark, Stateless IP/ICMP Translation Algorithm (SIIT).
RFC 2765, February 2000.
[NAT-PT] Tsirtsis, G., and P. Srisuresh, Network Address
Translation - Protocol Translation (NAT-PT). RFC 2766, February
2000.
[DNS-ALG-ISSUES] Issues with NAT-PT DNS ALG in RFC2766. Work in
progress.
[HALLIN-DNS-ALG] NAT-PT DNS ALG solutions. Work in progress.
[TRT] Hagino, J., and K. Yamamoto. An IPv6-to-IPv4 Transport Relay
Translator, RFC 3142, June 2001.
[DSTM] Dual Stack Transition Mechanism (DSTM). 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 (DHCPv6)." M. Carney. "Dynamic Host Configuration Protocol for IPv6
Work in progress. (DHCPv6)."RFC 3315, July 2003.
[DNSDHCPV6] R. Droms. "DNS Configuration options for DHCPv6." Work
in progress.
[DNSANYCAST] Durand, A., Hagino, J., and D. Thaler. "Well known
site local unicast addresses to communicate with recursive DNS
servers." Work in progress.
[LLMNR] Esibov, L., Aboba, B., and D. Thaler. "Linklocal Multicast
Name Resolution (LLMNR)Multicast DNS." Work in progress.
[NODEINFO] M. Crawford. "IPv6 Node Information Queries." Work in [DNSDHCPV6] R. Droms. "DNS Configuration options for DHCPv6." RFC
progress. 3646, December 2003.
[6TO4SECU] Savola, P., "Security Considerations for 6to4", Work in [PREFIXDHCPV6] Troan, O. and R. Droms. "IPv6 Prefix Options for
progress. DHCPv6." RFC 3633, December 2003.
Informative references Informative references
[NAT-PT] Tsirtsis, G., and P. Srisuresh. "Network Address [NAT-PT] Tsirtsis, G., and P. Srisuresh. "Network Address
Translation - Protocol Translation (NAT-PT)." RFC 2766, February Translation - Protocol Translation (NAT-PT)." RFC 2766, February
2000. 2000.
[DNS-ALG-ISSUES] A. Durand. "Issues with NAT-PT DNS ALG in RFC2766." [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy. "STUN
Work in progress. - Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003.
13 Authors' Addresses [DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational
Considerations and Issues with IPv6 DNS." Work in progress.
[LLMNR] Esibov, L., Aboba, B., and D. Thaler. "Linklocal Multicast
Name Resolution (LLMNR)." Work in progress.
14 Authors' Addresses
Christian Huitema Christian Huitema
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Email: huitema@microsoft.com Email: huitema@microsoft.com
Rob Austein Rob Austein
Email: sra@hactrn.net Email: sra@hactrn.net
skipping to change at page 16, line 8 skipping to change at page 17, line 8
Ronald van der Pol Ronald van der Pol
NLnet Labs NLnet Labs
Kruislaan 419 Kruislaan 419
1098 VA Amsterdam 1098 VA Amsterdam
NL NL
Email: Ronald.vanderPol@nlnetlabs.nl Email: Ronald.vanderPol@nlnetlabs.nl
Table of Contents: Table of Contents:
1 Introduction .................................................... 1 1 Introduction .................................................... 1
2 Meeting case A requirements ..................................... 2 2 Evaluation of Tunneling Solutions ............................... 2
2.1 Evaluation of connectivity mechanisms ......................... 2 2.1 Comparing automatic and configured solutions .................. 2
2.1.1 TEREDO ...................................................... 2 2.1.1 Path optimization in automatic tunnels ...................... 3
2.1.2 Simple UDP tunnel ........................................... 2 2.1.2 Automatic tunnels and relays ................................ 3
2.1.3 Comparison of TEREDO and tunnel solution .................... 3 2.1.3 The risk of several parallel IPv6 Internets ................. 4
2.1.4 Recommendation .............................................. 4 2.1.4 Lifespan of transition technologies ......................... 5
2.2 Security considerations in case A ............................. 4 2.2 Cost and benefits of NAT traversal ............................ 5
3 Meeting case B requirements ..................................... 4 2.2.1 Cost of NAT traversal ....................................... 6
3.1 Prefix delegation ............................................. 5 2.2.2 Types of NAT ................................................ 6
3.1.1 RA proxy .................................................... 5 2.2.3 Reuse of existing mechanisms ................................ 6
3.1.2 Explicit prefix delegation .................................. 5 2.3 Development of transition mechanisms .......................... 7
3.1.3 Recommendation .............................................. 5 3 Meeting case A requirements ..................................... 7
3.2 Communication between IPv4-only and IPv6-capable nodes ........ 5 3.1 Evaluation of connectivity mechanisms ......................... 7
3.3 Resolution of names to IPv6 addresses ......................... 6 3.2 Security considerations in case A ............................. 8
3.3.1 Provisioning the address of a DNS resolver .................. 6 4 Meeting case B requirements ..................................... 8
3.3.2 Publishing IPv6 addresses to the Internet ................... 6 4.1 Connectivity .................................................. 8
3.3.3 Resolving the IPv6 addresses of local hosts ................. 7 4.1.1 Extending a Subnet to Span Multiple Links ................... 8
3.3.4 Recommendations for name resolution ......................... 7 4.1.2 Explicit prefix delegation .................................. 9
3.4 Security considerations in case B ............................. 8 4.1.3 Recommendation .............................................. 9
4 Meeting case C requirements ..................................... 8 4.2 Communication between IPv4-only and IPv6-capable nodes ........ 9
4.1 Tunneling mechanisms .......................................... 8 4.3 Resolution of names to IPv6 addresses ......................... 10
4.1.1 6to4 ........................................................ 8 4.3.1 Provisioning the address of a DNS resolver .................. 10
4.1.2 Tunnel broker ............................................... 9 4.3.2 Publishing IPv6 addresses to the Internet ................... 10
4.1.3 ISATAP ...................................................... 9 4.3.3 Resolving the IPv6 addresses of local hosts ................. 11
4.1.4 Recommendations ............................................. 10 4.3.4 Recommendations for name resolution ......................... 11
4.2 Naming requirements in case C ................................. 10 4.4 Security considerations in case B ............................. 11
4.3 Security considerations in case C ............................. 10 5 Meeting case C requirements ..................................... 12
5 Meeting the case D requirements ................................. 10 5.1 Connectivity .................................................. 12
5.1.1 IPv6 addressing requirements ................................ 10 6 Meeting the case D requirements ................................. 12
5.1.2 IPv4 connectivity requirements ............................. 10 6.1 IPv6 addressing requirements .................................. 12
5.2 Naming requirements ........................................... 11 6.2 IPv4 connectivity requirements ............................... 13
5.3 Security requirements ......................................... 11 6.3 Naming requirements ........................................... 13
6 Provisional recommendations ..................................... 11 7 Provisional recommendations ..................................... 13
7 Security consideration .......................................... 11 8 Security considerations ......................................... 13
8 IANA Considerations ............................................. 12 9 IANA Considerations ............................................. 14
9 Copyright ....................................................... 12 10 Copyright ...................................................... 14
10 Intellectual Property .......................................... 12 11 Intellectual Property .......................................... 14
11 Acknowledgements ............................................... 13 12 Acknowledgements ............................................... 15
12 References ..................................................... 13 13 References ..................................................... 15
13 Authors' Addresses ............................................. 15 14 Authors' Addresses ............................................. 16
 End of changes. 

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