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

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 17 Nov 2020 17:23:15 +0000

I want to go back on what I said at the start of this thread. I now believe that
we have already reached the bottom and the bottom is /64. I think that will
be good for now and into the future in the universe we live in, but I think the
speculation we have engaged in regarding /112 and other pseudo-bottom
values are fine for consideration in some parallel universe. Am I wrong?

Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Joe Maimon
> Sent: Tuesday, November 17, 2020 8:41 AM
> To: Mark Smith <[email-masked]>; Gyan Mishra <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: [EXTERNAL] Re: The bottom is /112 (was: RE: Extending a /64)
> 
> Class E syndrome
> 
> Mark Smith 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 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:
> >
> >         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 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
> >
> >
> >
> >
> >         Fred
> >
> >
> >         --------------------------------------------------------------------
> >         IETF IPv6 working group mailing list
> >         [email-masked] <mailto:[email-masked]>
> >         Administrative Requests:
> >         https://www.ietf.org/mailman/listinfo/ipv6
> >         --------------------------------------------------------------------
> >
> >     --
> >
> >     <http://www.verizon.com/>
> >
> >     *Gyan Mishra*
> >
> >     /Network Solutions A//rchitect /
> >
> >     /M 301 502-1347
> >     13101 Columbia Pike
> >     /Silver Spring, MD
> >
> >
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     [email-masked] <mailto:[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
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Nov 2020 07:11:22 +1100

> values are fine for consideration in some parallel universe. Am I wrong?

At some point, just like any technology, IPv6 won't be able to effectively
suit a particular need.

/112s compromises too much the privacy, end-user friendlyness and security
properties we get with 64 bit IIDs.

If the only way to solve the aircraft problem is to embed 39 bit IDs in the
prefix, then IPv6 is the wrong tool for the job.

The value of trying to use something common like IPv6 is to gain from it
being a commodity and therefore lower cost.

However the trade off to make that gain is you need to be both willing and
able to make solution requirement compromises to fit within what already
exists within the commodity solution.

You can't customise a commodity and then still get the gains of it being a
commodity, because you've decommodified it.

Regards,
Mark.

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 17 Nov 2020 18:33:21 -0500

AsOn Tue, Nov 17, 2020 at 3:11 PM Mark Smith <[email-masked]> wrote:

>
>
> On Wed, 18 Nov 2020, 04:23 Templin (US), Fred L, <
> [email-masked]> wrote:
>
> If the only way to solve the aircraft problem is to embed 39 bit IDs in
> the prefix, then IPv6 is the wrong tool for the job.
>
> Guessing that ULAs were considered but rejected?

Kerry

---

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

On Wed, 18 Nov 2020, 10:33 Kerry Lynn, <[email-masked]> wrote:

>> At some point, just like any technology, IPv6 won't be able to
>> effectively suit a particular need.
>>
>> /112s compromises too much the privacy, end-user friendlyness and
>> security properties we get with 64 bit IIDs.
>>

As I understand it, the 39 bit ID is directly derived from the aircraft ID,
which would fail the ULA requirement that the global ID is pseudo random.

I happen to know a few people with small or smallish planes. One is VH-TCP,
owned by a former ISP owner I used to work for.

I'm wondering how easy it will be to work out that plane's IPv6 address in
this scheme.

I'd like to see an Internet Draft on this scheme, it's hard to pick out
details and motivation from various emails. In particular I'd like to see
the Security Considerations section.

(Defcon presentations on aircraft systems are interesting and concerning,
including a few from Balint Seeber.)

Regards,
Mark.

>> However the trade off to make that gain is you need to be both willing
>> and able to make solution requirement compromises to fit within what
>> already exists within the commodity solution.
>>
>> You can't customise a commodity and then still get the gains of it being
>> a commodity, because you've decommodified it.
>>
>> Regards,
>> Mark.
>>
>>
>>> Fred
>>>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 18 Nov 2020 01:31:47 +0000

Mark, the 39-bits (15-bit airline code and 24-bit aircraft ID) are for commercial aviation
airplanes only (i.e., passenger airliners). General aviation for small planes has been
out of scope up to now to the best of my knowledge, but maybe Tony can say more.

Fred

From: Mark Smith [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 5:25 PM
To: Kerry Lynn <[email-masked]>
Cc: Templin (US), Fred L <[email-masked]>; 6man WG <[email-masked]>
Subject: [EXTERNAL] Re: The bottom is /112 (was: RE: Extending a /64)

This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.

On Wed, 18 Nov 2020, 10:33 Kerry Lynn, <[email-masked]<mailto:[email-masked]>> wrote:
AsOn Tue, Nov 17, 2020 at 3:11 PM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, 18 Nov 2020, 04:23 Templin (US), Fred L, <[email-masked]<mailto:[email-masked]>> wrote:

At some point, just like any technology, IPv6 won't be able to effectively suit a particular need.

/112s compromises too much the privacy, end-user friendlyness and security properties we get with 64 bit IIDs.

If the only way to solve the aircraft problem is to embed 39 bit IDs in the prefix, then IPv6 is the wrong tool for the job.

As I understand it, the 39 bit ID is directly derived from the aircraft ID, which would fail the ULA requirement that the global ID is pseudo random.

I happen to know a few people with small or smallish planes. One is VH-TCP, owned by a former ISP owner I used to work for.

I'm wondering how easy it will be to work out that plane's IPv6 address in this scheme.

I'd like to see an Internet Draft on this scheme, it's hard to pick out details and motivation from various emails. In particular I'd like to see the Security Considerations section.

(Defcon presentations on aircraft systems are interesting and concerning, including a few from Balint Seeber.)

Regards,
Mark.

Kerry

The value of trying to use something common like IPv6 is to gain from it being a commodity and therefore lower cost.

However the trade off to make that gain is you need to be both willing and able to make solution requirement compromises to fit within what already exists within the commodity solution.

You can't customise a commodity and then still get the gains of it being a commodity, because you've decommodified it.

Regards,
Mark.

Fred

> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Joe Maimon
> To: Mark Smith <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
> Cc: 6man WG <[email-masked]<mailto:[email-masked]>>
> > On Tue, 17 Nov 2020, 11:01 Gyan Mishra, <[email-masked]<mailto:[email-masked]>
> > <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> >
> >
> >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> >         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >         Administrative Requests:
> >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 18 Nov 2020 19:35:43 -0500

Fred

So is that a minimum 39 bit prefix size block is the issue.  So a minimum
/25 would cover it.

That would be a large ISP allocation size  so you could go direct to RIR
for /25.

Gyan
On Tue, Nov 17, 2020 at 8:32 PM Templin (US), Fred L <
[email-masked]> wrote:

> *From:* Mark Smith [mailto:[email-masked]]
> *Sent:* Tuesday, November 17, 2020 5:25 PM
> *To:* Kerry Lynn <[email-masked]>
> *Cc:* Templin (US), Fred L <[email-masked]>; 6man WG <
> [email-masked]>
> *Subject:* [EXTERNAL] Re: The bottom is /112 (was: RE: Extending a /64)
>
>
>
> This message was sent from outside of Boeing. Please do not click links or
> open attachments unless you recognize the sender and know that the content
> is safe.
>
>
>
>
>
>
> As I understand it, the 39 bit ID is directly derived from the aircraft
> ID, which would fail the ULA requirement that the global ID is pseudo
> random.
>
>
>
> I happen to know a few people with small or smallish planes. One is
> VH-TCP, owned by a former ISP owner I used to work for.
>
>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%2FSilver+Spring,+MD?entry=gmail&source=g>>
> >
> > >     *Gyan Mishra*
> > >
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%2FSilver+Spring,+MD?entry=gmail&source=g>
> > >     /Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%2FSilver+Spring,+MD?entry=gmail&source=g>
> > >
> > >
> > >
-- 

*Gyan Mishra*

*Network Solutions A**rchitect *

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