Re: RFC 5006 status

[james woodyatt <jhw@apple.com>]

On Mar 19, 2010, at 05:41, STARK, BARBARA H (ATTLABS) wrote:
> [I wrote:]
>> 
>> I can see utility in the *limited* extension of RDNSS to standards
>> track, because it allows zero-configuration hosts on IPv6 networks
>> where all the routers advertise O=0 to have some hope of resolving
>> domain names after joining them.  They don't get that today, and I
>> don't see a good way to use DHCP to do anything about that.
> 
> I'm confused by this O=0 proposal. I thought the O flag was intended to
> announce that there was a DHCP server available with other (non-IA)
> configuration info, including NTP, SIP server, DNS, etc.

Yes, but O=0 does not actually imply that there MUST be no DHCP service, despite the Note on page 19 of RFC 4861.  It merely implies that there MAY be no DHCP service.  Another router on the same link can assert by advertising to hosts with O=1 that there MUST be a DHCP service.

>                                                               Is this
> suggesting that the O flag be used exclusively to announce the
> availability of DNS info in DHCPv6, and not any other config info?

Not at all.

> Should clients just guess whether DHCPv6 is available for non-IA,
> non-DNS info?

Right now, the only standard way to configure hosts dynamically with DNS server addresses is with DHCPv6.  Hosts that join networks where no routers are advertising O=1 are either configured with DNS server addresses manually, or they are forced to start their DHCPv6 clients to get configured-- despite the fact that all the routers are explicitly warning that there MAY be no DHCPv6 service available.

So.  An alternative way forward out of this mess would be to leave RFC 5006 in experimental category and deprecate the O bit entirely, i.e. update the router requirements to require all RA to be sent with O=1, and explicitly encourage hosts with DHCPv6 stateless clients to start them immediately on completion of SLAAC regardless of the state of AdvOtherConfigFlag.  I'd support that too.

> Is it suggesting that if clients do not support RFC5006
> for getting DNS info (but do support DHCPv6), that they not be given a
> hint that a DHCPv6 server is available that might have other config
> info? Or, with O=0, would there be a simultaneous proposal that support
> for RFC5006 be mandatory in clients?

I don't see a need to revise the host requirements to make support for processing RDNSS options in router advertisements any more necessary for conformance than support for processing DHCP.

But if we *did*, then that would mean that a certain operating system I'm thinking about would no longer be able to claim compliance with IPv6 host requirements while still requiring domesticated primates to type numeric IPv6 addresses into a squirrelly little text window buried three layers down in System Preferences before they can watch the special dancing animation on their favorite IPv6 pr0n site.

I'm trying to be careful what else I say about that.

> Just trying to understand this, since I've seen it suggested before, and
> can't quite figure out the full range of expected behavior in the wild
> frontier of IPv6 home networks.

Here's what the IPv6 router on my home network does today:

+ Advertises with O=1 and M=0.
+ Offers stateless DHCP6 service with its own global address as the DNS server for the link.
+ Advertises with RFC 5006 its own global address as the DNS server for the link.
  - Lifetime is set the same as the prefix lifetime.
+ Runs a recursive DNS forwarding server (access limited to the LAN prefix).

Currently, all the hosts on my home network that can process RFC 5006 messages also have DHCPv6 clients in them, so they process both sources of DNS server address, merge them together and get the single address that's advertised in both, and they configure themselves appropriately.

The interesting part happens when the delegated prefix changes, e.g. when I switch the WAN uplink from one network to another.  The addresses of the DNS servers available to hosts on the LAN link changes.  This gets reflected quickly in the RDNSS options that the router sends, and the hosts with RFC 5006 clients updates their DNS resolver configurations immediately.  Since I don't have any hosts with *only* a DHCPv6 client and no RFC 5006 client, I'm not sure what happens to such hosts when their DNS server addresses need to be changed away from the ones they learned from their DHCPv6 lease.  I suspect they just keep using the addresses they were initially offered until their lease expires, and this will produce suboptimal user experience until they go to renew.


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering