Important IPv6 Policy Issue -- Your Input Requested

Mon Nov 8 22:42:43 UTC 2004

At 04:17 PM 11/8/2004, Pekka Savola wrote:

>On Mon, 8 Nov 2004, Daniel Senie wrote:
>>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.
>
>Sure, though see #3 which can be stolen for lab usage as well.

I'm not sure it's a great idea to tie these together, based on what I've 
seen in the past.

>>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.
>
>For serious usage, I don't think the money involved is a major issues.

Translation: only rich companies are entitled. Smaller businesses are not 
entitled to space, and not entitled to use IPv6. For offline use, I guess 
IPv4 will be the permanent solution.

>>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.
>
>Already done, 2001:db8::/32 is set aside for documentation.

Good.

>>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.
>
>Setting up local v6 addressing for this reason seems like a bad idea 
>because there is no NAT and no global connectivity, so the box will need 
>some automated configuration protocol in any case.

Autoconfiguration is probably not the answer to every piece of routing gear 
or every embedded system built. I guess designers will need to continue 
installing a serial port on every device to ensure there is some way to get 
into the device and configure it if autoconfiguration isn't able to conquer 
the world.