RFC 3904
Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
RFC 3904: Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks 🦋
Okay bestie, this one is RFC 3904 💖 from the Network Working Group, and it's giving informational energy. C. Huitema is from Microsoft, R. Austein is from ISC, S. Satapati is from Cisco Systems, Inc., and R. van der Pol is from NLnet Labs 🧚. It dropped in September 2004, and it's filed as Informational. The title block doesn't list anything it obsoletes or updates ✨.
Status of this Memo 🎀
So this memo gives information to the Internet community. It is not a standard of any kind 🙈. You can distribute it as much as you want.
Copyright Notice 🌸
Copyright (C) The Internet Society (2004) 💜
Abstract 💜
This doc looks at how "unmanaged networks" move from IPv4 to IPv6. Unmanaged networks are usually home networks or small office networks 🏠. A companion paper goes through the requirements that these networks need from transition mechanisms in different scenarios. Building on that, this one checks how well the mechanisms that are already specified, proposed, or deployed actually fit 🔥.
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
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 ..................................... 191. Introduction ✨
This doc digs into the issues around moving from IPv4 to IPv6 [IPV6] 🦋. The companion paper [UNMANREQ] is where we defined "unmanaged networks" (usually home or small office networks) and laid out what transition mechanisms need to do in the different IPv6 transition scenarios 💅.
The requirements for unmanaged networks come from looking at four classes of applications: local, client, peer to peer, and servers. We're also looking at four deployment cases 🌈:
- 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 from IPv4 to IPv6, you'll have IPv4-only, dual-stack, or IPv6-only nodes 🫶. Here we assume that IPv6-only nodes don't need to talk to IPv4-only nodes. Devices that want to talk to both IPv4 and IPv6 nodes are expected to implement both, meaning they're dual-stack 💜.
This analysis splits the requirements into two types. Connectivity requirements are about making sure nodes can exchange IP packets. Naming requirements are about making sure nodes can resolve each other's names 😭. Connectivity requirements often need tunneling solutions, so the first section of this memo is all about evaluating those tunneling solutions 🔥.
2. Evaluation of Tunneling Solutions 🌸
In the case A and case C scenarios from [UNMANREQ], the unmanaged network can't get IPv6 service from its ISP, at least not natively 🙈. So in those cases the IPv6 service has to come through some form of tunnel. Lots of people have proposed different ways to tunnel IPv6 through an IPv4 service. We think these proposals can be sorted by 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 split the solution space into four broad classes. Each class has its own advantages and risks, and we'll get into those now ✨.
2.1. Comparing Automatic and Configured Solutions 🧚
Tunneling solutions can broadly be called either "automatic" or "configured" 💖. In an automatic solution, a host or router builds an IPv6 address or IPv6 prefix by combining a predefined prefix with some local attribute. That attribute might be a local IPv4 address [6TO4], or the combination of an address and a port number [TEREDO]. Another big, typical trait of automatic solutions is that they aim to work with a minimal amount of IPv6 support or infrastructure in the local or remote ISPs 🦋.
In a configured solution, a host or router identifies itself to a tunneling service so it can set up a "configured tunnel" with an explicitly defined "tunnel router" 🎀. How much configuration is involved can vary a lot. It could be manually configured static tunnels, dynamic tunnel services that only need a "tunnel broker" configured, or even a completely automatic discovery of the tunnel router 🌈.
Configured tunnels have a lot of advantages over automatic ones. The client is explicitly identified and can get a stable IPv6 address. The service provider is also clearly identified and can be held responsible for the quality of the service 👑. You can route multicast packets over the established tunnel too. There's a clear address delegation path, which makes reverse DNS lookups easy to support 💅.
Automatic tunnels generally can't give you the same level of service 😭. The IPv6 address is only as stable as the underlying IPv4 address. The quality of service depends on relays run by third parties. There's typically no multicast support, and there's often no easy way to do reverse DNS lookups (although some workarounds are probably possible) 💀. That said, automatic tunnels have other perks. They're obviously easier to set up, since there's no need for an explicit relationship with a tunnel service. They can also be more efficient in some cases, because they allow for "path optimization" 🫶.
2.1.1. Path Optimization in Automatic Tunnels ✨
In automatic tunnels like [TEREDO] and [6TO4], most of the traffic between two nodes using the same technology goes over a direct path between the endpoints. It uses the IPv4 services the endpoints already pay for 💖. Configured tunnel servers, on the other hand, carry all the traffic for the tunnel client 🐢.
Path optimization isn't a huge deal if the tunnel server is close to the client on the natural path between the client and its peers 🧚. But if a third party runs the tunnel server, that third party has to pay for the bandwidth the client uses. Those costs can add up fast 😭.
Those costs are mostly gone when the same ISP that provides the IPv4 service also configures the tunnels. The ISP can place the tunnel endpoints close to the client, which means they're mostly on the direct path between the client and its peers 🌸.
2.1.2. Automatic Tunnels and Relays 🦋
The economics of path optimization favor either configured tunnels from the local ISP, or automatic tunneling no matter whether ISPs cooperate 💅. But automatic solutions need relays set up throughout the Internet 🔥. If a host that got connectivity through an automatic tunnel service wants to talk to a "native" host, or to a host using a configured tunnel, it'll need to use a relay service. Someone has to provide and pay for that service, and that's an economic question we can't dodge 💰.
It's a good idea to put these relays close to the "native host" 👑. During the transition period, native ISPs have a reason to offer a relay service for their native subscribers. Those subscribers get better connectivity, so they're happier 🥰. Offering the service doesn't add much bandwidth demand, either. The packets are exchanged between the local subscribers and the Internet, they're just using a v6-v4 path instead of a v6-v6 path 🫶. (Native ISPs don't have an incentive to run relays for general use, so they're expected to restrict access to these relays to their own customers 🙈.)
We should note, though, that different automatic tunneling techniques have different deployment conditions ✨.
2.1.3. The Risk of Several Parallel IPv6 Internets ✨
okay so in an early deployment of Teredo by Microsoft, the relays were provided by the native (or 6to4) hosts themselves 🫶. These native or 6to4 hosts are de-facto "multi-homed" to native and Teredo hosts, even though they never publish a Teredo address in the DNS or anywhere else. So when a native host talks to a Teredo host, the first packets go through the native interface and get relayed by the Teredo server, and then the subsequent packets are tunneled "end-to-end" over IPv4 and UDP. This means Teredo can be deployed without having to field an infrastructure of relays in the network 💅
This type of solution carries the implicit risk of building two parallel IPv6 Internets, one native and one using Teredo 😭. To talk to a Teredo-only host, a native IPv6 host has to implement a Teredo interface. The Teredo implementations try to fix this by always preferring native paths when they're available, but a true fix means native hosts don't have to implement the transition technology at all. That requires cooperation from the IPv6 ISP, who will have to support the relays. An IPv6 ISP that really wants to keep its customers away from Teredo can do that by providing native connectivity and a Teredo relay, and then the ISP's customers won't 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, which is the closest router advertising the 2002::/16 prefix through the IPv6 routing tables. The 6to4 network sends its packets through a 6to4 relay that is either explicitly configured or discovered through the 6to4 anycast address 192.88.99.1 [6TO4ANYCAST]. The experience so far is that simple 6to4 routers are easy to deploy, but 6to4 relays are scarce 🥲. If there are too few relays, they'll create a bottleneck, and communications between 6to4 and native networks will be slower than direct communications between 6to4 hosts. That creates 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 how long the transition solutions will last ⏳. Since automatic tunneling technologies enable automatic deployment, there's a risk that some hosts never migrate out of the transition. The risk is arguably smaller for explicit tunnels, because 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 include an "implicit sunset" mechanism 🌅. Hosts won't configure a transition technology address if they have native connectivity, and the address selection mechanisms prefer native addresses when they're available. The transition technologies will eventually stop being used, once native connectivity has been deployed everywhere. However, the "implicit sunset" mechanism doesn't give any hard guarantee that the transition will be complete by a certain date 🙈
Yet supporting 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 for the transition 🧚
2.2. Cost and Benefits of NAT Traversal
During the transition, some hosts will be located behind IPv4 NATs 🏠. To take part in the transition, these hosts will have to use a tunneling mechanism designed to traverse NAT.
We may ask whether NAT traversal should be a generic property of any transition technology, or whether it makes sense to develop two types of technologies, some "NAT capable" and some not 🤔. An important question is also which kinds of NAT boxes one should be able to traverse. One should probably also consider whether it's necessary to build an IPv6-specific NAT traversal mechanism, or whether it's possible to combine an existing IPv4 NAT traversal mechanism with some form of IPv6 in IPv4 tunneling. There are many IPv4 NAT traversal mechanisms, so one may ask whether these need to be re-invented, especially when they're already complex 😩
A related question is whether NAT traversal technology should use automatic tunnels or configured tunnels. We saw in the previous section that you can argue both sides of this issue 🙃. In fact, there are already deployed automatic and configured solutions, so the reality is that we'll probably see both 💅
2.2.1. Cost of NAT Traversal
NAT traversal technologies generally involve encapsulating IPv6 packets inside a transport protocol that's known to traverse NAT, such as UDP or TCP 📦. These transport technologies need 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 need such a mechanism, but they risk "head of queue blocking", which may translate into poor performance 😬. Given that 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's desirable to find solutions that cover "almost all" models of NAT 🎯.
A configured tunnel solution will generally make fewer assumptions about the behavior of the NAT than an automatic solution does 🫧. The configured solutions only need to establish a connection between an internal node and a server, and pretty much all NAT configurations support this communication pattern. The variability will come from the types 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 others may only allow TCP, or possibly HTTP 🚧.
Automatic solutions have to rely on a "lowest common denominator" that's likely to be accepted by most models of NAT. In practice, that common denominator is UDP 🎮. UDP-based NAT traversal is required by many applications, e.g., networked games or voice over IP, and the experience shows that most recent "home routers" are designed to support these applications 📶. In some edge cases, 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 isn't 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 they 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, automatic solutions also require a mechanism of bubbles to establish the initial path through a NAT, and that mechanism isn't present in STUN. It's not clear that a combination of STUN and a bubble mechanism would have a technical advantage over a solution designed specifically for automatic tunneling through NAT 🤷♀️
2.3. Development of Transition Mechanisms
The previous sections make the case for developing four transition mechanisms, covering the following four 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.
Teredo is an example of an already designed solution for automatic tunnels across a NAT, and 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 don't 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 to minimize 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 🔒
okay so in case A, an isolated host gets global IPv6 through Teredo or some other tunneling thing, and it's giving main character energy 💅 but ngl it's also a risk 😭. If nothing is done, stuff that's only supposed to serve local hosts (like things behind the NAT, when there is one) could get exposed to the whole global internet 💀. Developers and administrators should make sure that global IPv6 connectivity is restricted to only those applications that are expressly designed for global Internet connectivity. Users should be able to configure which applications get IPv6 connectivity to the Internet and which shouldn't 🎀.
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 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 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.
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 🎯.
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 ✨
Okay so case D is the one where the ISP only gives you IPv6 services 🫶
6.1. IPv6 Addressing Requirements
We expect IPv6 addressing in case D to go pretty much the same way as case B 💅 So you'd use either an ND proxy or explicit prefix delegation through DHCPv6 to get an IPv6 prefix onto the gateway. Easy peasy 🎀
6.2. IPv4 Connectivity Requirements
Local IPv4 capable hosts may still want to reach IPv4-only services. 🦋 The proper way to do that for dual-stack nodes in the unmanaged network is to develop some form of "IPv4 over IPv6" tunneling. Ngl, there are no standardized solutions yet, and the IETF hasn't put much effort into this, although there's ongoing work with [DSTM] and [TSP]. 😭 A solution needs to be standardized. The standardization will also have to cover configuration issues, meaning how to give the IPv4 capable hosts the address of the local IPv4 tunnel servers. Main character problem, honestly 👑
6.3. Naming Requirements
Naming requirements are similar to case B, with one big difference 🌸 The gateway can't count on using DHCPv4 to get the address of the DNS resolver recommended by the ISP. Not it, bestie 💀
7. Recommendations
After a careful look at all the possible solutions, we can list a set of recommendations for the V6OPS working group 🧚
- To meet case A and case C requirements, we need to develop, or keep developing, 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. 🔥
- To make configured tunnels easier to use, 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. 🍓
- 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].) ✨
- To meet case B naming requirements, we need to keep going with the standardization of LLMNR. (The provisioning of DNS parameters can be accomplished through [DNSDHCPV6].) 💜
- To meet the 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 that have been behind a NAT get 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 that can benefit from global IPv6 connectivity on the nodes.
Security policies should be consistent between IPv4 and IPv6. A policy that blocks v6 while allowing v4 will discourage migration to v6 without meaningfully improving security, and that's a whole vibe-kill 💅 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. Take this one seriously, besties 🫶
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. Iconic contributors, all of them 👑✨
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.
[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.
[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.nl12. 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. 💖
📦 where this page comes from
- ietf: rfc3904 2004-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms