diff options
Diffstat (limited to 'doc/rfc/rfc3904.txt')
| -rw-r--r-- | doc/rfc/rfc3904.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc3904.txt b/doc/rfc/rfc3904.txt new file mode 100644 index 0000000..bbb3ebf --- /dev/null +++ b/doc/rfc/rfc3904.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group C. Huitema +Request for Comments: 3904 Microsoft +Category: Informational R. Austein + ISC + S. Satapati + Cisco Systems, Inc. + R. van der Pol + NLnet Labs + September 2004 + + + Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document analyzes issues involved in the transition of + "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically + correspond to home networks or small office networks. A companion + paper analyzes out the requirements for mechanisms needed in various + transition scenarios of these networks to IPv6. Starting from this + analysis, we evaluate the suitability of mechanisms that have already + been specified, proposed, or deployed. + +Table of Contents: + + 1. Introduction ................................................. 2 + 2. Evaluation of Tunneling Solutions ............................ 3 + 2.1. Comparing Automatic and Configured Solutions ........... 3 + 2.1.1. Path Optimization in Automatic Tunnels ......... 4 + 2.1.2. Automatic Tunnels and Relays ................... 4 + 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 + + + + +Huitema, et al. Informational [Page 1] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + 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 ..................... 11 + 4.1.3. Recommendation ................................. 11 + 4.2. Communication Between IPv4-only and IPv6-Capable Nodes . 11 + 4.3. Resolution of Names to IPv6 Addresses .................. 12 + 4.3.1. Provisioning the Address of a DNS Resolver ..... 12 + 4.3.2. Publishing IPv6 Addresses to the Internet ...... 12 + 4.3.3. Resolving the IPv6 Addresses of Local Hosts .... 13 + 4.3.4. Recommendations for Name Resolution ............ 13 + 4.4. Security Considerations in Case B ...................... 14 + 5. Meeting Case C Requirements .................................. 14 + 5.1. Connectivity ........................................... 14 + 6. Meeting the Case D Requirements .............................. 14 + 6.1. IPv6 Addressing Requirements ........................... 15 + 6.2. IPv4 Connectivity Requirements ........................ 15 + 6.3. Naming Requirements .................................... 15 + 7. Recommendations .............................................. 15 + 8. Security Considerations ...................................... 16 + 9. Acknowledgements ............................................. 16 + 10. References ................................................... 16 + 11. Authors' Addresses ........................................... 18 + 12. Full Copyright Statement ..................................... 19 + +1. Introduction + + This document analyzes the issues involved in the transition from + IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the + "unmanaged networks", which typically correspond to home networks or + small office networks, and the requirements for transition mechanisms + in various scenarios of transition to IPv6. + + The requirements for unmanaged networks are expressed by analyzing + four classes of applications: local, client, peer to peer, and + servers, and are considering four cases of deployment. These are: + + A) a gateway which does not provide IPv6 at all; + 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. + + 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 + hypothesis that the IPv6-only nodes do not need to communicate with + + + +Huitema, et al. Informational [Page 2] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + 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 sections. This + analysis outlines two types of requirements: connectivity + requirements, i.e., how to ensure that nodes can exchange IP packets, + and naming requirements, i.e., how to ensure that nodes can 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. Evaluation of Tunneling Solutions + + In the case A and case C scenarios described in [UNMANREQ], the + unmanaged network cannot obtain IPv6 service, at least natively, from + its ISP. In these cases, the IPv6 service will have to be provided + through some form of tunnel. There have been multiple proposals on + different ways to tunnel IPv6 through an IPv4 service. We believe + that these proposals can be categorized according to two important + properties: + + * Is the deployment automatic, or does it require explicit + configuration or service provisioning? + + * Does the proposal allow for the traversal of a NAT? + + 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. + +2.1. Comparing Automatic and Configured Solutions + + 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 a 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 "tunnel router". The amount of actual configuration may vary + from manually configured static tunnels to dynamic tunnel services + requiring only the configuration of a "tunnel broker", or even a + completely automatic discovery of the tunnel router. + + + +Huitema, et al. Informational [Page 3] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + 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. + + Automatic tunnels generally cannot provide the same level of 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 for an explicit relation with a tunnel service. They may + also be more efficient in some cases, as they allow for "path + optimization". + +2.1.1. Path Optimization in Automatic Tunnels + + In automatic tunnels like [TEREDO] and [6TO4], the bulk of the + traffic between two nodes using the same technology is exchanged on a + direct path between the endpoints, using the IPv4 services to which + the endpoints already subscribe. By contrast, the configured tunnel + servers carry all the traffic exchanged by the tunnel client. + + 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. + However, if the tunnel server is operated by a third party, this + third party will have to bear the cost of provisioning the bandwidth + used by the client. The associated costs can be significant. + + These costs are largely absent when the tunnels are configured 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 direct + path between the client and its peers. + +2.1.2. Automatic Tunnels and Relays + + 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 or with a host using a configured + + + + + +Huitema, et al. Informational [Page 4] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + tunnel, 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. + + It is desirable to locate these relays close to the "native host". + During the transition period, the native ISPs have an interest in + providing a relay service for use by their native subscribers. Their + subscribers will enjoy better connectivity, and will therefore 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 ISPs do not have an incentive + to provide relays for general use; they are expected to restrict + access to these relays to their customers.) + + We should note however that different automatic tunneling techniques + have different deployment conditions. + +2.1.3. The Risk of Several Parallel IPv6 Internets + + 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 hosts, + 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. + + This type of solution carries the implicit risk of developing two + parallel IPv6 Internets, one native and one using Teredo: in order to + communicate with a Teredo-only host, a native IPv6 host has to + implement a Teredo interface. The Teredo implementations try to + 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. + + Communication between 6to4 networks and native networks uses a + different structure. There are two relays, one for each direction of + communication. The native host sends its packets through the nearest + 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 + + + +Huitema, et al. Informational [Page 5] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + 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 + mitigated if there is a sufficient deployment of 6to4 relays. + + The configured tunnel solutions do not carry this type of risk. + +2.1.4. Lifespan of Transition Technologies + + A related issue is the lifespan of the transition solutions. Since + automatic tunneling technologies enable an automatic deployment, + there is a risk that some hosts never migrate out of the transition. + The risk is arguably less for explicit tunnels: the ISPs who provide + the tunnels have an incentive to replace them with a native solution + as soon as possible. + + 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. + + Yet, the support of transition technologies has a cost for the entire + network: native IPv6 ISPS have to support relays in order to provide + good performance and avoid the "parallel Internet" syndrome. These + costs may be acceptable during an initial deployment phase, 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. + +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 + + + +Huitema, et al. Informational [Page 6] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + 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. + +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 a mechanism, but they incur the risk of "head of queue + blocking", which may translate in poor performance. 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 + 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 supports, 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. + + + + + + +Huitema, et al. Informational [Page 7] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + The automatic solutions have to rely on a "lowest 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; however, these functions + are hard to use in an "unmanaged network" scenario. + +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 proposed IETF standard, L2TP, includes a PPP layer that + can 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 configurations: + + - 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. + + + + + +Huitema, et al. Informational [Page 8] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + Teredo is an example of an already designed solution for automatic + tunnels across a NAT; 6to4 is an example of a solution for automatic + tunnels 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. + + 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. + The requirements for such a service will be presented in another + document. + + 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 are only + expected to serve local hosts, e.g., those located behind the NAT + + + +Huitema, et al. Informational [Page 9] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + 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 get IPv6 connectivity to the Internet and which should + not. + + Any solution to the NAT traversal problem is likely to involve + relays. There are concerns that improperly designed protocols or + improperly managed relays could open new avenues for attacks against + Internet services. This issue should be addressed and mitigated in + the design of the NAT traversal protocols and in the deployment + guides for relays. + +4. Meeting Case B Requirements + + 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. + +4.1. Connectivity + + The gateway must be able to acquire an IPv6 prefix, delegated by the + ISP. This can be done through explicit prefix delegation (e.g., + [DHCPV6, PREFIXDHCPV6]), or if the ISP is advertising a /64 prefix on + the link, such a link can be extended by the use of an ND proxy or a + bridge. + + 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). + +4.1.1. Extending a Subnet to Span Multiple Links + + A /64 subnet can be extended to span multiple physical links using a + bridge or ND proxy. Bridges can be used when bridging multiple + similar media (mainly, Ethernet segments). On the other hand, an 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 all of the + unmanaged network is not recommended, and prefix delegation should be + used when available. However, sometimes it is unavoidable. In + + + +Huitema, et al. Informational [Page 10] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + 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". + This sharing has effects on neighbor discovery protocols, and + possibly also on other protocols such as LLMNR [LLMNR] that rely on + "link local multicast". These effects need to be carefully studied. + +4.1.2. Explicit Prefix Delegation + + Several networks have already started using an explicit prefix + delegation mechanism using DHCPv6. In this mechanism, the gateway + uses a DHCP request to obtain an adequate prefix from a DHCP server + managed by the Internet Service Provider. The DHCP request is + expected to carry proper identification of the gateway, which 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. + + DHCP is insecure unless authentication is used. This may be a + particular problem if the link between gateway and ISP is shared by + multiple subscribers. DHCP specification includes authentication + options, but the operational procedures for managing the keys and + methods for sharing the required information between the customer and + the ISP are unclear. To be secure in such an environment in + practice, the practical details of managing the DHCP authentication + need to be analyzed. + +4.1.3. Recommendation + + The ND proxy and DHCP methods appear to have complementary domains of + application. ND proxy is a simple method that corresponds well to + the "informal sharing" of a link, while explicit delegation provides + strong administrative control. Both methods require development: + specify the interaction with neighbor discovery for ND proxy; provide + security guidelines for explicit delegation. + +4.2. Communication Between IPv4-only and IPv6-capable Nodes + + 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 to provide some interconnection services so that IPv4-only and + IPv6-only hosts can communicate. However, it is hard to develop a + translation service that does not have unwanted side effects on the + efficiency or the security of communications. As a consequence, the + authors recommend that, if a device requires communication with + + + +Huitema, et al. Informational [Page 11] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + IPv4-only hosts, this device implements an IPv4 stack. The only + devices that should have IPv6-only connectivity are those that are + intended to only communicate with IPv6 hosts. + +4.3. Resolution of Names to IPv6 Addresses + + There are three types of name resolution services that should be + provided in case B: local IPv6 capable hosts must be able to obtain + the IPv6 addresses of correspondent hosts on the Internet, they + 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 address + of other local IPv6 hosts. These three problems are described in the + next sections. Operational considerations and issues with IPv6 DNS + are analyzed in [DNSOPV6]. + +4.3.1. Provisioning the Address of a DNS Resolver + + In an unmanaged environment, IPv4 hosts usually obtain the address of + the local DNS resolver through DHCPv4; the DHCPv4 service is + generally provided by the gateway. The gateway will also use DHCPv4 + to obtain the address of a suitable resolver from the local Internet + service provider. + + The DHCPv4 solution will suffice in practice for the gateway and also + for the dual-stack hosts. There is evidence that DNS servers + accessed over IPv4 can serve arbitrary DNS records, including AAAA + records. + + Just using DHCPv4 will not be an adequate solution for IPv6-only + local hosts. The DHCP working group has defined how to use + (stateless) DHCPv6 to obtain the address of the DNS server + [DNSDHCPV6]. DHCPv6 and several other possibilities are being looked + at in the DNSOP Working Group. + +4.3.2. Publishing IPv6 Addresses to the Internet + + IPv6 capable hosts may be willing to provide services accessible from + the global Internet. They will thus need to publish their address in + a server that is publicly available. IPv4 hosts in unmanaged + networks have a similar problem today, which they solve using one of + three possible solutions: + + * Manual configuration of a stable address in a DNS server; + * Dynamic configuration using the standard dynamic DNS protocol; + * Dynamic configuration using an ad hoc protocol. + + + + + + +Huitema, et al. Informational [Page 12] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + Manual configuration of stable addresses is not satisfactory in an + unmanaged IPv6 network: the prefix allocated to the gateway may or + may not be stable, and in any case, copying long hexadecimal strings + through a manual procedure is error prone. + + Dynamic configuration using the same type of ad hoc protocols that + are common today is indeed possible, but the IETF should encourage + the use of standard solutions based on Dynamic DNS (DDNS). + +4.3.3. Resolving the IPv6 Addresses of Local Hosts + + 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 + the local domain, or one may use a peer-to-peer address resolution + protocol such as LLMNR. + + When a DNS server is used, this server could in theory be located + anywhere on the Internet. There is however a very strong argument + for using a local server, which will remain reachable even if the + network connectivity is down. + + The use of a local server requires that IPv6 capable hosts discover + 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 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 + gateway. + + An alternative to using a local server is LLMNR, which uses a + multicast mechanism to resolve DNS requests. LLMNR does not require + any service from the gateway, and also does not require that hosts + use DDNS. An important problem is that some networks only have + limited support for multicast transmission, for example, multicast + transmission on 802.11 network is error prone. However, unmanaged + networks also use multicast for neighbor discovery [NEIGHBOR]; the + requirements of ND and LLMNR are similar; if a link technology + supports use of ND, it can also enable use of LLMNR. + +4.3.4. Recommendations for Name Resolution + + The IETF should quickly provide a recommended procedure for + provisioning the DNS resolver in IPv6-only hosts. + + The most plausible candidate for local name resolution appears to be + LLMNR; the IETF should quickly proceed to the standardization of that + protocol. + + + + + +Huitema, et al. Informational [Page 13] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + +4.4. Security Considerations in Case B + + The case B solutions provide global IPv6 connectivity to the local + hosts. Removing the limit to connectivity imposed by NAT is both a + feature and a risk. Implementations should carefully limit global + IPv6 connectivity to only those applications that are specifically + designed to operate on the global Internet. Local applications, for + example, could be restricted to only use link-local addresses, or + addresses whose most significant bits match the prefix of the local + 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. + +5. Meeting Case C Requirements + + 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 + mechanism to obtain IPv6 connectivity, and an address prefix. + + A simplified form of case B is a single host with a global 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 gateway. + +5.1. Connectivity + + Connectivity in case C requires some form of tunneling of IPv6 over + IPv4. The various tunneling solutions are discussed in section 2. + + 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 + configured tunnels mechanism [TUNNELS], but as the local ISP 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 + for some form of automatic configuration. + + Due to concerns with potential overload of public 6to4 relays, the + 6to4 implementations should include a configuration option that + allows the user to take advantage of specific relays. + +6. Meeting the Case D Requirements + + In case D, the ISP only provides IPv6 services. + + + + +Huitema, et al. Informational [Page 14] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + +6.1. IPv6 Addressing Requirements + + We expect IPv6 addressing in case D to proceed similarly to case B, + i.e., use either an ND proxy or explicit prefix delegation through + DHCPv6 to provision an IPv6 prefix on the gateway. + +6.2. IPv4 Connectivity Requirements + + Local IPv4 capable hosts may still want to 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" tunneling. There + are no standardized solutions and the IETF has devoted very little + effort to this issue, although there is ongoing work with [DSTM] and + [TSP]. A solution needs to be standardized. The standardization + will have to cover configuration issues, i.e., how to provision the + IPv4 capable hosts with the address of the local IPv4 tunnel servers. + +6.3. Naming Requirements + + Naming requirements are similar to case B, with one difference: the + gateway cannot expect to use DHCPv4 to obtain the address of the DNS + resolver recommended by the ISP. + +7. Recommendations + + After a careful analysis of the possible solutions, we can list a set + of recommendations for the V6OPS working group: + + 1. To meet case A and case C requirements, we need to develop, or + continue to develop, four types of tunneling technologies: + automatic tunnels without NAT traversal such as [6TO4], + automatic tunnels with NAT traversal such as [TEREDO], + configured tunnels without NAT traversal such as [TUNNELS, + TSP], and configured tunnels with NAT traversal. + + 2. To facilitate the use of configured tunnels, we need a + standardized way for hosts or gateways to discover the tunnel + server or tunnel broker that may have been configured by the + local ISP. + + 3. To meet case B "informal prefix sharing" requirements, we would + need a standardized way to perform "ND proxy", possibly as part + of a "multi-link subnet" specification. (The explicit prefix + delegation can be accomplished through [PREFIXDHCPV6].) + + 4. To meet case B naming requirements, we need to proceed with the + standardization of LLMNR. (The provisioning of DNS parameters + can be accomplished through [DNSDHCPV6].) + + + +Huitema, et al. Informational [Page 15] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + 5. To meet case D IPv4 connectivity requirement, we need to + standardize an IPv4 over IPv6 tunneling mechanism, as well as + the associated configuration services. + +8. Security 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 a NAT-like access configuration; however, any such + firewall configuration should allow for easy authorization of those + applications that actually need global connectivity. One might also + restrict applications which can benefit from global IPv6 connectivity + on the nodes. + + Security policies should be consistent between IPv4 and IPv6. A + policy which prevents use of v6 while allowing v4 will discourage + migration to v6 without significantly improving security. Developers + and administrators should make sure that global Internet connectivity + through either IPv4 or IPv6 is restricted to only those applications + that are expressly designed for global Internet connectivity. + + Several transition technologies require relays. There are concerns + that improperly designed protocols or improperly managed relays could + open new avenues for attacks against Internet services. This issue + should be addressed and mitigated in the design of the transition + technologies and in the deployment guides for relays. + +9. Acknowledgements + + This memo has benefited from the comments of Margaret Wasserman, + Pekka Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms, + Bill Sommerfeld, and Fred Templin. Tim Chown provided a lot of the + analysis for the tunneling requirements work. + +10. References + +10.1. Normative References + + [UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der + Pol, "Unmanaged Networks IPv6 Transition Scenarios", + RFC 3750, April 2004. + + + + + +Huitema, et al. Informational [Page 16] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. + + [NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 + Domains via IPv4 Clouds", RFC 3056, February 2001. + + [6TO4ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay + Routers", RFC 3068, June 2001. + + [TUNNELS] Durand, A., Fasano, P., Guardini, I., and D. Lento, + "IPv6 Tunnel Broker", RFC 3053, January 2001. + + [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [DNSDHCPV6] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + + [PREFIXDHCPV6] Troan, O. and R. Droms, "IPv6 Prefix Options for + Dynamic Host Configuration Protocol (DHCP) version 6", + RFC 3633, December 2003. + +10.2. Informative References + + [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. + Mahy, "STUN - Simple Traversal of User Datagram + Protocol (UDP) Through Network Address Translators + (NATs)", RFC 3489, March 2003. + + [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. + + [TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel + Setup Protocol(TSP)", Work in Progress. + + [DSTM] Bound, J., "Dual Stack Transition Mechanism", Work in + Progress. + + + + +Huitema, et al. Informational [Page 17] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + + [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + NATs", Work in Progress. + +11. Authors' Addresses + + Christian Huitema + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + + EMail: huitema@microsoft.com + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Suresh Satapati + Cisco Systems, Inc. + San Jose, CA 95134 + USA + + EMail: satapati@cisco.com + + + Ronald van der Pol + NLnet Labs + Kruislaan 419 + 1098 VA Amsterdam + NL + + EMail: Ronald.vanderPol@nlnetlabs.nl + + + + + + + + + + + + + + +Huitema, et al. Informational [Page 18] + +RFC 3904 Unmanaged Networks Transition Tools September 2004 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Huitema, et al. Informational [Page 19] + |