[118541] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: IPv6 Deployment for the LAN

daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Oct 23 00:07:29 2009

From: Owen DeLong <owen@delong.com>
In-Reply-To: <4AE0F223.3050000@coders.net>
Date: Thu, 22 Oct 2009 21:00:11 -0700
To: Perry Lorier <perry@coders.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Oct 22, 2009, at 5:00 PM, Perry Lorier wrote:

> trejrco@gmail.com 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  
> 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.
>
I thought ULA-C was dead... Did someone resurrect this unfortunate bad  
idea?

>
>
>> ... 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))
>>
>>
>> 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?

Owen



home help back first fref pref prev next nref lref last post