North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Important IPv6 Policy Issue -- Your Input Requested

  • From: Stephen Sprunk
  • Date: Wed Nov 10 20:19:21 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" <[email protected]>
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