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
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,
I quite liked the old
(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