Shim6, was: Re: filtering /48 is going to be necessary

William Herrin bill at herrin.us
Fri Mar 16 02:40:54 UTC 2012


2012/3/15 Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>:
> Even ordinary routers are ends w.r.t. routing protocols, though
> they also behave as intermediate systems to other routers.
>
> As LS requires less intelligence than DV, it converges faster.

I do believe that's the first time I've heard anybody suggest that a
link state routing protocol requires "less intelligence" than a
distance vector protocol.



>> If that isn't clear to you then don't presume to lecture me about the
>> end to end principle.
>
> Here is an exercise for you insisting on DNS, an intermediate
> system.
>
>        What if DNS servers, including root ones, are mobile?

DNS' basic bootstrapping issues don't change, nor do the solutions.

The resovlers find the roots via a set of static well-known layer 3
address which, more and more these days, are actually anycast
destinations matching diverse pieces of equipment. It makes no
particular sense to enhance their mobility beyond this level.

Before you jump up and down and yell "Ah ha!" realize that this is
true of a mapping function at any level of the stack. ARP doesn't work
without knowing the layer 2 broadcast address and IPv6's ND doesn't
work without knowing a static set of multicast addresses.

Below the roots, the authoritative zone servers are no different than
any other node. If you're willing to tolerate the lowered TTL for your
NS server's A and AAAA records then when IP address changes and your
parent zone is willing to tolerate dynamic updates for any glue, then
you can make DNS updates to the parent zone like any other mobile
node.

The clients find the recursing resovlers via whatever process assigns
the client's IP address, e.g. DHCP or PPP. If it is for some reason
useful for the server's base address to change then assign a set of
VIPs to the DNS service and route them at layer 3.

On the other side of the wall, the recursing resolvers don't
particularly care about their source addresses for originating queries
to the authoritative servers and will move to the newly favored
address with nary a hitch.



If you want an actually hard question, try this one: what do you do
when fewer than all of the authoritative DNS servers for your node's
name are available to receive an update? What do you do when those
servers suffer a split brain where each is reachable to some clients
but they can't talk to each other? How do you stop bog standard
outages from escalating into major network partitions?


For that matter, how do you solve the problem with your home agent
approach? Is it even capable of having multiple home agents active for
each node? How do you keep them in sync?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004




More information about the NANOG mailing list