[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 5006 status
On Fri, 19 Mar 2010 18:25:30 -0700
james woodyatt <jhw@apple.com> 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.
>
In principle I'm generally against CPE having DNS resolvers in them, as
they've caused me enough trouble in the past, however, that's probably
fundamentally been caused by implementation issues, not so much an
issue with the idea.
I'm wondering if it is right for the CPE router draft to assume that,
if it is being assumed to be the common case. It seems to be a very
common thing for DNS resolvers to be implemented in the CPE, including
in some IPv6 capable CPE I've seen.
I also think there is a possibility that service providers may start
delegating forward and reverse DNS zones to customers' CPE e.g.
<customer>.cust.example.com and <delegated prefix>.<blah>.in-addr.arpa.
That, combination with things like Zeroconf/DNS-Service Discovery, will
mean CPE may also become authoritative DNS servers as well as resolvers.
> In those cases, when the service provider moves the DNS servers, or when the WAN link is dropped and reacquired at a new connection point with a different delegated prefix and new DNS servers, the hosts on the LAN need to have their resolver configurations renumbered.
I'd think service providers changing DNS servers addresses these
days would be a rare event. The service providers I've worked at have
either implemented anycast DNS or already have it, to avoid having to
change DNS addresses. One contributor to this problem is that for some
reason one of the troubleshooting steps helpdesks seem to automatically
do is get the customer to statically configure the DNS server IP
addresses, even though the networking equipment is providing it
automatically e.g. via PPP. Usually when that doesn't fix the customers
issue, the helpdesk don't get the customer to reverse it, so as time
goes on you have more and more customers with static DNS
configurations. That makes it pretty much impossible to change DNS IP
addresses these days. Even if only 5% of customers have static DNS
addresses, with 50K+ customers, your still looking at 2500 additional
helpdesk calls within hours of the change if you do it.
Because of that, even if you do implement new anycast DNS servers
with IPv4 /32s out of a range of addresses reserved for /32s, you will
also need to now anycast the old DNS server addresses as /32s even if
they formerly out of e.g. a /24 assigned to a LAN. My estimate would be
that if you want that /24 back to use as a /24, rather than a new range
of 256 /32s, you'll be waiting around 5 years before the customer
disruption caused by removing them is small enough.
I do agree that updating DNS addresses caused by a change of provider
is an issue.
> 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. Any
> hosts that can't do DHCP Authentication won't get their resolvers
> reconfigured until they renew their lease. Bletch.
>
> 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.
>
Wind up their paranoia until they completely disconnect from the
Internet, and aren't a problem for you anymore :-) David Icke has a few
theories that might help with that. The CIA/NSA/etc. would be the least
of their worries if they find out about the reptilian humanoids
that are controlling the world.
;-)
Regards,
Mark.