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