IPv6 Deployment for the LAN

trejrco at gmail.com trejrco at gmail.com
Thu Oct 22 12:32:55 UTC 2009

WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? 

... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would only reach 9999 w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious))

Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ?

... Just thinking 'out loud' ...
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Perry Lorier <perry at coders.net>
Date: Fri, 23 Oct 2009 00:22:52 
To: <bmanning at vacation.karoshi.com>
Cc: <nanog at nanog.org>
Subject: Re: IPv6 Deployment for the LAN

bmanning at vacation.karoshi.com wrote:
> On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote:
>> On 22 okt 2009, at 01:55, bmanning at vacation.karoshi.com wrote:
>>> 	so your not a fan of the smart edge and the stupid network.
>> I'm a fan of getting things right. A server somewhere 5 subnets away  
>> doesn't really know what routers are working on my subnet. It can take  
>> a guess and then wait for people to complain and then an admin to fix  
>> stuff if the guess is wrong, but I wouldn't call that a "smart edge".
>> Always learn information from the place where it's actually known.
> 	i'm ok w// that mindset.
> 	one should learn routing from the router(s),
> 	time from the time servers,
> 	DNS from the DNS servers,
> 	etc...

I quite liked the old 
http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 idea.  
(tl;dr version: Have a set of well known site local anycast address for 
recursive name servers).  It has a number of nice features such as:

* since it's not in globally routable space people can't (ab)use your 
recursive name servers from outside your network. 
* you don't have to change recursive name servers when going to a 
different network -- they're the same everywhere.
* the addresses can be set as the default addresses by the OS 
manufacturer, and then don't need to be configured ever again.
* If your recursive name server becomes unreachable, broken or otherwise 
out of contact, it withdraws the address from your IGP, then since you 
can any cast these addresses, another node takes over.  Similar to the 
shared fate idea of RA's.
* You don't tie your recursive nameservers addresses to any point in the 
network, since they have their own special range, moving them, 
reshuffling them, or anything doesn't impact anything.  They don't need 
to cohabit a router sending RA's or anything odd like that.

However it has a number of obvious drawbacks, primarily amongst them 
being that it uses deprecated site local addresses.

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.... 

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 :)

More information about the NANOG mailing list