Re: IPv6 Deployment for the LAN

[Perry Lorier <perry () coders net>]

bmanning () vacation karoshi com wrote:
> On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote:
>   
> > You could imagine extending this to other services such as NTP, but I'm 
> > not sure that you really would want to go that far, perhaps using DNS to 
> > lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers.
> >
> > Another obvious approach might be to have a service discovery protocol 
> > where you send to a "service discovery" multicast group a message asking 
> > "wheres the nearest nameserver(s)?" then nameserver implementations 
> > could listen on this multicast group and reply.  Again shared fate.  
> > This does have the downside of people running rogue nameservers and 
> > needing a "ServiceDiscovery-Guard" feature for switches.... 
> >     
>
>         ah... well - if your a router centric person, then you want
>         to put everything into the tools you know and love.
>
>   

Generally I don't think of myself as a router centric person ;)

>         if your a dns centric person, then you put everything in the
>         DNS.
>
>   

This has always sounded like a nice solution to me, however, DNS is 
starting to look a little long in the tooth, overloading it with more 
and more semantics seems to be pushing it well beyond it's design 
envelope.  (EDNS0?)

>         I point you to the "DISCOVER' opcode (experimental) in the DNS
>         and the use of DNS over multicast for doing service discovery
>         (e.g. Apples Bonjour)...  Most of that is already designed/deployed
>         and in pretty widespread use... over IPv4 or IPv6.
>   

Yup, they're good ways to discover some local resources.  To my 
understanding mDNS works over the local subnet, unless you're going to 
start having your routers run as mDNS relays (is there any standards for 
this?  How do you stop mDNS relays from creating loops and broadcast 
storms?).  mDNS works over a a single multicast group with a single port 
5353 which makes it hard to filter different types of services (People 
on this switch can announce their iTunes sharing, but they're not 
allowed to announce a local DNS server) without DPI, you're more likely 
to find network engineers just filter the entire multicast group 
breaking it for other purposes  If you're not going to have mDNS 
forwarders on your routers, then you're going to need to reconfigure 
your entire configuration on every segment as well.

(IMHO) there are different types of configuration:

* Network related (routes, addressing).  RA's seem to do a fairly good 
job at at least 80% of this.

* Network provided services, such as DNS, NTP.  Well known anycast 
addresses seems to be (IMHO) the best way to advertise these.  Currently 
you need DHCPv6 to get this information.

* Application settings (web proxy, local outgoing SMTP relay, default 
printer location, local SIP/RTP proxy, local home/intranet page, what 
the current local timezone rules are).  This seems to be currently done 
by a variety of adhoc protocols, usually bundled over well known DNS 
names with HTTP, often replicating the same information in a wide range 
of different places in different formats.  This seems an ugly solution, 
but I have no other suggestions.  I'm sure there are several RFCs/Drafts 
around somewhere that tries to solve this.

* Ephemeral end user provided services, which is already provided today 
by the well documented, and deployed mDNS.

in theory you can kinda pick and choose between those, for instance you 
can run just mDNS on a network without RA's or DHCPv6 and things will 
work (for the limited value of work that involves only whatever the 
ephemeral services are being announced).  You can run RA's by 
themselves, and your bittorrent will work fine.
>         And yes, its not RA/ND, or DHCP... its another configuration protocol
>         and its not quite vendor specific.  The best thing is, it pushes
>         the smarts closer to the edge (the end device)  and this makes me happy.
>
>   
Theres a general issue of access control.  While I like a very smart 
edge, you don't want some ""misinformed"" user turning on a feature and 
suddenly having the rest of your network ending up using it. 


> > Personally I like the first option (anycast addresses) better, you can 
> > control who has access to your IGP and if your IGP is down, then for all 
> > intents and purposes your recursive nameservers are offline too :)
> >
> >     
>
>         everyone to their own taste.
>
>   

Yup.  There are different systems, they have different tradeoffs.  Pick 
the one that trades off things you don't care about for things you do 
care about. :)