On Oct 23, 2009, at 5:45 AM, TJ wrote:
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 device.
Anycast isn't really hard - same address, multiple places, routers
see what
appear to be multiple routes to same destination, they choose the
least
expensive. Only tricky part (for stateless things) is ensuring the
route
announcement is implicitly tied to service availability on that
device ...
Please remember that IPv6 DNS is OFTEN not stateless as the replies
are commonly too large for UDP.
There are some protocols that anycasting doesn't work well for,
they may
require multiple instances.
Fair enough; could also standardize something like FD00::<port
number>,
FD00::1:<port number>, and FD00::2:<port number> ... is three
addresses
enough? (IIRC, the Site-Local based automagic DNS used 2 or three
addresses
... )
That's what I meant by prefix::<inst:ance>:<serv:ice>
<instance> would be a 32-bit instance value and <service> would be a
32 bit
service value (probably port number in the low order bits initially).
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.
OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] -
reserving FD00::/96) covers us to port 9999 based on automatically
using
port numbers (or using automatically registered port numbers, see
below).
Why use the non-hex converted? Is it really hard to realize that 0x35
= 53?
Maybe FD00::FFFF:xxxx/112 as a block within the above range to be
used for
manual assignment of automatic service (potentially anycast)
addresses.
... 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.
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).
OK, so register them - but sign up some well-known ones at very
comfortable
addresses, like DNS at 53 :).
(Or 35 if you prefer hex-conversion ...)
And I am sure some would be concerned about hosts performing any
sort of
automatic service discovery anything, but this atleast has the
advantage
over multicast in that it doesn't require multicast routing or group
membership / state maintenance, only delivers packets to the nearest
(not
all) instances, etc.
Agreed, but, since this mostly doesn't get typed by humans, I think
that using
0x35 is much better in this case than using 0x53 -> 53 stuff.
Owen
