RFC 3750

Unmanaged Networks IPv6 Transition Scenarios

📅 published April 2004, from ietf

RFC 3750 🎀 Unmanaged Networks IPv6 Transition Scenarios

okay bestie, this is the RFC that tells us which IPv6 transition scenarios matter for unmanaged networks (aka your home wifi or the tiny office nobody is really in charge of) 🏠✨

  • Network Working Group 💅
  • Category: Informational 🦋 (it gives info, it does not set a standard)
  • Date: April 2004 🌸
  • Authors:
    • C. Huitema, Microsoft
    • R. Austein, ISC
    • S. Satapati, Cisco Systems, Inc.
    • R. van der Pol, NLnet Labs
  • Obsoletes / Updates: this title block doesn't list anything for either one 🙈

Status of this Memo 📜

ok so this memo is just providing info for the Internet community 💖 It is not a standard of any kind, so nobody's getting in trouble for skipping it. Distribution is unlimited, so share it with everyone you know 🫶

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 🧚

okay so the big picture is this: the doc defines the scenarios where IPv6 transition mechanisms are actually supposed to get used in unmanaged networks 🎀 We need those scenarios so we can judge whether a mechanism is even suitable. The "unmanaged network" is usually a home or small office, and each scenario is about a single subnet, defined by the IP connectivity the gateway and the Internet Service Provider (ISP) support 🏡

They look at the generic needs of four application classes: local, client, peer to peer, and server 👑 Then, for each scenario, they work out the transition requirements by checking what apps need to migrate smoothly from IPv4 to IPv6. It's giving careful planning, honestly 😭

1. Introduction 🌈

so, to judge transition mechanisms going from IPv4 [RFC791] to IPv6 [RFC2460], we first have to figure out the environment they'll be used in 🧚 The main focus is the "unmanaged networks", which usually means home networks or small office networks 🏠

this doc looks at what those transition scenarios require 💅 It has four main sections:

  • Section 2 defines the topology we're looking at 🗺️
  • Section 3 introduces the four classes of apps we care about for unmanaged networks: local, client, peer-to-peer, and server 🎀
  • Section 4 studies what those four classes need 🔥
  • Section 5 turns those needs into four configurations we expect to see during IPv6 deployment 💜

The four configurations are: gateways that don't provide IPv6, dual-stack gateways connected to dual-stack ISPs, dual-stack gateways connected to IPv4-only ISPs, and IPv6-capable gateways connected to IPv6-only ISPs 🦋 Real talk, these aren't every possible setup (not even close), but the authors believe they're the common cases for unmanaged networks ✨

2. Topology 🗺️

the typical unmanaged network is a single subnet, connected to the Internet through one Internet Service Provider (ISP) connection 💖 It can have several hosts hanging off that subnet:

   +------+
   | Host +--+
   +------+  |
             |
   +------+  |
   | Host +--+                         +--------------
   +------+  |                         |
             :                   +-----+
             :  +---------+      |     |
             +--+ Gateway +------| ISP | Internet
             :  +---------+      |     |
             :                   +-----+
   +------+  |                         |
   | Host +--+                         +--------------
   +------+  |
             |
   +------+  |
   | Host +--+
   +------+

between the subnet and the ISP access link sits a gateway 🚪 It may or may not do NAT and firewall stuff. When it does NAT [RFC3022], it usually hands out private IPv4 addresses [RFC1918] to the local hosts 🔐

the key vibe here is that the gateway is usually not "managed" 🙈 Most of the time it's a simple "appliance" with some static policies baked in. Plenty of the time, the ISP is the one who buys and configures it ✨

there are also cases with two gateways back to back: one run by the ISP, and one added by the owner of the unmanaged network 🧩 This memo doesn't cover those, because most of them either need some management, or the user's gateway can just act as an L2 switch 💅

the access link between the unmanaged network and the ISP can be static and permanent, or dynamic, like a dial-up or ISDN line 📞

in a degenerate case, an unmanaged network is just a single host plugged straight into an ISP 💀

sometimes the "gateway" is replaced by a layer-2 bridge 🌉 In those setups, the hosts have direct access to the ISP service. To avoid super long detours, the doc treats these cases as if there's no gateway, meaning each host is connected directly to the ISP 🧚

and one more thing: unmanaged networks explicitly exclude networks made of multiple subnets 🚫 Some home and small business networks really do have multiple subnets, sure, but right now those aren't "unmanaged" because some competent administrator has to configure the routers by hand. So the focus stays on single-subnet networks, where nobody like that is expected to be around 🍓

3. Applications 💜

so users use, or want to use, unmanaged network services in four types of applications: local, client, servers, and peer-to-peers 🎀 These might or might not run easily on today's networks (some do, some don't, it's a mixed bag fr fr) 🫠

3.1. Local Applications 🏠

"Local applications" are only meant to involve hosts that are part of the unmanaged network 🫶 Typical examples are file sharing or printer sharing 🖨️

they work effectively in IPv4 unmanaged networks, even when the gateway does NAT or firewall stuff 🔥 Honestly, firewall services at the gateway are often seen as desirable, since they keep local apps safe from interference by Internet users 🛡️

3.2. Client Applications 💻

"Client applications" are the ones with a client on the unmanaged network talking to a server somewhere remote 🌐 Typical examples: visiting a web server from a client inside the unmanaged network, or reading and sending e-mail with the help of a server outside it 📧

they tend to work just fine in IPv4 unmanaged networks, even with NAT or firewall functions on the gateway 💅 That's because those translation and firewall functions were designed specifically to enable client applications, so they're literally built for this ✨

3.3. Peer-to-Peer Applications 🤝

there are really two kinds of "peer-to-peer" apps 🧩 One kind only involves hosts on the unmanaged network. The other kind involves one or more hosts on the unmanaged network and one or more hosts outside it. This doc only considers the second kind, since the first kind can be treated as a subset of the local applications from section 3.1 💜

peer-to-peer apps often don't work well in unmanaged IPv4 networks 😭 Developers often have to bring in a "relay server", which basically restructures the peer-to-peer connection into a pair of back-to-back client/server connections 🔁

3.4. Server Applications 🖥️

"Server applications" involve running a server in the unmanaged network so that other parties outside the network can use it 🌸 Typical examples are running a web server or an e-mail server on one of the hosts inside the unmanaged network 📬

deploying these servers in most unmanaged IPv4 networks needs some special programming of the NAT or firewall [RFC2993] 🔧 It gets even more complex when the NAT only publishes a small number of global IP addresses and relies on "port translation" 🌀 In the common case where the NAT manages exactly one global IP address and relies on "port translation", a given external port can only be used by one internal server. Only one, bestie 💀

deploying servers usually also means giving each server a stable DNS name and tying a global IPv4 address to that name 🌍 That address might be the server's own, or the one of the router acting as a firewall or NAT. Updating DNS counts as a management task, so it kinda falls outside the scope of an unmanaged network 🙈 On the flip side, you can also pass the target server's address around with out-of-band techniques, like copy-pasting it into an instant message 💬 iykyk 🦋

⚠️ Reminder: unmanaged networks don't have a competent operator on hand, so the NAT and firewall tweaks, plus DNS updates, are where things get tricky for server apps 🎀

4. Application Requirements of an IPv6 Unmanaged Network ✨

okay so bestie, the whole point of the IPv6 transition is that apps which already work great on IPv4 should keep working great 💖 it should also be possible to use IPv6 to ship new apps that are basically impossible to deploy on IPv4 🧚 and deploying them should be simple and easy to manage, but the solutions also have to be robust and secure 🔐 no cap, that's a lot to ask 💅

the application requirements for IPv6 Unmanaged Networks fall into three big buckets: connectivity, naming, and security 🎀 connectivity is about getting IPv6 addresses and how good they are. do hosts need global addresses? should those addresses be stable, or more precisely, how long should they be expected to live? 🦋 naming is about managing names for the hosts. do hosts need DNS names, and is inverse name resolution [DNSINADDR] a requirement? 🌸 security covers possible restrictions on connectivity, privacy worries, and the security of the apps in general 🫶

4.1. Requirements of Local Applications

local apps need local connectivity ✨ they must keep working even when the unmanaged network is cut off from the Internet. like, they can't just die because the wifi has no outside connection 😭

local apps usually use ad hoc naming systems, and lowkey most of them are proprietary 🙈 one standard example is the service location protocol (SLP) [RFC2608] 🧚

the security of local apps will usually get a boost if they can be effectively isolated from the global Internet 🔒 main character energy for keeping things private 👑

4.2. Requirements of Client Applications

client apps need global connectivity 🌍 in an IPv6 network, we'd expect the client to use a global IPv6 address, and that address will have to stay stable for the whole client-server session 💜

client apps typically use the domain name system to find servers 🔍 in an IPv6 network, the client must be able to locate a DNS resolver. no resolver, no vibes 💀

a lot of servers try to look up a DNS name tied to the client's IP address 👀 in IPv4, that IP is often handed out by the ISP to the gateway, and the ISP keeps the matching PTR record. ngl these PTR records are kinda perfunctory 🥱 they're usually generated algorithmically from the IPv4 address, and the main thing they tell you is the ISP's domain name. whether IPv6 should offer an equivalent is genuinely unclear rn 🤷‍♀️

4.2.1. Privacy Requirement of Client Applications

okay this one is a whole debate 🍓 it's up in the air whether the IPv6 networking service should be built to boost client privacy, and specifically whether support for RFC 3041 [RFC3041] should be required. so here's the tea: RFC 3041 lets hosts pick IPv6 addresses where the host identifier is randomized 🎲 it was designed so the IPv6 addresses and the host identifier can't be used to track the Internet connections of a device's owner 🕵️‍♀️ iconic behavior ngl

many people point out that randomizing the host identifier is only a half measure 🙃 if the unmanaged network's address prefix stays constant, the randomization only hides which host in the network started a connection. think the children's computer versus their parents' 👨‍👩‍👧 that puts the privacy rating of these connections on a par with IPv4 connections from an unmanaged network where a NAT manages a static IPv4 address 🙌 in both cases, the IPv4 address or the IPv6 prefix can still identify the unmanaged network, like the specific home the connection came from 🏠

but randomizing the host identifier does have real perks ✨ first, if some hosts are mobile, the randomization destroys any correlation between the addresses used at different locations. the addresses alone couldn't tell you whether a connection came from the same laptop going from work to home, or from it being used on the road 💻🛣️ second, randomization removes any info that could be pulled out of a hardwired host identifier 🔢 for example, it stops outsiders from linking a serial number to a specific brand of expensive electronics, and then using that for marketing campaigns or possibly burglary attempts 😬 yikes, nobody needs that

randomizing addresses is not enough to guarantee privacy though 🙅‍♀️ usage can be tracked a bunch of other ways, from application-level "cookies" all the way to complex techniques involving data mining and traffic analysis 🍪 but we should not make a bad situation worse 💔 other privacy attacks may be possible, but that's not a reason to enable extra tracking through IPv6 addresses 🚫

randomizing the host identifier has some costs too. address management in hosts gets more complex, reverse DNS services are harder to provide, and the gateway may have to maintain a larger cache of neighbor addresses 🗂️ still, experience from existing implementations shows these costs aren't overwhelming 💪 so given the limited benefits, it would be unreasonable to require that all hosts use privacy addresses 🙅‍♀️ but given the limited costs, it is reasonable to require that all unmanaged networks allow use of privacy addresses by those hosts that choose to do so 🫶 that's the vibe: let the hosts choose, but don't block them 🦋

4.3. Requirements of Peer-to-Peer Applications

peer-to-peer apps need global connectivity 🌐 in an IPv6 network, we'd expect the peers to use a global IPv6 address, and it will have to stay stable for the whole peer-to-peer session 🤝

there are multiple sides to peer-to-peer security, and a lot of them come back to the security of the rendezvous system 🛎️ if we assume the peers have already been able to safely exchange their IPv6 addresses, the main security requirement is being able to safely exchange data between the peers without third parties interfering 🛡️ like, nobody crashing the party 🎉

some private chats one of the authors had with peer-to-peer developers suggest that a lot of people would be open to an "IPv6-only" model, if they can get two guarantees 👀

  1. no regression from IPv4. that means every customer who could take part in a peer-to-peer app over IPv4 can still be reached over IPv6 💯
  2. IPv6 solves at least some of their hard problems, like letting peers sitting behind an IPv4 NAT join a peer-to-peer app 🔓

requiring IPv6 connectivity for a popular peer-to-peer app could create what economists call a "network effect", and that could seriously speed up IPv6 deployment 🚀 everyone shows up when everyone's already there, obsessed 😭

4.4. Requirements of Server Applications

server apps need global connectivity, which in an IPv6 network implies global addresses 🌟 in an IPv4 network using a NAT, the NAT has to be configured for each service a server provides, so it knows to forward packets sent to that service to the server offering it 🔧 that's a whole chore 🙄

server apps normally rely on publishing the server's address in the DNS 📢 and that means the server has to be provisioned with a "global DNS name" 🏷️

the DNS entries for the server will have to be updated, preferably in real time, if the server's address changes 🕰️ in practice, updating the DNS can be slow, which means server apps have a better chance of being deployed if the IPv6 addresses stay stable 💖 stability is everything, periodt 💅

the security of server apps depends mostly on how correct the server is, and also on the absence of collateral effects 🧐 many incidents happen when opening a server to the Internet accidentally enables remote access to some other services on the same host 😱 one door opens, and suddenly ten more are wide open 🚪

5. Stages of IPv6 Deployment 🌈

we expect IPv6 deployment to go from an initial state with little or no deployment, to a final stage where we might finally retire the IPv4 infrastructure 🌅 this will stretch over many years, and it won't be synchronized, because the different parties involved will deploy IPv6 at different paces 🐢

to get some clarity, we split the transition of an unmanaged network into three entities: the ISP (possibly including ISP consumer premise equipment (CPE)), the home gateway, and the hosts (computers and appliances) 🏢🏠💻 each one can support IPv4-only, both IPv4 and IPv6, or IPv6-only. that gives us 27 possibilities 🤯 we'll describe the most important cases, and we'll assume the hosts are a combination of IPv4-only, dual stack, and (perhaps) IPv6-only hosts 🧩

the cases we'll consider are:

  • A) a gateway that 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 🫠
  • D) a gateway connected to an IPv6-only ISP 🧚

in most of these cases, we'll assume the gateway includes a NAT. we realize that's not always true, but we think it's common enough that we have to deal with it 💅 furthermore, we believe the non-NAT variants of these cases map pretty closely onto this same set of cases ✨ in fact, we can consider three non-NAT variants: a directly connected host, a gateway acting as a bridge, and a gateway acting as a non-NAT IP router 🦋

the cases of directly connected hosts are basically variants of cases B, C, and D, where the host can use all the solutions available to gateways 🎀 it's case B if the ISP is dual stack, case C if the ISP only provides IPv4 connectivity, and case D if the ISP only provides IPv6 connectivity 🌸

when the gateway is a bridge, the hosts are effectively directly connected to the ISP, and for all practical matters they behave like directly connected hosts 🌉

the case where the gateway is an IP router but not a NAT will be treated as small variants in the analysis of cases A, B, C, and D 🔍 no big deal, just tweaks 💁‍♀️

5.1. Case A, Host Deployment of IPv6 Applications

in this case, the gateway doesn't provide IPv6 😤 the ISP may or may not provide IPv6, but that doesn't really matter, since the non-upgraded gateway would stop the hosts from using the ISP service anyway 🚧 some hosts will still try to get IPv6 connectivity so they can run apps that require IPv6, or that just work better with it 🙏 in this case, the hosts will have to handle the IPv6 transition mechanisms on their own 🛠️ hosts doing their own thing, no help from the gateway 💅

there are two variations of this case, depending on the type of service the gateway implements 🎭 in many cases, the gateway is a direct obstacle to IPv6 deployment 🧱 but a gateway that's some form of bridge-mode CPE, or a plain router (neither filtering nor NAT), doesn't really fall into this category 🌷 those ones are giving helpful 🫶

5.1.1. Application Support in Case A ✨

okay so Case A is all about letting a host on the unmanaged network talk to some IPv6-only hosts out on the other side 🦋

For the early adopters of IPv6, the main focus right now is gonna be peer-to-peer applications 🫶 But as IPv6 deployment keeps going, we'll likely hit a point where some networks have IPv6-only services up, and then we'd really love for Case A client applications to be able to reach those services 💅

Local applications are not a primary focus of Case A 🙈 At this stage we expect every client in the unmanaged network to be either IPv4 only or dual stack, so local applications can keep chugging along using IPv4 ✨

Server applications aren't a primary focus either 💀 They need DNS support, which is hard to engineer for clients sitting behind a NAT (and a NAT is pretty likely here). Plus, server applications mostly cater to IPv4 clients right now, so putting up an IPv6-only server isn't very attractive 😭

Peer-to-peer apps, though? Those are both attractive AND easy to deploy 👑 They get deployed in a coordinated way as part of a peer-to-peer network, which means all the hosts can receive some form of an IPv6 upgrade. And they often bring their own naming infrastructure, so they aren't dependent on DNS services 🧚

5.1.2. Addresses and Connectivity in Case A

Remember from 5.1.1? The likely reason hosts in Case A want IPv6 is so they can use peer-to-peer and client IPv6 applications 🌈 Those apps need every participating node to get some form of IPv6 connectivity, meaning at least one globally reachable IPv6 address.

If the local gateway hands out global IPv4 addresses to the local hosts, then those hosts can each use the mechanisms in Case C, "IPv6 connectivity without provider support." 🎀 If the local gateway does NAT instead, then we need another type of mechanism 😬 The mechanism for giving NAT'd peers connectivity should be easy to deploy and lightweight. It's going to have to involve tunneling over a protocol that can easily traverse NAT, either TCP or (preferably) UDP, because tunneling over TCP can give poor performance when timeouts and retransmissions happen 🍓

If servers are needed, in practice they'll have to be deployed as part of the "support infrastructure" for the peer-to-peer network or for an IPv6-based service. Economic reality says the cost of running those servers should be as low as possible 💸

5.1.3. Naming Services in Case A

At this phase, hosts in the unmanaged domain can reach DNS services over IPv4 through the existing gateway 🌸 DNS resolvers are supposed to serve AAAA records even if they only implement IPv4, so local hosts should be able to get the IPv6 addresses of IPv6-only servers ✨

Reverse lookup is tricky to provide for hosts on the unmanaged network if the gateway isn't upgraded 😩 This is a potential issue for client applications. Some servers require a reverse lookup as part of accepting a client's connection, and may require that the direct lookup of the corresponding name matches the client's IPv6 address. So there's a requirement to either provide a reverse lookup solution, or make sure IPv6 servers don't require reverse lookup 🔥

5.2. Case B, IPv6 Connectivity with Provider Support 🌈

In this case the ISP and the gateway are both dual stack 🫶 The gateway can use native IPv6 connectivity to the ISP and can use an IPv6 prefix allocated by the ISP.

5.2.1. Application Support in Case B

If the ISP and the gateway are dual-stack, client applications, peer-to-peer applications, and server applications can all be enabled easily on the unmanaged network 🥳

We expect the unmanaged network to include three kinds of hosts: IPv4 only, IPv6-only, and dual stack. Dual stack hosts can obviously interact easily with either IPv4 only or IPv6-only hosts, but an IPv4 only host and an IPv6-only host can't communicate without a third party doing some kind of translation service 🙅 Our analysis concludes that unmanaged networks should not have to provide such translation services.

The argument for translation is that its availability would speed up deployment of IPv6-only devices, and so the transition to IPv6. That's a pretty dubious argument though, because you could also say translation services would reduce the pressure to provide IPv6 at all, and people would just keep shipping IPv4-only devices 🤷 The remaining pressure to provide IPv6 connectivity would just be the difference in "quality of service" between a translated exchange and a native interconnect.

The argument against translation is that it's hard to provide these services for all applications, compared to how relatively easy it is to install dual stack solutions in an unmanaged network 💅 Translation can come either from application relays, like HTTP proxies, or from network level services, like NAT-PT [RFC2766]. Application relays have several operational problems: first, you have to develop relays for all applications; second, you need a management infrastructure to provision hosts with the addresses of the relays; and the application may have to be modified if you want to use the relay selectively, e.g., only when a direct connection isn't available.

Network level translation has similar problems. In practice, network level actions have to be complemented by "application layer gateways" that rewrite references to IP addresses in the protocol. These relays aren't necessary for every application, but they're necessary for enough applications to make any sort of generalized translation pretty problematic. Hosts may need to be parameterized to use the translation service, and designing the right algorithm to decide when to translate DNS requests has proven very difficult 😵

Not assuming translation services in the network looks both more practical and more robust ✨ If the market requirement for a new device says it has to interact with both IPv4 and IPv6 hosts, we may expect manufacturers to program those devices with a dual stack capability. In particular, we expect general purpose systems, like personal computers, to be effectively dual-stack 💻 The only devices expected to support only IPv6 are ones designed for specific applications that don't need to interoperate with IPv4-only systems.

We also observe that providing both IPv4 and IPv6 connectivity in an unmanaged network isn't particularly difficult: we have a fair amount of experience running IPv4 in unmanaged networks alongside other protocols, like IPX 🕰️

5.2.2. Addresses and Connectivity in Case B

In Case B, the upgraded gateway acts as an IPv6 router 🦋 It keeps providing IPv4 connectivity, maybe using NAT. Nodes on the local network will typically obtain:

  • IPv4 addresses (from or via the gateway),
  • IPv6 link local addresses, and
  • IPv6 global addresses.

Sometimes NAT won't be in use and the local hosts will actually get global IPv4 addresses. We won't elaborate on that, since global IPv4 addresses don't add any extra complexity to the transition mechanisms 🌷

To make this work, the gateway needs a mechanism to get a global IPv6 address prefix from the ISP, and to advertise that prefix to the hosts in the unmanaged network. Several solutions will be assessed in a companion memo [EVAL] 📚

5.2.3. Naming Services in Case B

In Case B, hosts in the unmanaged domain can reach DNS services through the gateway 🧚 Since the gateway and the ISP both support IPv4 and IPv6, these services may be reachable by IPv4-only hosts using IPv4, by IPv6-only hosts using IPv6, and by dual stack hosts using either. Right now IPv4 only hosts usually discover the IPv4 address of the local DNS resolver using DHCP. There must be a way for IPv6-only hosts to discover the IPv6 address of the DNS resolver 🫶

There must be a way to resolve the name of local hosts to their IPv4 or IPv6 addresses. Typing auto-configured IPv6 addresses into a configuration file is impractical, so this implies either some form of dynamic registration of IPv6 addresses in the local service, or a dynamic address discovery mechanism. Possible solutions will be compared in the evaluation draft [EVAL] 🔍

Supporting server applications in the unmanaged network implies publishing the IPv6 addresses of local servers in the DNS 📣 There are multiple solutions, including domain name delegation. If efficient reverse lookup functions are to be provided, delegation of a fraction of the ip6.arpa tree is also required.

The response to a DNS request should not depend on the protocol by which the request is transported. Dual-stack hosts may use either IPv4 or IPv6 to contact the local resolver, the choice of IPv4 or IPv6 may be random, and the value of the response should not depend on a random event 🎲

DNS transition issues in a dual IPv4/IPv6 network are discussed in [DNSOPV6] 💜

5.3. Case C, IPv6 Connectivity without Provider Support

In this case the gateway is dual stack, but the ISP isn't 🙃 The gateway has been upgraded and offers both IPv4 and IPv6 connectivity to hosts. It can't rely on the ISP for IPv6 connectivity, because the ISP does not yet offer ISP connectivity.

5.3.1. Application Support in Case C

Application support in Case C should be identical to that of Case B 🎀

5.3.2. Addresses and Connectivity in Case C

The upgraded gateway behaves as an IPv6 router; it keeps providing IPv4 connectivity, maybe using NAT. Nodes in the local network obtain:

  • IPv4 addresses (from or via the gateway),
  • IPv6 link local addresses,
  • IPv6 global addresses.

There are two ways to bring immediate IPv6 connectivity on top of an IPv4 only infrastructure: automatic tunnels, e.g., provided by the 6TO4 technology [RFC3056], or configured tunnels. Both have advantages and limitations, which will be studied in another document ⚖️

There will be some cases where the local hosts actually obtain global IPv4 addresses. We won't discuss this scenario, since it doesn't make the use of transition technology any harder or more complex. Case A has already examined how hosts could obtain IPv6 connectivity individually 🌸

5.3.3. Naming Services in Case C

The local naming requirements in Case C are identical to the local naming requirements of Case B, with two differences: delegation of domain names, and management of reverse lookup queries 💖

A delegation of some domain name is required in order to publish the IPv6 addresses of servers in the DNS.

A specific mechanism for handling reverse lookup queries will be required if the gateway uses a dynamic mechanism, such as 6to4, to obtain a prefix independently of any IPv6 ISP 🌈

5.4. Case D, ISP Stops Providing Native IPv4 Connectivity 🌈

okay so case D is where the plot twist hits 😭. The ISP goes IPv6-only, which means the gateway loses its IPv4 connectivity and is stuck with an IPv6-only service provider 💀. The gateway itself is still dual stack, though, and the unmanaged network is a mix of IPv4-only, IPv6-only, and dual stack hosts. Any time a host in the unmanaged network wants to talk to an IPv4 host on the Internet, the ISP has to provide some inter-protocol services to make it happen 🫶.

5.4.1. Application Support in Case D 💅

At this phase, IPv6 hosts can join all types of applications with other IPv6 hosts ✨. IPv4 hosts in the unmanaged network can run local applications with IPv4 or dual stack local hosts 🎀.

As in case B, we're assuming IPv6-only hosts won't interact with IPv4-only hosts, local or remote. Still, we have to assume IPv4-only hosts and dual stack hosts are going to want to talk to IPv4 services on the Internet, ngl. If they couldn't, the IPv6-only provider would be at a huge commercial disadvantage compared to other ISPs 😭.

There are three ways an ISP can give hosts in the unmanaged network access to IPv4 applications: a set of application relays, an address translation service, or IPv4-over-IPv6 tunnels. Our analysis concludes that a tunnel service is vastly preferable 💖.

Remember the application gateway drawbacks from case B? You'd need relays for every application, a way to provision hosts with the addresses of those relays, and you'd have to modify the applications so they only use the relays when needed 🙈. On top of that, in an IPv6-only ISP the relays would only be accessible over IPv6, which means the "legacy" IPv4-only hosts couldn't reach them. The application relay approach is not very attractive, bestie 🥲.

Network address and protocol translation between IPv6 and IPv4 has plenty of drawbacks too. Like case B, it would need to be complemented by "application layer gateways" that rewrite references to IP addresses in the protocol. Hosts may need to be parameterized to use the translation service, and we'd have to solve DNS issues 💀. The network level protocol translation service doesn't seem very desirable.

The preferable alternative to application relays and network address translation is an IPv4-over-IPv6 service 🦋.

5.4.2. Addresses and Connectivity in Case D 🧚

The ISP assigns an IPv6 prefix to the unmanaged network, so hosts get a global IPv6 address and use it for global IPv6 connectivity. This needs delegation of an IPv6 address prefix, as investigated in case C 💜.

To let IPv4 hosts and dual stack hosts reach remote IPv4 services, the ISP must provide the gateway with at least one IPv4 address, using some form of IPv4-over-IPv6 tunneling. Once those addresses are handed over, the gateway effectively gets dual-stack connectivity. For hosts inside the unmanaged network, that will be indistinguishable from the IPv4 connectivity they got in case B or C 🎀.

5.4.3. Naming Services in Case D 🔥

Losing IPv4 connectivity has a direct impact on naming services 😩. In many IPv4 unmanaged networks, hosts get their DNS configuration parameters from the local gateway, typically through the DHCP service. If we want that same setup in case D, the gateway has to be provisioned with the address of a DNS resolver and with other DNS parameters, and that provisioning has to use IPv6 mechanisms. Another side effect is that the DNS service in the gateway can only use IPv6 connectivity to resolve queries. If local hosts do DNS resolution on their own, they get the same restriction 💔.

On the surface, this seems to mean local hosts can only resolve names if the domain servers are reachable through an IPv6 address documented in an AAAA record. But DNS is just one case of "IPv4 servers accessed by IPv6 hosts," so it should be possible to simply send queries through the IPv4 connectivity services to reach the IPv4-only servers 🧠✨.

The gateway should be able to act as a recursive DNS name server for the remaining IPv4-only hosts 👑.

6. Security Considerations 🔐

Heads up, this section is serious business 🚨. Security considerations are discussed as part of the applications' requirements, and they include:
  • the guarantee that local applications are only used locally,
  • the protection of the privacy of clients
  • the requirement that peer-to-peer connections are only used by authorized peers
  • the requirement that tunneling protocols used for IPv6 access over IPv4 be designed for secure use
  • the related requirement that servers in the infrastructure supporting transition scenarios be designed so as to not be vulnerable to abuse.

The security solutions currently used in IPv4 networks include a combination of firewall functions in the gateway, authentication and authorization functions in the applications, encryption and authentication services provided by IP security, Transport Layer Security and application specific services, and host-based security products, such as anti-virus software and host firewalls. The applicability of these tools in IPv6 unmanaged networks will be studied in a another document 🛡️.

7. Acknowledgements 🫶

This document has benefited from the comments of the members of the IETF V6OPS working group, and from extensive reviews by Chris Fischer, Tony Hain, Kurt Erik Lindqvist, Erik Nordmark, Pekka Savola, and Margaret Wasserman 💕.

8. References 📚

8.1. Normative References

[RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
             September 1981.

[RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

8.2. Informative References

[EVAL]      Evaluation of Transition Mechanisms for Unmanaged
             Networks, Work in Progress.

[RFC1918]   Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
             J. and E. Lear, "Address Allocation for Private
             Internets", BCP 5, RFC 1918, February 1996.

[RFC2608]   Guttman, E., Perkins, C., Veizades, J. and M. Day,
             "Service Location Protocol, Version 2", RFC 2608, June
             1999.

[RFC3056]   Carpenter, B. and K. Moore, "Connection of IPv6 Domains
             via IPv4 Clouds", RFC 3056, February 2001.

[RFC3022]   Srisuresh, P. and K. Egevang. "Traditional IP Network
             Address Translator (Traditional NAT)", RFC 3022, January
             2001.

[RFC2993]   Hain, T., "Architectural Implications of NAT", RFC 2993,
             November 2000.

[RFC3041]   Narten, T. and R. Draves, "Privacy Extensions for
             Stateless Address Autoconfiguration in IPv6", RFC 3041,
             January 2001.

[RFC2766]   Tsirtsis, G. and P. Srisuresh, "Network Address
             Translation - Protocol Translation (NAT-PT)", RFC 2766,
             February 2000.

[DNSOPV6]   Durand, A., Ihren, J. and P. Savola, "Operational
             Considerations and Issues with IPv6 DNS", Work in
             Progress.

[DNSINADDR] Senie, D., "Requiring DNS IN-ADDR Mapping", Work in
             Progress.

9. 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

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/SHE 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 procedures with respect to rights in RFC 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