On Wed, 21 Apr 2010 01:46:47 -0400 Daniel Senie <dts@senie.com> wrote:
I see a need for stable, permanent blocks of addresses within an organization. For example, a branch office connecting to a central office over VPN: firewall rules need to be predictable. If the branch office' IPv6 block changes, much access will break. This is directly analogous to how RFC1918 space is used today in such environments.
There is a need to have organizations be able to either self-assign or RIR-assign space that they own and can use without trouble within their network. That address space need not be routable on the public networks.
In general I think this draft has merit.
Unique Local Adresses, of which the linked draft is specifying a subset, were specified in RFC4193, published in October 2005. They meet all the requirements you've stated. You might also want to have a look at RFC3879, "Deprecating Site Local Addresses" for the reasons why IPv6 Site Local addresses, the direct IPv6 equivalent of RFC1918 addresses, were deprecated. Many of the reasons provided also apply to using IPv4 RFC1918 addresses. This draft is about a centralised registry for one half of the ULA space. It is debatable whether it is necessary, as ULAs shouldn't leak out of a site using them. The major concern is that if they are globally registered, then some people will start believing that they can use them as global addresses, and start demanding other parties such as their ISP or IXes route them, instead of getting proper global addresses for that purpose. As an example of the risks, an informal registry for non-central ULAs has been created at sixxs.net. As a single ULA /48 should be enough for most organisations, looking at the list, it seems that some people are already attempting an addressing 'land grab'. I can't even reach the website of one of the people who as registered 7 /48s. It's a bit hard to believe he has a large enough network to need 458 752 subnets ... http://www.sixxs.net/tools/grh/ula/list/ I think the fact that people have listed them there also means that they now think they now globally 'own' those addresses, and should there be a (very unlikely) collision, would argue that the address space was theirs first and point to that list. While duplicated ULAs shouldn't happen, it shouldn't matter if it does, unless those two organisations want to interconnect directly. ULAs are meant to be stable addressing for inside of your network. They are not meant to be leaked outside your network under most circumstances. The only time routes for your ULA address space may appear outside of your network is if you have a direct link to another organisation (i.e. a backdoor link), and you want to avoid using your Internet transit to reach them and vice-versa. In BGP terms, when you announce some of your ULA address space to the other organisation, you'd attach a NO_EXPORT community. Regards, Mark.