[75186] in North American Network Operators' Group
Re: Important IPv6 Policy Issue -- Your Input Requested
daemon@ATHENA.MIT.EDU (Daniel Senie)
Mon Nov 8 17:48:28 2004
Date: Mon, 08 Nov 2004 17:42:43 -0500
To: Pekka Savola <pekkas@netcore.fi>
From: Daniel Senie <dts@senie.com>
Cc: nanog@merit.edu
In-Reply-To: <Pine.LNX.4.61.0411082314130.23653@netcore.fi>
Errors-To: owner-nanog-outgoing@merit.edu
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.
