Important IPv6 Policy Issue -- Your Input Requested

Thu Nov 11 00:54:04 UTC 2004

First of all, as one of the proponents of ULAs in the IPv6 WG, I want to 
emphatically state that enabling IPv6 NAT was not the justification for 
ULAs.  It might make doing so easier, which is unfortunate, but there are 
lots of other reasons that justify their creation and not creating ULAs is 
unlikely to prevent IPv6 NAT anyways because, as others here have noted, 
people will do it anyway with some other address range.

The central point we kept coming back to was that local addressing of some 
sort will inevitably be used in many places, and providing a mechanism to 
prevent collisions was deemed worthwhile.

Thus spake "Daniel Senie" <dts at senie.com>
> At 02:36 PM 11/8/2004, you wrote:
>>Just out of interest, why do you think 1918-style space for v6 is needed?
>
> Well, you asked the original poster, but since you asked publicly, I'll 
> answer with my reasons.
>
> Reason #1: Lab use. People should NEVER, EVER pick random space from 
> public > space for doing experiments in the lab. Sooner or later something 
> leaks, and people get really honked off. This happened a LOT with IPv4, 
> prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make 
> sure people have a specific place to get address space from for 
> experiments.

I don't think this use ever came up, but it makes sense.

> Reason #2: Disjoint networks: though we may think the only reason to use 
> the IP protocol suites (v4 or v6) is to connect to other places in the 
> world, there are networks which do not (or are at least not supposed to) 
> intersect with the public Internet. Address allocation policies are based 
> on what space you're going to advertise, and registries want money for the 
> space. Networks that are not connected should be able to use the IP 
> protocol suites too.

This was a big motivator.  Disjoint or occasionally-connected networks need 
an address pool that is guaranteed to work within their own domain.  Even if 
PI space were made available, that involves time, money, paperwork, etc. for 
people who currently don't have to deal with that when using RFC1918.

> Reason #4: Initial configuration of equipment which lacks a console port. 
> I know, you're going to suggest the use of autoconfiguration mechanisms or 
> DHCP. That's sometimes hard, for example in the case of a broadband 
> "router" (home gateway) box that's going to be the DHCP server, print 
> servers, and other such equipment. Having some block for this (or just use 
> some subnet of the RFC-1918-like space) is a reasonable use.

IMHO, link local addresses should be used for this.

Reason #5:  Thanks to prefix delegation, unavailability of PI addresses, 
etc. global addresses are viewed as "unstable".  The current IPv6 
multihoming model says that prefixes for each connection should be 
distributed and assigned to hosts throughout the domain; these prefixes may 
come and go as those connections go up and down, disrupting internal-only 
communication.  Not acceptable.

Reason #6:  Many enterprises will want "internal-only" resources that never 
get assigned a global address, and ULAs fit this need well.  Sure, we all 
know that this isn't true security, but it's a lot easier to simply block 
all ULAs at your border than to maintain lists of specific subnets out of 
your globals that should not talk to the outside world.  Less maintenance 
means fewer errors and thus fewer leaks and security goofs.

Reason #7:  Following on to that, some companies elect to not assign PA 
addresses internally for any hosts, requiring them to go through proxies for 
any external access.  Some use PI for this today, others use RFC1918, but 
since neither option is available in IPv6 they would use ULAs for this.

Reason #8:  Many companies need addresses to communicate with business 
partners privately and using global addresses complicates (and thus 
introduces human errors into) routing, ACLs, DNS, etc. when those globals 
are reached via a link other than their default route.  This is currently a 
mess with RFC1918 addresses because each pair of companies must negotiate 
range(s) of addresses that aren't already in use in either network; N 
companies will have O(N^2) negotiations, which clearly doesn't scale.

In closing, I'll note that the nature of the central registry was criticized 
no matter what was proposed; what is in the draft now is the least 
objectionable of what was floated, and it did survive consultation with the 
existing RIRs.  I can't recall if a home was indeed found for it already, 
but there were several offers of organizations willing to provide the 
service at no cost, which is how that ended up in the draft.  The central 
registry was split off from the main draft because it's not clear that 
consensus was achieved on that element and the chairs didn't want to hold up 
the rest of the draft.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 