IPv6 Deployment for the LAN ... anycast

Fri Oct 23 04:38:31 UTC 2009

> >> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?
> > You want to allow for more than one for obvious fault isolation and
> > load balancing reasons.  The draft suggested using <prefix>:FFFF::1

FWIW - I think simple anycast fits that bill.

> > I personally would suggest getting a well known ULA-C allocation
> > assigned to IANA, then use <prefix>::<protocol assignment>:1
> > <prefix>::<protocol assignment>:2 and <prefix>::<protocol
> > assignment>:3, where <protocol assignment> could be "0035" for DNS,
> > and "007b" for NTP, and if you're feeling adventurous you could use
> > "0019" for outgoing SMTP relay.

IMHO non-hex-converted port numbers works cleanly ... ?

> I thought ULA-C was dead... Did someone resurrect this unfortunate bad
> idea?

Anything is dead until someone uses it.
I was thinking FD00 just to have symmetry with anyone using ULAs today, so
FC00::/8 could be outright blocked ... ?
FC may make sense as they are, de facto, registered ...

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

Thinking further, if simply based on port#s wouldn't even need a registry.
Unless it was decided to implement the multiple-addresses-per-function
mentioned above, then perhaps useful.

> >> Easily identified, not globally routable, can be pre-programmed in
> >> implementations/applications ... ?
> > Exactly, seems easy, straight forward, robust, reliable and allows
> > for things like fate sharing and fail over.
> Why pull this out of ULA?  Why not pull it out of 0000/16 or one of
> the other reserved prefixes?

ULAs are already defined as "internally routable, but not globally routable"
- which is exactly how I would envision these being used.
IOW, seemed to make sense to me!

/TJ