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: Daniel Senie
  • Date: Mon Nov 08 16:09:20 2004 
At 02:36 PM 11/8/2004, you wrote:



On 8 Nov 2004, at 14:25, Leo Bicknell wrote:


   In the end I think we need 1918 style space, and that it should
   simply be set aside as a large block and expected to never be
   useful in the context of other organizations, just like 1918
   space is today.

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.

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.

Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside.

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.