Subject: New Approach For Discussing IPv10.

From: Khaled Omar <[email-masked]>
Date: Fri, 16 Apr 2021 17:28:25 +0000

Dear IETFers,

I hope you are all fine,

I still see through my online research that the world still working on IPv4 and the migration to IPv6 will take longer than expected due to the slow movement towards IPv6.

We still have the opportunity here to discuss more transitioning solutions and I think I suggested one (IPv10 or IPmix) to help in solving this migration issue under the new administration of the IETF.

Best Regards,

Khaled Omar
Senior Network and Security Engineer
Mobile *: (EGY) (+2)-01003620284
E-mail *:    [email-masked]<mailto:[email-masked]>
Connect with me:
[Twitter]<http://www.twitter.com/eng_khaled_omar>
Twitter<http://www.twitter.com/eng_khaled_omar>
[LinkedIn]<http://www.linkedin.com/in/engkhaledomar>
LinkedIn<http://www.linkedin.com/in/engkhaledomar>

---

From: Lloyd W <[email-masked]>
Date: Sat, 17 Apr 2021 08:44:20 +1000

Khaled

The same IPv10 whose drafts you previously wanted removing from the drafts repository?

https://mailarchive.ietf.org/arch/msg/ietf/7pc66r2Kf83BfaHW4ZWIK9GfcBk/

that does not encourage others to look at your drafts.

Lloyd Wood
[email-masked]

> On 17 Apr 2021, at 03:29, Khaled Omar <[email-masked]> wrote:
> 
> 
> Dear IETFers,
>  
> I hope you are all fine,
>  
> Mobile ): (EGY) (+2)-01003620284
> E-mail *:    [email-masked]
> Connect with me:
> 
> Twitter
> 
> LinkedIn
>  
>

---

From: Khaled Omar <[email-masked]>
Date: Fri, 16 Apr 2021 22:49:10 +0000

Hi Wood,

I just thought maybe something has changed, if u understand the recent situation you would suggest or do something positive, anyway we can just wait and see if the "problem" will cross the threshold or not.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Lloyd W <[email-masked]>
Sent: Saturday, April 17, 2021 12:44:20 AM
To: Khaled Omar <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: New Approach For Discussing IPv10.

Khaled

Lloyd Wood
[email-masked]

Dear IETFers,

I hope you are all fine,

Best Regards,

Khaled Omar

Mobile •: (EGY) (+2)-01003620284

E-mail •:    [email-masked]<mailto:[email-masked]>

Connect with me:

---

From: Khaled Omar <[email-masked]>
Date: Fri, 16 Apr 2021 23:18:33 +0000

What i mean by Problem, is that i see companies ask for a public IPv4 addresses and service providers responds with "sorry, we ran out of v4" and at the same time, people don't think about migration as they are still need training and so on.

But with IPv10, things will be easier and we all will avoid the consequences of not applying a solution.

________________________________
From: ietf <[email-masked]> on behalf of Khaled Omar <[email-masked]>
Sent: Saturday, April 17, 2021 12:49:10 AM
To: Lloyd W <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: New Approach For Discussing IPv10.

Hi Wood,

Khaled

Lloyd Wood
[email-masked]

Dear IETFers,

I hope you are all fine,

Best Regards,

Khaled Omar

Connect with me:

---

From: Ofer Inbar <[email-masked]>
Date: Fri, 16 Apr 2021 22:53:22 -0400

On Fri, Apr 16, 2021 at 10:49:10PM +0000,
> I just thought maybe something has changed, if u understand the recent situation you would suggest or do something positive, anyway we can just wait and see if the "problem" will cross the threshol…

What I recall from past threads about this is that nobody was able to
understand how this proposal would make it any easier to solve the
problem.  So it's not a matter of whether the problem will cross any
threshold; as long as it's the same proposal you made before, I don't
think any of the rest of us see how it will help.  It sounds no easier
to transition to than existing already-adopted solutions.

Yes, those have many problems, and have taken a long time, but the
point is that I don't recall seeing any way that this proposal you
call IPv10 would do any better, so it just seems like it would
complicate matters without helping.

If you have a new proposal, or a clear explanation of how your
existing proposal will outperform existing solutions in a significant
way, that's what might get people to consider your proposal.  But
just pointing out the problem you want to solve, and that it's not
solved yet, without getting anyone to understand how your proposal
actually does so better than what they're already doing, won't.

I did read a lot of what you said in past threads, as well as looked
at your drafts, and I could not find that.  I saw something that would
be just as hard to transition to, except with a much later start
giving it a disadvantage.
  -- Cos

---

From: Khaled Omar <[email-masked]>
Date: Sat, 17 Apr 2021 14:39:58 +0000

>> The same IPv10 whose drafts you previously wanted removing from the drafts repository?

And regarding this question, yes, same draft.

From: Lloyd W [mailto:[email-masked]]
Sent: Saturday, April 17, 2021 12:44 AM
To: Khaled Omar <[email-masked]>
Cc: [email-masked]
Subject: Re: New Approach For Discussing IPv10.

Khaled

Lloyd Wood
[email-masked]<mailto:[email-masked]>

On 17 Apr 2021, at 03:29, Khaled Omar <[email-masked]<mailto:[email-masked]>> wrote:

Dear IETFers,

I hope you are all fine,

Best Regards,

Khaled Omar

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 18 Apr 2021 00:48:46 -0400

IPv6 isn't actually a 'protocol' as such. It is merely a data structure. It
has a source address in a 128 bit domain and a destination address and a
few flags and counters to stop loops, etc. and an extension mechanism
allowing folk to throw pretty much anything else in.

Are you absolutely sure you can't achieve what you want inside the IPv6
regime? Because it is a ten year multi-billion dollar expense to change
stuff at that level. You have an addressing scheme that can get you to give
a unique address to every grain of sand. You have an extension scheme.

The interesting thing, the part that animates IPv6 is actually the routing
tables and the technologies that maintain those are separate. You can tweak
those without moving from IPv6.

On Sat, Apr 17, 2021 at 10:40 AM Khaled Omar <[email-masked]>
wrote:

> *From:* Lloyd W [mailto:[email-masked]]
> *Sent:* Saturday, April 17, 2021 12:44 AM
> *To:* Khaled Omar <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: New Approach For Discussing IPv10.
>
>
>
> Khaled
>
>
>
> I still see through my online research that the world still working on
> IPv4 and the migration to IPv6 will take longer than expected due to the
> slow movement towards IPv6.
>
>
>
> We still have the opportunity here to discuss more transitioning solutions
> and I think I suggested one (IPv10 or IPmix) to help in solving this
> migration issue under the new administration of the IETF.
>
>
>
> *Best Regards,*
>
>
>
> *Khaled Omar*
>
>  <http://www.twitter.com/eng_khaled_omar>[image:
> http://campaign.vmware.com/imgs/spacer.gif]
>
> Twitter <http://www.twitter.com/eng_khaled_omar>
>
>  <http://www.linkedin.com/in/engkhaledomar>[image:
> http://campaign.vmware.com/imgs/spacer.gif]
>
> LinkedIn <http://www.linkedin.com/in/engkhaledomar>
>
>
>
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Apr 2021 22:23:40 -0700

> On Apr 17, 2021, at 9:49 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> IPv6 isn't actually a 'protocol' as such.

It might be useful to provide your definition of a protocol...

> It is merely a data structure.

You have described the messages only, which alone has never been enough to define a protocol.

> It has a source address in a 128 bit domain and a destination address and a few flags and counters to stop loops, etc. and an extension mechanism

That’s a step in the right direction, but omits quite a lot, e.g., longest prefix lookup of destination bawd tables that point to next hop interface and up address and more than a few other parts like definitions of most of those extensions and limits there upon. 

> allowing folk to throw pretty much anything else in. 

Not if you comply with the *protocol*.

You can redefine the bits’ behaviors and meanings, but that would be defining a new protocol, at which point there’s little utility if any in keeping the bit patterns the same.

Joe

---

From: Khaled Omar <[email-masked]>
Date: Sun, 18 Apr 2021 10:44:01 +0000

>> Are you absolutely sure you can't achieve what you want inside the IPv6 regime?

We have now two options, either by modifying the packet from inside, or to add a tunnel to the packet from outside, the second option is easier.

Regards,

Khaled Omar

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Sunday, April 18, 2021 6:49 AM
To: Khaled Omar <[email-masked]>
Cc: Lloyd W <[email-masked]>; [email-masked]
Subject: Re: New Approach For Discussing IPv10.

IPv6 isn't actually a 'protocol' as such. It is merely a data structure. It has a source address in a 128 bit domain and a destination address and a few flags and counters to stop loops, etc. and an extension mechanism allowing folk to throw pretty much anything else in.

Are you absolutely sure you can't achieve what you want inside the IPv6 regime? Because it is a ten year multi-billion dollar expense to change stuff at that level. You have an addressing scheme that can get you to give a unique address to every grain of sand. You have an extension scheme.

The interesting thing, the part that animates IPv6 is actually the routing tables and the technologies that maintain those are separate. You can tweak those without moving from IPv6.

From: Lloyd W [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, April 17, 2021 12:44 AM
To: Khaled Omar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: New Approach For Discussing IPv10.

Khaled

Lloyd Wood

Dear IETFers,

I hope you are all fine,

Best Regards,

Khaled Omar

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 18 Apr 2021 23:42:28 -0400

> You have described the messages only, which alone has never been enough to

Usually that is the case. But IP is a rather peculiar exception. There is
lots of stuff above and lots of stuff below and there is the routing layer
out to the side. But what is there to the packet layer except the packet
format and the rule that you take a packet from the input port, decrement a
counter and pass it to the output port.

How far is it possible to move from that approach and still be doing packet
data? You can change the selection of which packet is chosen to pass next
or affect the pass/drop rules.

You can redefine the bits’ behaviors and meanings, but that would be
> defining a new protocol, at which point there’s little utility if any in
> keeping the bit patterns the same.
>

My point is simply this: what is it that cannot be done within the
constraints of IPv6 would motivate a new protocol?

We keep having people coming along making these suggestions for IPv8,
IPv10, etc. etc. and the inventors never once seem fit to ask what is so
different about their proposal it can't be done in IPv6.

The whole point of the Internet is the narrow waist is really simple.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Apr 2021 16:52:58 +1200

I've been keeping clear of this thread, but I think Phill does remind us of an important point (hence the small change of subject):
On 19-Apr-21 15:42, Phillip Hallam-Baker wrote:
...
> We keep having people coming along making these suggestions for IPv8, IPv10, etc. etc. and the inventors never once seem fit to ask what is so different about their proposal it can't be done in IPv6.

Back in 1994, it had become clear that deploying new header options in IPv4 across the Internet was in practice impossible, however well they worked in the lab. Extending IPv4 was therefore theoretically possible but impossible in reality. So we started IPv6.

27 years later, it has become clear that deploying new extension headers in IPv6 across the Internet is in practice impossible, however well they work in the lab.

There's little prospect that things would be different if we repeat the experiment.
 
> The whole point of the Internet is the narrow waist is really simple.

As it is written: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible."

(What about deterministic networking? Indeed, that requires support as a feature of the communication system. Therefore, it will never happen across the Internet as a whole.)

    Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 19 Apr 2021 08:33:40 +0000

The Internet is the "dumb pipe" because only 5% of traffic has been paid for QoS (even inside one AS). The rest is BE.
Many Carriers are trying to improve this situation for many years but the reality is still close to 5%.
Hence, all these fancy QoS features are not needed on the Internet.
5% of traffic could be easily prioritized in the simplest "Strict Priority Queue" (for the smallest jitter) on the shortest path (for the lowest latency).
EH is just not needed for QoS. Almost nothing is needed for QoS.

Virtualization is needed on the Internet for traffic isolation.
MPLS did play this role for 23 years. EH was too complicated for hardware to replace it yet.
EH is the nested 2 layers model (options inside separate headers) with variable length size at both layers that pose the real challenge for processing.
MPLS is extremely simple to compare to EH hierarchical model.
Data Plane is becoming stronger and stronger - it is probably possible (or would be possible very soon) to squeeze EH hierarchy into PFE.
If MPLS would add a little more complexity to headers ("argument" for the particular application?) - it would be possible to implement it on the current level of PFE development.
It is still not known: will EH replace MPLS or not? Carriers still have to vote by money.

TE is needed. But not 10 versions of VTN that is promoted now in IETF - it is for QoS that is not needed.
TE should have the capability to leverage all investments into infrastructure. In simple explanation:
"all links from one node at the busy hour should have equal % of load independent of links sizes and directions".
It could save 2 digits (in %) for overall infrastructure cost. Primarily on fiber and DWDM layers because the cost structure for fiber:DWDM:IP is like 10:3:1.
We still have only 15y old CSPF with auto-bandwidth for Control Plane implementation of Traffic Engineering (to manage utilization).
Some vendors have an excellent implementation for Management Plane (SDN), but it would not fly because no horizon for it to become multi-vendor.
Nobody did try to use EH as the solution to this problem. This problem is just dropped from the agenda.

IMHO: it was a big mistake to group EH in a hierarchy of variable size objects. Hardware PFE did not exist at that time (it was invented 2-3 years later).
It did look acceptable for software processing at that time (single-thread) but it is not the best even for software now because the software has become multi-thread multi-core (it was the only possibility to improve computing power for the last 14 years). EH structure is not welcome for parallel processing or selective processing.
PFE has achieved the capability to support this complexity only now, but it is still questionable how comprehensive this support could be.
IMHO: it is not possible to fix EH - it would have a very limited permutation of supported features for a long time to come.

Conclusion: Additional complexity should not be the driver for next-next generation IP. We already have an EH example.
The primary design rule was already famous at the time of IPv6 development: KISS. The bare IPv6 header has an excellent fit for it.
Add a little more complex MPLS than we have now. That’s what we need for the Internet.

PS:
The situation could be very much different for Intranets (private networks). They may have enough important traffic to deal with a very complex QoS.
Ed/
-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, April 19, 2021 7:53 AM
To: Phillip Hallam-Baker <[email-masked]>; Joe Touch <[email-masked]>
Cc: Lloyd W <[email-masked]>; IETF Discussion Mailing List <[email-masked]>
Subject: New Approach For Discussing IPng

 

    Brian

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Apr 2021 10:50:06 +0200

On Sun, Apr 18, 2021 at 11:42:28PM -0400,
 Phillip Hallam-Baker <[email-masked]> wrote 
 a message of 100 lines which said:

> Usually that is the case. But IP is a rather peculiar
> exception. There is lots of stuff above and lots of stuff below and
> there is the routing layer out to the side. But what is there to the
> packet layer except the packet format

I agree with you (that IP does not really fit the traditional
description of a "protocol", for instance it does not have a state
machine, explicit or implicit) but the same could be said for
Ethernet, which was a protocol once but now is only a format.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Apr 2021 10:54:51 +0200

On Mon, Apr 19, 2021 at 04:52:58PM +1200,
 Brian E Carpenter <[email-masked]> wrote 

> There's little prospect that things would be different if we repeat the experiment.

If we repeat it exactly in the same way, sure. But with new features,
like greasing, and a lot of encryption (like QUIC does) to keep
middleboxes away?

---

From: Khaled Omar <[email-masked]>
Date: Mon, 19 Apr 2021 11:29:13 +0000

Hi Brian,

>> Back in 1994, it had become clear that deploying new header options in IPv4 across the Internet was in practice impossible, however well they worked in the lab. Extending IPv4 was therefore theore…

How VPN tunnels works in reality?! I think it works by first encrypting the original packet, THEN, "adding a new source and destination addresses to the packet", this is what I'm asking for to allow IPv10 concept works.

Regards,

Khaled

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, April 19, 2021 6:53 AM
To: Phillip Hallam-Baker <[email-masked]>; Joe Touch <[email-masked]>
Cc: Lloyd W <[email-masked]>; IETF Discussion Mailing List <[email-masked]>
Subject: New Approach For Discussing IPng

 

    Brian

---

From: Tom Beecher <[email-masked]>
Date: Mon, 19 Apr 2021 09:27:44 -0400

I first read the IPv10 draft after the October discussions about it.

I would echo what others have said. In its current form I struggle to find
any technological benefits in the proposal. It is deficient as a
standalone L3 addressing scheme, and really more of another V4/V6
transition mechanism, but one that requires every device on the internet to
be updated to support it.

---

From: Tom Beecher <[email-masked]>
Date: Mon, 19 Apr 2021 09:45:11 -0400

>
> How VPN tunnels works in reality?! I think it works by first encrypting
> the original packet, THEN, "adding a new source and destination addresses
> to the packet", this is what I'm asking for to allow IPv10 concept works.
>

That would be an accurate description of tunnel mode IPSEC. If that is what
you are proposing, numerous v4/v6 tunneling standards are already defined
and are well developed.

On Mon, Apr 19, 2021 at 7:30 AM Khaled Omar <[email-masked]>
wrote:

> Hi Brian,
>
> >> Back in 1994, it had become clear that deploying new header options in
> IPv4 across the Internet was in practice impossible, however well they
> worked in the lab. Extending IPv4 was therefore theoretically possible but
> impossible in reality. So we started IPv6.
>
> How VPN tunnels works in reality?! I think it works by first encrypting
> the original packet, THEN, "adding a new source and destination addresses
> to the packet", this is what I'm asking for to allow IPv10 concept works.
>
> Regards,
>
> Khaled
>
> I've been keeping clear of this thread, but I think Phill does remind us
> of an important point (hence the small change of subject):
> Back in 1994, it had become clear that deploying new header options in
> IPv4 across the Internet was in practice impossible, however well they
> worked in the lab. Extending IPv4 was therefore theoretically possible but
> impossible in reality. So we started IPv6.
>
> 27 years later, it has become clear that deploying new extension headers
> in IPv6 across the Internet is in practice impossible, however well they
> work in the lab.
>
> As it is written: "The function in question can completely and correctly
> be implemented only with the knowledge and help of the application standing
> at the endpoints of the communication system. Therefore, providing that
> questioned function as a feature of the communication system itself is not
> possible."
>
> (What about deterministic networking? Indeed, that requires support as a
> feature of the communication system. Therefore, it will never happen across
> the Internet as a whole.)
>
>     Brian
>
>
>
>

---

From: Khaled Omar <[email-masked]>
Date: Mon, 19 Apr 2021 13:52:51 +0000

Hi Tom,

>> That would be an accurate description of tunnel mode IPSEC. If that is what you are proposing, numerous v4/v6 tunneling standards are already defined and are well developed.

I’m not asking for an IPSec tunnel, I’m proposing something like that tunnel when it adds another header with different source and destination addresses.

Once that will be accomplished, then peacefully IPv4 and IPv6 can coexist and communicate.

Khaled Omar

From: Tom Beecher [mailto:[email-masked]]
Sent: Monday, April 19, 2021 3:45 PM
To: Khaled Omar <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Phillip Hallam-Baker <[email-masked]>; Joe Touch <[email-masked]>; Lloyd W <[email-masked]>; IETF Discussion Mailing List <[email-masked]>
Subject: Re: New Approach For Discussing IPng

That would be an accurate description of tunnel mode IPSEC. If that is what you are proposing, numerous v4/v6 tunneling standards are already defined and are well developed.

On Mon, Apr 19, 2021 at 7:30 AM Khaled Omar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian,

Regards,

Khaled

-----Original Message-----
From: ietf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E Carpenter
Sent: Monday, April 19, 2021 6:53 AM
To: Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>; Joe Touch <[email-masked]<mailto:[email-masked]>>
Cc: Lloyd W <[email-masked]<mailto:[email-masked]>>; IETF Discussion Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: New Approach For Discussing IPng

    Brian

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 19 Apr 2021 10:09:15 -0400

On Mon, Apr 19, 2021 at 9:53 AM Khaled Omar <[email-masked]>
wrote:

> Hi Tom,
>
>
>
> >> That would be an accurate description of tunnel mode IPSEC. If that is
> what you are proposing, numerous v4/v6 tunneling standards are already
> defined and are well developed.
>
>
>
> I’m not asking for an IPSec tunnel, I’m proposing something like that
> tunnel when it adds another header with different source and destination
> addresses.
>
>
>

https://tools.ietf.org/html/rfc2890

> Once that will be accomplished, then peacefully IPv4 and IPv6 can coexist

all done.

---

From: Khaled Omar <[email-masked]>
Date: Mon, 19 Apr 2021 14:12:30 +0000

YES, same concept as GRE.

Khaled Omar

From: Christopher Morrow [mailto:[email-masked]]
Sent: Monday, April 19, 2021 4:09 PM
To: Khaled Omar <[email-masked]>
Cc: Tom Beecher <[email-masked]>; Phillip Hallam-Baker <[email-masked]>; IETF Discussion Mailing List <[email-masked]>; Lloyd W <[email-masked]>
Subject: Re: New Approach For Discussing IPng

On Mon, Apr 19, 2021 at 9:53 AM Khaled Omar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

all done.

---

From: Joseph Touch <[email-masked]>
Date: Mon, 19 Apr 2021 07:25:32 -0700

> On Apr 19, 2021, at 1:50 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

There is a state machine; most of it is degenerate*, but there’s definitely state associated with at least fragmentation reassembly.

*the core state is quite complex in its rules, i.e., 
	net in -> net out includes hop count processing, check for destination accept, ECN marking, DSCP prioritization, and HBH extension processing
	net in -> user out includes ECN relay to transport, E2E extension processing including reassembly
	user in -> net out includes source address determination, DSCP and ECN setting, E2E extension processing including fragmentation

And don’t forget the receipt and generation of ICMPs, RAs, NDs, etc.

Joe

---

From: Joseph Touch <[email-masked]>
Date: Mon, 19 Apr 2021 07:36:51 -0700

> On Apr 18, 2021, at 8:42 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> On Sun, Apr 18, 2021 at 1:23 AM Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Apr 17, 2021, at 9:49 PM, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> Usually that is the case. But IP is a rather peculiar exception. There is lots of stuff above and lots of stuff below and there is the routing layer out to the side. But what is there to the packet layer except the packet format and the rule that you take a packet from the input port, decrement a counter and pass it to the output port.

See the note I posted to Stephanie. There is a LOT there beyond just counter decrement.

Just because a separate mechanism populates the forwarding table also doesn’t override the longest-prefix nature of that table, nor that it includes both outgoing interface and next-hop IP.

> How far is it possible to move from that approach and still be doing packet data? You can change the selection of which packet is chosen to pass next or affect the pass/drop rules.

Yes, you can change the order - but that’s because IP is defined as not preserving order. You can drop - because IP does not guarantee delivery. That doesn’t undo the many other rules that are still followed.

> My point is simply this: what is it that cannot be done within the constraints of IPv6 would motivate a new protocol?

Simply put, take anything IPv6 requires and change it. No RA. No ND. No longest-prefix match. Different address locations or bit meanings within those addresses. Basically, take everything that is IPv6 and undo it.

> We keep having people coming along making these suggestions for IPv8, IPv10, etc. etc. and the inventors never once seem fit to ask what is so different about their proposal it can't be done in IPv…

It’s definitely fair to ask “is there a way to do what you want within the IPv6 protocol”, or, for that matter, any other existing protocol (GRE, IPsec, etc.).

> The whole point of the Internet is the narrow waist is really simple.

There are many “whole points” to the Internet. Globally unique addressing, local forwarding decisions with global impact, packets that can’t circulate forever, finite but variable length messages, etc. Narrow waist is only one of those points.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Apr 2021 10:43:10 -0400

> of an important point (hence the small change of subject):

I have also been avoiding the issue raised, But the peculiar fact that
there is so little can be done at that level in the stack did seem worth
mention...

The only scope for innovation I can see in the space is to drop the source
address from data packets... And that is not one I care to attempt for
obvious reasons even when that is exactly what I am doing at the
transport/presentation layer.

> in IPv6 across the Internet is in practice impossible, however well they

Like multicast, the deployment requires substantial cooperation between
commercial entities which are competitors who won't even share their
network maps...

How can we expect Internet QoS to work when ISPs can't even be bothered to
police source packet address declarations on broadband network gateways?

I do not accept everyone's interpretation of 'end to end' but I do accept
that what happens on the network and what happens on the inter-network have
to be rather different. Einar Stefferud had a good presentation explaining
why this is the case.

Where I depart from end-to-end absolutism is that I recognize the network
interfaces as being places where 'different' things can and in some cases
MUST happen. I do not want every coffee pot on my network to have full
Internet access. That would be silly and break the least privilege
principle.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Apr 2021 15:32:54 -0400

I think it is worth asking 'what in the world could we do that was
meaningfully different'. I did actually come up with an answer.

On Mon, Apr 19, 2021 at 10:25 AM Joseph Touch <[email-masked]> wrote:

> There is a state machine; most of it is degenerate*, but there’s
> definitely state associated with at least fragmentation reassembly.
>
>         net in -> net out includes hop count processing, check for
> destination accept, ECN marking, DSCP prioritization, and HBH extension
> processing
>         user in -> net out includes source address determination, DSCP and
> ECN setting, E2E extension processing including fragmentation
>

Sure, there is some degree of choice at that layer, yet this never seems to
be the area people propose to innovate. Its 'lets do a new version of IP so
I can have my name on it'.

ICMP, RA, ND etc. are really secondary support, we can change those without
changing IPv6, if we change I, we would need to invent a whole new set of
support.

The one approach that is meaningfully different and could work is to
dispense with the IPv6 source AND destination addresses and prefix packets
with the destination ASN number instead.

So instead of the Internet core routers knowing the IPaddress->ASN tables,
they are given the ASN number and an opaque blob.

This approach would require packets to be converted from network format
(IPv6) to IPvX format at the network gateway and back again. And of course,
packets would have to carry information that allows the IPv6
source/destination to be recovered at the other end.

That is the road not travelled, or at least not yet. There is only one
circumstance where I can see this approach being worthwhile at this point
and it is in a mesh network (i.e. mesh in the non Mathematical Mesh sense)
that is designed to resist traffic analysis and censorship at a more
fundamental level than existing schemes.

And of course, someone will now point out a circumstance where this is
already happening because...

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 19 Apr 2021 14:46:55 -0500

> And don’t forget the receipt and generation of ICMPs, RAs, NDs, etc.

+1

Behcet

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 19 Apr 2021 21:48:28 +0100

Phillip Hallam-Baker wrote on 19/04/2021 20:32:
> dispense with the IPv6 source AND destination addresses and prefix 
> packets with the destination ASN number instead.

I guess an ASN is attractive to the extent that it's a number that every 
routing entity already has, but it's got nearly 40 years of baggage and 
encumbering it with even more is not likely to end well.  Do we want a 
single routing policy for every identifier in an ASN?  Fine for leaf 
sites with small numbers of identifiers; not so good for larger networks.

It's worth noting that there have been plenty of locator/identifier 
proposals over the years. LISP was the most successful but is still not 
widely used on the internet.

Nick

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2021 17:09:47 -0400

>source/destination to be recovered at the other end.

It sounds like every network gateway needs the equivalent of a full
set of routing tables to map address->ASN.  Am I missing something
or is that going to have a few scaling problems?

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Apr 2021 18:50:35 -0400

> or is that going to have a few scaling problems?

I was merely enumerating the possibility space.

Yes, you would need the ASN data but you don't necessarily need to get that
from the routing tables, it could be pushed out as part of discovery. There
could be a small cache backed up by an online lookup service.

At this point, the market for interesting new directions in networking is
probably limited to LEO satellite constellations. They have the money and
the cost constraints because their entire legacy infrastructure will not
just become obsolete, it will literally crash and burn every 5-10 years or
so.