IPv6 Deployment for the LAN ... anycast
perry at coders.net
Fri Oct 23 12:25:33 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 think for very small/small networks anycast requires a lot of overhead
and understanding. If your big enough to do anycast and/or
loadbalancing it's not hard for you to put all three addresses onto one
There are some protocols that anycasting doesn't work well for, they may
require multiple instances.
>>> 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 ... ?
Up to 9999, if you want to announce a service port 30,000 you're in
trouble. Also quite a few protocols don't have "well known" ports, so
may want to get things assigned. If you're doing assignment you could
do nice things like 0x53 for DNS and then ports >9999 and protocols that
don't have "well known" ports could get an unused one assigned to them.
>>>> ... 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
> 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.
In my humble opinion I'd have them registered, linking them to port
numbers means that it's easier on the poor admins brain at 3am while
diagnosing faults, but may cause various hassles in the future (see above).
More information about the NANOG