by syscomet

DHCPv6 compared to DHCPv4

Summary of RFC3315 and related (see bottom of message) RFCs as they relate to DHCPv4.

DHCPv4 is a bit of a mess; it’s written to be an easy upgrade from the old BOOTP protocol; that BOOTP was often embedded in firmware and used for diskless client start-up and working with it was probably a major factor in DHCPv4’s success. But it means that at a protocol level, some elements are in a fixed record format and some (“options”) are in Type-Length-Value (TLV) triples, and those triples can be in three different areas of the packet, which are logically joined together in a different order to how they appear in the packet (and dependent upon an option saying to do so). Repeated options (with the same Type) are merged together into one option, because there’s a length limit of 256 so merging is needed. Some options don’t have a length, the T value makes it implicit. In some areas the specification is a little vague and some implementors take advantage of that to fob off responsibility to someone else, decreasing security.

Also, in DHCPv4 the client has no IP address until DHCP has been run, so various gross hacks are done and servers tend to be written using something like the Berkeley Packet Filter (BPF) or Linux raw sockets to get access to the packets, so host packet filters are ineffective (different code-path) and IPsec policies can’t be applied, even in a relay situation (with normal servers; DemonNL’s is different).

DHCPv6 is a significant clean-up; there is no large backwards-compatibility fixed area, there are no permanent giaddr fields with semantics to be argued about, there is no way that server IP addresses leak to clients even through relays, etc. All options are in TLV options, except where a particular DHCPv6 packet type fundamentally needs some data, which can then use a record layout. Error responses have an assigned code and a text field for presentation to the end-user. All timers are clearly documented. Behaviour when one party misbehaves is much less ambiguous.

DHCPv6 shows the fundamental similarities between DHCP and RADIUS, whilst remaining distinct.

DHCPv6 does not intrinsically support network booting. Your boot system needs to be able to get an IPv6 address before it can proceed. I don’t yet know how netbooting is supposed to work in a v6-only environment.

All options are TLV, type and length are 16 bits long so scarcity of options is not an issue and there’s no need to “merge” same-Type options together. Because options are not merged, a particular Type can appear more than once if it’s useful to do so. The vendor-specific stuff is in from the start, so there’s less reason for vendors to resist using it and try to get global options. Vendor-specific stuff is where the Enterprise Number is used as a tag for the associated data. Because options are not merged, multiple Vendor-specific Information options can appear, each with a distinct enterprise-number, so this is cleaned up some.

Option embedding is hierarchical. I’ll come back to this below.

Two new port allocations instead of reusing 67 and 68. Clients listen on 546 and servers on 547. Because a host in IPv6 always has some IP address, even if it’s just a link-local address, there is no need to fiddle around in grotty ways. All DHCPv6 is UDP, some multicast and some unicast. A particular response might be unicast but clients are not allowed to use unicast to the server unless explicitly told to with the Server Unicast option, which provides the server-address. Client Identifiers and Server Identifiers are constructs for uniqueness which do not provide routable addresses, so a client can’t just use the server address unless provided. The server explicitly MUST reject unicast not solicited with the Server Unicast option and the spec explicitly notes that where a server is using Relay Agent information for policy decisions such as allocation, the server should not allow unicast; that way, the relay agent is, per spec, explicitly supposed to remain “in the loop” whenever its data is being used. This is a helpful clarification relative to DHCPv4 and one which will irritate certain DSL providers.

Several DHCPv6 packet types exist; some do stateful allocation, some just request information. A server can mandate that a client accept Reconfigure notices, whereupon the client starts a reconfiguration process immediately. DHCP Authentication is mandatory for Reconfigure.

Finding an initial DHCP server is a link-local multicast send, to the allocated All_DHCP_Relay_Agents_and_Servers (FF02::1:2) address. All DHCP servers join that multicast group for all interfaces on which they serve requests. So host security packet filters can be applied, IPsec can be used, etc. At present, IPsec isn’t used for client↔server communications; or rather, relay_agent↔server and relay_agent↔relay_agent are explicitly allowed but client↔relay_agent_or_server is not explicitly forbidden. However, the DHCP authentication protocol is carried over from DHCPv4.

Instead of asking “what is my IP address?” there is no limit of “one resource collection per host”; instead, a host (as identified by Client Identifier) can get general resources and collections of resources; the host will identify an “interface”; it can request data for that interface and get one or more IPv6 addresses and various options relating to those addresses; this is where options are hierarchical. Things like NTP servers can (I think) be per-link. These per-interface aggregates are called “Identity Associations”. One IA can have multiple addresses, each with its own independent preferred and valid lifetimes (and all distinct from the T1 and T2 timers). This allows for renumbering; it’s clear which interface has a new IP address, specific IP addresses can have a lifetime set to 0 for “withdraw this address”, etc.

As well as “what is my IPv6 address”, a client can ask for an IPv6 prefix for allocation (RFC 3633). So an ISP can fairly easily see when a customer is connecting a machine directly via a DSL bridging modem and when the DSL modem is a router, since the router should be asking for prefixes instead of addresses. I suppose that a router could ask for a public IPv6 address for itself and perhaps should, for ICMP error source addresses, but really on the public side the router only needs a link local address — this would limit the ability of attackers to probe end-user insecure devices. Of course, using DHCPv6 the ISP could issue a site-local IPv6 address instead, so that the ISP can manage those devices which are its to manage. RFC3633 has a pretty ASCII-art diagram showing the CPE router, end machines, ISP kit, etc.

Another example of hierarchical options is the use of Relay Agents; this is done with the Relay-forward and Relay-reply messages, which use a fixed record that has an options section at the end. The record has the hop count, the agent’s own link address and the peer address (the client, or downstream relay agent if chaining). The forwarded request is then embedded, in its entirety, inside a “Relay Message option” in the options section. These can nest! (Examples in RFC3315 §20) Another option the relay agent might embed is an interface identifier; I think that this can be used to replace RAIO from DHCPv4: it’s an opaque value (defined in RFC3315 §22.18) and could hold ATM circuit information. I’ve not yet seen anything else which provides RAIO style of functionality, so I think that this is it.

In the presence of a Relay Agent, the client has a Server Identifier which can’t be routed to, may be forced to continue to use Multicast by not saying “unicast allowed” and multiple level encapsulation/de-encapsulation is cleanly defined with RAIO-style tagging at each layer. And the RFC is very clear that when doing RAIO, it’s A Bad Thing to not keep the relay agent in the loop.

Oh, and the headache which keeps me from thinking that DHCPv6 is sunshine and happiness and things finally done right: there are two types of IP address assignment, Temporary and Non-temporary, but the Non-temporary ones have lifetimes and the Temporary ones don’t. That’s because temporary addresses are for the ones which keep changing, for privacy reasons (RFC 3041, originally known as That Weird Thing Which Microsoft Do for Client Hosts, now known as Maybe Hell Has Frozen Over And Microsoft Were Right, Not Sure And Will Get Back To You). DHCP says nothing itself about the lifetime of these, its all in the hands of the client. RFC3315 §12 is mercifully short and the wording almost suggests that these Temporary Addresses are “Not Our Idea, Damnit!”; The IA_NA stuff, Identity Associations for Non-temporary Addresses, is the stuff which is “normal” IP address assignment and which has timers and the like.

Politics.

After all, the addresses could have been assigned normally, with shortish lifetimes and perhaps an extra option in the IA saying “this one is temporary, see RFC3041 for what that means”. Bah!

But for the most part, DHCPv6 is clean and nice and a huge relief; I don’t think that I’ll ever again be able to hack on DHCPv4 server code without wistful thoughts of how much cleaner things are in v6 land. Although given that an option with one IPv6 address is at least 20 octets long (2 type, 2 length, 16 for IPv6 address) I can see the UDP packet space being burned through quickly enough; fortunately IPv6 raises the minimum packet size to 1280 octets (RFC 2460 §5) which means that, with records and the like, around 60 addresses can still be managed. A couple of IP addresses for the client (during migrations), three DNS servers, a couple of time servers … its doable, but I’d be careful about embedding any additional services unless they’re configured by DNS and DNS compression is allowed after all (in some revision) or the search list from the DNS Recursive Name Server option is applied to hostnames given for additional services. I’m thinking of mail smarthosts, POP3 servers, etc. RFC 3898 (for NIS) shows how with DHCPv6 you can use DNS hostnames without needing to have the server resolve them to IP addresses at start-up to comply with DHVPv4’s worldview of “everything is an IP address”, but I am left wondering how more sophisticated setups will be managed unless ACAP starts to take off.

RFCs