Re: IPv6 Deployment for the LAN ... anycast

[Owen DeLong <owen () delong com>]

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