Real world use for the U/L bit?

Brian E Carpenter brian.e.carpenter at gmail.com
Mon Nov 15 01:09:32 CET 2010


George,

The u/l bit is quite orthogonal to ULA prefixes.

I fully agree that ULA prefixes are for local use, by definition.
For example, number your printers and and other devices like that
out of a ULA prefix, and you will never need to change them even if
your ISP changes your main prefix. This makes good use of IPv6's
ability to run with several simultaneous prefixes.

There's considerable discussion of using ULAs in RFC 4864.

Regards
   Brian Carpenter

On 2010-11-15 12:14, George Bonser wrote:
>> This was in the hope of a multihoming solution that would avoid PI
>> prefixes.
>> That is still an active hope.
> 
> Note that anyone affiliated with a provider is going to push back like crazy against any sort of ULA.  This is because they are going to see that as the nose of the NAT camel nudging under the tent of their customers (and potentially their own).
> 
> 
> If one is going to use ULA, I would *strongly* recommend that you use the suggested algorithm and generate a random network to use.  While this would not *guarantee* a collision should you attempt to route traffic to another entity such as through a VPN but it would greatly reduce the chances of it.
> 
> If anyone is going to use ULA, I would also suggest the following and make it part of your official policy:
> 
> 1.  *Never* and I mean *never ever* expect that address space to be NATed to global unique space.  If you decide to use ULA, do so with no expectation that those addresses will ever be used to communication with the global Internet.  In fact, I would only do it on networks that are not routed at all.
> 
> 2.  Generate your subnets using the random generation method.  Do not grab "blocks" of them, get random /48 subnets.  Don't worry about attempting to aggregate /48's into larger subnet spaces.  You can use a tool such as this one to generate your subnets: http://www.sixxs.net/tools/grh/ula/  and you can enter the ones you have generated in their "registration" database but be advised that all that registration database is going to do is *potentially* reduce collisions with others using the same tool.  It doesn't not mean that someone else isn't going to end up using that same space, but again, it reduces the chances of that happening.  In other words, it doesn't guarantee anything but it doesn't hurt anything, either, to place the subnets you generated into that database.
> 
> 3. *Never* and I mean *never ever* expect that your ULA subnets are going to be unique and will never collide with someone else's space.  You can greatly decrease the probability of a collision with another organization but you cannot guarantee it with this method.  That is why it is called Unique *Local* Addressing.  The only thing you can guarantee with absolute certainty is that you would not collide internally within your own network.
> 
> There is really little reason to use it (ULA) anyway.  Getting v6 space is going to be pretty easy.  If you run out of subnets, just go get some more v6 address space.  The only place I can see any utility for ULA is in networks that absolutely positively under no circumstances ever communication with anyone for any reason outside the organization.  I have a couple of candidates to run it in my network, flat subnets that interconnect servers but have no layer 3 routing on them.  They would use ULA because some of these servers have more than one of these subnets carrying different sorts of traffic so link local only is not an option.
> 
> I would avoid ULA wherever possible.  Conservation of subnets is not currently an issue nor do I see it being an issue for the next century or so.
> 
> 



More information about the ipv6-ops mailing list