Re: RFC 5006 status

[Doug Barton <dougb@dougbarton.us>]

On 03/19/10 18:25, james woodyatt wrote:
> On Mar 19, 2010, at 16:46, Mark Smith wrote:
>> On Fri, 19 Mar 2010 12:27:04 -0700 james woodyatt <jhw@apple.com>
>> wrote:
>>> 
>>> 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.
>> 
>> I think that issue would be resolved by having your CPE use it's
>> LAN interface ULA addresses to announce it's local DNS resolution
>> service. Doing that isn't explicitly mentioned in the basic CPE
>> draft, however as the CPE's DNs resolution service is an optional
>> 'site local' service, I think using the CPE's LAN interface ULA
>> address to announce it would make sense, and avoid the issue you
>> mention.
> 
> That might work fine for routers that are integrated with their own
> DNS forwarding servers.  The interesting case is routers that *DO
> NOT* have integrated DNS servers, which if I recall correctly, the
> current CPE router draft implicitly assumes.

Given the large number of problems these forwarders cause for
advancement to the DNS protocol (EDNS0, DNSSEC, new RR types, etc.) I
think continuing to encourage NOT including them is the best course of
action.

> In those cases, when the service provider moves the DNS servers,

On a rational network this does not happen often enough to be considered
a primary design goal.

> when the WAN link is dropped and reacquired at a new connection point
> with a different delegated prefix and new DNS servers,

Both RA and DHCP already handle this case.

> The RDNSS option in router advertisements permits this to happen
> immediately after reattaching to the service provider network for
> every host on the LAN with a short burst of link-local multicast
> packets, but DHCP requires a Reconfiguration message to be unicast to
> every client, which implies that all the hosts on the LAN are
> required to implement not just DHCP6, but DHCP Authentication. 

See above.

> I think RFC 5006 is a much simpler solution for this scenario.  But I
> recognize that there are people who think that every IPv6 network,
> *everywhere*-- even the ones in our own homes-- should have *every*
> interface address managed and firewalled six ways to Sunday, in case
> the secret police come calling and wish to inspect the premises for
> evidence of terrorist activity.  I really don't know what to say to
> those people anymore.

Um, wow.


-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/