Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

[Fred Baker <[e-mail]>]

Well, since the draft has expired...

On Dec 8, 2010, at 4:36 PM, Behcet Sarikaya wrote:

> 
> 
>> 
>> I believe these  recommendations are good for the "basic requirements" document 
>> under  >discussion.  When adequate solutions to the problems described in  
>> I-D.ietf-6man-addr-select-sol are commonly deployed and readily available,  
>> *then*-- and only then-- should IETF >consider revising these recommendations to  
>> allow for use of ULA prefixes when no globally > routable prefix is  available.  
>> 
> 
> 
> I could not find anything related to ULAs, site-local and the like in
> http://tools.ietf.org/id/draft-ietf-6man-addr-select-sol-03.txt.
> ?
> Which section or document are you referring to?

I think the key paragraph from RFC 3483 would be:

   The algorithms use several criteria in making their decisions.  The
   combined effect is to prefer destination/source address pairs for
   which the two addresses are of equal scope or type, prefer smaller
   scopes over larger scopes for the destination address, prefer non-
   deprecated source addresses, avoid the use of transitional addresses
   when native addresses are available, and all else being equal prefer
   address pairs having the longest possible common prefix.  For source
   address selection, public addresses [3] are preferred over temporary
   addresses.  In mobile situations [8], home addresses are preferred
   over care-of addresses.  If an address is simultaneously a home
   address and a care-of address (indicating the mobile node is "at
   home" for that address), then the home/care-of address is preferred
   over addresses that are solely a home address or solely a care-of
   address.

If I have several prefixes (and therefore several addressees) and/or my peer does, then I take the cross-product of the sets. For each address pair, the first N bits, for some value of N >= 0, are the same. I count how many bits there are in the common prefix.

For example: if I have addresses

       FD00:1234:5678:9ABC:whatever/128
       2001:0DB8:5678:9ABC:whatever/128
and    2002:1234:5678:9ABC:whatever/128

and my peer has addresses

       FD00:1234:5670::whatever/128
and    2001:0DB8:0678::whatever/128

my ULA and his match in the first 44 bits, my 2001:: address matches his in the first 33 bits, and in all other cases the match is pretty short, on the order of 0..16 bits. The matching algorithm suggests that I try ULA to ULA, as that is the longest match, and if that fails, try 2001:0DB8:5678:9ABC:whatever to 2001:0DB8:0678:9ABC:whatever. What the tables would try to dissuade me from is various forms of translation such as 6to4 etc if I can avoid it.

Where knowing about a ULA could be of value is in funny situations. Imagine if you will that I have two LANs within a ULA and therefore within my own network, but they differ in bit 48 (the most significant bit of the subnet field), and I also have a /56 prefix from my provider. Regardless of how I number the subnets within the /56, the global address prefix will match in at least the first 56 bits, but the ULA will match in only the first 48. So I will try the global address first. There is a line of reasoning that says I should try the ULA instead; if my administration buys into that line of reasoning, it's going to have to play with my RFC 3484 tables to over-ride the longest-match rule.