[ipv6-wg] 96 more bits... time for some magic after all?

Hi Yannis and list,

Yannis Nikolopoulos <dez at otenet.gr> writes:

> On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote:
>> Hi Roger and list,
>>
>> On Fri, Roger Jørgensen <rogerj at gmail.com> writes:
>>
>>>   Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand
>>> <bs at stepladder-it.com> wrote:
>>> What I wouldn't want to see however is that some big player gets
>>> some extra address space because they wasted their existing
>>> one. Once that happens, everyone will demand the same. 
>
> that's the second time I read this in this thread. Why would this
> happen? All allocations are subject to RIR policy

yes, but policies can be circumvented, lobbied out of the way or
overridden by legislation, as was effectively the case with the
Nortel/Microsoft deal, among others.

There used to be a policy that IP addresses can't be traded.  Take a
look at the recordings from the RIPE meeting last week to see what
happens right now.

>>> One way to waste is to give every single customer a /48 when you are
>>> really really big. /56 work just fine really, even for techies like me :)
>> Sorry, but I disagree on that.  A /56 is fine for today's requirements,
>> but if this hype about the "Internet of Things" really takes off and you
>> want to put things into different subnets, a /56 may occasionally be a
>> problem even for consumer households.  Not today, but think anything
>> from ten to fourty years.
>
> 40 years from now? Many, more significant changes will probably
> overshadow this. Otherwise, 256 different policies in a home sound
> just fine

According to Bob Kahn with exactly the same reasoning the original 6 bit
addresses in the Arpanet were widely ridiculed; pretty much the same
happened again again when they went straight for 32 bit addresses in
IPv4 (which was pretty much exactly the 40 years I mentioned ago, so
that's where I got that number from).

If you plan for future networks by today's demands, without taking into
account either some future growth nor some imminent or at least apparent
developments, like the currrent growth of networked embedded systems,
you won't make it through even the next ten years.

And considering the time it took for IPv6 to take off, even if we
started on developing its successor today, we'd have to live with IPv6
for another 25 years or more; IPv4 will likely last another five years,
making it a total lifetime of 45 years.  We might as well accept that
whatever we do today will haunt us at that long as well.

>>> There was major discussion just to get that /56 into the documents.
>>> Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing
>>> it even more. Are discussion on moving away from /64's on the wire to...
>> It's not just autoconfiguration, but when it comes to embedded
>> system/microcontroller implementations, changing that is rather
>> difficult.
>
> care to elaborate on that?

Yes, but I'd rather do that in a separate thread/with a new subject...

>>> * Somewhere else I'm using a /50 on the wire, that also work just fine.
>> Same issue.  Yes, at least some implementations support that right now,
>> but you shouldn't rely on that.  Additionally, for whoever may have to
>> run that system further later on you set up some ugly surprise that way.
>
> again, care to elaborate a bit?

Yes.  If somebody decides to remove support for a configurable subnet
prefix length, based on the fact that the RFCs mentioned below don't
allow anything but a /64 as subnet prefix, an upgrade of a system with a
differently configured subnet prefix will blow up in your face.  If this
happens because of a security hole, this leaves you the choice of either
running the vulnerable old version, or taking a (production) system down
until you've sorted out your network setup.

There are at least two valid reasons to remove support for a
configurable subnet prefix length: It adds overhead to the
implementation (again, this is particularly troublesome with
microcontrollers) and it is yet another option to frustrate end users.

As far as your possible successors as sysadmin/netadmin are concerned:
If somebody in some not-so-far-away future inherits the systems you have
set up and has to handle them, doing something that is not covered by
specifications but happens to work with some implementations, this is
quite likely to blow up in their faces---and your (former) company's,
since this is likely to cost noticeable money.  Yes, I've been down that
road in several slightly different contexts, and thinking of the trouble
it caused I consider these sorts of time bombs reason enough to sack
whoever set them up.  And no, sorry, I can't provide any more details,
except maybe that with BIND4 it was possible to put periods in DNS
labels...

As far as end users are concerned: When it comes to systems that are
operated by end users who don't understand---and shouldn't need to
understand---the internals of the stuff they use, every single
configuration options is something that at best adds, or rather
multiplies, to the number of options they have to try to get things up
and running.  This is bad for the end user as well as the vendor of the
gear, so minimizing the number of configurables is actually one of the
key measures to keep non-professional end users happy.

> How's a /50 not compliant with RFC 4291?

(One of these days I'll actually make that into a separate three-page
RFC, so people who won't or can't read 4291 can be referred to that...)

RFC 4291, page 8, section 2.5.1, for all unicast addresses except those
starting with 000b, which is currently :: and ::1, and again in

RFC 4291, page 10, section 2.5.4 (for global unicast addresses)
RFC 4291, page 11, section 2.5.6 (for link-local unicast addresses)
RFC 4193, page  3, section 3.1   (for unique-local unicast addresses)


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.        http://www.stepladder-it.com/