IPv6 Deployment for the LAN ... anycast

[owen at delong.com (Owen DeLong)]

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