IPv6: What's the Problem?
- The Configuration Problem
- But I Like My Solution!
- It Works For Me™
- Which One First?
- Why Bother?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Last week we looked at some of the issues facing people who are trying to use IPv6. This week, we'll take a closer look at some of the problems facing IPv6 adoption.
The Configuration Problem
If you have an IPv4 network, then you almost certainly use the Dynamic Host Configuration Protocol (DHCP) to assign IP addresses. This works by sending a broadcast packet across the network and having another host reply with the assignments.
This is not always reliable. The computer society at my university managed to take all of the lab machines offline back in the late '90s with a DHCP server. The entire campus network was configured with a flat topology and so DHCP requests were sent to every single machine on the network. The computer society ran its own computer room (and still does), with a guest network that members could use, after registering. The DHCP server for the guest network was receiving all of the DHCP requests and replying with an "access denied" message before the university DHCP server. Any time a computer was rebooted, it got kicked off the network and users couldn't log in.
This is quite rare; most of the time, you won't use a flat network topology for anything other than a very small site. DHCP is still quite fragile though; any computer on the local broadcast domain can send DHCP replies, unless they are all connected via a managed switch.
IPv6 partially simplifies this by allowing computers to generate their own IP addresses. This is great for simple networks[md]no configuration at all is required. Unfortunately, it only solves part of the problem.
DHCP is used to assign IPv4 addresses, but that's not all that it's used for. A typical DHCP reply contains a lot more information, such as the addresses of DNS servers, the default route, and maybe even the host name to use. IPv6 autoconfiguration allows the host to assign itself an IP address, but how do you get the other bits of information?
Unfortunately, this is a problem that the IPv6 working group spent a lot of time thinking about, and came up with a lot of different solutions. One approach is to simply to replace DHCP with DHCP6, a new protocol that solves exactly the same problem as DHCP in a similar manner.
Another idea is to piggyback other information onto the router advertisement. When an IPv6 host has assigned itself an address on the link-local network, it broadcasts a router solicitation. A router should then reply with a router advertisement, which gives it the network prefix and the address of the router. The host then generates a new routeable IPv6 address.
The router advertisement can contain other information. If your router is running some *NIX variant, it probably uses radvd to send these messages. This supports sending the DNS servers to use, as part of the router advertisement.
Another solution is to use mDNS-SD. This is a combination of two protocols. The first, multicast DNS (mDNS), allows you to send DNS queries to the local network's broadcast address and get a reply from any host. This is most commonly used to advertise the name of each host in the .local. top-level domain. For example, if you broadcast a query for example.local. then every host that wants to call itself example will reply with its IP address.
The other protocol is DNS service discovery (DNS-SD). This defines a way of formulating service address queries as DNS host names. You then look up the SRV record corresponding to this address and get information about how to connect. The combination of the two (sometimes branded Bonjour or Zeroconf) provides a generic mechanism for publishing discoverable network services. Apple uses it a lot[md]for example, for iTunes shares, Safari shared bookmarks, and so on.