draft-ietf-v6ops-unmaneval-02.txt   draft-ietf-v6ops-unmaneval-03.txt 
INTERNET DRAFT C. Huitema INTERNET DRAFT C. Huitema
<draft-ietf-v6ops-unmaneval-02.txt> Microsoft <draft-ietf-v6ops-unmaneval-03.txt> Microsoft
May 19, 2004 R. Austein June 1, 2004 R. Austein
Expires November 19, 2004 Bourgeois Dilettante Expires December 1, 2004 ISC
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 By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
This document is an Internet-Draft. Internet-Drafts are working Internet-Drafts are working documents of the Internet Engineering
documents of the Internet Engineering Task Force (IETF), its areas, Task Force (IETF), its areas, and its working groups. Note that
and its working groups. Note that other groups may also distribute other groups may also distribute working documents as Internet-
working documents as Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
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
skipping to change at page 10, line ? skipping to change at page 10, line ?
Abstract Abstract
In a companion paper we defined the "unmanaged networks", which In a companion paper we defined the "unmanaged networks", which
typically correspond to home networks or small office networks, and typically correspond to home networks or small office networks, and
the requirements for transition mechanisms in various scenarios of the requirements for transition mechanisms in various scenarios of
transition to IPv6. We start from this analysis and evaluate here transition to IPv6. We start from this analysis and evaluate here
the suitability of mechanisms that have already been specified, the suitability of mechanisms that have already been specified,
proposed or deployed. proposed or deployed.
Huitema et al. [Page 1]
Table of Contents:
1 Introduction .................................................... 3
2 Evaluation of Tunneling Solutions ............................... 3
2.1 Comparing automatic and configured solutions .................. 4
2.1.1 Path optimization in automatic tunnels ...................... 4
2.1.2 Automatic tunnels and relays ................................ 5
2.1.3 The risk of several parallel IPv6 Internets ................. 5
2.1.4 Lifespan of transition technologies ......................... 6
2.2 Cost and benefits of NAT traversal ............................ 6
2.2.1 Cost of NAT traversal ....................................... 7
2.2.2 Types of NAT ................................................ 7
2.2.3 Reuse of existing mechanisms ................................ 8
2.3 Development of transition mechanisms .......................... 8
3 Meeting case A requirements ..................................... 9
3.1 Evaluation of connectivity mechanisms ......................... 9
3.2 Security considerations in case A ............................. 9
4 Meeting case B requirements ..................................... 10
4.1 Connectivity .................................................. 10
4.1.1 Extending a Subnet to Span Multiple Links ................... 10
4.1.2 Explicit prefix delegation .................................. 10
4.1.3 Recommendation .............................................. 11
4.2 Communication between IPv4-only and IPv6-capable nodes ........ 11
4.3 Resolution of names to IPv6 addresses ......................... 11
4.3.1 Provisioning the address of a DNS resolver .................. 11
4.3.2 Publishing IPv6 addresses to the Internet ................... 12
4.3.3 Resolving the IPv6 addresses of local hosts ................. 12
4.3.4 Recommendations for name resolution ......................... 13
4.4 Security considerations in case B ............................. 13
5 Meeting case C requirements ..................................... 13
5.1 Connectivity .................................................. 13
6 Meeting the case D requirements ................................. 14
6.1 IPv6 addressing requirements .................................. 14
6.2 IPv4 connectivity requirements ............................... 14
6.3 Naming requirements ........................................... 14
7 Recommendations ................................................. 14
8 Security considerations ......................................... 15
9 IANA Considerations ............................................. 15
10 Acknowledgements ............................................... 16
11 References ..................................................... 16
12 Authors' Addresses ............................................. 17
13 Intellectual Property Statement ................................ 17
14 Copyright ...................................................... 18
Huitema et al. [Page 2]
1 Introduction 1 Introduction
This document analyses the issues involved in the transition from This document analyses the issues involved in the transition from
IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the
"unmanaged networks", which typically correspond to home networks or "unmanaged networks", which typically correspond to home networks or
small office networks, and the requirements for transition small office networks, and the requirements for transition
mechanisms in various scenarios of transition to IPv6. 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 applications: local, client, peer to peer, and
servers, and considering four cases of deployment. These are: servers, and considering four cases of deployment. These are:
Huitema et al. [Page 1]
A) a gateway which does not provide IPv6 at all; A) a gateway which does not provide IPv6 at all;
B) a dual-stack gateway connected to a dual-stack ISP; B) a dual-stack gateway connected to a dual-stack ISP;
C) a dual-stack gateway connected to an IPv4-only ISP; and 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.
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 or IPv6-only nodes. In this document, we make the only, dual-stack or IPv6-only nodes. In this document, we make the
hypothesis that the IPv6-only nodes do not need to communicate with hypothesis that the IPv6-only nodes do not need to communicate with
IPv4-only nodes; devices that want to communicate with both IPv4 and 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 IPv6 nodes are expected to implement both IPv4 and IPv6, i.e., be
skipping to change at page 10, line ? skipping to change at page 10, line ?
* Is the deployment automatic, or does it require explicit * Is the deployment automatic, or does it require explicit
configuration or service provisioning? configuration or service provisioning?
* Does the proposal allow for the traversal of a NAT [NAT-T]? * Does the proposal allow for the traversal of a NAT [NAT-T]?
These two questions divide the solution space into four broad These two questions divide the solution space into four broad
classes. Each of these classes has specific advantages and risks, classes. Each of these classes has specific advantages and risks,
which we will now develop. which we will now develop.
Huitema et al. [Page 3]
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. infrastructure for IPv6 in the local or remote ISPs.
In a configured solution, a host or a router identifies itself to a In a configured solution, a host or a router identifies itself to a
Huitema et al. [Page 2]
tunneling service to set up a "configured tunnel" with an explicitly tunneling service to set up a "configured tunnel" with an explicitly
defined "tunnel router". The amount of actual configuration may vary defined "tunnel router". The amount of actual configuration may vary
from manually configured static tunnels to dynamic tunnel services from manually configured static tunnels to dynamic tunnel services
requiring only the configuration of a "tunnel broker". requiring only the configuration of a "tunnel broker", or even a
completely automatic discovery of the tunnel router.
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 ?
a direct path between the endpoints, using the IPv4 services to a direct path between the endpoints, using the IPv4 services to
which the endpoints already subscribe. By contrast, the configured which the endpoints already subscribe. By contrast, the configured
tunnel servers carry all the traffic exchanged by the tunnel client. tunnel servers carry all the traffic exchanged by the tunnel client.
Path optimization is not a big issue if the tunnel server is close Path optimization is not a big issue if the tunnel server is close
to the client, on the natural path between the client and its peers. to the client, on the natural path between the client and its peers.
However, if the tunnel server is operated by a third party, this However, if the tunnel server is operated by a third party, this
third party will have to bear the cost of provisioning the bandwidth third party will have to bear the cost of provisioning the bandwidth
used by the client. The associated costs can be significant. used by the client. The associated costs can be significant.
These costs are largely inexistent when the tunnels are configured These costs are largely absent when the tunnels are configured by
by the same ISP that provides the IPv4 service. The ISP can place
the tunnel end-points close to the client, i.e., mostly on the Huitema et al. [Page 4]
direct path between the client and its peers. the same ISP that provides the IPv4 service. The ISP can place the
tunnel end-points close to the client, i.e., mostly on the 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 or with a host using a to communicate with a "native" host or with a host using a
configured tunnel, it will need to use a relay service, and someone configured tunnel, it will need to use a relay service, and someone
Huitema et al. [Page 3]
will have to provide and pay for that service. We cannot escape will have to provide and pay for that service. We cannot escape
economic considerations for the deployment of these relays. 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 ISPS 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.)
We should note however that different automatic tunneling techniques We should note however that different automatic tunneling techniques
have different deployment conditions. have different deployment conditions.
2.1.3 The risk of several parallel IPv6 Internets 2.1.3 The risk of several parallel IPv6 Internets
In an early deployment of the Teredo service by Microsoft, the In an early deployment of the Teredo service by Microsoft, the
relays are provided by the native (or 6to4) hosts themselves. 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, native or 6to4 hosts are de-facto "multi-homed" to native and
although they never publish a Teredo address in the DNS or Teredo, although they never publish a Teredo address in the DNS or
otherwise. When a native host communicates with a Teredo host, the otherwise. When a native host communicates with a Teredo host, the
first packets are exchanged through the native interface and relayed first packets are exchanged through the native interface and relayed
by the Teredo server, while the subsequent packets are tunneled by the Teredo server, while the subsequent packets are tunneled
"end-to-end" over IPv4 and UDP. This enables deployment of Teredo "end-to-end" over IPv4 and UDP. This enables deployment of Teredo
without having to field an infrastructure of relays in the network. without having to field an infrastructure of relays in the network.
This type of solution carries the implicit risk of developing two This type of solution carries the implicit risk of developing two
parallel IPv6 Internets, one native and one using Teredo: in order parallel IPv6 Internets, one native and one using Teredo: in order
to communicate with a Teredo-only host, a native IPv6 host has to to communicate with a Teredo-only host, a native IPv6 host has to
implement a Teredo interface. The Teredo implementations try to implement a Teredo interface. The Teredo implementations try to
mitigate this risk by always preferring native paths when available, mitigate this risk by always preferring native paths when available,
but a true mitigation requires that native hosts do not have to but a true mitigation requires that native hosts do not have to
implement the transition technology. This requires cooperation from implement the transition technology. This requires cooperation from
the IPv6 ISP, who will have to support the relays. An IPv6 ISP that 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 really wants to isolate its customers from the Teredo technology can
do that by providing native connectivity and a Teredo relay. The do that by providing native connectivity and a Teredo relay. The
Huitema et al. [Page 5]
ISP's customers will not need to implement their own relay. ISP's customers will not need to implement their own relay.
Communication between 6to4 networks and native networks uses a Communication between 6to4 networks and native networks uses a
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
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. 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
skipping to change at page 10, line ? skipping to change at page 10, line ?
but they can certainly not be supported for an indefinite period. but they can certainly not be supported for an indefinite period.
The "implicit sunset" mechanisms may not be sufficient to guarantee The "implicit sunset" mechanisms may not be sufficient to guarantee
a finite lifespan of the transition. a finite lifespan of the transition.
2.2 Cost and benefits of NAT traversal 2.2 Cost and benefits of NAT traversal
During the transition, some hosts will be located behind IPv4 NATs. During the transition, some hosts will be located behind IPv4 NATs.
In order to participate in the transition, these hosts will have to In order to participate in the transition, these hosts will have to
use a tunneling mechanism designed to traverse NAT. use a tunneling mechanism designed to traverse NAT.
Huitema et al. [Page 6]
We may ask whether NAT traversal should be a generic property of any We may ask whether NAT traversal should be a generic property of any
transition technology, or whether it makes sense to develop two transition technology, or whether it makes sense to develop two
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.
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
blocking", which may translate in poor performances. Given the blocking", which may translate in poor performance. Given the
difference in performance, it makes sense to consider two types of difference in performance, it makes sense to consider two types of
transition technologies, some capable of traversing NAT and some transition technologies, some capable of traversing NAT and some
aiming at the best performance. aiming at the best performance.
2.2.2 Types of NAT 2.2.2 Types of NAT
There are many kinds of NAT on the market. Different models There are many kinds of NAT on the market. Different models
implement different strategies for address and port allocations, and implement different strategies for address and port allocations, and
also different types of timers. It is desirable to find solutions also different types of timers. It is desirable to find solutions
that cover "almost all" models of NAT. that cover "almost all" models of NAT.
skipping to change at page 10, line ? skipping to change at page 10, line ?
the behavior of the NAT than an automatic solution. The configured the behavior of the NAT than an automatic solution. The configured
solutions only need to establish a connection between an internal solutions only need to establish a connection between an internal
node and a server; this communication pattern is supported by pretty node and a server; this communication pattern is supported by pretty
much all NAT configurations. The variability will come from the type much all NAT configurations. The variability will come from the type
of transport protocols that the NAT support, especially when the NAT of transport protocols that the NAT support, especially when the NAT
also implements "firewall" functions. Some models will allow also implements "firewall" functions. Some models will allow
establishment of a single "protocol 41" tunnel, while some may establishment of a single "protocol 41" tunnel, while some may
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 "lowest common
that is likely to be accepted by most models of NAT. In practice,
this common denominator is UDP. UDP based NAT traversal is required Huitema et al. [Page 7]
by many applications, e.g., networked games or voice over IP. The denominator" that is likely to be accepted by most models of NAT. In
experience shows that most recent "home routers" are designed to practice, this common denominator is UDP. UDP based NAT traversal is
support these applications. In some edge cases, the automatic required by many applications, e.g., networked games or voice over
solutions will require explicit configuration of a port in the home IP. The experience shows that most recent "home routers" are
router, using the so-called "DMZ" functions; however, these 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; however, these
functions are hard to use in an "unmanaged network" scenario. 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 proposed IETF standard, L2TP, includes a PPP layer that
encapsulate IPv6 as well as IPv4. Several NAT models are explicitly can encapsulate IPv6 as well as IPv4. Several NAT models are
designed to pass VPN traffic, and several VPN solutions have special explicitly designed to pass VPN traffic, and several VPN solutions
provisions to traverse NAT. When we study the establishment of have special provisions to traverse NAT. When we study the
configured tunnels through NAT, it makes a lot of sense to consider establishment of configured tunnels through NAT, it makes a lot of
existing VPN solutions. sense to consider 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
specification as part of an automatic tunneling solution. However, specification as part of an automatic tunneling solution. However,
the automatic solutions also require a mechanism of bubbles to the automatic solutions also require a mechanism of bubbles to
establish the initial path through a NAT. This mechanism is not 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 present in STUN. It is not clear that a combination of STUN and a
bubble mechanism would have a technical advantage over a solution bubble mechanism would have a technical advantage over a solution
skipping to change at page 10, line ? skipping to change at page 10, line ?
- Automatic tunnel over IPv4 in the absence of NAT; - Automatic tunnel over IPv4 in the absence of NAT;
- Configured tunnel across a NAT; - Configured tunnel across a NAT;
- Automatic tunnel across a NAT. - Automatic tunnel across a NAT.
Teredo is an example of already designed solution for automatic Teredo is an example of already designed solution for automatic
tunnel across a NAT; 6to4 is an example of solution for automatic tunnel across a NAT; 6to4 is an example of solution for automatic
tunnel over IPv4 in the absence of NAT. tunnel over IPv4 in the absence of NAT.
All solutions should be designed to meet generic requirements such All solutions should be designed to meet generic requirements such
as security, scalability, support for reverse name lookup, or simple as security, scalability, support for reverse name lookup, or simple
Huitema et al. [Page 8]
management. In particular, automatic tunneling solutions may need to management. In particular, automatic tunneling solutions may need to
be augmented with a special purpose reverse DNS lookup mechanism, be augmented with a special purpose reverse DNS lookup mechanism,
while configured tunnel solutions would benefit from an automatic while configured tunnel solutions would benefit from an automatic
service configuration mechanism. service configuration mechanism.
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.
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.
The requirements for such a service will be presented in another
document.
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
deployment. The service is designed for minimizing the cost of deployment. The service is designed for minimizing the cost of
deploying the server, which matches the requirement of minimizing deploying the server, which matches the requirement of minimizing
the cost of the "supporting infrastructure". the cost of the "supporting infrastructure".
3.2 Security considerations in case A 3.2 Security considerations in case A
A characteristic of case A is that an isolated host acquires global A characteristic of case A is that an isolated host acquires global
skipping to change at page 10, line ? skipping to change at page 10, line ?
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 Any solution to the NAT traversal problem is likely to involve
relays. There are concerns that improperly designed protocols or relays. There are concerns that improperly designed protocols or
improperly managed relays could open new avenues for attacks against improperly managed relays could open new avenues for attacks against
Huitema et al. [Page 9]
Internet services. This issue should be addressed and mitigated in Internet services. This issue should be addressed and mitigated in
the design of the NAT traversal protocols and in the deployment the design of the NAT traversal protocols and in the deployment
guides for relays. 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
skipping to change at page 10, line ? skipping to change at page 11, line 19
should automatically assign /64s out of this /48 to its internal should automatically assign /64s out of this /48 to its internal
links. links.
DHCP is insecure unless authentication is used. This may be a DHCP is insecure unless authentication is used. This may be a
particular problem if the link between gateway and ISP is shared by particular problem if the link between gateway and ISP is shared by
multiple subscribers. DHCP specification includes authentication multiple subscribers. DHCP specification includes authentication
options, but the operational procedures for managing the keys and options, but the operational procedures for managing the keys and
methods for sharing the required information between the customer methods for sharing the required information between the customer
and the ISP are unclear. To be secure in such environment in and the ISP are unclear. To be secure in such environment in
practice, the practical details of managing the DHCP authentication practice, the practical details of managing the DHCP authentication
Huitema et al. [Page 9]
need to be analyzed. need to be analyzed.
4.1.3 Recommendation 4.1.3 Recommendation
The ND proxy and DHCP methods appear to have complementary domains The ND proxy and DHCP methods appear to have complementary domains
of 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.
skipping to change at page 11, line 9 skipping to change at page 12, line 24
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
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 publish 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.
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
skipping to change at page 12, line 8 skipping to change at page 13, line 22
use DDNS. An important problem is that some networks only have use DDNS. An important problem is that some networks only have
limited support for multicast transmission: for example, multicast limited support for multicast transmission: for example, multicast
transmission on 802.11 network is error prone. However, unmanaged transmission on 802.11 network is error prone. However, unmanaged
networks also use multicast for neighbor discovery [NEIGHBOR]; the networks also use multicast for neighbor discovery [NEIGHBOR]; the
requirements of ND and LLMNR are similar; if a link technology requirements of ND and LLMNR are similar; if a link technology
supports use of ND, it can also enable use of LLMNR. supports use of ND, it can also enable use of LLMNR.
4.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.
standardizing the proper DHCPv6 subset, or by recommending an
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 LLMNR; the IETF should quickly proceed to the standardization of
that protocol. that protocol.
4.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
skipping to change at page 12, line 36 skipping to change at page 13, line 48
advertisement. There is a debate as to whether such restrictions advertisement. There is a debate as to whether such restrictions
should be "per-site" or "per-link", but this is not a serious issue should be "per-site" or "per-link", but this is not a serious issue
when an unmanaged network is composed of a single link. when an unmanaged network is composed of a single link.
5 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 is a single host with a global IPv4
IPv4 address, i.e., with a direct connection to the IPv4 Internet. address, i.e., with a direct connection to the IPv4 Internet. This
This host will be able to use the same tunneling mechanisms as a 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 is not configured tunnels mechanism [TUNNELS], but as the local ISP is not
IPv6-enabled this may not be feasible. The practical conclusion of IPv6-enabled this may not be feasible. The practical conclusion of
our analysis is that "upgraded gateways" will probably support the our analysis is that "upgraded gateways" will probably support the
6to4 technology, and will have an optional configuration option for 6to4 technology, and will have an optional configuration option 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.
skipping to change at page 14, line 42 skipping to change at page 16, line 4
applications that are expressly designed for global Internet applications that are expressly designed for global Internet
connectivity. connectivity.
Several transition technologies require relays. There are concerns Several transition technologies require relays. There are concerns
that improperly designed protocols or improperly managed relays that improperly designed protocols or improperly managed relays
could open new avenues for attacks against Internet services. This could open new avenues for attacks against Internet services. This
issue should be addressed and mitigated in the design of the issue should be addressed and mitigated in the design of the
transition technologies and in the deployment guides for relays. 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 Acknowledgements
The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this
document.
Copyright (C) The Internet Society June 3, 2003. All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11 Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996],
Section 10.4, and describes the position of the IETF concerning
intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
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, Tony Hain, Marc Blanchet, Ralph Droms, Bill Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms, Bill
Sommerfeld and Fred Templin. Tim Chown provided a lot of the 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 11 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", RFC 3750, April
progress. 2004.
[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.
[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."
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.
Informative references Informative references
[NAT-PT] Tsirtsis, G., and P. Srisuresh. "Network Address
Translation - Protocol Translation (NAT-PT)." RFC 2766, February
2000.
[STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy. "STUN [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy. "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through Network - Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003. Address Translators (NATs)", RFC 3489, March 2003.
[DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational [DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational
Considerations and Issues with IPv6 DNS." Work in progress. Considerations and Issues with IPv6 DNS." Work in progress.
[LLMNR] Esibov, L., Aboba, B., and D. Thaler. "Linklocal Multicast [LLMNR] Esibov, L., Aboba, B., and D. Thaler. "Linklocal Multicast
Name Resolution (LLMNR)." Work in progress. Name Resolution (LLMNR)." Work in progress.
14 Authors' Addresses [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.
[TEREDO] C. Huitema. "Teredo: Tunneling IPv6 over UDP through NATs."
Work in progress.
12 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 Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Suresh Satapati Suresh Satapati
Cisco Systems, Inc. Cisco Systems, Inc.
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: satapati@cisco.com EMail: satapati@cisco.com
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: 13 Intellectual Property Statement
1 Introduction .................................................... 1 The IETF takes no position regarding the validity or scope of any
2 Evaluation of Tunneling Solutions ............................... 2 Intellectual Property Rights or other rights that might be claimed
2.1 Comparing automatic and configured solutions .................. 2 to pertain to the implementation or use of the technology described
2.1.1 Path optimization in automatic tunnels ...................... 3 in this document or the extent to which any license under such
2.1.2 Automatic tunnels and relays ................................ 3 rights might or might not be available; nor does it represent that
2.1.3 The risk of several parallel IPv6 Internets ................. 4 it has made any independent effort to identify any such rights.
2.1.4 Lifespan of transition technologies ......................... 5
2.2 Cost and benefits of NAT traversal ............................ 5 Information on the procedures with respect to rights in RFC
2.2.1 Cost of NAT traversal ....................................... 6 documents can be found in BCP 78 and BCP 79.
2.2.2 Types of NAT ................................................ 6
2.2.3 Reuse of existing mechanisms ................................ 6 Copies of IPR disclosures made to the IETF Secretariat and any
2.3 Development of transition mechanisms .......................... 7 assurances of licenses to be made available, or the result of an
3 Meeting case A requirements ..................................... 7 attempt made to obtain a general license or permission for the use
3.1 Evaluation of connectivity mechanisms ......................... 7 of such proprietary rights by implementers or users of this
3.2 Security considerations in case A ............................. 8 specification can be obtained from the IETF on-line IPR repository
4 Meeting case B requirements ..................................... 8 at http://www.ietf.org/ipr.
4.1 Connectivity .................................................. 8
4.1.1 Extending a Subnet to Span Multiple Links ................... 9 The IETF invites any interested party to bring to its attention any
4.1.2 Explicit prefix delegation .................................. 9 copyrights, patents or patent applications, or other proprietary
4.1.3 Recommendation .............................................. 10 rights that may cover technology that may be required to implement
4.2 Communication between IPv4-only and IPv6-capable nodes ........ 10 this standard. Please address the information to the IETF at ietf-
4.3 Resolution of names to IPv6 addresses ......................... 10 ipr@ietf.org.
4.3.1 Provisioning the address of a DNS resolver .................. 10
4.3.2 Publishing IPv6 addresses to the Internet ................... 11 14 Copyright
4.3.3 Resolving the IPv6 addresses of local hosts ................. 11
4.3.4 Recommendations for name resolution ......................... 12 The following copyright notice is copied from [RFC3667], Section
4.4 Security considerations in case B ............................. 12 5.4. It describes the applicable copyright for this document.
5 Meeting case C requirements ..................................... 12
5.1 Connectivity .................................................. 12 Copyright (C) The Internet Society (2004). This document is subject
6 Meeting the case D requirements ................................. 13 to the rights, licenses and restrictions contained in BCP 78, and
6.1 IPv6 addressing requirements .................................. 13 except as set forth therein, the authors retain all their rights.
6.2 IPv4 connectivity requirements ............................... 13
6.3 Naming requirements ........................................... 13 This document and the information contained herein are provided on
7 Recommendations ................................................. 13 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
8 Security considerations ......................................... 14 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
9 IANA Considerations ............................................. 14 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
10 Copyright ...................................................... 14 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
11 Intellectual Property .......................................... 15 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
12 Acknowledgements ............................................... 15
13 References ..................................................... 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/