Subject: [dhcwg] stateless dhcp6 and timely information update

From: james woodyatt <[email-masked]>
Date: Thu, 25 Mar 2010 15:17:18 -0700

everyone--

As we discussed in the DHC session today at IETF 77 in Anaheim, I've got a problem with using stateless DHCP6 to provide IPv6 hosts on the local side of a residential CPE gateway with timely updates of changes to the DNS server addresses and related configuration parameters.

It's an old problem, and it's well documented already in RFC 4076.  If you haven't read that, then please refresh your memory now.  I'll wait.  Done?  Okay, now I'll get into the weeds of why I'm suddenly all spun up about it.

Consider this scenario: home gateway runs stateful DHCP6 client on its WAN interface, requests DNS server addresses, domain name, domain search path, and prefix delegation; also runs *stateless* DHCP6 server on the LAN, responds to requests for DNS server addresses, domain name, domain search path.  Hosts get configured.  All good, right?  (This is pretty much what I-D.ietf-v6ops-ipv6-cpe-router is saying to do.)

Now consider what happens next: WAN link goes down for a few minutes, and when it comes back up, the gateway's DHCP6 client fails to renew, instead needs to rebind.  (Alternatively, this same scenario could arise with the reconfiguration update subprotocol, but let's not get ahead of ourselves.)  Residential gateway gets new DNS server addresses and service no longer available at old addresses.  If there is also a new prefix, then that goes out in router advertisements, and the hosts on the LAN all renumber properly, but the issue arises even when the prefix doesn't change.

How do the hosts on the LAN get the new DNS server addresses sent by the service provider?  Answer: they don't, because the reconfiguration update subprotocol only works for the *stateful* variant of DHCP6, not the stateless one.  So, now all the hosts on the LAN have broken DNS resolvers.  Notice that hosts on LAN do not see link state changes, the router address doesn't change, they don't necessarily get *any* signal that network information has been changed.  The will remain broken until their information expires and they initiate a new request.

What can a residential gateway vendor do about this?  Unfortunately, there is no magic bullet.  There are basically three options I see for my product, two of which are very similar.

1) Give up on stateless DHCP6.  We could run the DHCP6 server in stateful mode on the LAN and set A=0 in the prefix advertisement so as to disallow SLAAC nodes on the LAN.  This option makes Windows Vista and Windows 7 hosts reasonably happy, but it's a non-starter for anybody who wants IPv6 service to be available to hosts running any currently support version of Mac OS X.  As you might imagine, this is a completely unacceptable alternative to *me*, but I could imagine the DHC working group not caring about my problems.

2a) Keep using stateless DHCP6, but work around its problems with timely update by using router advertisements.  The RDNSS option in RFC 5006 allows for reconfiguration of DNS server addresses, and that might be enough for most residential networks, but it doesn't help with any of the other information parameters that a stateless DHCP6 server can provide.

2b) Keep using stateless DHCP6, but work around its problems with timely update another way.  Apple's AirPort base station has always contained an integrated DNS forwarder.  We could advertise the server with a unique local address assigned to the loopback interface.  We don't have to update the LAN hosts with new DNS server addresses any time the WAN information changes.

Both case 2a and 2b don't offer any way to provide timely updates to LAN hosts for information other than the DNS server addresses.  On a residential network, maybe I don't care about anything else.  Maybe.  I think service providers might be surprised, however, that their domain name and search path parameter changes don't get propagated properly.

Generalizing the problem beyond just my issues, what about vendors planning *not* to include an integrated DNS server?  There are people in DNSOP who keep yelling at me that putting a DNS server in the residential CPE gateway is considered harmful.  Yet here I am finding a reason why it's absolutely got to be there.

In any case, it seems to me that the problem described in RFC 4076 remains open.  Stateless DHCP6 is basically broken because there isn't a way for clients to be notified that previously satisfied information requests have been rendered invalid before their associated lifetime has expired.

This needs to be solved.  If we *don't* want to solve the problem described in RFC 4076, then we should just deprecate RFC 3736 and throw in the towel.  How do we want to proceed?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Mar 2010 12:09:42 -0700

One observation I have about this is that I think your problem is actually a tightly constrained one that's specific to the use case you're trying to address.   In general, ISPs do not change the IP addresses of their DNS resolvers or any other services they offer to customers at the drop of a hat--these changes are phased in over time.

When doing a normal renumbering event, the way we expect it to work is that the ISP will deprecate the old address space, and start propagating the new one, and that there will be a period of overlap when both spaces are in effect.   Consequently, there's no need for instant updating of DHCP parameters--it's sufficient to do it next time the client renews.

Your use case is different, because your information changes when your connection changes, and that can't always be done neatly.   I expect that the transition you're most interested in is the offline->online transition--is that correct?   In that case, you go from having no DNS service to having DNS service, and you'd really like your clients to know about it sooner rather than later.

Does this make sense?   Can we in fact constrain the use case here to the one you're addressing?   I can imagine other use cases, like mobile roaming, but I think they already have mechanisms for dealing with this; in particular, it would be surprising to me if the IP address of my DNS server on AT&T stopped working simply because I'd roamed from one cell site to another.

The other use case I can imagine is the case of the mobile hotspot.   But that's pretty much the same use case that you have--the only difference is that in that case, if the hotspot supports multiple providers, you might also have to deal with the old->new transition when the hotspot roams to a different provider.   I think that whatever mechanism you choose to solve the offline->online transition will also work for the old->new transition, so even though the problem is a little bit different, we can call it the same problem.

---

From: james woodyatt <[email-masked]>
Date: Fri, 26 Mar 2010 12:23:36 -0700

> Your use case is different, because your information changes when your connection changes, and that can't always be done neatly.   I expect that the transition you're most interested in is the offl…

The case I have to handle that poses the most obvious difficulty is when the LAN is renumbered because the WAN is disconnected from one provider and connected to a completely different provider.