Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

[Mark Smith <[e-mail]>]

On 10 Aug. 2017 15:58, "Gert Doering" <[e-mail]> wrote:

Hi,

On Thu, Aug 10, 2017 at 11:24:48AM +1000, Mark Smith wrote:
> > And yes, I think this is extremely wastive, well over the limits of what
> > is normal "do not care about wasting addresses!" level of IPv6 normal.
>
> So it's worth considering what the word "waste" means. It means
> getting no value at all from some quantity of a resource. That
> quantity of resource isn't being used for anything of value to the
> resource's user.

Waste can also mean "I have used up something without actually needing
it, and now it's missing somewhere *else*".



Do we have to purposely make something hard and costly to use before we can
make it easy and cheap to use? Do we have to treat IPv6 addresses like
diamonds, before eventually accepting the *maths* that shows they're at
least as common as grains of sand.



[..]
> > Should this topic come up in RIPE policy discussion, I'll chair the
> > discussion and refrain from having an opinion, but will reserve the
right
> > for a "told you so" later.
>
> I assume RIPE give out /32s as the minimum to an ISP, or 4+ billion
> /64s? If an ISP isn't giving out at least /56s to customers, the
> problem isn't with the /64 boundary, it is the ISP carrying IPv4
> address scarcity management practices over to IPv6 where they aren't
> needed.

So how useful is a /56 to a customer if the customer wants to do
/64-per-host?

If it's /64-per-LAN, a /56 is a useful value, but for /64-per-Host it's
all of a sudden becoming tight for slightly larger customer sites.


/56 entirely inappropriate for slightly larger sites. Give them a /48. If
an ISP thinks they can't get bigger than a /32 from their RIR, or that they
have to squeeze everything into a /32 "because it is so large and therefore
that's all I'll ever be able to justify getting", they need to be corrected.


> We are wasting our time (getting no value from it) trying to
> accommodate unneeded IPv4 practices carried over to IPv6. We end up
> trying to make things accommodate more and more perverse and
> unnecessarily conservative IPv4 carried over practices. If we
> accommodate them, we're also tacitly endorsing them.

I could point out that "a /64 everyhwere" is repeating the "Class A, B, C"
mistakes from IPv4.


Classes weren't a really a mistake. They were a workaround for not having
enough address bits and not being able to easily change the number of
address bits.

IP addresses went through many format and size changes between 1974 ("A
Protocol for Packet Network Intercommunication") and 1978 before 32 bits
was chosen as the fixed address size in September of 1978 (IEN54), with a
format of 8 bit network number and 24 bit hosts i.e. N.H.H.H. (There were
two different attempts at having variable length addresses that were
abandoned, RFC675 and IEN21.)

That persisted until RFC791, in September of 1981, where Class A, B, C, D
and E address types were introduced. Also at that time, show in RFC790,
there were already 42 what would now become "Class A" network numbers
assigned. So there was at least 3 years of happy and successful operation
with a simple N.H.H.H address format (i.e., no complexity due to classes,
subnets, subnet masks or prefix lengths) between IEN54 and RFC791.

I've called classes, subnets, CIDR etc. a series of neat hacks to get
around the 32 bit address space limit. At the time I asked Vint Cerf for
some more context.

https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html

"Date: Sat, 3 Apr 2010 08:17:28 -0400
From: Vint Cerf <vint at google.com>
To: Mark Smith
<nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Cc: Andrew
Gray <3356 at blargh.com>, NANOG List <nanog at nanog.org> Subject: Re:
legacy /8


When the Internet design work began, there were only a few fairly large
networks around. ARPANET was one. The Packet Radio and Packet Satellite
networks were still largely nascent. Ethernet had been implemented in
one place: Xerox PARC. We had no way to know whether the Internet idea
was going to work. We knew that the NCP protocol was inadequate for
lossy network operation (think: PRNET and Ethernet in particular). This
was a RESEARCH project. We assumed that national scale networks were
expensive so there would not be too many of them.  And we certainly did
not think there would be many built for a proof of concept. So 8 bits
seemed reasonable. Later, with local networks becoming popular, we
shifted to the class A-D address structure and when class B was near
exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but
perhaps others also) came up with CIDR and the use of masks to indicate
the size of the "network" part of the 32 bit address structure. By 1990
(7 years after the operational start of the Internet and 17 years since
its basic design), it seemed clear that the 32 bit space would be
exhausted and the long debate about IPng that became IPv6 began. CIDR
slowed the rate of consumption through more efficient allocation of
network addresses but now, in 2010, we face imminent exhaustion of the
32 bit structure and must move to IPv6.

Part of the reason for not changing to a larger address space sooner
had to do with the fact that there were a fairly large number of
operating systems in use and every one of them would have had to be
modified to run a new TCP and IP protocol. So the "hacks" seemed the
more convenient alternative. There had been debates during the 1976
year about address size and proposals ranged from 32 to 128 bit to
variable length address structures. No convergence appeared and, as the
program manager at DARPA, I felt it necessary to simply declare a
choice. At the time (1977), it seemed to me wasteful to select 128 bits
and variable length address structures led to a lot of processing
overhead per packet to find the various fields of the IP packet format.
So I chose 32 bits.

vint"


People who believe IPv4 addressing that we have today is an ideal that we
should be aiming for in IPv6 are probably unlikely to be aware of IPv4
history of addressing evolution, or the research or proof-of-concept
network context it was originally designed and chosen for. IPv6 is really
the first true Internet protocol, and should not be artificially inhibited
by the legacy of IPv4's design context, practices, constraints and
workarounds.


Regards,
Mark.