Subject: The bottom is /112 (was: RE: Extending a /64)

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 16 Nov 2020 16:30:50 +0000

New thread just to make sure this simple assertion is not lost. I hereby declare
"the bottom" to be /112. That gives a 112-bit "network part" and a 16-bit "host
part". That is as many addresses as an old-fashioned IPv4 "class-B", and it also
parallels the number of transport port numbers available in a 16-bit UDP/TCP
port number space, so it is also good for multi-addressing.

I think /112 is good for now and for all time - with the exception of /127 for
P2P links, of course. Agreed?

Fred

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 16 Nov 2020 10:37:00 -0600

> P2P links, of course. Agreed?
Yes :)

Behcet

> Fred
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Nov 2020 17:38:28 +0100

> P2P links, of course. Agreed?

I do not oppose that.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 16 Nov 2020 16:47:23 +0000

OK, so now that we have raced to the bottom we need to ask what we are giving up?
IMHO, there will still be use cases for RFC4941(bis) where we will still want to stop
at /64. In those cases, RFC6177 still applies and our aviation world is one example.

Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Monday, November 16, 2020 8:38 AM
> To: [email-masked]
> Subject: Re: The bottom is /112 (was: RE: Extending a /64)
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2020 17:50:44 +0100

>P2P links, of course. Agreed?

For SLAAC, /112 is way underground. To keep collisions to a reasonable level,
a SLAAC prefix cannot be longer than /80 but /76 would be preferred.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Nov 2020 17:55:11 +0100

> OK, so now that we have raced to the bottom we need to ask what we 

The more we race to the bottom, the longer the search algorithm at the
edges takes to forward a packet.  It's unfortunate for these low
capability devices at the edges to have to scan so deep into a prefix,
whereas their counterparts in the DFZ are more powerful and have shorter
prefixes to look at.

But that's because how IP routing works.  And I will not propose to
change it.

Were short prefixes at the edges and long prefixes in the core, then it
would be different.

>> IMHO, there will still be use cases for RFC4941(bis) where we will
>> still want to stop at /64. In those cases, RFC6177 still applies
>> and our aviation world is one example.

Well I tend to agree with the part that still these RFCs apply, but I 
dont see how the aviation world applies.

I still have to see a passenger airplane on IPv6, or offering IPv6 to 
passengers.

Alex

> 
> Fred
> 
>> -----Original Message----- From: ipv6 
>> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu 
>> Sent: Monday, November 16, 2020 8:38 AM To: [email-masked] Subject: 
>> Re: The bottom is /112 (was: RE: Extending a /64)
>> 
>> 
>>> New thread just to make sure this simple assertion is not lost.
>>> I hereby declare "the bottom" to be /112. That gives a 112-bit 
>>> "network part" and a 16-bit "host part". That is as many 
>>> addresses as an old-fashioned IPv4 "class-B", and it also 
>>> parallels the number of transport port numbers available in a 
>>> 16-bit UDP/TCP port number space, so it is also good for 
>>> multi-addressing.
>>> 
>>> I think /112 is good for now and for all time - with the 
>>> exception of /127 for P2P links, of course. Agreed?
>> 
>> I do not oppose that.
>> 
>> Alex
>> 
>>> 
>>> Fred
>>> 
>>> 
>>> [email-masked] Administrative Requests: 
>>> https://www.ietf.org/mailman/listinfo/ipv6 
>> IETF IPv6 working group mailing list [email-masked] Administrative 
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Nov 2020 08:43:40 +1300

> a SLAAC prefix cannot be longer than /80 but /76 would be preferred.

Also for privacy/guessability reasons, /112 is totally unacceptable. The original (RFC1884) /80 is probably OK from that point of view. However, the privacy argument for /64 will only strengthen over time.

I find this whole conversation hallucinatory, as if the last 25 years had never happened.

   Brian

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 16 Nov 2020 15:16:46 -0500

On Mon, Nov 16, 2020 at 2:43 PM Brian E Carpenter <
[email-masked]> wrote:

> Also for privacy/guessability reasons, /112 is totally unacceptable. The
> original (RFC1884) /80 is probably OK from that point of view. However, the
> privacy argument for /64 will only strengthen over time.
>
> To Brian's point, and as I mentioned in one of the several other threads
on this topic, RFC 8065 makes an argument for at least 46 and preferably
59 bits of host address length in designs where address scanning is likely.

Kerry

---

From: 神明達哉 <[email-masked]>
Date: Mon, 16 Nov 2020 13:06:47 -0800

At Tue, 17 Nov 2020 08:43:40 +1300,

> I find this whole conversation hallucinatory, as if the last 25 years had never happened.

This thread is awkward to me, too.  I don't deny the possibility of
lowering "the bottom" in future, but I'd expect it can only happen
after very careful and probably heated discussions, followed by quite
a long period of experiments and transition.  On the other hand this
thread looks like it can be so casually tweaked just at the whim of
someone for whom the lower bottom is convenient.  If it were that easy
we wouldn't have had the very long (and still unresolved) discussions
triggered by draft-bourbaki-6man-classless-ipv6.

I see some real issue in the original "Extending a /64" thread that
we (the wg) should work on; this /112 thread just seems to be
a distraction and time wasting (so I'll refrain from contributing to
it further).

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Nov 2020 08:11:26 +1100

> P2P links, of course. Agreed?

How would you have solved this problem if IPv6 addresses were 64 bits in
size?

That was the original proposal, and it was considered large enough to solve
the next generation Internet protocol problem. See RFC8507.

The only reason addresses were made 128 bits was that so all IPv6 node
interfaces could have single size 64 bit interface identifiers. See RFC7421.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 16 Nov 2020 19:00:27 -0500

> P2P links, of course. Agreed?

I love it!!!!

   I agree as well that /112 providing the additional 48 bits network part
and helps further extend the current 2000::/3.  In the v6ops deck I sent
this morning this very race to the bottom it really helps serve two
purposes.

In the context below of wearable /48 end site allocation in the future with
5G Enhanced VPN framework network slicing concept, I could see maybe
multiple /48 per human in future for sure.

How do we get there??  Good question and Fred helped kindly shed some light
on how that is possible with the aviation scenario.

Firstly due to blockwise IPv6 allocation process and how the internet works
as far as allocations IANA -RIR-ISP-End host, the issue exists as I stated
in the v6ops slide deck we will review on Thursday and now precursor on ML,
that even if we want to give a /48 to all users it’s is not possible for
operators like Verizon.  Here is the problem - A /24 yields 11.6M and /20
160M and Verizon have today 150M 3GPP subscribers today and would like 1B
or even 7B worth of space for future growth with network slicing enhanced
capabilities but not just Verizon - all large providers.

So the extending the network prefix 48 bits would solve that issue and
allow the Verizon’s of the world to be able to make /48s a wearable space
and site allocation by making /112 the official new bottom, thereby
changing the fixed boundary to /112.

On the other side of that it resolves the Day 17 year interoperability
issue that exist with vlsm as now operators can have mix of dhcpv6 stateful
and static hosts on the same subnet as slaac hosts up to /112.

>From a privacy standpoint we lose 16 bits of heuristic as far as privacy
now having 48 bit IID instead of 64.  Now modified EUI64 mac or random
would not support the 64 bit fixed boundary and a new 48 bit fixed boundary
would be established.

As far as shorter 16  bit IID for privacy extension RFC 4941 would still
work but just now would be a random 16 bit IID with slightly much less
heuristics for privacy.

As far as stable random IID camp  48 bit stable RFC 7217 would still work
as well but now just 16 bit heuristics for privacy.

The privacy issue has always been a double edged sword so is a win win for
operators and Law Enforcement tracking offenders committing cover crimes
now being able assist with scanning capabilities but also gives the end
user enough heuristics for privacy to protect against sophisticated
criminals.

Also the added benefit as it eliminated and now permanently solved and
gives path forward for operators using vlsm can now support prefix length
down to /112.  That adds tremendous value for operators in the world we
live in today as vlsm is the real reality for operators and is not a corner
case bubble as some may think.

And of course solves the aviation issues.  There maybe others similar
situations that may arise that you have to address every human and due to
the blockwise allocation schema trickle down from IANA 2000::/3 way down
 to the end site by the time it gets to the end site it’s not quite 135
trillion.

I think the first step is that we all agree with the multiple layers of
problems we are trying to solve related to the existing 64 bit fixed
boundary.

Once we agree with all the issues and I would say with 5G and network
slicing being able to have in reality wearable multiple /48s which could be
in reality the future we have to extend the prefix length.

There are tradeoffs and the big one is privacy but if we can get a
consensus and a balance on ML before the Thursday v6ops call would be
great!!!

Here are the 16 bit boundary options to make it simpler and then if we want
to hone further in byte boundary or nibble we can.

For me I think /80 could solve a lot of problems but I think a /96 would be
a middle of the road happy medium that keeps the double edged sword camps
happy  Camp 1 -operators and law enforcement for scanning shorter IID Camp
2 - end user privacy

/64 - current
/80 - end user privacy camp
/96 - middle of the road
/112 - operator camp

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 16 Nov 2020 19:16:25 -0500

Sorry fixing some typos on the IID length with /112 would be 16 bits.

See below updated text

I love it!!!!

>From a privacy standpoint we lose 16 bits of heuristic as far as privacy
now having 16 bit IID instead of 64.  Now modified EUI64 mac or random
would not support the 64 bit fixed boundary and a new 16 bit fixed boundary
would be established which would use random IID generation schemes,

As far as stable random IID RFC 7217 would still work as well but now just
16 bit heuristics for privacy.

And of course solves this aviation issues.  There maybe others similar
situations that may arise due to 5G network slicing capabilities that you
have to address every human and due to the blockwise allocation schema
trickle down from IANA 2000::/3 way down  to the end site by the time it
gets to the end site it’s not quite 135 trillion.

I think the first step is that we all agree with the problems we are trying
to solve related to the existing 64 bit fixed boundary and that we all
agree the the problems even if you agree with some but not all you are
willing to change it.

 I would say with 5G and network slicing being able to have in reality
wearable multiple /48s which could be in reality the future we have to
extend the prefix length to a new bottom to make that possible.

For me I think /80 could solve a lot of problems but I think a /96 would be
a middle of the road keeping a happy medium that keeps the double edged
sword camps happy  — Camp 1 -operators and law enforcement for scanning
shorter IID Camp 2 - end user privacy

/64 - current

Kind Regards

Gyan

On Mon, Nov 16, 2020 at 7:00 PM Gyan Mishra <[email-masked]> wrote:

> In the context below of wearable /48 end site allocation in the future
> with 5G Enhanced VPN framework network slicing concept, I could see maybe
> How do we get there??  Good question and Fred helped kindly shed some
> light on how that is possible with the aviation scenario.
>
> Firstly due to blockwise IPv6 allocation process and how the internet
> works as far as allocations IANA -RIR-ISP-End host, the issue exists as I
> stated in the v6ops slide deck we will review on Thursday and now precursor
> on ML, that even if we want to give a /48 to all users it’s is not possible
> for operators like Verizon.  Here is the problem - A /24 yields 11.6M and
> /20 160M and Verizon have today 150M 3GPP subscribers today and would like
> 1B or even 7B worth of space for future growth with network slicing
> enhanced capabilities but not just Verizon - all large providers.
>
> Here are the 16 bit boundary options to make it simpler and then if we
> want to hone further in byte boundary or nibble we can.
>
> For me I think /80 could solve a lot of problems but I think a /96 would
> be a middle of the road happy medium that keeps the double edged sword
> camps happy  Camp 1 -operators and law enforcement for scanning shorter IID
> Camp 2 - end user privacy
>
> /64 - current

*Gyan Mishra*

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Nov 2020 12:19:43 +1100

Do you realise the current unicast address space is only 1/8th of the total
IPv6 address space? With multicast taking up another 1/8th, and a some
other things outside of that e.g. ::1, ULA, we have at least 6/8ths of the
IPv6 address space available for more unicast address space should 2000::/3
run out.

---

From: Fred Baker <[email-masked]>
Date: Mon, 16 Nov 2020 18:42:30 -0800

Yes, that’s true. I don’t think it’s news, however.

Sent using a machine that autocorrects in interesting ways...

> On Nov 16, 2020, at 5:20 PM, Mark Smith <[email-masked]> wrote:
> 
> 
> Do you realise the current unicast address space is only 1/8th of the total IPv6 address space? With multicast taking up another 1/8th, and a some other things outside of that e.g. ::1, ULA, we have at least 6/8ths of the IPv6 address space available for more unicast address space should 2000::/3 run out.
> 
> 
> 
>>> On Mon, Nov 16, 2020 at 11:31 AM Templin (US), Fred L <[email-masked]> wrote:
>>    I agree as well that /112 providing the additional 48 bits network part and helps further extend the current 2000::/3.  In the v6ops deck I sent this morning this very race to the bottom it really helps serve two purposes.  
>> 
>> In the context below of wearable /48 end site allocation in the future with 5G Enhanced VPN framework network slicing concept, I could see maybe multiple /48 per human in future for sure.
>> 
>> How do we get there??  Good question and Fred helped kindly shed some light on how that is possible with the aviation scenario.
>> 
>> Firstly due to blockwise IPv6 allocation process and how the internet works as far as allocations IANA -RIR-ISP-End host, the issue exists as I stated in the v6ops slide deck we will review on Thursday and now precursor on ML, that even if we want to give a /48 to all users it’s is not possible for operators like Verizon.  Here is the problem - A /24 yields 11.6M and /20 160M and Verizon have today 150M 3GPP subscribers today and would like 1B or even 7B worth of space for future growth with network slicing enhanced capabilities but not just Verizon - all large providers.  
>> 
>> So the extending the network prefix 48 bits would solve that issue and allow the Verizon’s of the world to be able to make /48s a wearable space and site allocation by making /112 the official new bottom, thereby changing the fixed boundary to /112.
>> 
>> 
>> On the other side of that it resolves the Day 17 year interoperability issue that exist with vlsm as now operators can have mix of dhcpv6 stateful and static hosts on the same subnet as slaac hosts up to /112.
>> 
>> From a privacy standpoint we lose 16 bits of heuristic as far as privacy now having 48 bit IID instead of 64.  Now modified EUI64 mac or random would not support the 64 bit fixed boundary and a new 48 bit fixed boundary would be established.
>> 
>> As far as shorter 16  bit IID for privacy extension RFC 4941 would still work but just now would be a random 16 bit IID with slightly much less heuristics for privacy.
>> 
>> As far as stable random IID camp  48 bit stable RFC 7217 would still work as well but now just 16 bit heuristics for privacy.
>> 
>> The privacy issue has always been a double edged sword so is a win win for operators and Law Enforcement tracking offenders committing cover crimes now being able assist with scanning capabilities but also gives the end user enough heuristics for privacy to protect against sophisticated criminals.
>> 
>> Also the added benefit as it eliminated and now permanently solved and gives path forward for operators using vlsm can now support prefix length down to /112.  That adds tremendous value for operators in the world we live in today as vlsm is the real reality for operators and is not a corner case bubble as some may think.  
>> 
>> And of course solves the aviation issues.  There maybe others similar situations that may arise that you have to address every human and due to the blockwise allocation schema trickle down from IANA 2000::/3 way down  to the end site by the time it gets to the end site it’s not quite 135 trillion.
>> 
>> I think the first step is that we all agree with the multiple layers of problems we are trying to solve related to the existing 64 bit fixed boundary.
>> 
>> Once we agree with all the issues and I would say with 5G and network slicing being able to have in reality wearable multiple /48s which could be in reality the future we have to extend the prefix length.
>> 
>> There are tradeoffs and the big one is privacy but if we can get a consensus and a balance on ML before the Thursday v6ops call would be great!!!
>> 
>> Here are the 16 bit boundary options to make it simpler and then if we want to hone further in byte boundary or nibble we can.
>> 
>> For me I think /80 could solve a lot of problems but I think a /96 would be a middle of the road happy medium that keeps the double edged sword camps happy  Camp 1 -operators and law enforcement for scanning shorter IID Camp 2 - end user privacy 
>> 
>> /64 - current 
>> Gyan Mishra
>> Network Solutions Architect 
>> M 301 502-1347
>> 13101 Columbia Pike 
>> Silver Spring, MD
>>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 16 Nov 2020 23:44:11 -0500

Yep well aware here is the link.  I pinged Jordi to see if there are any
rumblings of releasing more blocks as their ar 5 more /3 enough for 1  per
RIR.

https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

On Mon, Nov 16, 2020 at 8:19 PM Mark Smith <[email-masked]> wrote:

> Do you realise the current unicast address space is only 1/8th of the
> total IPv6 address space? With multicast taking up another 1/8th, and a
> some other things outside of that e.g. ::1, ULA, we have at least 6/8ths of
> the IPv6 address space available for more unicast address space should
> 2000::/3 run out.
>
>
>
>>    I agree as well that /112 providing the additional 48 bits network
>> part and helps further extend the current 2000::/3.  In the v6ops deck I
>> sent this morning this very race to the bottom it really helps serve two
>> purposes.
>>
>> The privacy issue has always been a double edged sword so is a win win
>> for operators and Law Enforcement tracking offenders committing cover
>> crimes now being able assist with scanning capabilities but also gives the
>> end user enough heuristics for privacy to protect against sophisticated
>> criminals.
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>

*Gyan Mishra*

---

From: Joe Maimon <[email-masked]>
Date: Tue, 17 Nov 2020 11:40:54 -0500

Class E syndrome

Mark Smith wrote:
> total IPv6 address space? With multicast taking up another 1/8th, and 
> a some other things outside of that e.g. ::1, ULA, we have at least 
> 6/8ths of the IPv6 address space available for more unicast address 
> space should 2000::/3 run out.
>
>
>
> On Tue, 17 Nov 2020, 11:01 Gyan Mishra, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Mon, Nov 16, 2020 at 11:31 AM Templin (US), Fred L
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         16-bit UDP/TCP
>        I agree as well that /112 providing the additional 48 bits
>     network part and helps further extend the current 2000::/3.  In
>     the v6ops deck I sent this morning this very race to the bottom it
>     really helps serve two purposes.
>
>     In the context below of wearable /48 end site allocation in the
>     future with 5G Enhanced VPN framework network slicing concept, I
>     could see maybe multiple /48 per human in future for sure.
>
>     How do we get there??  Good question and Fred helped kindly shed
>     some light on how that is possible with the aviation scenario.
>
>     Firstly due to blockwise IPv6 allocation process and how the
>     internet works as far as allocations IANA -RIR-ISP-End host, the
>     issue exists as I stated in the v6ops slide deck we will review on
>     Thursday and now precursor on ML, that even if we want to give a
>     /48 to all users it’s is not possible for operators like Verizon. 
>     Here is the problem - A /24 yields 11.6M and /20 160M and Verizon
>     have today 150M 3GPP subscribers today and would like 1B or even
>     7B worth of space for future growth with network slicing enhanced
>     So the extending the network prefix 48 bits would solve that issue
>     and allow the Verizon’s of the world to be able to make /48s a
>     wearable space and site allocation by making /112 the official new
>     bottom, thereby changing the fixed boundary to /112.
>
>
>     On the other side of that it resolves the Day 17 year
>     interoperability issue that exist with vlsm as now operators can
>     have mix of dhcpv6 stateful and static hosts on the same subnet as
>     slaac hosts up to /112.
>
>     From a privacy standpoint we lose 16 bits of heuristic as far as
>     privacy now having 48 bit IID instead of 64.  Now modified EUI64
>     mac or random would not support the 64 bit fixed boundary and a
>     new 48 bit fixed boundary would be established.
>
>     As far as shorter 16  bit IID for privacy extension RFC 4941 would
>     still work but just now would be a random 16 bit IID with slightly
>     much less heuristics for privacy.
>
>     As far as stable random IID camp  48 bit stable RFC 7217 would
>     still work as well but now just 16 bit heuristics for privacy.
>
>     The privacy issue has always been a double edged sword so is a win
>     win for operators and Law Enforcement tracking offenders
>     committing cover crimes now being able assist with scanning
>     capabilities but also gives the end user enough heuristics for
>     privacy to protect against sophisticated criminals.
>
>     Also the added benefit as it eliminated and now permanently solved
>     and gives path forward for operators using vlsm can now support
>     prefix length down to /112.  That adds tremendous value for
>     operators in the world we live in today as vlsm is the real
>     reality for operators and is not a corner case bubble as some may
>     think.
>
>     And of course solves the aviation issues. There maybe others
>     similar situations that may arise that you have to address every
>     human and due to the blockwise allocation schema trickle down from
>     IANA 2000::/3 way down  to the end site by the time it gets to the
>     end site it’s not quite 135 trillion.
>
>     I think the first step is that we all agree with the multiple
>     layers of problems we are trying to solve related to the existing
>     64 bit fixed boundary.
>
>     Once we agree with all the issues and I would say with 5G and
>     network slicing being able to have in reality wearable multiple
>     /48s which could be in reality the future we have to extend the
>     prefix length.
>
>     consensus and a balance on ML before the Thursday v6ops call would
>     be great!!!
>
>     Here are the 16 bit boundary options to make it simpler and then
>     if we want to hone further in byte boundary or nibble we can.
>
>     For me I think /80 could solve a lot of problems but I think a /96
>     would be a middle of the road happy medium that keeps the double
>     edged sword camps happy  Camp 1 -operators and law enforcement for
>     scanning shorter IID Camp 2 - end user privacy
>
>     /64 - current
>         [email-masked] <mailto:[email-masked]>
>         Administrative Requests:
>     /Network Solutions A//rchitect /
>
>     /M 301 502-1347
>     13101 Columbia Pike
>     /Silver Spring, MD
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Nov 2020 06:42:52 +1100

> Class E syndrome

We can deal with that if it happens. It wasn't worth dealing with that in
IPv4 because it didn't give back enough address space for the effort.

---

From: Joe Maimon <[email-masked]>
Date: Tue, 17 Nov 2020 15:41:16 -0500

Mark Smith wrote:
>
>
> On Wed, 18 Nov 2020, 03:40 Joe Maimon, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Class E syndrome
>
>
> We can deal with that if it happens.

If it does happen, it will happen 2-5 times longer than it did for ipv4, 
and it will be all the worse then.

The only historical example we have suggests that the rest of the first 
3 bits cannot be fully counted on.

> It wasn't worth dealing with that in IPv4 because it didn't give back 
> enough address space for the effort.
>
>
Thank you for helping define class E syndrome. Which is a symptom of 
community standardization mistaking themselves for a top down hierarchy 
and creating self fulfilling obstacles to everyone else.

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Nov 2020 12:44:26 +1100

> 3 bits cannot be fully counted on.

You're simplifying the situation and pretending there wasn't a better
alternative available.

IPv6 was available and ready to be deployed when the idea of using Class E
came up.

The cost of upgrading networks and hosts to use Class E would be about the
same as deploying IPv6.

Which provided the better return on time and resource investment?

Spending it on Class E wouldn't have avoided the IPv6 deployment cost, it
would only have delayed it, and effectively doubled the cost of moving to a
larger Internet address space.

> and creating self fulfilling obstacles to everyone else.

IPv4 addressing history and motivation is a lot more complicated than that.

As an example, have a look at the IPv4 address format in RFC760, and then
compare that RFC's date to RFC791's, where address classes were introduced.

 Also look up the address format in RFC675, effectively IPv1 (before TCP
was split away).

IPv6 is really the first protocol designed for the Internet that we have
today. IPv4 was an experiment that escaped the lab into world wide
production.