RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Hello Dave:

If you have a v4 only network and are willing to migrate to v6 that’s certainly 
neat and the YATT traffic will just be another v6 traffic that your BCP 38 
rules will process. Still you’ll find IPv4 only customers, and you’ll end up 
with both v4 and v6, and CG NATs, etc. This is what we need to compare with, 
not IPv6 only.

YADA applies to those who would not want dual stack and CG NAT, at least as the 
main rule. Those who would prefer to see end point transition for the most part 
to something easier to digest if not full v6.

To your points:

- yes the NAT is not stateful and that makes all the difference in the world. 
It becomes a network operation like an MPLS tunnel encapsulation that your 
router does BAU day in day out

- I’ll trust you on your filters but filters for IPv4 only does probably do 
something for IP in IP, be it for the case where it’s v6 inside. Not saying 
it’s free, it’s a one-time opex. But not seeing that it’s the same cost as dual 
stack and CG NATs either, which are both opex and capex.

- Upgrade/replace all my CPE + Have the network stack on my customers OS 
upgraded
That’s where the kneejerk rejection shows the most. For the one thing if the 
customer OS is upgraded then why would you update the CPE? Then not all devices 
need this, many are hapopy with the current state of affairs? And the other way 
around if the CPE is upgraded, do we need to update the users devices? So 
presented as you did it’s plain dishonest. That’s why I found the YADA pun so 
funny actually.

Unless we’re uncharacteristically efficient on this one, the CPE software will 
be upgraded a number of times before this thing takes off, and the CPE 
themselves might be replaced for the most part.

The way I see it, adoption can happen from one customer alone. And yes, that 
would add to the list of ways to bypass BCP 38. So yes, it would be neat that 
you install rules that understand IP in IP if you do not already have them, 
with something for YADA in addition, and yes, that’s not free.

But compared to CG NAT and dual stack? Well, I’d be happy to help people have 
that choice.

Keep safe;

Pascal



From: Dave Bell 
Sent: mardi 5 avril 2022 13:03
To: Pascal Thubert (pthubert) 
Cc: Dave Bell ; Matthew Petach ; 
Vasilenko Eduard ; NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi Pascal,

From what I'm reading, it seems like you're implying that the bulk of the ISP 
network does not need to change to implement this new IP protocol. If that is 
the case, then you are incorrect.

Without the router that the customer connects to being aware of this new 
protocol, then you are opening yourself up to address forgery on a massive 
scale. The ISPs next hop needs to be able to inspect both the regular source 
address, and the encapsulated source address to ensure that the customer is 
sending legitimate traffic (uRPF). In my world the BNG is the most complicated 
part of the network.

The CPE I'm sending out to my customers now presumably needs its NAT 
implementation altering? It now does translation on the inner IP header rather 
than the regular what is now outer.

So to summarize, to implement this I need to do the following:
* Install some CG-NAT device (You can argue its not CG-NAT because its 
stateless - It will have a lot of traffic going through it, so its carrier 
grade, and its translating from one type of IP to another, so its network 
address translation.)
* Upgrade my BNGs to cope with the new address format for uRPF purposes
* Upgrade/replace all my CPE
* Have the network stack on my customers OS upgraded

Not to mention all the testing required to ensure that it all will work 
smoothly.

That is a lot of work, and I still don't see the benefit over just moving to 
IPv6.

Regards,
Dave

On Tue, 5 Apr 2022 at 10:30, Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Dave:

The problem we have not solved is with the (host, gateway, ISP network) that 
will not move; and I’m hearing in this list that there’s one big reason: 
because the step (the leap really) is too wide. And I also read a consensus 
that dual stack and large NATs are not the long term solution people want.

The primary goal here is to avoid  dual stack forever, and not having enormous 
CG-NATs either. The proposal is to replace the leap that few can achieve by a 
series of baby steps that most can, and will to a point.

To your example: say that you’re willing to migrate your host stack to 
IPv6-only. But then your ISP or your home gateway does not have it. Stuck. If 
you form a YATT address, the stateless translation will discover that there’s 
no v6 and turn the YATT packet into YADA. With that you can talk to any YADA 
and YATT node in the universe, though you can neither reach all IPv6 nodes nor 
all IPv4 nodes. That’s where the baby steps land.

The motivation to go YADA from IPv4 (as opposed to IPv6 altogether) is 
feasibility. Wit

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Dave Bell]

Hi Pascal,

>From what I'm reading, it seems like you're implying that the bulk of the
ISP network does not need to change to implement this new IP protocol. If
that is the case, then you are incorrect.

Without the router that the customer connects to being aware of this new
protocol, then you are opening yourself up to address forgery on a massive
scale. The ISPs next hop needs to be able to inspect both the regular
source address, and the encapsulated source address to ensure that the
customer is sending legitimate traffic (uRPF). In my world the BNG is the
most complicated part of the network.

The CPE I'm sending out to my customers now presumably needs its NAT
implementation altering? It now does translation on the inner IP header
rather than the regular what is now outer.

So to summarize, to implement this I need to do the following:
* Install some CG-NAT device (You can argue its not CG-NAT because its
stateless - It will have a lot of traffic going through it, so its carrier
grade, and its translating from one type of IP to another, so its network
address translation.)
* Upgrade my BNGs to cope with the new address format for uRPF purposes
* Upgrade/replace all my CPE
* Have the network stack on my customers OS upgraded

Not to mention all the testing required to ensure that it all will work
smoothly.

That is a lot of work, and I still don't see the benefit over just moving
to IPv6.

Regards,
Dave

On Tue, 5 Apr 2022 at 10:30, Pascal Thubert (pthubert) 
wrote:

> Hello Dave:
>
>
>
> The problem we have not solved is with the (host, gateway, ISP network)
> that will not move; and I’m hearing in this list that there’s one big
> reason: because the step (the leap really) is too wide. And I also read a
> consensus that dual stack and large NATs are not the long term solution
> people want.
>
>
>
> The primary goal here is to avoid  dual stack forever, and not having
> enormous CG-NATs either. The proposal is to replace the leap that few can
> achieve by a series of baby steps that most can, and will to a point.
>
>
>
> To your example: say that you’re willing to migrate your host stack to
> IPv6-only. But then your ISP or your home gateway does not have it. Stuck.
> If you form a YATT address, the stateless translation will discover that
> there’s no v6 and turn the YATT packet into YADA. With that you can talk to
> any YADA and YATT node in the universe, though you can neither reach all
> IPv6 nodes nor all IPv4 nodes. That’s where the baby steps land.
>
>
>
> The motivation to go YADA from IPv4 (as opposed to IPv6 altogether) is
> feasibility. With YADA, the change is smaller in the upper stack and the
> applications. Say you have VMs that are IPv4 only, that you do not control
> the stack at all but just the hosting system. The hosting system can serve
> as/intercept DNS, NAT the YADA double-A destination to a single-A with an
> address from the pool, leaving the VM stack unchanged. An upgraded home
> gateway could do that too for the whole private network.
>
>
>
> YADA and YATT are equivalent, they are the IPv4 and IPv6 formulations of
> the same thing; what goes on the wire is whatever matches what the ISP
> network offers. Each AS or realm can decide to be one version only. The
> stateless NAT at the border can be wire speed, there’s state nor no
> complexity involved in that translation.
>
>
>
> When you’re already IPv6 you need none of that. IPv6 is the sphere than
> encompasses all the planes (realms) and the shaft. Plus all the air in
> between. But the IPv6 host could be so nice as to support YATT, which
> effectively is an effort on its part, but gives it a /64 for free,
> automatically. That’s a bonus that could become handy.
>
>
>
> Keep safe;
>
>
>
> Pascal
>
>
>
>
>
> *From:* Dave Bell 
> *Sent:* mardi 5 avril 2022 9:45
> *To:* Pascal Thubert (pthubert) 
> *Cc:* Matthew Petach ; Vasilenko Eduard <
> vasilenko.edu...@huawei.com>; NANOG 
> *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not supported
> re: 202203261833.AYC
>
>
>
> Considering this requires updating every single IP stack that wants to
> utilise this, what are the benefits of it other than just moving to IPv6?
>
>
>
> Regards,
>
> Dave
>
>
>
> On Tue, 5 Apr 2022 at 08:24, Pascal Thubert (pthubert) via NANOG <
> nanog@nanog.org> wrote:
>
> Hello Matthew
>
>
>
> At the moment the draft has a general architecture, and it will take the
> right minds and experience to turn a model into a live network. Considering
> what the people in this list have already built, it’s no gigantic leap to
> figure they can build that too. Most of the building blocks that are
> implicit or TBD in the draft exist already.
>

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Hello Dave:

The problem we have not solved is with the (host, gateway, ISP network) that 
will not move; and I’m hearing in this list that there’s one big reason: 
because the step (the leap really) is too wide. And I also read a consensus 
that dual stack and large NATs are not the long term solution people want.

The primary goal here is to avoid  dual stack forever, and not having enormous 
CG-NATs either. The proposal is to replace the leap that few can achieve by a 
series of baby steps that most can, and will to a point.

To your example: say that you’re willing to migrate your host stack to 
IPv6-only. But then your ISP or your home gateway does not have it. Stuck. If 
you form a YATT address, the stateless translation will discover that there’s 
no v6 and turn the YATT packet into YADA. With that you can talk to any YADA 
and YATT node in the universe, though you can neither reach all IPv6 nodes nor 
all IPv4 nodes. That’s where the baby steps land.

The motivation to go YADA from IPv4 (as opposed to IPv6 altogether) is 
feasibility. With YADA, the change is smaller in the upper stack and the 
applications. Say you have VMs that are IPv4 only, that you do not control the 
stack at all but just the hosting system. The hosting system can serve 
as/intercept DNS, NAT the YADA double-A destination to a single-A with an 
address from the pool, leaving the VM stack unchanged. An upgraded home gateway 
could do that too for the whole private network.

YADA and YATT are equivalent, they are the IPv4 and IPv6 formulations of the 
same thing; what goes on the wire is whatever matches what the ISP network 
offers. Each AS or realm can decide to be one version only. The stateless NAT 
at the border can be wire speed, there’s state nor no complexity involved in 
that translation.

When you’re already IPv6 you need none of that. IPv6 is the sphere than 
encompasses all the planes (realms) and the shaft. Plus all the air in between. 
But the IPv6 host could be so nice as to support YATT, which effectively is an 
effort on its part, but gives it a /64 for free, automatically. That’s a bonus 
that could become handy.

Keep safe;

Pascal


From: Dave Bell 
Sent: mardi 5 avril 2022 9:45
To: Pascal Thubert (pthubert) 
Cc: Matthew Petach ; Vasilenko Eduard 
; NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Considering this requires updating every single IP stack that wants to utilise 
this, what are the benefits of it other than just moving to IPv6?

Regards,
Dave

On Tue, 5 Apr 2022 at 08:24, Pascal Thubert (pthubert) via NANOG 
mailto:nanog@nanog.org>> wrote:
Hello Matthew

At the moment the draft has a general architecture, and it will take the right 
minds and experience to turn a model into a live network. Considering what the 
people in this list have already built, it’s no gigantic leap to figure they 
can build that too. Most of the building blocks that are implicit or TBD in the 
draft exist already.

About linking ASN to realms, that’s Eduard’s view, I’ll let him answer. The 
draft is not like that, all existing ASN and IP addresses can be reused in 
every new realm, and there does not need to be any mapping. If people find a 
need or a reason to add constraints, that’s beyond me at this time, and against 
the natural philosophy of minimizing interdependences to maintain design 
freedom in each realm. The draft has one and one only dependency, that surface 
of the shaft is common to all realms.

To your point, and unrelated to ASNs, the shaft can be physically distributed. 
Each physical place would announce 240.0.0.0/6<http://240.0.0.0/6>, and the 
nearest alive would attract the traffic. See it as as many IXPs. In the current 
draft, there’s only one shaft that links all realms. And there’s a single realm 
number for each realm that is advertised in every physical instances of the 
shaft. All that is a  simplification to highlight the design.

As the shaft lives on, a realm may be multihomed, the shaft might be subnetted 
to interconnect only specific realms, or to be advertised differently in 
different geographies. And then the subnets will need to be injected in the 
realms. The way around a breakage can be DNS, or BGP.

All this is possible, you’ve already done it, and it’s really your play. We 
build the car, you drive it. Happy that you start figuring out how you prefer 
it to happen. While we figure out protocols to renumber more efficiently, fix 
source address selection, extend the NATs, you name it. There’s work for all 
and at every phase. But at this stage of the discussion, I favor the 10 miles 
view to get a shared basic understanding.

On the side, I’d be happy to learn how you solved a situation like the one 
below, if there’s any article / doc?

Keep safe;

Pascal

From: Matthew Petach mailto:mpet...@netflight.com>>
Sent: mardi 5 avril 2022 0:29
To: Vasilenko Eduard 
mailto:vasilenko.edu...@huawei.com>>
Cc: 

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Dave Bell]

Considering this requires updating every single IP stack that wants to
utilise this, what are the benefits of it other than just moving to IPv6?

Regards,
Dave

On Tue, 5 Apr 2022 at 08:24, Pascal Thubert (pthubert) via NANOG <
nanog@nanog.org> wrote:

> Hello Matthew
>
>
>
> At the moment the draft has a general architecture, and it will take the
> right minds and experience to turn a model into a live network. Considering
> what the people in this list have already built, it’s no gigantic leap to
> figure they can build that too. Most of the building blocks that are
> implicit or TBD in the draft exist already.
>
>
>
> About linking ASN to realms, that’s Eduard’s view, I’ll let him answer.
> The draft is not like that, all existing ASN and IP addresses can be reused
> in every new realm, and there does not need to be any mapping. If people
> find a need or a reason to add constraints, that’s beyond me at this time,
> and against the natural philosophy of minimizing interdependences to
> maintain design freedom in each realm. The draft has one and one only
> dependency, that surface of the shaft is common to all realms.
>
>
>
> To your point, and unrelated to ASNs, the shaft can be physically
> distributed. Each physical place would announce 240.0.0.0/6, and the
> nearest alive would attract the traffic. See it as as many IXPs. In the
> current draft, there’s only one shaft that links all realms. And there’s a
> single realm number for each realm that is advertised in every physical
> instances of the shaft. All that is a  simplification to highlight the
> design.
>
>
>
> As the shaft lives on, a realm may be multihomed, the shaft might be
> subnetted to interconnect only specific realms, or to be advertised
> differently in different geographies. And then the subnets will need to be
> injected in the realms. The way around a breakage can be DNS, or BGP.
>
>
>
> All this is possible, you’ve already done it, and it’s really your play.
> We build the car, you drive it. Happy that you start figuring out how you
> prefer it to happen. While we figure out protocols to renumber more
> efficiently, fix source address selection, extend the NATs, you name it.
> There’s work for all and at every phase. But at this stage of the
> discussion, I favor the 10 miles view to get a shared basic understanding.
>
>
>
> On the side, I’d be happy to learn how you solved a situation like the one
> below, if there’s any article / doc?
>
>
>
> Keep safe;
>
>
>
> Pascal
>
>
>
> *From:* Matthew Petach 
> *Sent:* mardi 5 avril 2022 0:29
> *To:* Vasilenko Eduard 
> *Cc:* Pascal Thubert (pthubert) ; Nicholas Warren <
> nwar...@barryelectric.com>; Abraham Y. Chen ; Justin
> Streiner ; NANOG 
> *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not supported
> re: 202203261833.AYC
>
>
>
>
>
>
>
> On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG <
> nanog@nanog.org> wrote:
>
> 240.0.01.1 address is appointed not to the router. It is appointed to
> Realm.
> It is up to the realm owner (ISP to Enterprise) what particular router (or
> routers) would do translation between realms.
>
>
>
> Please forgive me as I work this out in my head for a moment.
>
>
>
> If I'm a global network with a single ASN on every populated continent
>
> on the planet, this means I would have a single Realm address; for
>
> the sake of the example, let's suppose I'm ASN 42, so my Realm
>
> address is 240.0.0.42.  I have 200+ BGP speaking routers at
>
> exchange points all over the planet where I exchange traffic with
>
> other networks.
>
>
>
> In this new model, every border router I have would all use the
>
> same 240.0.0.42 address in the Shaft, and other Realms would
>
> simply hand traffic to the nearest border router of mine, essentially
>
> following a simple Anycast model where the nearest instance of the
>
> Realm address is the one that traffic is handed to, with no way to do
>
> traffic engineering from continent to continent?
>
>
>
> Or is there some mechanism whereby different instances of 240.0.0.42
>
> can announce different policies into the Shaft to direct traffic more
>
> appropriately that I'm not understanding from the discussion?
>
>
>
> Because if it's one big exercise in enforced Hot Potato Routing with
>
> a single global announcement of your reachability...
>
>
>
> ...that's gonna fail big-time the first time there's a major undersea
>
> quake in the Strait of Taiwan, which cuts 7/8ths of the trans-pacific
>
> connectivity off, and suddenly you've got the same Realm address
>
> being advertised in the US as in Asia, but with no underlying connectivity
>
> between them.
>
>
>
>
> https://www.submarinenetworks.com/news/cables-cut-after-taiwan-earthquake-2006
>
>
>
> We who do not learn from history are doomed to repeat it...badly.   :(
>
>
>
> Matt
>
>
>

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Hello Matthew

At the moment the draft has a general architecture, and it will take the right 
minds and experience to turn a model into a live network. Considering what the 
people in this list have already built, it’s no gigantic leap to figure they 
can build that too. Most of the building blocks that are implicit or TBD in the 
draft exist already.

About linking ASN to realms, that’s Eduard’s view, I’ll let him answer. The 
draft is not like that, all existing ASN and IP addresses can be reused in 
every new realm, and there does not need to be any mapping. If people find a 
need or a reason to add constraints, that’s beyond me at this time, and against 
the natural philosophy of minimizing interdependences to maintain design 
freedom in each realm. The draft has one and one only dependency, that surface 
of the shaft is common to all realms.

To your point, and unrelated to ASNs, the shaft can be physically distributed. 
Each physical place would announce 240.0.0.0/6, and the nearest alive would 
attract the traffic. See it as as many IXPs. In the current draft, there’s only 
one shaft that links all realms. And there’s a single realm number for each 
realm that is advertised in every physical instances of the shaft. All that is 
a  simplification to highlight the design.

As the shaft lives on, a realm may be multihomed, the shaft might be subnetted 
to interconnect only specific realms, or to be advertised differently in 
different geographies. And then the subnets will need to be injected in the 
realms. The way around a breakage can be DNS, or BGP.

All this is possible, you’ve already done it, and it’s really your play. We 
build the car, you drive it. Happy that you start figuring out how you prefer 
it to happen. While we figure out protocols to renumber more efficiently, fix 
source address selection, extend the NATs, you name it. There’s work for all 
and at every phase. But at this stage of the discussion, I favor the 10 miles 
view to get a shared basic understanding.

On the side, I’d be happy to learn how you solved a situation like the one 
below, if there’s any article / doc?

Keep safe;

Pascal

From: Matthew Petach 
Sent: mardi 5 avril 2022 0:29
To: Vasilenko Eduard 
Cc: Pascal Thubert (pthubert) ; Nicholas Warren 
; Abraham Y. Chen ; Justin 
Streiner ; NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC



On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG 
mailto:nanog@nanog.org>> wrote:
240.0.01.1 address is appointed not to the router. It is appointed to Realm.
It is up to the realm owner (ISP to Enterprise) what particular router (or 
routers) would do translation between realms.

Please forgive me as I work this out in my head for a moment.

If I'm a global network with a single ASN on every populated continent
on the planet, this means I would have a single Realm address; for
the sake of the example, let's suppose I'm ASN 42, so my Realm
address is 240.0.0.42.  I have 200+ BGP speaking routers at
exchange points all over the planet where I exchange traffic with
other networks.

In this new model, every border router I have would all use the
same 240.0.0.42 address in the Shaft, and other Realms would
simply hand traffic to the nearest border router of mine, essentially
following a simple Anycast model where the nearest instance of the
Realm address is the one that traffic is handed to, with no way to do
traffic engineering from continent to continent?

Or is there some mechanism whereby different instances of 240.0.0.42
can announce different policies into the Shaft to direct traffic more
appropriately that I'm not understanding from the discussion?

Because if it's one big exercise in enforced Hot Potato Routing with
a single global announcement of your reachability...

...that's gonna fail big-time the first time there's a major undersea
quake in the Strait of Taiwan, which cuts 7/8ths of the trans-pacific
connectivity off, and suddenly you've got the same Realm address
being advertised in the US as in Asia, but with no underlying connectivity
between them.

https://www.submarinenetworks.com/news/cables-cut-after-taiwan-earthquake-2006

We who do not learn from history are doomed to repeat it...badly.   :(

Matt

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Matthew Petach via NANOG]

On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG 
wrote:

> 240.0.01.1 address is appointed not to the router. It is appointed to
> Realm.
> It is up to the realm owner (ISP to Enterprise) what particular router (or
> routers) would do translation between realms.
>

Please forgive me as I work this out in my head for a moment.

If I'm a global network with a single ASN on every populated continent
on the planet, this means I would have a single Realm address; for
the sake of the example, let's suppose I'm ASN 42, so my Realm
address is 240.0.0.42.  I have 200+ BGP speaking routers at
exchange points all over the planet where I exchange traffic with
other networks.

In this new model, every border router I have would all use the
same 240.0.0.42 address in the Shaft, and other Realms would
simply hand traffic to the nearest border router of mine, essentially
following a simple Anycast model where the nearest instance of the
Realm address is the one that traffic is handed to, with no way to do
traffic engineering from continent to continent?

Or is there some mechanism whereby different instances of 240.0.0.42
can announce different policies into the Shaft to direct traffic more
appropriately that I'm not understanding from the discussion?

Because if it's one big exercise in enforced Hot Potato Routing with
a single global announcement of your reachability...

...that's gonna fail big-time the first time there's a major undersea
quake in the Strait of Taiwan, which cuts 7/8ths of the trans-pacific
connectivity off, and suddenly you've got the same Realm address
being advertised in the US as in Asia, but with no underlying connectivity
between them.

https://www.submarinenetworks.com/news/cables-cut-after-taiwan-earthquake-2006

We who do not learn from history are doomed to repeat it...badly.   :(

Matt

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Very right; the stateless operation is simpler than say tunneling in MPLS. Very 
easy to program in asic.

The key points that make this feasible :
- not trying the infeasible: any v4 to any v6 is a non goal.
- legacy v4 host to legacy v4 application can still work the same long as they 
are deployed in the same realm. Say your bank deploys a realm as an isolation 
measure. Say it has legacy client server applications. It’s quite logical for 
the bank to deploy them in the same realm. Effectively they will not be 
reachable from other realms unless a nat is voluntarily installed.
- A great many hosts are deployed in private networks. They could be connected  
to the YADA world by changing their existing nat only. This is why we need a 
second prefix from which the nat builds an A record from the AA to present as a 
replacement for the AA inside.

Keep safe,

Pascal

Le 4 avr. 2022 à 21:14, Vasilenko Eduard  a écrit :


Well, if something is stateless then it is not CGNAT, it is just a router that 
may be called a gateway.
It is a very similar thing that we have on the border between any domains when 
having a different data plane:

-  DC (VxLAN) and Backbone (MPLS)

-  Backbone and Metro (both MPLS)
For sure, it is better to avoid gateways because it is typically (not always) 
an additional hop that costs money.
But the router is 3x less expensive than CGNAT. Hence, I would like to point 
out that the problem is 3x smaller.
Ed/
From: Dave Bell [mailto:m...@geordish.org]
Sent: Monday, April 4, 2022 9:21 PM
To: Nicholas Warren 
Cc: Vasilenko Eduard ; Abraham Y. Chen 
; Pascal Thubert (pthubert) ; Justin 
Streiner ; NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC


This seems pretty unworkable.

We would now all need to maintain large CG-NAT boxes in the network to 
decasulate the traffic from a source to the subscriber. It does seem like it 
would be fairly stateless, it is not improving things.

Assuming the end host is sending traffic with the magic header already affixed, 
we now need to update literally every IP stack in existence if it wants to take 
part.

I need to update all my customer facing routers to have some fancy feature to 
look deep into the packet to check they are not circumventing BCP38.

This all seems like a lot of work just to not deploy IPv6.

Regards,
Dave

On Mon, 4 Apr 2022 at 15:37, Nicholas Warren 
mailto:nwar...@barryelectric.com>> wrote:
The vocabulary is distracting...

In practice this extends IPv4 addresses by 32 bits, making them 64 bits in 
total. They are referring to the top 32 bits (240.0.0.0/6<http://240.0.0.0/6>) 
as a “shaft.” The bottom 32 bits make up the "realm."

Here is the way my teeny tiny brain understands it:
1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
2. We announce our shiny new shafts in BGP. Yes, we announce the /32 that is 
our shaft.
3. We setup our networks to use the bottom 32 bits however we see fit in our 
network. (for the example, I assign my client 1.2.3.4 and you assign your 
client 4.3.2.1)
4. Somehow, we get DNS to hand out 64 bit addresses, probably through a  
and just ignoring the last 64 bits.
5. My client, assigned the address 1.2.3.4 in my realm, queries your client's 
address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
6. My client then sends your client a packet (IPv4 source: 240.0.0.1; IPv4 
destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4 
destination: 4.3.2.1)
7. 240.0.0.0/6<http://240.0.0.0/6> is routable on plain old normal internet 
routers, so nothing needs to be changed. (lol)
8a. Your router receives the packet, and your router does special things with 
its shaft. (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
(IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_)
8b. Alternatively, every router in your network could determine next hop by 
investigating the second header when the destination is your shaft.
9. Your client receives the packet and can either handle this case in a special 
way or translate it to a v6 address for higher level applications.

No, as a matter of fact, I don't know I'm talking about. Hopefully one of the 
authors can correct my walkthrough of how it works 

Shaft and realm are fun words. I see why they picked them.

- Nich

From: NANOG 
mailto:barryelectric@nanog.org>>
 On Behalf Of Vasilenko Eduard via NANOG
Sent: Monday, April 4, 2022 3:28 AM
To: Abraham Y. Chen mailto:ayc...@avinta.com>>; Pascal 
Thubert (pthubert) mailto:pthub...@cisco.com>>; Justin 
Streiner mailto:strein...@gmail.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

2)When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
ther

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Isn’t load balancing one of the neat things you do with loopbacks?

Certainly the router that serves the shaft is virtual and distributed. The 
shaft itself can/should  be physically distributed in multiple IXPs.

For now let us agree on the simple view.

Things like load balancing and physical distribution around the planet will be 
arranged in their own time.

Regards,

Pascal

Le 4 avr. 2022 à 20:21, Dave Bell  a écrit :



This seems pretty unworkable.

We would now all need to maintain large CG-NAT boxes in the network to 
decasulate the traffic from a source to the subscriber. It does seem like it 
would be fairly stateless, it is not improving things.

Assuming the end host is sending traffic with the magic header already affixed, 
we now need to update literally every IP stack in existence if it wants to take 
part.

I need to update all my customer facing routers to have some fancy feature to 
look deep into the packet to check they are not circumventing BCP38.

This all seems like a lot of work just to not deploy IPv6.

Regards,
Dave

On Mon, 4 Apr 2022 at 15:37, Nicholas Warren 
mailto:nwar...@barryelectric.com>> wrote:
The vocabulary is distracting...

In practice this extends IPv4 addresses by 32 bits, making them 64 bits in 
total. They are referring to the top 32 bits (240.0.0.0/6<http://240.0.0.0/6>) 
as a “shaft.” The bottom 32 bits make up the "realm."

Here is the way my teeny tiny brain understands it:
1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
2. We announce our shiny new shafts in BGP. Yes, we announce the /32 that is 
our shaft.
3. We setup our networks to use the bottom 32 bits however we see fit in our 
network. (for the example, I assign my client 1.2.3.4 and you assign your 
client 4.3.2.1)
4. Somehow, we get DNS to hand out 64 bit addresses, probably through a  
and just ignoring the last 64 bits.
5. My client, assigned the address 1.2.3.4 in my realm, queries your client's 
address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
6. My client then sends your client a packet (IPv4 source: 240.0.0.1; IPv4 
destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4 
destination: 4.3.2.1)
7. 240.0.0.0/6<http://240.0.0.0/6> is routable on plain old normal internet 
routers, so nothing needs to be changed. (lol)
8a. Your router receives the packet, and your router does special things with 
its shaft. (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
(IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_)
8b. Alternatively, every router in your network could determine next hop by 
investigating the second header when the destination is your shaft.
9. Your client receives the packet and can either handle this case in a special 
way or translate it to a v6 address for higher level applications.

No, as a matter of fact, I don't know I'm talking about. Hopefully one of the 
authors can correct my walkthrough of how it works 

Shaft and realm are fun words. I see why they picked them.

- Nich

From: NANOG 
mailto:barryelectric@nanog.org>>
 On Behalf Of Vasilenko Eduard via NANOG
Sent: Monday, April 4, 2022 3:28 AM
To: Abraham Y. Chen mailto:ayc...@avinta.com>>; Pascal 
Thubert (pthubert) mailto:pthub...@cisco.com>>; Justin 
Streiner mailto:strein...@gmail.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

2)When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
there is no isolated buildings with isolated floors to deploy your model 
anymore. There is only one spherical layer of physical earth surface for you to 
use as a realm, which is the current IPv4 deployment. How could you still have 
multiple full IPv4 address sets deployed, yet not seeing their identical twins, 
triplets, etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?

It is the same as what I was trying to explain to Pascal. How to map the 
2-level hierarchy of the draft (“Shaft”:”Realm”) to the real world?
I am sure that it is possible to do this if assume that the real world has 2 
levels of hierarchy where the high level is “BGP AS”.
“BGP AS” is the name that everybody understands, No need for a new name “Shaft”.

Ed/
From: Abraham Y. Chen [mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>]
Sent: Saturday, April 2, 2022 12:45 AM
To: Pascal Thubert (pthubert) 
<mailto:pthub...@cisco.com<mailto:pthub...@cisco.com>>; Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>>; 
Justin Streiner <mailto:strein...@gmail.com<mailto:strein...@gmail.com>>
Cc: NANOG <mailto:nanog@nanog.org<mailto:nanog@nanog.org>>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supp

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Vasilenko Eduard via NANOG]

Well, if something is stateless then it is not CGNAT, it is just a router that 
may be called a gateway.
It is a very similar thing that we have on the border between any domains when 
having a different data plane:

-  DC (VxLAN) and Backbone (MPLS)

-  Backbone and Metro (both MPLS)
For sure, it is better to avoid gateways because it is typically (not always) 
an additional hop that costs money.
But the router is 3x less expensive than CGNAT. Hence, I would like to point 
out that the problem is 3x smaller.
Ed/
From: Dave Bell [mailto:m...@geordish.org]
Sent: Monday, April 4, 2022 9:21 PM
To: Nicholas Warren 
Cc: Vasilenko Eduard ; Abraham Y. Chen 
; Pascal Thubert (pthubert) ; Justin 
Streiner ; NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC


This seems pretty unworkable.

We would now all need to maintain large CG-NAT boxes in the network to 
decasulate the traffic from a source to the subscriber. It does seem like it 
would be fairly stateless, it is not improving things.

Assuming the end host is sending traffic with the magic header already affixed, 
we now need to update literally every IP stack in existence if it wants to take 
part.

I need to update all my customer facing routers to have some fancy feature to 
look deep into the packet to check they are not circumventing BCP38.

This all seems like a lot of work just to not deploy IPv6.

Regards,
Dave

On Mon, 4 Apr 2022 at 15:37, Nicholas Warren 
mailto:nwar...@barryelectric.com>> wrote:
The vocabulary is distracting...

In practice this extends IPv4 addresses by 32 bits, making them 64 bits in 
total. They are referring to the top 32 bits (240.0.0.0/6<http://240.0.0.0/6>) 
as a “shaft.” The bottom 32 bits make up the "realm."

Here is the way my teeny tiny brain understands it:
1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
2. We announce our shiny new shafts in BGP. Yes, we announce the /32 that is 
our shaft.
3. We setup our networks to use the bottom 32 bits however we see fit in our 
network. (for the example, I assign my client 1.2.3.4 and you assign your 
client 4.3.2.1)
4. Somehow, we get DNS to hand out 64 bit addresses, probably through a  
and just ignoring the last 64 bits.
5. My client, assigned the address 1.2.3.4 in my realm, queries your client's 
address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
6. My client then sends your client a packet (IPv4 source: 240.0.0.1; IPv4 
destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4 
destination: 4.3.2.1)
7. 240.0.0.0/6<http://240.0.0.0/6> is routable on plain old normal internet 
routers, so nothing needs to be changed. (lol)
8a. Your router receives the packet, and your router does special things with 
its shaft. (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
(IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_)
8b. Alternatively, every router in your network could determine next hop by 
investigating the second header when the destination is your shaft.
9. Your client receives the packet and can either handle this case in a special 
way or translate it to a v6 address for higher level applications.

No, as a matter of fact, I don't know I'm talking about. Hopefully one of the 
authors can correct my walkthrough of how it works 

Shaft and realm are fun words. I see why they picked them.

- Nich

From: NANOG 
mailto:barryelectric@nanog.org>>
 On Behalf Of Vasilenko Eduard via NANOG
Sent: Monday, April 4, 2022 3:28 AM
To: Abraham Y. Chen mailto:ayc...@avinta.com>>; Pascal 
Thubert (pthubert) mailto:pthub...@cisco.com>>; Justin 
Streiner mailto:strein...@gmail.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

2)When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
there is no isolated buildings with isolated floors to deploy your model 
anymore. There is only one spherical layer of physical earth surface for you to 
use as a realm, which is the current IPv4 deployment. How could you still have 
multiple full IPv4 address sets deployed, yet not seeing their identical twins, 
triplets, etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?

It is the same as what I was trying to explain to Pascal. How to map the 
2-level hierarchy of the draft (“Shaft”:”Realm”) to the real world?
I am sure that it is possible to do this if assume that the real world has 2 
levels of hierarchy where the high level is “BGP AS”.
“BGP AS” is the name that everybody understands, No need for a new name “Shaft”.

Ed/
From: Abraham Y. Chen [mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>]
Sent: Saturday, April 2, 2022 12:45 AM
To: Pascal Thubert 

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Dave Bell]

This seems pretty unworkable.

We would now all need to maintain large CG-NAT boxes in the network to
decasulate the traffic from a source to the subscriber. It does seem like
it would be fairly stateless, it is not improving things.

Assuming the end host is sending traffic with the magic header already
affixed, we now need to update literally every IP stack in existence if it
wants to take part.

I need to update all my customer facing routers to have some fancy feature
to look deep into the packet to check they are not circumventing BCP38.

This all seems like a lot of work just to not deploy IPv6.

Regards,
Dave

On Mon, 4 Apr 2022 at 15:37, Nicholas Warren 
wrote:

> The vocabulary is distracting...
>
> In practice this extends IPv4 addresses by 32 bits, making them 64 bits in
> total. They are referring to the top 32 bits (240.0.0.0/6) as a “shaft.”
> The bottom 32 bits make up the "realm."
>
> Here is the way my teeny tiny brain understands it:
> 1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
> 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 that
> is our shaft.
> 3. We setup our networks to use the bottom 32 bits however we see fit in
> our network. (for the example, I assign my client 1.2.3.4 and you assign
> your client 4.3.2.1)
> 4. Somehow, we get DNS to hand out 64 bit addresses, probably through a
>  and just ignoring the last 64 bits.
> 5. My client, assigned the address 1.2.3.4 in my realm, queries your
> client's address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
> 6. My client then sends your client a packet (IPv4 source: 240.0.0.1; IPv4
> destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4
> destination: 4.3.2.1)
> 7. 240.0.0.0/6 is routable on plain old normal internet routers, so
> nothing needs to be changed. (lol)
> 8a. Your router receives the packet, and your router does special things
> with its shaft. (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next
> Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_)
> 8b. Alternatively, every router in your network could determine next hop
> by investigating the second header when the destination is your shaft.
> 9. Your client receives the packet and can either handle this case in a
> special way or translate it to a v6 address for higher level applications.
>
> No, as a matter of fact, I don't know I'm talking about. Hopefully one of
> the authors can correct my walkthrough of how it works 
>
> Shaft and realm are fun words. I see why they picked them.
>
> - Nich
>
> From: NANOG  On Behalf
> Of Vasilenko Eduard via NANOG
> Sent: Monday, April 4, 2022 3:28 AM
> To: Abraham Y. Chen ; Pascal Thubert (pthubert) <
> pthub...@cisco.com>; Justin Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
>
> 2)When you extend each floor to use the whole IPv4 address pool,
> however, you are essential talking about covering the entire surface of the
> earth. Then, there is no isolated buildings with isolated floors to deploy
> your model anymore. There is only one spherical layer of physical earth
> surface for you to use as a realm, which is the current IPv4 deployment.
> How could you still have multiple full IPv4 address sets deployed, yet not
> seeing their identical twins, triplets, etc.? Are you proposing multiple
> spherical layers of "realms", one on top of the other?
>
> It is the same as what I was trying to explain to Pascal. How to map the
> 2-level hierarchy of the draft (“Shaft”:”Realm”) to the real world?
> I am sure that it is possible to do this if assume that the real world has
> 2 levels of hierarchy where the high level is “BGP AS”.
> “BGP AS” is the name that everybody understands, No need for a new name
> “Shaft”.
>
> Ed/
> From: Abraham Y. Chen [mailto:ayc...@avinta.com]
> Sent: Saturday, April 2, 2022 12:45 AM
> To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Vasilenko
> Eduard <mailto:vasilenko.edu...@huawei.com>; Justin Streiner  strein...@gmail.com>
> Cc: NANOG <mailto:nanog@nanog.org>
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
>
> Hi, Pascal:
>
> 1)" ...  for the next version. ...":I am not sure that I can
> wait for so long, because I am asking for the basics. The reason that I
> asked for an IP packet header example of your proposal is to visualize what
> do you mean by the model of "realms and shafts in a multi-level building".
> The presentation in the draft  sounds okay, because the floors are
> physically isolated from one another. And, even the building is isolated
> from

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Vasilenko Eduard via NANOG]

Then change it. It may still be programmed on loopbacks, but treat it as 
anycast.

-Original Message-
From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] 
Sent: Monday, April 4, 2022 8:50 PM
To: Vasilenko Eduard 
Cc: Nicholas Warren ; Abraham Y. Chen 
; Justin Streiner ; NANOG 

Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hello Eduard 

In the YADA draft 240.0.0.1 is effectively programmed on the shaft router loop 
ack and used as router ID on the IGP inside the shaft…

240 addresses are the only ones advertised by the IGP. No prefix,


Regards,

Pascal

> Le 4 avr. 2022 à 19:41, Pascal Thubert (pthubert)  a 
> écrit :
> 
> 
> About IBM I meant that they already live in a wall garden that is limited in 
> size to one /8.
> 
> They could move it to another realm without renumbering, and now they would 
> have 200 times more addresses for whatever else they need.
> 
> They could still own their /8 in the main internet and repurpose it as 
> they wish…
> 
> Regards,
> 
> Pascal
> 
>> Le 4 avr. 2022 à 19:36, Vasilenko Eduard  a 
>> écrit :
>> 
>> 240.0.01.1 address is appointed not to the router. It is appointed to Realm.
>> It is up to the realm owner (ISP to Enterprise) what particular router (or 
>> routers) would do translation between realms.
>> 
>> -Original Message-
>> From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
>> Sent: Monday, April 4, 2022 7:20 PM
>> To: Nicholas Warren ; Vasilenko Eduard 
>> ; Abraham Y. Chen ; 
>> Justin Streiner 
>> Cc: NANOG 
>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported 
>> re: 202203261833.AYC
>> 
>> Hello Nicholas
>> 
>> Sorry for the distraction with the names; I did not forge realm, found it in 
>> the art. OTOH I created shaft because of elevator shaft, could have used 
>> staircase.
>> 
>> 
>>> In practice this extends IPv4 addresses by 32 bits, making them 64 
>>> bits in total. They are referring to the top 32 bits (240.0.0.0/6) as a 
>>> “shaft.”
>>> The bottom 32 bits make up the "realm."
>> 
>> 
>> 
>> 
>>> Here is the way my teeny tiny brain understands it:
>>> 1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
>> 
>> On address per realm, yes. The we create an IXP where my 240.0.0.1 discovers 
>> your 240.0.0.2.
>> Depending on the size of the shaft, we can have an IGP, probably not BGP 
>> though. Because The 240.0.01.1 address could litelally be the router ID and 
>> there would be nothing else advertised inside the shaft.
>> 
>> 
>>> 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 
>>> that is our shaft.
>> 
>> Inside your realm you inject 240.0.0.0/6. You roulm router(s) attract all 
>> traffic to the shaft. Traffic that remains inside the realm is routed 
>> normally, no IP in IP. Traffic towards another realm has the outer 240.0.0.2 
>> destination.
>> 
>> 
>> 
>>> 3. We setup our networks to use the bottom 32 bits however we see 
>>> fit in our network. (for the example, I assign my client 1.2.3.4 and 
>>> you assign your client 4.3.2.1) 4. Somehow, we get DNS to hand out 
>>> 64 bit addresses, probably through a  and just ignoring the last 64 
>>> bits.
>> 
>> Or a new AA, yes
>> 
>> 4?
>> 
>> 
>>> 5. My client, assigned the address 1.2.3.4 in my realm, queries your 
>>> client's address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
>> 
>> Yes
>> 
>> 
>> 
>>> 6. My client then sends your client a packet (IPv4 source: 
>>> 240.0.0.1;
>>> IPv4
>>> destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4;
>>> IPv4
>>> destination: 4.3.2.1) 7. 240.0.0.0/6 is routable on plain old normal 
>>> internet routers, so nothing needs to be changed. (lol)
>> 
>> Hopefully the routers are less subject to 240 hiccups than the hosts. I'm 
>> not aware of code in our boxes that does anything special about it but then 
>> the code base is large.
>> Now, 240 is just because F000/6 is free in IPv6 so you can literally place 
>> the 2 IPv4 in one IPv6 /64. Otherwise there will be some nastly little 
>> natting there too.
>> 
>> 7?
>> 
>>> 8a. Your router receives the packet, and your router does special things 
>>> with its shaft.
>>> (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
>>> (IPv4); IPv4 sourc

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Hello Eduard 

In the YADA draft 240.0.0.1 is effectively programmed on the shaft router loop 
ack and used as router ID on the IGP inside the shaft…

240 addresses are the only ones advertised by the IGP. No prefix,


Regards,

Pascal

> Le 4 avr. 2022 à 19:41, Pascal Thubert (pthubert)  a 
> écrit :
> 
> 
> About IBM I meant that they already live in a wall garden that is limited in 
> size to one /8.
> 
> They could move it to another realm without renumbering, and now they would 
> have 200 times more addresses for whatever else they need.
> 
> They could still own their /8 in the main internet and repurpose it as they 
> wish…
> 
> Regards,
> 
> Pascal
> 
>> Le 4 avr. 2022 à 19:36, Vasilenko Eduard  a 
>> écrit :
>> 
>> 240.0.01.1 address is appointed not to the router. It is appointed to Realm.
>> It is up to the realm owner (ISP to Enterprise) what particular router (or 
>> routers) would do translation between realms.
>> 
>> -Original Message-
>> From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] 
>> Sent: Monday, April 4, 2022 7:20 PM
>> To: Nicholas Warren ; Vasilenko Eduard 
>> ; Abraham Y. Chen ; Justin 
>> Streiner 
>> Cc: NANOG 
>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
>> 202203261833.AYC
>> 
>> Hello Nicholas
>> 
>> Sorry for the distraction with the names; I did not forge realm, found it in 
>> the art. OTOH I created shaft because of elevator shaft, could have used 
>> staircase.
>> 
>> 
>>> In practice this extends IPv4 addresses by 32 bits, making them 64 
>>> bits in total. They are referring to the top 32 bits (240.0.0.0/6) as a 
>>> “shaft.”
>>> The bottom 32 bits make up the "realm."
>> 
>> 
>> 
>> 
>>> Here is the way my teeny tiny brain understands it:
>>> 1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
>> 
>> On address per realm, yes. The we create an IXP where my 240.0.0.1 discovers 
>> your 240.0.0.2.
>> Depending on the size of the shaft, we can have an IGP, probably not BGP 
>> though. Because The 240.0.01.1 address could litelally be the router ID and 
>> there would be nothing else advertised inside the shaft.
>> 
>> 
>>> 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 
>>> that is our shaft.
>> 
>> Inside your realm you inject 240.0.0.0/6. You roulm router(s) attract all 
>> traffic to the shaft. Traffic that remains inside the realm is routed 
>> normally, no IP in IP. Traffic towards another realm has the outer 240.0.0.2 
>> destination.
>> 
>> 
>> 
>>> 3. We setup our networks to use the bottom 32 bits however we see fit 
>>> in our network. (for the example, I assign my client 1.2.3.4 and you 
>>> assign your client 4.3.2.1) 4. Somehow, we get DNS to hand out 64 bit 
>>> addresses, probably through a  and just ignoring the last 64 bits.
>> 
>> Or a new AA, yes
>> 
>> 4?
>> 
>> 
>>> 5. My client, assigned the address 1.2.3.4 in my realm, queries your 
>>> client's address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
>> 
>> Yes
>> 
>> 
>> 
>>> 6. My client then sends your client a packet (IPv4 source: 240.0.0.1; 
>>> IPv4
>>> destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; 
>>> IPv4
>>> destination: 4.3.2.1) 7. 240.0.0.0/6 is routable on plain old normal 
>>> internet routers, so nothing needs to be changed. (lol)
>> 
>> Hopefully the routers are less subject to 240 hiccups than the hosts. I'm 
>> not aware of code in our boxes that does anything special about it but then 
>> the code base is large.
>> Now, 240 is just because F000/6 is free in IPv6 so you can literally place 
>> the 2 IPv4 in one IPv6 /64. Otherwise there will be some nastly little 
>> natting there too.
>> 
>> 7?
>> 
>>> 8a. Your router receives the packet, and your router does special things 
>>> with its shaft.
>>> (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
>>> (IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_)
>> 
>>> 8b. Alternatively, every router in your network could determine next 
>>> hop by investigating the second header when the destination is your shaft.
>> 
>> 8b is not suggested, because in your example I could be the Internet.
>> 
>> 
>>> 9. Your client receives the packet and can either handle this case in 
>

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

About IBM I meant that they already live in a wall garden that is limited in 
size to one /8.

They could move it to another realm without renumbering, and now they would 
have 200 times more addresses for whatever else they need.

They could still own their /8 in the main internet and repurpose it as they 
wish…

Regards,

Pascal

> Le 4 avr. 2022 à 19:36, Vasilenko Eduard  a 
> écrit :
> 
> 240.0.01.1 address is appointed not to the router. It is appointed to Realm.
> It is up to the realm owner (ISP to Enterprise) what particular router (or 
> routers) would do translation between realms.
> 
> -Original Message-
> From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] 
> Sent: Monday, April 4, 2022 7:20 PM
> To: Nicholas Warren ; Vasilenko Eduard 
> ; Abraham Y. Chen ; Justin 
> Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
> 202203261833.AYC
> 
> Hello Nicholas
> 
> Sorry for the distraction with the names; I did not forge realm, found it in 
> the art. OTOH I created shaft because of elevator shaft, could have used 
> staircase.
> 
> 
>> In practice this extends IPv4 addresses by 32 bits, making them 64 
>> bits in total. They are referring to the top 32 bits (240.0.0.0/6) as a 
>> “shaft.”
>> The bottom 32 bits make up the "realm."
> 
> 
> 
> 
>> Here is the way my teeny tiny brain understands it:
>> 1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
> 
> On address per realm, yes. The we create an IXP where my 240.0.0.1 discovers 
> your 240.0.0.2.
> Depending on the size of the shaft, we can have an IGP, probably not BGP 
> though. Because The 240.0.01.1 address could litelally be the router ID and 
> there would be nothing else advertised inside the shaft.
> 
> 
>> 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 
>> that is our shaft.
> 
> Inside your realm you inject 240.0.0.0/6. You roulm router(s) attract all 
> traffic to the shaft. Traffic that remains inside the realm is routed 
> normally, no IP in IP. Traffic towards another realm has the outer 240.0.0.2 
> destination.
> 
> 
> 
>> 3. We setup our networks to use the bottom 32 bits however we see fit 
>> in our network. (for the example, I assign my client 1.2.3.4 and you 
>> assign your client 4.3.2.1) 4. Somehow, we get DNS to hand out 64 bit 
>> addresses, probably through a  and just ignoring the last 64 bits.
> 
> Or a new AA, yes
> 
> 4?
> 
> 
>> 5. My client, assigned the address 1.2.3.4 in my realm, queries your 
>> client's address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
> 
> Yes
> 
> 
> 
>> 6. My client then sends your client a packet (IPv4 source: 240.0.0.1; 
>> IPv4
>> destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; 
>> IPv4
>> destination: 4.3.2.1) 7. 240.0.0.0/6 is routable on plain old normal 
>> internet routers, so nothing needs to be changed. (lol)
> 
> Hopefully the routers are less subject to 240 hiccups than the hosts. I'm not 
> aware of code in our boxes that does anything special about it but then the 
> code base is large.
> Now, 240 is just because F000/6 is free in IPv6 so you can literally place 
> the 2 IPv4 in one IPv6 /64. Otherwise there will be some nastly little 
> natting there too.
> 
> 7?
> 
>> 8a. Your router receives the packet, and your router does special things 
>> with its shaft.
>> (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
>> (IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_)
> 
>> 8b. Alternatively, every router in your network could determine next 
>> hop by investigating the second header when the destination is your shaft.
> 
> 8b is not suggested, because in your example I could be the Internet.
> 
> 
>> 9. Your client receives the packet and can either handle this case in 
>> a special way or translate it to a v6 address for higher level applications.
> 
> The socket be updated to could understand the AA and play ball. Or 
> statelesslessly NAT to IPv6, yes. This uses a well known IID that the IPv6 
> stack would autoconf it automatically when handed out a prefix in the F000/6 
> range. Note that it's a also /64 per host, which many have been asking for a 
> while.
> 
> 
>> No, as a matter of fact, I don't know I'm talking about. Hopefully one 
>> of the authors can correct my walkthrough of how it works 
> 
> You were mostly there. Just that routing inside the shaft is probably a 
> single IGP with no prefix attached, just links and router IDs.
> 
>> 
>> Shaft and 

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Vasilenko Eduard via NANOG]

240.0.01.1 address is appointed not to the router. It is appointed to Realm.
It is up to the realm owner (ISP to Enterprise) what particular router (or 
routers) would do translation between realms.

-Original Message-
From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] 
Sent: Monday, April 4, 2022 7:20 PM
To: Nicholas Warren ; Vasilenko Eduard 
; Abraham Y. Chen ; Justin 
Streiner 
Cc: NANOG 
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hello Nicholas

Sorry for the distraction with the names; I did not forge realm, found it in 
the art. OTOH I created shaft because of elevator shaft, could have used 
staircase.

 
> In practice this extends IPv4 addresses by 32 bits, making them 64 
> bits in total. They are referring to the top 32 bits (240.0.0.0/6) as a 
> “shaft.”
> The bottom 32 bits make up the "realm."



 
> Here is the way my teeny tiny brain understands it:
> 1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.

On address per realm, yes. The we create an IXP where my 240.0.0.1 discovers 
your 240.0.0.2.
Depending on the size of the shaft, we can have an IGP, probably not BGP 
though. Because The 240.0.01.1 address could litelally be the router ID and 
there would be nothing else advertised inside the shaft.


> 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 
> that is our shaft.

Inside your realm you inject 240.0.0.0/6. You roulm router(s) attract all 
traffic to the shaft. Traffic that remains inside the realm is routed normally, 
no IP in IP. Traffic towards another realm has the outer 240.0.0.2 destination.



> 3. We setup our networks to use the bottom 32 bits however we see fit 
> in our network. (for the example, I assign my client 1.2.3.4 and you 
> assign your client 4.3.2.1) 4. Somehow, we get DNS to hand out 64 bit 
> addresses, probably through a  and just ignoring the last 64 bits.

Or a new AA, yes

4?


> 5. My client, assigned the address 1.2.3.4 in my realm, queries your 
> client's address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.

Yes



> 6. My client then sends your client a packet (IPv4 source: 240.0.0.1; 
> IPv4
> destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; 
> IPv4
> destination: 4.3.2.1) 7. 240.0.0.0/6 is routable on plain old normal 
> internet routers, so nothing needs to be changed. (lol)

Hopefully the routers are less subject to 240 hiccups than the hosts. I'm not 
aware of code in our boxes that does anything special about it but then the 
code base is large.
Now, 240 is just because F000/6 is free in IPv6 so you can literally place the 
2 IPv4 in one IPv6 /64. Otherwise there will be some nastly little natting 
there too.

7?

> 8a. Your router receives the packet, and your router does special things with 
> its shaft.
> (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
> (IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_)

> 8b. Alternatively, every router in your network could determine next 
> hop by investigating the second header when the destination is your shaft.

8b is not suggested, because in your example I could be the Internet.


> 9. Your client receives the packet and can either handle this case in 
> a special way or translate it to a v6 address for higher level applications.

The socket be updated to could understand the AA and play ball. Or 
statelesslessly NAT to IPv6, yes. This uses a well known IID that the IPv6 
stack would autoconf it automatically when handed out a prefix in the F000/6 
range. Note that it's a also /64 per host, which many have been asking for a 
while.

 
> No, as a matter of fact, I don't know I'm talking about. Hopefully one 
> of the authors can correct my walkthrough of how it works 

You were mostly there. Just that routing inside the shaft is probably a single 
IGP with no prefix attached, just links and router IDs.

> 
> Shaft and realm are fun words. I see why they picked them.
> 

Cool 

Keep safe;

Pascal


> - Nich
> 
> From: NANOG  On 
> Behalf Of Vasilenko Eduard via NANOG
> Sent: Monday, April 4, 2022 3:28 AM
> To: Abraham Y. Chen ; Pascal Thubert (pthubert) 
> ; Justin Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 2)    When you extend each floor to use the whole IPv4 address pool, 
> however, you are essential talking about covering the entire surface 
> of the earth. Then, there is no isolated buildings with isolated 
> floors to deploy your model anymore. There is only one spherical layer 
> of physical earth surface for you to use as a realm, which is the 
> current IPv4 deployment. How could you still have multiple full IPv4 
> address sets deployed, yet not seeing their identical twins, trip

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Vasilenko Eduard via NANOG]

Hi Pascal,
The world has moved to 32bit AS# not far in the past. For sure, AS# would not 
cross 28bits.
I do not understand why you need something different from AS# to point to the 
Realm.
The one who would need a new realm - could go to RIR and ask for AS. Realm 
would be calculated automatically as 240.0.0.0+AS#.

I fail to see why you continue talking about IBM property.
Why do you need it?
Why do you believe IBM would grant it to the community?
Eduard
-Original Message-
From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] 
Sent: Monday, April 4, 2022 7:27 PM
To: Vasilenko Eduard ; Nicholas Warren 
; Abraham Y. Chen ; Justin 
Streiner 
Cc: NANOG 
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hello Eduard

As (badly) written, all ASes and IP addresses that exist today in the internet 
could be either reused or moved in any parallel realm. 

Now that the ASN space is 32 bits, there would not be room for non-ASN based 
shaft routers. I fail to see the value in conflating.

IBM could move 9.0.0.0 to another realm, and then grow outside of 9.0.0.0 to 
whatever they need inside. The YADA format would not be much worse than the 
socks they used at the time I was there.

That's the way I prefer it, but happy to see the little bird fly from the nest 
and become what it likes.

Keep safe;

Pascal

> -Original Message-
> From: Vasilenko Eduard 
> Sent: lundi 4 avril 2022 16:52
> To: Nicholas Warren ; Abraham Y. Chen 
> ; Pascal Thubert (pthubert) ; 
> Justin Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> Hi Nicholas,
> In fact, your explanation is much better than the draft explanation.
> Could I propose a small modification?
> Every AS announces 240.0.0.0 + AS# that they already have then there 
> is no need for "shafts from ARIN" - AS# is already distributed and unique.
> Eduard
> -Original Message-
> From: Nicholas Warren [mailto:nwar...@barryelectric.com]
> Sent: Monday, April 4, 2022 5:33 PM
> To: Vasilenko Eduard ; Abraham Y. Chen 
> ; Pascal Thubert (pthubert) ; 
> Justin Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> The vocabulary is distracting...
> 
> In practice this extends IPv4 addresses by 32 bits, making them 64 
> bits in total. They are referring to the top 32 bits (240.0.0.0/6) as a 
> “shaft.”
> The bottom 32 bits make up the "realm."
> 
> Here is the way my teeny tiny brain understands it:
> 1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
> 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 
> that is our shaft.
> 3. We setup our networks to use the bottom 32 bits however we see fit 
> in our network. (for the example, I assign my client 1.2.3.4 and you 
> assign your client 4.3.2.1) 4. Somehow, we get DNS to hand out 64 bit 
> addresses, probably through a  and just ignoring the last 64 bits.
> 5. My client, assigned the address 1.2.3.4 in my realm, queries your 
> client's address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
> 6. My client then sends your client a packet (IPv4 source: 240.0.0.1; 
> IPv4
> destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; 
> IPv4
> destination: 4.3.2.1) 7. 240.0.0.0/6 is routable on plain old normal 
> internet routers, so nothing needs to be changed. (lol) 8a. Your 
> router receives the packet, and your router does special things with its 
> shaft.
> (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
> (IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_) 8b.
> Alternatively, every router in your network could determine next hop 
> by investigating the second header when the destination is your shaft.
> 9. Your client receives the packet and can either handle this case in 
> a special way or translate it to a v6 address for higher level applications.
> 
> No, as a matter of fact, I don't know I'm talking about. Hopefully one 
> of the authors can correct my walkthrough of how it works 
> 
> Shaft and realm are fun words. I see why they picked them.
> 
> - Nich
> 
> From: NANOG  On 
> Behalf Of Vasilenko Eduard via NANOG
> Sent: Monday, April 4, 2022 3:28 AM
> To: Abraham Y. Chen ; Pascal Thubert (pthubert) 
> ; Justin Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 2)    When you extend each floor to use the whole IPv4 address pool, 
> however, you are essential talking about covering the entire surface 
> of the earth. Then, there is no isolated buildings with isolated 
> floors to deploy your model anymore. T

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Hello Eduard

As (badly) written, all ASes and IP addresses that exist today in the internet 
could be either reused or moved in any parallel realm. 

Now that the ASN space is 32 bits, there would not be room for non-ASN based 
shaft routers. I fail to see the value in conflating.

IBM could move 9.0.0.0 to another realm, and then grow outside of 9.0.0.0 to 
whatever they need inside. The YADA format would not be much worse than the 
socks they used at the time I was there.

That's the way I prefer it, but happy to see the little bird fly from the nest 
and become what it likes.

Keep safe;

Pascal

> -Original Message-
> From: Vasilenko Eduard 
> Sent: lundi 4 avril 2022 16:52
> To: Nicholas Warren ; Abraham Y. Chen
> ; Pascal Thubert (pthubert) ;
> Justin Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> Hi Nicholas,
> In fact, your explanation is much better than the draft explanation.
> Could I propose a small modification?
> Every AS announces 240.0.0.0 + AS# that they already have then there is no
> need for "shafts from ARIN" - AS# is already distributed and unique.
> Eduard
> -Original Message-
> From: Nicholas Warren [mailto:nwar...@barryelectric.com]
> Sent: Monday, April 4, 2022 5:33 PM
> To: Vasilenko Eduard ; Abraham Y. Chen
> ; Pascal Thubert (pthubert) ;
> Justin Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> The vocabulary is distracting...
> 
> In practice this extends IPv4 addresses by 32 bits, making them 64 bits in
> total. They are referring to the top 32 bits (240.0.0.0/6) as a “shaft.”
> The bottom 32 bits make up the "realm."
> 
> Here is the way my teeny tiny brain understands it:
> 1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
> 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 that
> is our shaft.
> 3. We setup our networks to use the bottom 32 bits however we see fit in
> our network. (for the example, I assign my client 1.2.3.4 and you assign
> your client 4.3.2.1) 4. Somehow, we get DNS to hand out 64 bit addresses,
> probably through a  and just ignoring the last 64 bits.
> 5. My client, assigned the address 1.2.3.4 in my realm, queries your
> client's address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
> 6. My client then sends your client a packet (IPv4 source: 240.0.0.1; IPv4
> destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4
> destination: 4.3.2.1) 7. 240.0.0.0/6 is routable on plain old normal
> internet routers, so nothing needs to be changed. (lol) 8a. Your router
> receives the packet, and your router does special things with its shaft.
> (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4
> (IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_) 8b.
> Alternatively, every router in your network could determine next hop by
> investigating the second header when the destination is your shaft.
> 9. Your client receives the packet and can either handle this case in a
> special way or translate it to a v6 address for higher level applications.
> 
> No, as a matter of fact, I don't know I'm talking about. Hopefully one of
> the authors can correct my walkthrough of how it works 
> 
> Shaft and realm are fun words. I see why they picked them.
> 
> - Nich
> 
> From: NANOG  On Behalf
> Of Vasilenko Eduard via NANOG
> Sent: Monday, April 4, 2022 3:28 AM
> To: Abraham Y. Chen ; Pascal Thubert (pthubert)
> ; Justin Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 2)    When you extend each floor to use the whole IPv4 address pool,
> however, you are essential talking about covering the entire surface of
> the earth. Then, there is no isolated buildings with isolated floors to
> deploy your model anymore. There is only one spherical layer of physical
> earth surface for you to use as a realm, which is the current IPv4
> deployment. How could you still have multiple full IPv4 address sets
> deployed, yet not seeing their identical twins, triplets, etc.? Are you
> proposing multiple spherical layers of "realms", one on top of the other?
> 
> It is the same as what I was trying to explain to Pascal. How to map the
> 2-level hierarchy of the draft (“Shaft”:”Realm”) to the real world?
> I am sure that it is possible to do this if assume that the real world has
> 2 levels of hierarchy where the high level is “BGP AS”.
> “BGP AS” is the name that everybody understands, No need for a new name
> “Shaft”.
> 
> Ed/
> From: Abraham Y. Chen [mailto:ayc...@avinta.c

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Hello Nicholas

Sorry for the distraction with the names; I did not forge realm, found it in 
the art. OTOH I created shaft because of elevator shaft, could have used 
staircase.

 
> In practice this extends IPv4 addresses by 32 bits, making them 64 bits in
> total. They are referring to the top 32 bits (240.0.0.0/6) as a “shaft.”
> The bottom 32 bits make up the "realm."



 
> Here is the way my teeny tiny brain understands it:
> 1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.

On address per realm, yes. The we create an IXP where my 240.0.0.1 discovers 
your 240.0.0.2.
Depending on the size of the shaft, we can have an IGP, probably not BGP 
though. Because The 240.0.01.1 address could litelally be the router ID and 
there would be nothing else advertised inside the shaft.


> 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 that
> is our shaft.

Inside your realm you inject 240.0.0.0/6. You roulm router(s) attract all 
traffic to the shaft. Traffic that remains inside the realm is routed normally, 
no IP in IP. Traffic towards another realm has the outer 240.0.0.2 destination.



> 3. We setup our networks to use the bottom 32 bits however we see fit in
> our network. (for the example, I assign my client 1.2.3.4 and you assign
> your client 4.3.2.1) 4. Somehow, we get DNS to hand out 64 bit addresses,
> probably through a  and just ignoring the last 64 bits.

Or a new AA, yes

4?


> 5. My client, assigned the address 1.2.3.4 in my realm, queries your
> client's address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.

Yes



> 6. My client then sends your client a packet (IPv4 source: 240.0.0.1; IPv4
> destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4
> destination: 4.3.2.1) 7. 240.0.0.0/6 is routable on plain old normal
> internet routers, so nothing needs to be changed. (lol) 

Hopefully the routers are less subject to 240 hiccups than the hosts. I'm not 
aware of code in our boxes that does anything special about it but then the 
code base is large.
Now, 240 is just because F000/6 is free in IPv6 so you can literally place the 
2 IPv4 in one IPv6 /64. Otherwise there will be some nastly little natting 
there too.

7?

> 8a. Your router receives the packet, and your router does special things with 
> its shaft.
> (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4
> (IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_) 

> 8b. Alternatively, every router in your network could determine next hop by
> investigating the second header when the destination is your shaft.

8b is not suggested, because in your example I could be the Internet.


> 9. Your client receives the packet and can either handle this case in a
> special way or translate it to a v6 address for higher level applications.

The socket be updated to could understand the AA and play ball. Or 
statelesslessly NAT to IPv6, yes. This uses a well known IID that the IPv6 
stack would autoconf it automatically when handed out a prefix in the F000/6 
range. Note that it's a also /64 per host, which many have been asking for a 
while.

 
> No, as a matter of fact, I don't know I'm talking about. Hopefully one of
> the authors can correct my walkthrough of how it works 

You were mostly there. Just that routing inside the shaft is probably a single 
IGP with no prefix attached, just links and router IDs.

> 
> Shaft and realm are fun words. I see why they picked them.
> 

Cool 

Keep safe;

Pascal


> - Nich
> 
> From: NANOG  On Behalf
> Of Vasilenko Eduard via NANOG
> Sent: Monday, April 4, 2022 3:28 AM
> To: Abraham Y. Chen ; Pascal Thubert (pthubert)
> ; Justin Streiner 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 2)    When you extend each floor to use the whole IPv4 address pool,
> however, you are essential talking about covering the entire surface of
> the earth. Then, there is no isolated buildings with isolated floors to
> deploy your model anymore. There is only one spherical layer of physical
> earth surface for you to use as a realm, which is the current IPv4
> deployment. How could you still have multiple full IPv4 address sets
> deployed, yet not seeing their identical twins, triplets, etc.? Are you
> proposing multiple spherical layers of "realms", one on top of the other?
> 
> It is the same as what I was trying to explain to Pascal. How to map the
> 2-level hierarchy of the draft (“Shaft”:”Realm”) to the real world?
> I am sure that it is possible to do this if assume that the real world has
> 2 levels of hierarchy where the high level is “BGP AS”.
> “BGP AS” is the name that everybody understands, No need for a new name
> “Shaft”.
> 
> Ed/
> From: Abraham Y.

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Vasilenko Eduard via NANOG]

Hi Nicholas,
In fact, your explanation is much better than the draft explanation.
Could I propose a small modification?
Every AS announces 240.0.0.0 + AS# that they already have
then there is no need for "shafts from ARIN" - AS# is already distributed and 
unique.
Eduard
-Original Message-
From: Nicholas Warren [mailto:nwar...@barryelectric.com] 
Sent: Monday, April 4, 2022 5:33 PM
To: Vasilenko Eduard ; Abraham Y. Chen 
; Pascal Thubert (pthubert) ; Justin 
Streiner 
Cc: NANOG 
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

The vocabulary is distracting...

In practice this extends IPv4 addresses by 32 bits, making them 64 bits in 
total. They are referring to the top 32 bits (240.0.0.0/6) as a “shaft.” The 
bottom 32 bits make up the "realm."

Here is the way my teeny tiny brain understands it:
1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
2. We announce our shiny new shafts in BGP. Yes, we announce the /32 that is 
our shaft.
3. We setup our networks to use the bottom 32 bits however we see fit in our 
network. (for the example, I assign my client 1.2.3.4 and you assign your 
client 4.3.2.1)
4. Somehow, we get DNS to hand out 64 bit addresses, probably through a  
and just ignoring the last 64 bits.
5. My client, assigned the address 1.2.3.4 in my realm, queries your client's 
address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
6. My client then sends your client a packet (IPv4 source: 240.0.0.1; IPv4 
destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4 
destination: 4.3.2.1)
7. 240.0.0.0/6 is routable on plain old normal internet routers, so nothing 
needs to be changed. (lol)
8a. Your router receives the packet, and your router does special things with 
its shaft. (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
(IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_)
8b. Alternatively, every router in your network could determine next hop by 
investigating the second header when the destination is your shaft.
9. Your client receives the packet and can either handle this case in a special 
way or translate it to a v6 address for higher level applications.

No, as a matter of fact, I don't know I'm talking about. Hopefully one of the 
authors can correct my walkthrough of how it works 

Shaft and realm are fun words. I see why they picked them.

- Nich

From: NANOG  On Behalf Of 
Vasilenko Eduard via NANOG
Sent: Monday, April 4, 2022 3:28 AM
To: Abraham Y. Chen ; Pascal Thubert (pthubert) 
; Justin Streiner 
Cc: NANOG 
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

2)    When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
there is no isolated buildings with isolated floors to deploy your model 
anymore. There is only one spherical layer of physical earth surface for you to 
use as a realm, which is the current IPv4 deployment. How could you still have 
multiple full IPv4 address sets deployed, yet not seeing their identical twins, 
triplets, etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?

It is the same as what I was trying to explain to Pascal. How to map the 
2-level hierarchy of the draft (“Shaft”:”Realm”) to the real world?
I am sure that it is possible to do this if assume that the real world has 2 
levels of hierarchy where the high level is “BGP AS”.
“BGP AS” is the name that everybody understands, No need for a new name “Shaft”.

Ed/
From: Abraham Y. Chen [mailto:ayc...@avinta.com]
Sent: Saturday, April 2, 2022 12:45 AM
To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Justin Streiner 
<mailto:strein...@gmail.com>
Cc: NANOG <mailto:nanog@nanog.org>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi, Pascal:

1)    " ...  for the next version. ...    ":    I am not sure that I can wait 
for so long, because I am asking for the basics. The reason that I asked for an 
IP packet header example of your proposal is to visualize what do you mean by 
the model of "realms and shafts in a multi-level building". The presentation in 
the draft  sounds okay, because the floors are physically isolated from one 
another. And, even the building is isolated from other buildings. This is 
pretty much how PBX numbering plan worked. 

2)    When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
there is no isolated buildings with isolated floors to deploy your model 
anymore. There is only one spherical layer of physical earth surface for you to 
use as a realm, which is the current IPv4 deployment. How could you 

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Nicholas Warren]

The vocabulary is distracting...

In practice this extends IPv4 addresses by 32 bits, making them 64 bits in 
total. They are referring to the top 32 bits (240.0.0.0/6) as a “shaft.” The 
bottom 32 bits make up the "realm."

Here is the way my teeny tiny brain understands it:
1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2.
2. We announce our shiny new shafts in BGP. Yes, we announce the /32 that is 
our shaft.
3. We setup our networks to use the bottom 32 bits however we see fit in our 
network. (for the example, I assign my client 1.2.3.4 and you assign your 
client 4.3.2.1)
4. Somehow, we get DNS to hand out 64 bit addresses, probably through a  
and just ignoring the last 64 bits.
5. My client, assigned the address 1.2.3.4 in my realm, queries your client's 
address "shaft:240.0.0.2; realm 4.3.2.1" from DNS.
6. My client then sends your client a packet (IPv4 source: 240.0.0.1; IPv4 
destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4 
destination: 4.3.2.1)
7. 240.0.0.0/6 is routable on plain old normal internet routers, so nothing 
needs to be changed. (lol)
8a. Your router receives the packet, and your router does special things with 
its shaft. (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 
(IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_)
8b. Alternatively, every router in your network could determine next hop by 
investigating the second header when the destination is your shaft.
9. Your client receives the packet and can either handle this case in a special 
way or translate it to a v6 address for higher level applications.

No, as a matter of fact, I don't know I'm talking about. Hopefully one of the 
authors can correct my walkthrough of how it works 

Shaft and realm are fun words. I see why they picked them.

- Nich

From: NANOG  On Behalf Of 
Vasilenko Eduard via NANOG
Sent: Monday, April 4, 2022 3:28 AM
To: Abraham Y. Chen ; Pascal Thubert (pthubert) 
; Justin Streiner 
Cc: NANOG 
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

2)    When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
there is no isolated buildings with isolated floors to deploy your model 
anymore. There is only one spherical layer of physical earth surface for you to 
use as a realm, which is the current IPv4 deployment. How could you still have 
multiple full IPv4 address sets deployed, yet not seeing their identical twins, 
triplets, etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?

It is the same as what I was trying to explain to Pascal. How to map the 
2-level hierarchy of the draft (“Shaft”:”Realm”) to the real world?
I am sure that it is possible to do this if assume that the real world has 2 
levels of hierarchy where the high level is “BGP AS”.
“BGP AS” is the name that everybody understands, No need for a new name “Shaft”.

Ed/
From: Abraham Y. Chen [mailto:ayc...@avinta.com] 
Sent: Saturday, April 2, 2022 12:45 AM
To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Justin Streiner 
<mailto:strein...@gmail.com>
Cc: NANOG <mailto:nanog@nanog.org>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi, Pascal:

1)    " ...  for the next version. ...    ":    I am not sure that I can wait 
for so long, because I am asking for the basics. The reason that I asked for an 
IP packet header example of your proposal is to visualize what do you mean by 
the model of "realms and shafts in a multi-level building". The presentation in 
the draft  sounds okay, because the floors are physically isolated from one 
another. And, even the building is isolated from other buildings. This is 
pretty much how PBX numbering plan worked. 

2)    When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
there is no isolated buildings with isolated floors to deploy your model 
anymore. There is only one spherical layer of physical earth surface for you to 
use as a realm, which is the current IPv4 deployment. How could you still have 
multiple full IPv4 address sets deployed, yet not seeing their identical twins, 
triplets, etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?

2)    When I cited the DotConnectAfrica graphic logo as a visual model for the 
EzIP deployment over current IPv4, I was pretty specific that each RAN was 
tethered from the current Internet core via one IPv4 address. We were very 
careful about isolating the netblocks in terms of which one does what. In other 
words, even though the collection of RANs form a parallel cyberspace to the 

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Vasilenko Eduard via NANOG]

2)When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
there is no isolated buildings with isolated floors to deploy your model 
anymore. There is only one spherical layer of physical earth surface for you to 
use as a realm, which is the current IPv4 deployment. How could you still have 
multiple full IPv4 address sets deployed, yet not seeing their identical twins, 
triplets, etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?

It is the same as what I was trying to explain to Pascal. How to map the 
2-level hierarchy of the draft (“Shaft”:”Realm”) to the real world?
I am sure that it is possible to do this if assume that the real world has 2 
levels of hierarchy where the high level is “BGP AS”.
“BGP AS” is the name that everybody understands, No need for a new name “Shaft”.

Ed/
From: Abraham Y. Chen [mailto:ayc...@avinta.com]
Sent: Saturday, April 2, 2022 12:45 AM
To: Pascal Thubert (pthubert) ; Vasilenko Eduard 
; Justin Streiner 
Cc: NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi, Pascal:

1)" ...  for the next version. ...":I am not sure that I can wait 
for so long, because I am asking for the basics. The reason that I asked for an 
IP packet header example of your proposal is to visualize what do you mean by 
the model of "realms and shafts in a multi-level building". The presentation in 
the draft  sounds okay, because the floors are physically isolated from one 
another. And, even the building is isolated from other buildings. This is 
pretty much how PBX numbering plan worked.

2)When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
there is no isolated buildings with isolated floors to deploy your model 
anymore. There is only one spherical layer of physical earth surface for you to 
use as a realm, which is the current IPv4 deployment. How could you still have 
multiple full IPv4 address sets deployed, yet not seeing their identical twins, 
triplets, etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?

2)When I cited the DotConnectAfrica graphic logo as a visual model for the 
EzIP deployment over current IPv4, I was pretty specific that each RAN was 
tethered from the current Internet core via one IPv4 address. We were very 
careful about isolating the netblocks in terms of which one does what. In other 
words, even though the collection of RANs form a parallel cyberspace to the 
Internet, you may look at each RAN as an isolated balloon for others. So that 
each RAN can use up the entire 240/4 netblock.

Please clarify your configuration.

Thanks,


Abe (2022-04-01 17:44)




On 2022-04-01 10:55, Abraham Y. Chen wrote:
On 2022-04-01 10:00, Pascal Thubert (pthubert) wrote:
Makes sense, Abe, for the next version.

Note that the intention is NOT any to ANY. A native IPv6 IoT device can only 
talk to another IPv6 device, where that other device may use a YATT address or 
any other IPv6 address.
But it cannot talk to a YADA node. That’s what I mean by baby steps for those 
who want to.

Keep safe;

Pascal

From: Abraham Y. Chen <mailto:ayc...@avinta.com>
Sent: vendredi 1 avril 2022 15:49
To: Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Pascal 
Thubert (pthubert) <mailto:pthub...@cisco.com>; Justin 
Streiner <mailto:strein...@gmail.com>
Cc: NANOG <mailto:nanog@nanog.org>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi, Pascal:

What I would appreciate is an IP packet header design/definition layout, 
word-by-word, ideally in bit-map style, of an explicit presentation of all IP 
addresses involved from one IoT in one realm to that in the second realm. This 
will provide a clearer picture of how the real world implementation may look 
like.

Thanks,


Abe (2022-04-01 09:48)


On 2022-04-01 08:49, Vasilenko Eduard wrote:
As I understand: “IPv4 Realms” between “Shaft” should be capable to have a 
plain IPv4 header (or else why all of these).
Then Gateway in the Shaft should change headers (from IPv4 to IPv6).
Who should implement this gateway and why? He should be formally appointed to 
such an exercise, right?
Map this 2 level hierarchy to the real world – you may fail with this.
Ed/
From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
Sent: Friday, April 1, 2022 3:41 PM
To: Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Justin 
Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen 
<mailto:ayc...@avinta.com>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hello Eduard:

Did you just demonstrate that POPs cannot exist? Or that there canno

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Pascal:

0)    As the good old saying stated: "A picture is worth one thousand 
words." Let's take advantage of such a teaching.


1)    Focusing at just the text before and after Figure 1 of your below 
draft, I found:


https://datatracker.ietf.org/doc/html/draft-thubert-v6ops-yada-yatt-01

    A.    " In the analogy of a building, */the ground floor would be 
the Interne/*t, and each additional floor would be */another IPv4 
realm/*.  ...  analog to */the full IPv4/**/addressing /*that is 
available in each realm.  ": Unless there is certain hidden refinement 
that I could not decipher, the combination of the three phrases 
highlighted above by me seems to refer to the entire IPv4 netblock, 
addresses and practices, etc., all inclusive. (By the way, the phrase 
"ground floor" appears to contradict the "(current IPv4 Internet)" label 
in the figure that is on the top floor (realm 1) of a building. Unless, 
you are presenting an underground building? But, we can regard this as a 
minor typo.)


    B.    " ... A single /24 IPv4 prefix assigned allows for*/> 250 
times the capacity of the Internet as we know it /*...   ": Are you 
visualizing that your YADA / YATT draft proposes creating >250 layers of 
cyberspace, each with the same capacity of the current Internet? If so, 
it will be fantastic. Then, how can you physically deploying that many 
layers, each fully covering the entire globe, yet without stepping on 
one another's toes (the identical IP addresses packed >250 deep)? That 
is, I failed to imagine what kind of mechanism that you have for 
isolating the layers, such as populating people accordingly.


Please clarify.

Regards,


Abe (2022-04-02 12:22 EDT)






On 2022-04-02 04:56, Pascal Thubert (pthubert) wrote:


That does not need to be long, Abe.

There’s no minimal interval between version. I already published 01… 
And I do not have a special address format beyond what’s in the draft 
already. It’s only IPv4 and IPv6. No new address format. Just assigned 
ranges, and well known IIDs.


To your point: the addresses in each realm are the full IPv4 that we 
know and they cannot talk directly between realms. They are indeed 
isolated. Nodes in different floors can only communicate through the 
shaft. Think of a human and a stairwell. The physical space reserved 
for the stair well at each level is the same.  What people do with the 
rest of the space is their own. All addresses and AS numbers are reusable.


I do not see you image of a sphere. My image of  a sphere is IPv6, 
that contains all the IPv4 “planes”, the shaft, and all the air in 
between.


You design uses the internet as shaft if you like. In that we differ. 
YADA leaves the internet as is, and allows to build other internets 
that cannot leak in one another. But participating nodes can 
communicate through the shaft.


If end nodes do not participate, then a stateful Nat is still needed. 
For most homes that means an upgrade of the stateful NAT in the 
gateway so the public side has a YATT format, and DNS snooping to 
provide a A record inside. Same for PLATs. For most servers, that 
means an update in the load balancer, and a NAT if there was none, to 
allow to speak to other realms. Whatever happened in the current IPv4 
can still do. Some levels can be created IPv6 only from the start, 
providing YATT addresses to those who need to communicate with the 
other levels.


Keep safe;

Pascal

*From:* Abraham Y. Chen 
*Sent:* vendredi 1 avril 2022 23:45
*To:* Pascal Thubert (pthubert) ; Vasilenko Eduard 
; Justin Streiner 

*Cc:* NANOG 
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Hi, Pascal:

1)    " ... for the next version. ...   ":    I am not sure that I can 
wait for so long, because I am asking for the basics. The reason that 
I asked for an IP packet header example of your proposal is to 
visualize what do you mean by the model of "realms and shafts in a 
multi-level building". The presentation in the draft sounds okay, 
because the floors are physically isolated from one another. And, even 
the building is isolated from other buildings. This is pretty much how 
PBX numbering plan worked.


2)    When you extend each floor to use the whole IPv4 address pool, 
however, you are essential talking about covering the entire surface 
of the earth. Then, there is no isolated buildings with isolated 
floors to deploy your model anymore. There is only one spherical layer 
of physical earth surface for you to use as a realm, which is the 
current IPv4 deployment. How could you still have multiple full IPv4 
address sets deployed, yet not seeing their identical twins, triplets, 
etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?


2)    When I cited the DotConnectAfrica graphic logo as a visual model 
for the EzIP deployment over current IPv4, I wa

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

That does not need to be long, Abe.

There’s no minimal interval between version. I already published 01… And I do 
not have a special address format beyond what’s in the draft already. It’s only 
IPv4 and IPv6. No new address format. Just assigned ranges, and well known IIDs.

To your point: the addresses in each realm are the full IPv4 that we know and 
they cannot talk directly between realms. They are indeed isolated. Nodes in 
different floors can only communicate through the shaft. Think of a human and a 
stairwell. The physical space reserved for the stair well at each level is the 
same.  What people do with the rest of the space is their own. All addresses 
and AS numbers are reusable.

I do not see you image of a sphere. My image of  a sphere is IPv6, that 
contains all the IPv4 “planes”, the shaft, and all the air in between.

You design uses the internet as shaft if you like. In that we differ. YADA 
leaves the internet as is, and allows to build other internets that cannot leak 
in one another. But participating nodes can communicate through the shaft.

If end nodes do not participate, then a stateful Nat is still needed. For most 
homes that means an upgrade of the stateful NAT in the gateway so the public 
side has a YATT format, and DNS snooping to provide a A record inside. Same for 
PLATs. For most servers, that means an update in the load balancer, and a NAT 
if there was none, to allow to speak to other realms. Whatever happened in the 
current IPv4 can still do. Some levels can be created IPv6 only from the start, 
providing YATT addresses to those who need to communicate with the other levels.

Keep safe;

Pascal

From: Abraham Y. Chen 
Sent: vendredi 1 avril 2022 23:45
To: Pascal Thubert (pthubert) ; Vasilenko Eduard 
; Justin Streiner 
Cc: NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi, Pascal:

1)" ...  for the next version. ...":I am not sure that I can wait 
for so long, because I am asking for the basics. The reason that I asked for an 
IP packet header example of your proposal is to visualize what do you mean by 
the model of "realms and shafts in a multi-level building". The presentation in 
the draft  sounds okay, because the floors are physically isolated from one 
another. And, even the building is isolated from other buildings. This is 
pretty much how PBX numbering plan worked.

2)When you extend each floor to use the whole IPv4 address pool, however, 
you are essential talking about covering the entire surface of the earth. Then, 
there is no isolated buildings with isolated floors to deploy your model 
anymore. There is only one spherical layer of physical earth surface for you to 
use as a realm, which is the current IPv4 deployment. How could you still have 
multiple full IPv4 address sets deployed, yet not seeing their identical twins, 
triplets, etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?

2)When I cited the DotConnectAfrica graphic logo as a visual model for the 
EzIP deployment over current IPv4, I was pretty specific that each RAN was 
tethered from the current Internet core via one IPv4 address. We were very 
careful about isolating the netblocks in terms of which one does what. In other 
words, even though the collection of RANs form a parallel cyberspace to the 
Internet, you may look at each RAN as an isolated balloon for others. So that 
each RAN can use up the entire 240/4 netblock.

Please clarify your configuration.

Thanks,


Abe (2022-04-01 17:44)




On 2022-04-01 10:55, Abraham Y. Chen wrote:
On 2022-04-01 10:00, Pascal Thubert (pthubert) wrote:
Makes sense, Abe, for the next version.

Note that the intention is NOT any to ANY. A native IPv6 IoT device can only 
talk to another IPv6 device, where that other device may use a YATT address or 
any other IPv6 address.
But it cannot talk to a YADA node. That’s what I mean by baby steps for those 
who want to.

Keep safe;

Pascal

From: Abraham Y. Chen <mailto:ayc...@avinta.com>
Sent: vendredi 1 avril 2022 15:49
To: Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Pascal 
Thubert (pthubert) <mailto:pthub...@cisco.com>; Justin 
Streiner <mailto:strein...@gmail.com>
Cc: NANOG <mailto:nanog@nanog.org>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi, Pascal:

What I would appreciate is an IP packet header design/definition layout, 
word-by-word, ideally in bit-map style, of an explicit presentation of all IP 
addresses involved from one IoT in one realm to that in the second realm. This 
will provide a clearer picture of how the real world implementation may look 
like.

Thanks,


Abe (2022-04-01 09:48)


On 2022-04-01 08:49, Vasilenko Eduard wrote:
As I understand: “IPv4 Realms” between “Shaft” should be capable to have a 
plain IPv4 header (or else why all of these).
Then G

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Pascal:

1)    " ... for the next version. ... ":    I am not sure that I can 
wait for so long, because I am asking for the basics. The reason that I 
asked for an IP packet header example of your proposal is to visualize 
what do you mean by the model of "realms and shafts in a multi-level 
building". The presentation in the draft  sounds okay, because the 
floors are physically isolated from one another. And, even the building 
is isolated from other buildings. This is pretty much how PBX numbering 
plan worked.


2)    When you extend each floor to use the whole IPv4 address pool, 
however, you are essential talking about covering the entire surface of 
the earth. Then, there is no isolated buildings with isolated floors to 
deploy your model anymore. There is only one spherical layer of physical 
earth surface for you to use as a realm, which is the current IPv4 
deployment. How could you still have multiple full IPv4 address sets 
deployed, yet not seeing their identical twins, triplets, etc.? Are you 
proposing multiple spherical layers of "realms", one on top of the other?


2)    When I cited the DotConnectAfrica graphic logo as a visual model 
for the EzIP deployment over current IPv4, I was pretty specific that 
each RAN was tethered from the current Internet core via one IPv4 
address. We were very careful about isolating the netblocks in terms of 
which one does what. In other words, even though the collection of RANs 
form a parallel cyberspace to the Internet, you may look at each RAN as 
an isolated balloon for others. So that each RAN can use up the entire 
240/4 netblock.


Please clarify your configuration.

Thanks,


Abe (2022-04-01 17:44)




On 2022-04-01 10:55, Abraham Y. Chen wrote:

On 2022-04-01 10:00, Pascal Thubert (pthubert) wrote:


Makes sense, Abe, for the next version.

Note that the intention is NOT any to ANY. A native IPv6 IoT device 
can only talk to another IPv6 device, where that other device may use 
a YATT address or any other IPv6 address.


But it cannot talk to a YADA node. That’s what I mean by baby steps 
for those who want to.


Keep safe;

Pascal

*From:* Abraham Y. Chen 
*Sent:* vendredi 1 avril 2022 15:49
*To:* Vasilenko Eduard ; Pascal Thubert 
(pthubert) ; Justin Streiner 

*Cc:* NANOG 
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Hi, Pascal:

What I would appreciate is an IP packet header design/definition 
layout, word-by-word, ideally in bit-map style, of an explicit 
presentation of all IP addresses involved from one IoT in one realm 
to that in the second realm. This will provide a clearer picture of 
how the real world implementation may look like.


Thanks,

Abe (2022-04-01 09:48)

On 2022-04-01 08:49, Vasilenko Eduard wrote:

As I understand: “IPv4 Realms” between “Shaft” should be capable
to have a plain IPv4 header (or else why all of these).

Then Gateway in the Shaft should change headers (from IPv4 to IPv6).

Who should implement this gateway and why? He should be formally
appointed to such an exercise, right?

Map this 2 level hierarchy to the real world – you may fail with
this.

Ed/

*From:* Pascal Thubert (pthubert) [mailto:pthub...@cisco.com
<mailto:pthub...@cisco.com>]
*Sent:* Friday, April 1, 2022 3:41 PM
*To:* Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Justin Streiner
 <mailto:strein...@gmail.com>; Abraham Y.
Chen  <mailto:ayc...@avinta.com>
    *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC

Hello Eduard:

Did you just demonstrate that POPs cannot exist? Or that there
cannot be a Default Free Zone?

I agree with your real world issue that some things will have to
be planned between stake holders, and that it will not be easy.

But you know what the French say about “impossible”.

Or to paraphrase Sir Arthur, now that we have eliminated all the
impossible transition scenarios, whatever remains…

There will be YADA prefixes just like there are root DNS. To be
managed by different players as you point out. And all routable
within the same shaft.

Keep safe;

Pascal

*From:* Vasilenko Eduard 
*Sent:* vendredi 1 avril 2022 14:32
*To:* Pascal Thubert (pthubert) ; Justin
    Streiner ; Abraham Y. Chen 
    *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC

Hi Pascal,

In general, your idea to create a hierarchy is good.

In practice, it would fail because you have created a virtual
hierarchy that does not map to any administrative border. Who
should implement gateways for the “Shaft”? Why?

If you would appoint Carrier as the Shaft responsible then it is
not enough bits for Shaft.

If you would appoint Governments as the Shaft responsible then
would be a so big sca

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Makes sense, Abe, for the next version.

Note that the intention is NOT any to ANY. A native IPv6 IoT device can only 
talk to another IPv6 device, where that other device may use a YATT address or 
any other IPv6 address.
But it cannot talk to a YADA node. That’s what I mean by baby steps for those 
who want to.

Keep safe;

Pascal

From: Abraham Y. Chen 
Sent: vendredi 1 avril 2022 15:49
To: Vasilenko Eduard ; Pascal Thubert (pthubert) 
; Justin Streiner 
Cc: NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi, Pascal:

What I would appreciate is an IP packet header design/definition layout, 
word-by-word, ideally in bit-map style, of an explicit presentation of all IP 
addresses involved from one IoT in one realm to that in the second realm. This 
will provide a clearer picture of how the real world implementation may look 
like.

Thanks,


Abe (2022-04-01 09:48)


On 2022-04-01 08:49, Vasilenko Eduard wrote:
As I understand: “IPv4 Realms” between “Shaft” should be capable to have a 
plain IPv4 header (or else why all of these).
Then Gateway in the Shaft should change headers (from IPv4 to IPv6).
Who should implement this gateway and why? He should be formally appointed to 
such an exercise, right?
Map this 2 level hierarchy to the real world – you may fail with this.
Ed/
From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
Sent: Friday, April 1, 2022 3:41 PM
To: Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Justin 
Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen 
<mailto:ayc...@avinta.com>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hello Eduard:

Did you just demonstrate that POPs cannot exist? Or that there cannot be a 
Default Free Zone?
I agree with your real world issue that some things will have to be planned 
between stake holders, and that it will not be easy.
But you know what the French say about “impossible”.
Or to paraphrase Sir Arthur, now that we have eliminated all the impossible 
transition scenarios, whatever remains…

There will be YADA prefixes just like there are root DNS. To be managed by 
different players as you point out. And all routable within the same shaft.

Keep safe;

Pascal

From: Vasilenko Eduard 
mailto:vasilenko.edu...@huawei.com>>
Sent: vendredi 1 avril 2022 14:32
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; 
Justin Streiner mailto:strein...@gmail.com>>; Abraham Y. 
Chen mailto:ayc...@avinta.com>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi Pascal,
In general, your idea to create a hierarchy is good.
In practice, it would fail because you have created a virtual hierarchy that 
does not map to any administrative border. Who should implement gateways for 
the “Shaft”? Why?
If you would appoint Carrier as the Shaft responsible then it is not enough 
bits for Shaft.
If you would appoint Governments as the Shaft responsible then would be a so 
big scandal that you would regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA successful.
Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Friday, April 1, 2022 2:26 PM
To: Justin Streiner mailto:strein...@gmail.com>>; Abraham 
Y. Chen mailto:ayc...@avinta.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

For the sake of it, Justin, I just published 
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
The first section of the draft (YADA) extends IPv4 range in an IPv4-only world. 
For some people that might be enough and I’m totally fine with that.

Keep safe;

Pascal

From: NANOG 
mailto:nanog-bounces+pthubert=cisco@nanog.org>>
 On Behalf Of Justin Streiner
Sent: dimanche 27 mars 2022 18:12
To: Abraham Y. Chen mailto:ayc...@avinta.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Abe:

To your first point about denying that anyone is being stopped from working on 
IPv4, I'm referring to users being able to communicate via IPv4.  I have seen 
no evidence of that.

I'm not familiar with the process of submitting ideas to IETF, so I'll leave 
that for others who are more knowledgeable on that to speak up if they're so 
inclined.

Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

1)"... no one is stopping anyone from working on IPv4 ... ":   After 
all these discussions, are you still denying this basic issue? For example, 
there has not been any straightforward way to introduce IPv4 enhancement ideas 
to IETF since at least 2015. If you know the way, please make it public. I am 
sure that many

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Pascal:

What I would appreciate is an IP packet header design/definition layout, 
word-by-word, ideally in bit-map style, of an explicit presentation of 
all IP addresses involved from one IoT in one realm to that in the 
second realm. This will provide a clearer picture of how the real world 
implementation may look like.


Thanks,


Abe (2022-04-01 09:48)


On 2022-04-01 08:49, Vasilenko Eduard wrote:


As I understand: “IPv4 Realms” between “Shaft” should be capable to 
have a plain IPv4 header (or else why all of these).


Then Gateway in the Shaft should change headers (from IPv4 to IPv6).

Who should implement this gateway and why? He should be formally 
appointed to such an exercise, right?


Map this 2 level hierarchy to the real world – you may fail with this.

Ed/

*From:* Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
*Sent:* Friday, April 1, 2022 3:41 PM
*To:* Vasilenko Eduard ; Justin Streiner 
; Abraham Y. Chen 
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Hello Eduard:

Did you just demonstrate that POPs cannot exist? Or that there cannot 
be a Default Free Zone?


I agree with your real world issue that some things will have to be 
planned between stake holders, and that it will not be easy.


But you know what the French say about “impossible”.

Or to paraphrase Sir Arthur, now that we have eliminated all the 
impossible transition scenarios, whatever remains…


There will be YADA prefixes just like there are root DNS. To be 
managed by different players as you point out. And all routable within 
the same shaft.


Keep safe;

Pascal

*From:* Vasilenko Eduard 
*Sent:* vendredi 1 avril 2022 14:32
*To:* Pascal Thubert (pthubert) ; Justin Streiner 
; Abraham Y. Chen 
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Hi Pascal,

In general, your idea to create a hierarchy is good.

In practice, it would fail because you have created a virtual 
hierarchy that does not map to any administrative border. Who should 
implement gateways for the “Shaft”? Why?


If you would appoint Carrier as the Shaft responsible then it is not 
enough bits for Shaft.


If you would appoint Governments as the Shaft responsible then would 
be a so big scandal that you would regret the proposal.


Hence, I do not see proper mapping for the hierarchy to make YADA 
successful.


Eduard

*From:* NANOG 
[mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org 
<mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org>] *On 
Behalf Of *Pascal Thubert (pthubert) via NANOG

*Sent:* Friday, April 1, 2022 2:26 PM
*To:* Justin Streiner ; Abraham Y. Chen 


*Cc:* NANOG 
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


For the sake of it, Justin, I just published 
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.


The first section of the draft (YADA) extends IPv4 range in an 
IPv4-only world. For some people that might be enough and I’m totally 
fine with that.


Keep safe;

Pascal

*From:* NANOG  *On Behalf 
Of *Justin Streiner

*Sent:* dimanche 27 mars 2022 18:12
*To:* Abraham Y. Chen 
*Cc:* NANOG 
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Abe:

To your first point about denying that anyone is being stopped from 
working on IPv4, I'm referring to users being able to communicate via 
IPv4.  I have seen no evidence of that.


I'm not familiar with the process of submitting ideas to IETF, so I'll 
leave that for others who are more knowledgeable on that to speak up 
if they're so inclined.


Thank you

jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen  wrote:

1)    "... no one is stopping anyone from working on IPv4 ... ":  
After all these discussions, are you still denying this basic
issue? For example, there has not been any straightforward way to
introduce IPv4 enhancement ideas to IETF since at least 2015. If
you know the way, please make it public. I am sure that many are
eager to learn about it. Thanks.




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

There are 2 ways to stop a war:

1) one side it utterly defeated and disaggregated
2) both sides suffered enough and agree to start thinking of the best terms for 
coexistence

1) is not close to happening any time soon

From this, the conclusion is that we have not suffered enough.

On the side, the IETF has its own Tao for consensus and such things.
See section 4.2 of https://www.ietf.org/about/participate/tao/

As a WG chair, I happen to have to figure consensus out. It's a rough and very 
human process. It has to do with feeling of support from the room and the 
mailing list. It has also to do with insuring that all technically valid 
objections found an answer, even if the opponent is a minority.

For work that does not have a home, there's always the Int Area WG.

And for those who think we already reached 2) after only 20 years, there's 
always the discussion on the original thread, and the yada-yatt draft.

Keep safe;

Pascal


> -Original Message-
> From: NANOG  On Behalf Of Joe
> Maimon
> Sent: vendredi 1 avril 2022 5:46
> To: Owen DeLong 
> Cc: NANOG 
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 
> 
> Owen DeLong wrote:
> >
> > Yep… He’s absolutely right… We need to find a way to get the networks
> > that aren’t deploying IPv6 to get off the dime and stop holding the rest of
> the world hostage in the IPv4 backwater.
> >
> > Owen
> >
> >
> 
> You keep championing that approach, essentially unchanged for the past
> 20 years with an impressive record of partial success and much failure and I
> will fully support and applaud your efforts in doing so. I will also hope
> that it doesnt take another 20 to finally succeed, because as you point out,
> you require an extremely high level of participation before its Mission
> Accomplished.
> 
> And its not unreasonable to expect that until that approach succeeds, that
> others' efforts to work on the ongoing problem receive the same support and
> encouragement.
> 
> IPv6 uber-alles adherents had more than enough time to claim it was going to
> solve the problem without any need for anything else and to "request" (quite
> strongly and wrongly so in my opinion) that everyone rally their efforts
> around that.
> 
> Now its time for those adherents to reciprocate.
> 
> And here is a little bit of constructive criticism to the Evangelical
> approach. Essentially, you need to pivot from how their efforts can save the
> world into how their efforts can benefit themselves.
> 
> You want more people to use IPv6? Make it worth their while. Lower the
> barriers the cost the risks and increase the bennies.
> 
> The early adopters, the activists, those who define themselves by their
> altruism you already got.
> 
> Dont be surprised when so many balk at doing things they have no particular
> defined need or interest in doing when the primary beneficiaries arent
> themselves, but the primary cost carriers are.
> 
> Or we can just wait and see how the natural course of events eventually plays
> out. Still looks likely that IPv6 will eventually take over the internet, but
> it sure would be nice if IPv4 did not become completely unusable before that
> manages to occur.
> 
> Joe

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

For the sake of it, Justin, I just published 
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
The first section of the draft (YADA) extends IPv4 range in an IPv4-only world. 
For some people that might be enough and I’m totally fine with that.

Keep safe;

Pascal

From: NANOG  On Behalf Of Justin 
Streiner
Sent: dimanche 27 mars 2022 18:12
To: Abraham Y. Chen 
Cc: NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Abe:

To your first point about denying that anyone is being stopped from working on 
IPv4, I'm referring to users being able to communicate via IPv4.  I have seen 
no evidence of that.

I'm not familiar with the process of submitting ideas to IETF, so I'll leave 
that for others who are more knowledgeable on that to speak up if they're so 
inclined.

Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

1)"... no one is stopping anyone from working on IPv4 ... ":   After 
all these discussions, are you still denying this basic issue? For example, 
there has not been any straightforward way to introduce IPv4 enhancement ideas 
to IETF since at least 2015. If you know the way, please make it public. I am 
sure that many are eager to learn about it. Thanks.

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Owen DeLong wrote:


Yep… He’s absolutely right… We need to find a way to get the networks that 
aren’t deploying IPv6 to
get off the dime and stop holding the rest of the world hostage in the IPv4 
backwater.

Owen




You keep championing that approach, essentially unchanged for the past 
20 years with an impressive record of partial success and much failure 
and I will fully support and applaud your efforts in doing so. I will 
also hope that it doesnt take another 20 to finally succeed, because as 
you point out, you require an extremely high level of participation 
before its Mission Accomplished.


And its not unreasonable to expect that until that approach succeeds, 
that others' efforts to work on the ongoing problem receive the same 
support and encouragement.


IPv6 uber-alles adherents had more than enough time to claim it was 
going to solve the problem without any need for anything else and to 
"request" (quite strongly and wrongly so in my opinion) that everyone 
rally their efforts around that.


Now its time for those adherents to reciprocate.

And here is a little bit of constructive criticism to the Evangelical 
approach. Essentially, you need to pivot from how their efforts can save 
the world into how their efforts can benefit themselves.


You want more people to use IPv6? Make it worth their while. Lower the 
barriers the cost the risks and increase the bennies.


The early adopters, the activists, those who define themselves by their 
altruism you already got.


Dont be surprised when so many balk at doing things they have no 
particular defined need or interest in doing when the primary 
beneficiaries arent themselves, but the primary cost carriers are.


Or we can just wait and see how the natural course of events eventually 
plays out. Still looks likely that IPv6 will eventually take over the 
internet, but it sure would be nice if IPv4 did not become completely 
unusable before that manages to occur.


Joe

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

iMac:owen (112) ~ % host www.amazon.com 
2022/03/31 17:16:40
www.amazon.com is an alias for tp.47cf2c8c9-frontier.amazon.com.
tp.47cf2c8c9-frontier.amazon.com is an alias for d3ag4hukkh62yn.cloudfront.net.
d3ag4hukkh62yn.cloudfront.net has address 143.204.129.80

and

iMac:owen (113) ~ % dig -t  www.amazon.com  
2022/03/31 17:26:36

; <<>> DiG 9.10.6 <<>> -t  www.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33930
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.amazon.com.IN  

;; ANSWER SECTION:
www.amazon.com. 228 IN  CNAME   
tp.47cf2c8c9-frontier.amazon.com.
tp.47cf2c8c9-frontier.amazon.com. 45 IN CNAME   d3ag4hukkh62yn.cloudfront.net.

;; AUTHORITY SECTION:
d3ag4hukkh62yn.cloudfront.net. 46 INSOA ns-130.awsdns-16.com. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 0 msec
;; SERVER: 192.159.10.2#53(192.159.10.2)
;; WHEN: Thu Mar 31 17:26:50 PDT 2022
;; MSG SIZE  rcvd: 206

0.002u 0.017s 0:00.02 50.0% 0+0k 0+0io 2pf+0w
iMac:owen (114) ~ % dig -t  tp.47cf2c8c9-frontier.amazon.com
2022/03/31 17:26:50

; <<>> DiG 9.10.6 <<>> -t  tp.47cf2c8c9-frontier.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;tp.47cf2c8c9-frontier.amazon.com. IN   

;; ANSWER SECTION:
tp.47cf2c8c9-frontier.amazon.com. 21 IN CNAME   d3ag4hukkh62yn.cloudfront.net.

;; AUTHORITY SECTION:
d3ag4hukkh62yn.cloudfront.net. 22 INSOA ns-130.awsdns-16.com. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 0 msec
;; SERVER: 192.159.10.2#53(192.159.10.2)
;; WHEN: Thu Mar 31 17:27:14 PDT 2022
;; MSG SIZE  rcvd: 188

0.002u 0.005s 0:00.00 0.0%  0+0k 0+0io 0pf+0w
iMac:owen (115) ~ % dig -t  d3ag4hukkh62yn.cloudfront.net.  
2022/03/31 17:27:14

; <<>> DiG 9.10.6 <<>> -t  d3ag4hukkh62yn.cloudfront.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63871
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;d3ag4hukkh62yn.cloudfront.net. IN  

;; AUTHORITY SECTION:
d3ag4hukkh62yn.cloudfront.net. 5 IN SOA ns-130.awsdns-16.com. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 0 msec
;; SERVER: 192.159.10.2#53(192.159.10.2)
;; WHEN: Thu Mar 31 17:27:31 PDT 2022
;; MSG SIZE  rcvd: 142


So… As I said… Amazon.

Owen


> On Mar 31, 2022, at 16:00 , Andras Toth  wrote:
> 
> https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/
>  
> <https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/>
> 
>> On 1 Apr 2022, at 06:44, Owen DeLong via NANOG  wrote:
>> 
>> In short:
>>  Amazon
>>  Alibaba
>>  Google Cloud
>> 
>> And a few other laggards that are key destinations that a lot of eyeball 
>> customers expect to be
>> able to reach.
>> 
>> Owen
>> 
>> 
>>> On Mar 29, 2022, at 13:53 , Jacques Latour >> <mailto:jacques.lat...@cira.ca>> wrote:
>>> 
>>> So, in 25, 50 or 100 years from now, are we still going to be dual stack 
>>> IPv4/IPv6?
>>> When are we going to give up on IPv4?
>>> People can run IPv4 all they want inside their networks for 1000s of years.
>>> What will it take to be IPv6 only?
>>>  
>>> 
>>>  
>>> From: NANOG >> <mailto:nanog-bounces+jacques.latour=cira...@nanog.org>> On Behalf Of Owen 
>>> DeLong via NANOG
>>> Sent: March 29, 2022 3:52 PM
>>> To: Abraham Y. Chen mailto:ayc...@avinta.com>>
>>> Cc: NANOG mailto:nanog@nanog.org>>
>>> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported 
>>> re: 202203261833.AYC
>>>  
>>> Submit an Internet draft, same as any other IP related enhancement gets 
>>> introduced.
>>>  
>>> What you’re really

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

> On Mar 31, 2022, at 15:32 , Joe Maimon  wrote:
> 
> 
> 
> Matthew Petach wrote:
>> 
>> 
>> In short, at the moment, you *can't* deploy IPv6 without also having IPv4
>> somewhere in your network.  IPv6 hasn't solved the problem of IPv4
>> address shortage, because you can't functionally deploy IPv6 without
>> also having at least some IPv4 addresses to act as endpoints.
>> 
>> For the people who already have IPv4 addresses to say "hey, that's
>> not a problem for us" to everyone who can't get IPv4 addresses is
>> exactly the problem warned against in section 6 of 
>> https://datatracker.ietf.org/doc/html/rfc7282:
>> 
>> "
>> 6 . One hundred 
>> people for and five people against might not be rough
>> consensus
>> 
>>Section 3   
>> discussed the idea of consensus being achieved when
>>objections had been addressed (that is, properly considered, and
>>accommodated if necessary).  Because of this, using rough consensus
>>avoids a major pitfall of a straight vote: If there is a minority of
>>folks who have a valid technical objection, that objection must be
>>dealt with before consensus can be declared. "
>> The point at which we have parity between IPv4 and IPv6 connectivity is the 
>> point
>> at which we can start to talk about sunsetting IPv4 and declaring it 
>> historic, and
>> no longer concern ourselves with address exhaustion.  Until then, so long as
>> being able to obtain IPv4 addresses is a mandatory step in being functional 
>> on
>> the internet, it is unreasonable to say that the address exhaustion problem 
>> is
>> "solved."
>> 
>> Matt
>> 
> 
> I dont know how many ways and times this needs to be said, but you said it 
> quite well.
> 
> Joe

Yep… He’s absolutely right… We need to find a way to get the networks that 
aren’t deploying IPv6 to
get off the dime and stop holding the rest of the world hostage in the IPv4 
backwater.

Owen

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

> But as anyone who has tried to deploy IPv6-only networks quickly discovers, 
> at the present time, you can't deploy an IPv6-only network with any 
> success on the global internet today.  There's too many IPv6-ish networks 
> out there that haven't fully established their infrastructure to be reachable 
> without v4 connectivity also in place.  In order to deploy an IPv6 network 
> today, you *must* also have IPv4 addresses to work with.  Try to ping 
> apple.com  via v6, or microsoft.com 
>  via v6, and see how far you get.
> Closer to home, try to ping juniper.com/juniper.net 
>  via v6, or nokia.com ,
> and you'll find there's a whole bunch of assumptions that you've got 
> some level of working IPv4 in the picture to talk to your hardware and 
> software vendors.
> 

While I can’t ping those, I did turn off IPv4 and successfully pinged (and 
downloaded
web pages from):
www.apple.com 
www.microsoft.com 
www.juniper.net 
www.nokia.com 

I wasn’t able to find  records for any useful variant of juniper.com 
, but since that’s
a bank (www.juniper.com  has a CNAME record pointing 
to www.juniper.egs1b.barclaycards.com),
I expect them to be laggards… To the best of my knowledge, very few banks have 
deployed
IPv6 in any meaningful way.

> In short, at the moment, you *can't* deploy IPv6 without also having IPv4 
> somewhere in your network.  IPv6 hasn't solved the problem of IPv4 
> address shortage, because you can't functionally deploy IPv6 without 
> also having at least some IPv4 addresses to act as endpoints. 

Well, yes and no. The only real limitation requiring you to “have some IPv4”
is the failure of other networks to deploy IPv6. That’s not exactly an 
architectural or
technical problem with IPv6, it’s a deployment issue.

> For the people who already have IPv4 addresses to say "hey, that's 
> not a problem for us" to everyone who can't get IPv4 addresses is 
> exactly the problem warned against in section 6 of 
> https://datatracker.ietf.org/doc/html/rfc7282 
> :
> 
> "
> 
> 6 .  One hundred 
> people for and five people against might not be rough
> consensus
> 
>Section 3  
> discussed the idea of consensus being achieved when
>objections had been addressed (that is, properly considered, and
>accommodated if necessary).  Because of this, using rough consensus
>avoids a major pitfall of a straight vote: If there is a minority of
>folks who have a valid technical objection, that objection must be
>dealt with before consensus can be declared. “

Again, yes and no. While the failure of some networks to deploy IPv6 is proving 
debilitating to other
networks (including mine) ability to move forward with deprecation of IPv4 it’s 
really hard for me to
view that as a technical problem with IPv6, rather than a problem with the 
failure of those networks.

> The point at which we have parity between IPv4 and IPv6 connectivity is the 
> point 
> at which we can start to talk about sunsetting IPv4 and declaring it 
> historic, and 
> no longer concern ourselves with address exhaustion.  Until then, so long as 
> being able to obtain IPv4 addresses is a mandatory step in being functional 
> on 
> the internet, it is unreasonable to say that the address exhaustion problem is
> "solved."

OK, it’s not solved. However, the solution is fully architected and widely 
deployed. The failure of some
networks to deploy the solution really isn’t a design problem or a protocol 
problem. Arguably, it’s not
really a technical problem. It’s certainly not a technical shortcoming of IPv6. 
It’s a deployment failure,
arguably a bureaucratic or political problem as much as anything.

Owen

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Andras Toth]

https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/

> On 1 Apr 2022, at 06:44, Owen DeLong via NANOG  wrote:
> 
> In short:
>   Amazon
>   Alibaba
>   Google Cloud
> 
> And a few other laggards that are key destinations that a lot of eyeball 
> customers expect to be
> able to reach.
> 
> Owen
> 
> 
>> On Mar 29, 2022, at 13:53 , Jacques Latour  wrote:
>> 
>> So, in 25, 50 or 100 years from now, are we still going to be dual stack 
>> IPv4/IPv6?
>> When are we going to give up on IPv4?
>> People can run IPv4 all they want inside their networks for 1000s of years.
>> What will it take to be IPv6 only?
>>  
>> 
>>  
>> From: NANOG  On Behalf Of 
>> Owen DeLong via NANOG
>> Sent: March 29, 2022 3:52 PM
>> To: Abraham Y. Chen 
>> Cc: NANOG 
>> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported 
>> re: 202203261833.AYC
>>  
>> Submit an Internet draft, same as any other IP related enhancement gets 
>> introduced.
>>  
>> What you’re really complaining about is that it’s been virtually impossible 
>> to gain consensus to move anything IPv4 related forward in the IETF since at 
>> least 2015.
>>  
>> Well… It’s a consensus process. If your idea isn’t getting consensus, then 
>> perhaps it’s simply that the group you are seeking consensus from doesn’t 
>> like your idea.
>>  
>> Your inability to convince the members of the various working groups that 
>> your idea has merit isn’t necessarily a defect in the IETF process… It might 
>> simply be a lack of merit in your ideas.
>>  
>> Owen
>>  
>> 
>> 
>> On Mar 26, 2022, at 15:43 , Abraham Y. Chen  wrote:
>>  
>> Hi, Justin:
>>  
>> 1)"... no one is stopping anyone from working on IPv4 ... ":   After 
>> all these discussions, are you still denying this basic issue? For example, 
>> there has not been any straightforward way to introduce IPv4 enhancement 
>> ideas to IETF since at least 2015. If you know the way, please make it 
>> public. I am sure that many are eager to learn about it. Thanks.
>>  
>> Regards,
>>  
>>  
>> Abe (2022-03-26 18:42)
>>  
>>  
>>  
>>  
>> On 2022-03-26 11:20, Justin Streiner wrote:
>> While the Internet is intended to allow the free exchange of information, 
>> the means of getting that information from place to place is and has to be 
>> defined by protocols that are implemented in a consistent manner (see: BGP, 
>> among many other examples).  It's important to separate the ideas from the 
>> plumbing.
>>  
>> That said, no one is stopping anyone from working on IPv4, so what personal 
>> freedoms are being impacted by working toward deploying IPv6, with an eye 
>> toward sunsetting IPv4 in the future?
>>  
>> Keep in mind that IPv4 started out as an experiment that found its way into 
>> wider use.  It's a classic case of a test deployment that suddenly mutated 
>> into a production service.  Why should we continue to expend effort to 
>> perpetuate the sins of the past, rather work toward getting v6 into wider 
>> use?
>>  
>> Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain 
>> point of IPv4 - address space exhaustion.
>>  
>> Thank you
>> jms
>>  
>> On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen  wrote:
>>  
>> 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic 
>> baseline that we need to sort out, first. That is, we must keep in mind that 
>> the Internet community strongly promotes "personal freedom". Assuming that 
>> by stopping others from working on IPv4 will shift their energy to IPv6 is 
>> totally contradicting such a principle. A project attracts contributors by 
>> its own merits, not by relying on artificial barriers to the competitions. 
>> Based on my best understanding, IPv6 failed right after the decision of "not 
>> emphasizing the backward compatibility with IPv4". It broke one of the 
>> golden rules in the system engineering discipline. After nearly three 
>> decades, still evading such fact, but defusing IPv6 issues by various 
>> tactics is the real impedance to progress, not only to IPv4 but also to IPv6.
> 

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Matthew Petach wrote:



In short, at the moment, you *can't* deploy IPv6 without also having IPv4
somewhere in your network.  IPv6 hasn't solved the problem of IPv4
address shortage, because you can't functionally deploy IPv6 without
also having at least some IPv4 addresses to act as endpoints.

For the people who already have IPv4 addresses to say "hey, that's
not a problem for us" to everyone who can't get IPv4 addresses is
exactly the problem warned against in section 6 of 
https://datatracker.ietf.org/doc/html/rfc7282:


"
6 . One 
hundred people for and five people against might not be rough

consensus

Section 3   
discussed the idea of consensus being achieved when
objections had been addressed (that is, properly considered, and
accommodated if necessary).  Because of this, using rough consensus
avoids a major pitfall of a straight vote: If there is a minority of
folks who have a valid technical objection, that objection must be
dealt with before consensus can be declared. "
The point at which we have parity between IPv4 and IPv6 connectivity 
is the point
at which we can start to talk about sunsetting IPv4 and declaring it 
historic, and
no longer concern ourselves with address exhaustion.  Until then, so 
long as
being able to obtain IPv4 addresses is a mandatory step in being 
functional on
the internet, it is unreasonable to say that the address exhaustion 
problem is

"solved."

Matt



I dont know how many ways and times this needs to be said, but you said 
it quite well.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Matthew Petach]

On Wed, Mar 30, 2022 at 12:47 PM Tom Beecher  wrote:

> If the IETF has really been unable to achieve consensus on properly
>> supporting the currently still dominant internet protocol, that is
>> seriously problematic and a huge process failure.
>>
>
> That is not an accurate statement.
>
> The IETF has achieved consensus on this topic. It's explained here by
> Brian Carpenter.
>
> https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDXyAUA/
>
> He expressly states with many +1s that if something IPv4 related needs to
> get worked on , it will be worked on, but the consensus solution to V4
> address exhaustion was IPng that became IPv6, so that is considered a
> solved problem.
>
> Some folks don't LIKE the solution, as is their right to do. But the
> problem of V4 address exhaustion is NOT the same thing as "I don't like the
> solution that they chose."
>

I suspect people differ in their understanding of the word "consensus":

https://www.merriam-webster.com/dictionary/consensus

"Definition of *consensus*

1a
: general agreement : UNANIMITY
"

Versus the IETF:
https://tools.ietf.org/id/draft-resnick-on-consensus-01.html
(and subsequently https://datatracker.ietf.org/doc/html/rfc7282 )

specifically, this paragraph:

"Any finding of rough consensus needs at some level to be a satisfactory
explanation to the person(s) raising the issue of why their concern is not
going to be dealt with. A good outcome is for the objector to be satisfied
that, although their issue is not being accommodated in the final product,
they understand and accept the outcome. Remember, if the objector feels
that the issue is so essential that it must be attended to, they always
have the option to file an appeal. A technical error is always a valid
basis for an appeal, and a chair or AD has the freedom and the
responsibility to say, "The group did not take this technical issue into
proper account." Simply having a number of people agreeing to dismiss an
objection is not enough."

It would seem that Brian Carpenter's message drifted more towards the
dictionary definition of "consensus" than what the IETF has historically
used to determine "consensus".

Brian seems to have tried to sweep under the carpet a very serious
problem without properly addressing it, by saying (direct quote):
"We shouldn't be fixing problems that IPv6 already fixes,
and shortage of addresses is certainly in that category."

But as anyone who has tried to deploy IPv6-only networks quickly discovers,
at the present time, you can't deploy an IPv6-only network with any
success on the global internet today.  There's too many IPv6-ish networks
out there that haven't fully established their infrastructure to be
reachable
without v4 connectivity also in place.  In order to deploy an IPv6 network
today, you *must* also have IPv4 addresses to work with.  Try to ping
apple.com via v6, or microsoft.com via v6, and see how far you get.
Closer to home, try to ping juniper.com/juniper.net via v6, or nokia.com,
and you'll find there's a whole bunch of assumptions that you've got
some level of working IPv4 in the picture to talk to your hardware and
software vendors.

In short, at the moment, you *can't* deploy IPv6 without also having IPv4
somewhere in your network.  IPv6 hasn't solved the problem of IPv4
address shortage, because you can't functionally deploy IPv6 without
also having at least some IPv4 addresses to act as endpoints.

For the people who already have IPv4 addresses to say "hey, that's
not a problem for us" to everyone who can't get IPv4 addresses is
exactly the problem warned against in section 6 of
https://datatracker.ietf.org/doc/html/rfc7282:

"


6 .  One
hundred people for and five people against might not be rough
consensus

   Section 3 
discussed the idea of consensus being achieved when
   objections had been addressed (that is, properly considered, and
   accommodated if necessary).  Because of this, using rough consensus
   avoids a major pitfall of a straight vote: If there is a minority of
   folks who have a valid technical objection, that objection must be
   dealt with before consensus can be declared. "



The point at which we have parity between IPv4 and IPv6 connectivity is the
point
at which we can start to talk about sunsetting IPv4 and declaring it
historic, and
no longer concern ourselves with address exhaustion.  Until then, so long
as
being able to obtain IPv4 addresses is a mandatory step in being functional
on
the internet, it is unreasonable to say that the address exhaustion problem
is
"solved."

Matt

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

> On Mar 30, 2022, at 17:00 , Joe Maimon  wrote:
> 
> 
> 
> Tom Beecher wrote:
>> 
>>If the IETF has really been unable to achieve consensus on properly
>>supporting the currently still dominant internet protocol, that is
>>seriously problematic and a huge process failure.
>> 
>> 
>> That is not an accurate statement.
>> 
>> The IETF has achieved consensus on this topic. It's explained here by Brian 
>> Carpenter.
>> 
>> https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDXyAUA/
> 
> As I have explained with my newly introduced consensus standards, there is no 
> such consensus.
> 
> To reiterate my consensus standards, consensus is only to be considered as 
> amongst stakeholders and IPv6 specific related stakes are not relevant to 
> IPv4. If you consider the reverse to be true as well, I think my version of 
> consensus would achieve a much wider and diverse consensus than the the 
> stated IETF's consensus.
> 
> Once a consensus has been proven invalid its beyond obnoxious to cling to it 
> as though it maintains its own reality field.

Yes, but you don’t have consensus for your new consensus standard, so…

Owen

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

> On Mar 30, 2022, at 09:16 , Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong via NANOG wrote:
>> What you’re really complaining about is that it’s been virtually impossible 
>> to gain consensus to move anything IPv4 related forward in the IETF since at 
>> least 2015.
>> 
>> Well… It’s a consensus process. If your idea isn’t getting consensus, then 
>> perhaps it’s simply that the group you are seeking consensus from doesn’t 
>> like your idea.
> 
> If the IETF has really been unable to achieve consensus on properly 
> supporting the currently still dominant internet protocol, that is seriously 
> problematic and a huge process failure.

Perhaps it’s more a question of the definition of “properly supporting” than 
whether or not to do so.

> When vendors do that sort of thing people get up in arms. When open source 
> projects do that sort of thing, they get forked. When community grassroots 
> governance bodies do that sort of thing, I dont want to find out.

My best guess is that the closest example is BSD and it’s tragedy of CARP.

> Responsible stewardship of internet community standardization would be 
> excluding IPv6 strategic concerns from considerations of consensus on IPv4 
> issues.

We can agree to disagree about this. If enough people agree with you, perhaps 
you can get consensus for that. If enough people agree with me, perhaps not.

> In other words, if the only issues you can bring to bear on any matter 
> pertaining solely to IPv4 is all about IPv6, your not relevant to the process 
> and should be struck from the record.

You are entitled to your opinion.

> I would even go so far as to say that you are actually poisoning the process.

Now you’re bordering on ad hominem.

>> Your inability to convince the members of the various working groups that 
>> your idea has merit isn’t necessarily a defect in the IETF process… It might 
>> simply be a lack of merit in your ideas.
>> 
>> Owen
>> 
>> 
> This part is very good advice, perhaps restated as a lack of merit in the 
> idea when combined with much wider and diverse perspectives.
> 
> On the other hand, with no record and history of ideology driven agendas, the 
> IETF process would be a whole lot more trustworthy.

There’s no such thing as a human process without ideology driven agendas, so 
it’s hard to take such a comment seriously.

Owen

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

In short:
Amazon
Alibaba
Google Cloud

And a few other laggards that are key destinations that a lot of eyeball 
customers expect to be
able to reach.

Owen


> On Mar 29, 2022, at 13:53 , Jacques Latour  wrote:
> 
> So, in 25, 50 or 100 years from now, are we still going to be dual stack 
> IPv4/IPv6?
> When are we going to give up on IPv4?
> People can run IPv4 all they want inside their networks for 1000s of years.
> What will it take to be IPv6 only?
>  
> 
>  
> From: NANOG  <mailto:nanog-bounces+jacques.latour=cira...@nanog.org>> On Behalf Of Owen 
> DeLong via NANOG
> Sent: March 29, 2022 3:52 PM
> To: Abraham Y. Chen mailto:ayc...@avinta.com>>
> Cc: NANOG mailto:nanog@nanog.org>>
> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported 
> re: 202203261833.AYC
>  
> Submit an Internet draft, same as any other IP related enhancement gets 
> introduced.
>  
> What you’re really complaining about is that it’s been virtually impossible 
> to gain consensus to move anything IPv4 related forward in the IETF since at 
> least 2015.
>  
> Well… It’s a consensus process. If your idea isn’t getting consensus, then 
> perhaps it’s simply that the group you are seeking consensus from doesn’t 
> like your idea.
>  
> Your inability to convince the members of the various working groups that 
> your idea has merit isn’t necessarily a defect in the IETF process… It might 
> simply be a lack of merit in your ideas.
>  
> Owen
>  
> 
> 
> On Mar 26, 2022, at 15:43 , Abraham Y. Chen  <mailto:ayc...@avinta.com>> wrote:
>  
> Hi, Justin:
>  
> 1)"... no one is stopping anyone from working on IPv4 ... ":   After 
> all these discussions, are you still denying this basic issue? For example, 
> there has not been any straightforward way to introduce IPv4 enhancement 
> ideas to IETF since at least 2015. If you know the way, please make it 
> public. I am sure that many are eager to learn about it. Thanks.
>  
> Regards,
>  
>  
> Abe (2022-03-26 18:42)
>  
>  
>  
>  
> On 2022-03-26 11:20, Justin Streiner wrote:
> While the Internet is intended to allow the free exchange of information, the 
> means of getting that information from place to place is and has to be 
> defined by protocols that are implemented in a consistent manner (see: BGP, 
> among many other examples).  It's important to separate the ideas from the 
> plumbing.
>  
> That said, no one is stopping anyone from working on IPv4, so what personal 
> freedoms are being impacted by working toward deploying IPv6, with an eye 
> toward sunsetting IPv4 in the future?
>  
> Keep in mind that IPv4 started out as an experiment that found its way into 
> wider use.  It's a classic case of a test deployment that suddenly mutated 
> into a production service.  Why should we continue to expend effort to 
> perpetuate the sins of the past, rather work toward getting v6 into wider use?
>  
> Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain 
> point of IPv4 - address space exhaustion.
>  
> Thank you
> jms
>  
> On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen  <mailto:ayc...@avinta.com>> wrote:
>  
> 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic 
> baseline that we need to sort out, first. That is, we must keep in mind that 
> the Internet community strongly promotes "personal freedom". Assuming that by 
> stopping others from working on IPv4 will shift their energy to IPv6 is 
> totally contradicting such a principle. A project attracts contributors by 
> its own merits, not by relying on artificial barriers to the competitions. 
> Based on my best understanding, IPv6 failed right after the decision of "not 
> emphasizing the backward compatibility with IPv4". It broke one of the golden 
> rules in the system engineering discipline. After nearly three decades, still 
> evading such fact, but defusing IPv6 issues by various tactics is the real 
> impedance to progress, not only to IPv4 but also to IPv6.

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Dear Colleagues:

0)    I would like to summarize this thread of discussion with the 
following:


1)    It has been well-known in democracy that too much emphasis on 
"majority consensus" may not be really good for the intended goal. For 
example, if the general opinions in the ancient time prevailed and the 
objectors prosecuted, we probably are still living in a world of 
believing that the earth is flat and the sun rotates around the earth! 
Science and technology make advances due to a few stubborn and forward 
looking hard workers, not by popular wisdom.


2)    No one should be "defending" the decision of going to IPv6 three 
decades ago. There is no need to, because it was based on the best 
information and knowledge at that time. Now, after two decades of 
"experimenting", we have enough data to analyze and a lot of 
alternatives to review. There is nothing improper to revise the current 
Internet course that was set by engineers of at least two generations ago.


3)    It puzzles me deeply that the voices of the "Internet-way 
followers" these days have been so loud. What happened to the rebellion 
behaviors of restless young generations? Or, such voices come from those 
who made the choice three decades ago and refuse to update?


Regards,


Abe (2022-03-31 11:20)



On 2022-03-31 08:35, Vasilenko Eduard via NANOG wrote:

IMHO: IETF is only partially guilty. Who was capable to predict in 1992-1994 
that:

- Wireless would become so popular (WiFi is from 1997) and wireless would 
emulate multicast so badly (hi SLAAC)
- Hardware forwarding (PFE) would be invented (1997) that would have a big 
additional cost to implement Enhanced Headers
- Encryption would never have a small enough cost to make it mandatory
- Router would be available in every smallest thing that makes distributed 
address acquisition redundant (hi SLAAC)

We should be fair - it was not possible to guess.

Ed/
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Joe Maimon
Sent: Thursday, March 31, 2022 3:01 AM
To: Tom Beecher
Cc: NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC



Tom Beecher wrote:

 If the IETF has really been unable to achieve consensus on properly
 supporting the currently still dominant internet protocol, that is
 seriously problematic and a huge process failure.


That is not an accurate statement.

The IETF has achieved consensus on this topic. It's explained here by
Brian Carpenter.

https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDX
yAUA/

As I have explained with my newly introduced consensus standards, there is no 
such consensus.

To reiterate my consensus standards, consensus is only to be considered as 
amongst stakeholders and IPv6 specific related stakes are not relevant to IPv4. 
If you consider the reverse to be true as well, I think my version of consensus 
would achieve a much wider and diverse consensus than the the stated IETF's 
consensus.

Once a consensus has been proven invalid its beyond obnoxious to cling to it as 
though it maintains its own reality field.


He expressly states with many +1s that if something IPv4 related needs
to get worked on , it will be worked on,

IPv4 still needs address exhaustion solutions.


but the consensus solution to V4 address exhaustion was IPng that
became IPv6, so that is considered a solved problem.

IPv6 is not a solution. Its a replacement that does not have the same problem. 
Which could be a solution to the problem, but only if the replacement happens 
on schedule. However, so long as the replacement hasnt happened, we still are 
dealing with the problem.

The IETF made a stupendously bad bet that IPv6 would happen in time.
That is the kind of bet that you better be right about. They were a
decade+ wrong. That they have the audacity and temerity to continue
doubling down on that would be funny if it wasnt so outrageous, wrong and 
harmful.

Let us re-examine the premise. When did it become acceptable to quash work on 
one protocol because of the existence of another one that is preferred by the 
quashers?

Or in other words, the way you are framing things makes it seem as if the IETF 
has with intent and malice chosen to extend or at the very least ignore 
exhaustion issues for actual internet users so as to rig the system for their 
preferred outcome.


Some folks don't LIKE the solution, as is their right to do.

I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2 resolution, 
not addressing policy, not the chaos of choice of inadequate interoperability 
approaches, not the denial of features desired by users, not the pmtud, not the 
fragmentation, and many other warts. I dont even like the notation schemes. 
They require multiple vision passes.

I do like the extra bits. Just not the way they are being frittered.

The real crux of the matter is 

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Pascal Thubert (pthubert) via NANOG]

Hi Eduard

And SDN, and overlays, and... I certainly agree with what you're saying. 

This is why the L3 tech has to keep evolving as a survival trait. It's a 
delicate balance between evolving too quickly and producing the impression on 
unstable tech in the one hand, and stalling in the prehistory that you describe 
on the other, ask a dino when you meet one.

I argue that there are IPv6 RFCs to accommodate the cases I've seen on this 
list, but that the capabilities are largely ignored and -consequently- did not 
necessarily pass the PM barrier. Stalled we are indeed, but not for the lack of 
IETF work.

Keep safe;

Pascal



> -Original Message-
> From: NANOG  On Behalf Of
> Vasilenko Eduard via NANOG
> Sent: jeudi 31 mars 2022 14:36
> To: Joe Maimon ; Tom Beecher 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> IMHO: IETF is only partially guilty. Who was capable to predict in 1992-1994
> that:
> 
> - Wireless would become so popular (WiFi is from 1997) and wireless would
> emulate multicast so badly (hi SLAAC)
> - Hardware forwarding (PFE) would be invented (1997) that would have a big
> additional cost to implement Enhanced Headers
> - Encryption would never have a small enough cost to make it mandatory
> - Router would be available in every smallest thing that makes distributed
> address acquisition redundant (hi SLAAC)
> 
> We should be fair - it was not possible to guess.
> 
> Ed/
> -Original Message-
> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On
> Behalf Of Joe Maimon
> Sent: Thursday, March 31, 2022 3:01 AM
> To: Tom Beecher 
> Cc: NANOG 
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 
> 
> Tom Beecher wrote:
> >
> > If the IETF has really been unable to achieve consensus on properly
> > supporting the currently still dominant internet protocol, that is
> > seriously problematic and a huge process failure.
> >
> >
> > That is not an accurate statement.
> >
> > The IETF has achieved consensus on this topic. It's explained here by
> > Brian Carpenter.
> >
> > https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDX
> > yAUA/
> 
> As I have explained with my newly introduced consensus standards, there is no
> such consensus.
> 
> To reiterate my consensus standards, consensus is only to be considered as
> amongst stakeholders and IPv6 specific related stakes are not relevant to
> IPv4. If you consider the reverse to be true as well, I think my version of
> consensus would achieve a much wider and diverse consensus than the the
> stated IETF's consensus.
> 
> Once a consensus has been proven invalid its beyond obnoxious to cling to it
> as though it maintains its own reality field.
> 
> >
> > He expressly states with many +1s that if something IPv4 related needs
> > to get worked on , it will be worked on,
> 
> IPv4 still needs address exhaustion solutions.
> 
> > but the consensus solution to V4 address exhaustion was IPng that
> > became IPv6, so that is considered a solved problem.
> 
> IPv6 is not a solution. Its a replacement that does not have the same
> problem. Which could be a solution to the problem, but only if the
> replacement happens on schedule. However, so long as the replacement hasnt
> happened, we still are dealing with the problem.
> 
> The IETF made a stupendously bad bet that IPv6 would happen in time.
> That is the kind of bet that you better be right about. They were a
> decade+ wrong. That they have the audacity and temerity to continue
> doubling down on that would be funny if it wasnt so outrageous, wrong and
> harmful.
> 
> Let us re-examine the premise. When did it become acceptable to quash work on
> one protocol because of the existence of another one that is preferred by the
> quashers?
> 
> Or in other words, the way you are framing things makes it seem as if the
> IETF has with intent and malice chosen to extend or at the very least ignore
> exhaustion issues for actual internet users so as to rig the system for their
> preferred outcome.
> 
> >
> > Some folks don't LIKE the solution, as is their right to do.
> 
> I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2
> resolution, not addressing policy, not the chaos of choice of inadequate
> interoperability approaches, not the denial of features desired by users, not
> the pmtud, not the fragmentation, and many other warts. I dont even like the
> notation schemes. They require multiple vision passes.
> 
> I do like the extra bits. Just not the way they 

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Vasilenko Eduard via NANOG]

IMHO: IETF is only partially guilty. Who was capable to predict in 1992-1994 
that:

- Wireless would become so popular (WiFi is from 1997) and wireless would 
emulate multicast so badly (hi SLAAC)
- Hardware forwarding (PFE) would be invented (1997) that would have a big 
additional cost to implement Enhanced Headers
- Encryption would never have a small enough cost to make it mandatory
- Router would be available in every smallest thing that makes distributed 
address acquisition redundant (hi SLAAC)

We should be fair - it was not possible to guess.

Ed/
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Joe Maimon
Sent: Thursday, March 31, 2022 3:01 AM
To: Tom Beecher 
Cc: NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC



Tom Beecher wrote:
>
> If the IETF has really been unable to achieve consensus on properly
> supporting the currently still dominant internet protocol, that is
> seriously problematic and a huge process failure.
>
>
> That is not an accurate statement.
>
> The IETF has achieved consensus on this topic. It's explained here by 
> Brian Carpenter.
>
> https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDX
> yAUA/

As I have explained with my newly introduced consensus standards, there is no 
such consensus.

To reiterate my consensus standards, consensus is only to be considered as 
amongst stakeholders and IPv6 specific related stakes are not relevant to IPv4. 
If you consider the reverse to be true as well, I think my version of consensus 
would achieve a much wider and diverse consensus than the the stated IETF's 
consensus.

Once a consensus has been proven invalid its beyond obnoxious to cling to it as 
though it maintains its own reality field.

>
> He expressly states with many +1s that if something IPv4 related needs 
> to get worked on , it will be worked on,

IPv4 still needs address exhaustion solutions.

> but the consensus solution to V4 address exhaustion was IPng that 
> became IPv6, so that is considered a solved problem.

IPv6 is not a solution. Its a replacement that does not have the same problem. 
Which could be a solution to the problem, but only if the replacement happens 
on schedule. However, so long as the replacement hasnt happened, we still are 
dealing with the problem.

The IETF made a stupendously bad bet that IPv6 would happen in time. 
That is the kind of bet that you better be right about. They were a 
decade+ wrong. That they have the audacity and temerity to continue
doubling down on that would be funny if it wasnt so outrageous, wrong and 
harmful.

Let us re-examine the premise. When did it become acceptable to quash work on 
one protocol because of the existence of another one that is preferred by the 
quashers?

Or in other words, the way you are framing things makes it seem as if the IETF 
has with intent and malice chosen to extend or at the very least ignore 
exhaustion issues for actual internet users so as to rig the system for their 
preferred outcome.

>
> Some folks don't LIKE the solution, as is their right to do.

I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2 resolution, 
not addressing policy, not the chaos of choice of inadequate interoperability 
approaches, not the denial of features desired by users, not the pmtud, not the 
fragmentation, and many other warts. I dont even like the notation schemes. 
They require multiple vision passes.

I do like the extra bits. Just not the way they are being frittered.

The real crux of the matter is that it did not work. Address exhaustion has not 
been alleviated. For many years now and who knows how much longer.

> But the problem of V4 address exhaustion is NOT the same thing as "I 
> don't like the solution that they chose."

The problem of V4 address exhaustion is NOT the same thing as turn on
IPv6 and wait for the rest of the world to do the same.

When considered in that manner the IETF's bet looks even worse.

What I dont like is that they were wrong. What I dislike even more is that they 
refuse to admit it and learn from their mistakes.

Joe

> On Wed, Mar 30, 2022 at 12:18 PM Joe Maimon  <mailto:jmai...@jmaimon.com>> wrote:
>
>
>
> Owen DeLong via NANOG wrote:
>
> >
> > Well… It’s a consensus process. If your idea isn’t getting
> consensus,
> > then perhaps it’s simply that the group you are seeking
> consensus from
> > doesn’t like your idea.
>

Consensus processes are vulnerable to tyranny of a well positioned minority.

Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Tom Beecher wrote:


If the IETF has really been unable to achieve consensus on properly
supporting the currently still dominant internet protocol, that is
seriously problematic and a huge process failure.


That is not an accurate statement.

The IETF has achieved consensus on this topic. It's explained here by 
Brian Carpenter.


https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDXyAUA/


As I have explained with my newly introduced consensus standards, there 
is no such consensus.


To reiterate my consensus standards, consensus is only to be considered 
as amongst stakeholders and IPv6 specific related stakes are not 
relevant to IPv4. If you consider the reverse to be true as well, I 
think my version of consensus would achieve a much wider and diverse 
consensus than the the stated IETF's consensus.


Once a consensus has been proven invalid its beyond obnoxious to cling 
to it as though it maintains its own reality field.




He expressly states with many +1s that if something IPv4 related needs 
to get worked on , it will be worked on,


IPv4 still needs address exhaustion solutions.

but the consensus solution to V4 address exhaustion was IPng that 
became IPv6, so that is considered a solved problem.


IPv6 is not a solution. Its a replacement that does not have the same 
problem. Which could be a solution to the problem, but only if the 
replacement happens on schedule. However, so long as the replacement 
hasnt happened, we still are dealing with the problem.


The IETF made a stupendously bad bet that IPv6 would happen in time. 
That is the kind of bet that you better be right about. They were a 
decade+ wrong. That they have the audacity and temerity to continue 
doubling down on that would be funny if it wasnt so outrageous, wrong 
and harmful.


Let us re-examine the premise. When did it become acceptable to quash 
work on one protocol because of the existence of another one that is 
preferred by the quashers?


Or in other words, the way you are framing things makes it seem as if 
the IETF has with intent and malice chosen to extend or at the very 
least ignore exhaustion issues for actual internet users so as to rig 
the system for their preferred outcome.




Some folks don't LIKE the solution, as is their right to do.


I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2 
resolution, not addressing policy, not the chaos of choice of inadequate 
interoperability approaches, not the denial of features desired by 
users, not the pmtud, not the fragmentation, and many other warts. I 
dont even like the notation schemes. They require multiple vision passes.


I do like the extra bits. Just not the way they are being frittered.

The real crux of the matter is that it did not work. Address exhaustion 
has not been alleviated. For many years now and who knows how much longer.


But the problem of V4 address exhaustion is NOT the same thing as "I 
don't like the solution that they chose."


The problem of V4 address exhaustion is NOT the same thing as turn on 
IPv6 and wait for the rest of the world to do the same.


When considered in that manner the IETF's bet looks even worse.

What I dont like is that they were wrong. What I dislike even more is 
that they refuse to admit it and learn from their mistakes.


Joe

On Wed, Mar 30, 2022 at 12:18 PM Joe Maimon > wrote:




Owen DeLong via NANOG wrote:

>
> Well… It’s a consensus process. If your idea isn’t getting
consensus,
> then perhaps it’s simply that the group you are seeking
consensus from
> doesn’t like your idea.



Consensus processes are vulnerable to tyranny of a well positioned minority.

Joe

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Mark Andrews]

Sites looking at the traffic they get and saying, you know what all our 
customers connect to us
over IPv6 with some of them also connecting over IPv4.  I think we can stop 
supporting IPv4 now.

ISP’s saying this IPv4aaS isn’t getting much traffic anymore lets out source it 
for the few
customers that are still using it.  Lots of ISPs are well down the path leading 
to this point
by turning off IPv4 on the access networks.

Home / enterprise networks.  All my gear is IPv6 capable and supports IPv4aaS 
for the few legacy
IPv4 sites I need to connect to.  This is happening today.

In the end almost all the IPv4 traffic with be with the third party IPv4aaS 
providers and collectively
they will decide to turn off the lights. 

> On 30 Mar 2022, at 07:53, Jacques Latour  wrote:
> 
> So, in 25, 50 or 100 years from now, are we still going to be dual stack 
> IPv4/IPv6?
> When are we going to give up on IPv4?
> People can run IPv4 all they want inside their networks for 1000s of years.
> What will it take to be IPv6 only?
> 
> 
> 
> From: NANOG  On Behalf Of 
> Owen DeLong via NANOG
> Sent: March 29, 2022 3:52 PM
> To: Abraham Y. Chen 
> Cc: NANOG 
> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported 
> re: 202203261833.AYC
> 
> Submit an Internet draft, same as any other IP related enhancement gets 
> introduced.
> 
> What you’re really complaining about is that it’s been virtually impossible 
> to gain consensus to move anything IPv4 related forward in the IETF since at 
> least 2015.
> 
> Well… It’s a consensus process. If your idea isn’t getting consensus, then 
> perhaps it’s simply that the group you are seeking consensus from doesn’t 
> like your idea.
> 
> Your inability to convince the members of the various working groups that 
> your idea has merit isn’t necessarily a defect in the IETF process… It might 
> simply be a lack of merit in your ideas.
> 
> Owen
> 
> 
> 
> On Mar 26, 2022, at 15:43 , Abraham Y. Chen  wrote:
> 
> Hi, Justin:
> 
> 1)"... no one is stopping anyone from working on IPv4 ... ":   After 
> all these discussions, are you still denying this basic issue? For example, 
> there has not been any straightforward way to introduce IPv4 enhancement 
> ideas to IETF since at least 2015. If you know the way, please make it 
> public. I am sure that many are eager to learn about it. Thanks.
> 
> Regards,
> 
> 
> Abe (2022-03-26 18:42)
> 
> 
> 
> 
> On 2022-03-26 11:20, Justin Streiner wrote:
> While the Internet is intended to allow the free exchange of information, the 
> means of getting that information from place to place is and has to be 
> defined by protocols that are implemented in a consistent manner (see: BGP, 
> among many other examples).  It's important to separate the ideas from the 
> plumbing.
> 
> That said, no one is stopping anyone from working on IPv4, so what personal 
> freedoms are being impacted by working toward deploying IPv6, with an eye 
> toward sunsetting IPv4 in the future?
> 
> Keep in mind that IPv4 started out as an experiment that found its way into 
> wider use.  It's a classic case of a test deployment that suddenly mutated 
> into a production service.  Why should we continue to expend effort to 
> perpetuate the sins of the past, rather work toward getting v6 into wider use?
> 
> Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain 
> point of IPv4 - address space exhaustion.
> 
> Thank you
> jms
> 
> On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen  wrote:
> 
> 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic 
> baseline that we need to sort out, first. That is, we must keep in mind that 
> the Internet community strongly promotes "personal freedom". Assuming that by 
> stopping others from working on IPv4 will shift their energy to IPv6 is 
> totally contradicting such a principle. A project attracts contributors by 
> its own merits, not by relying on artificial barriers to the competitions. 
> Based on my best understanding, IPv6 failed right after the decision of "not 
> emphasizing the backward compatibility with IPv4". It broke one of the golden 
> rules in the system engineering discipline. After nearly three decades, still 
> evading such fact, but defusing IPv6 issues by various tactics is the real 
> impedance to progress, not only to IPv4 but also to IPv6.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Tom Beecher]

>
> If the IETF has really been unable to achieve consensus on properly
> supporting the currently still dominant internet protocol, that is
> seriously problematic and a huge process failure.
>

That is not an accurate statement.

The IETF has achieved consensus on this topic. It's explained here by Brian
Carpenter.

https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDXyAUA/

He expressly states with many +1s that if something IPv4 related needs to
get worked on , it will be worked on, but the consensus solution to V4
address exhaustion was IPng that became IPv6, so that is considered a
solved problem.

Some folks don't LIKE the solution, as is their right to do. But the
problem of V4 address exhaustion is NOT the same thing as "I don't like the
solution that they chose."

On Wed, Mar 30, 2022 at 12:18 PM Joe Maimon  wrote:

>
>
> Owen DeLong via NANOG wrote:
> > What you’re really complaining about is that it’s been virtually
> > impossible to gain consensus to move anything IPv4 related forward in
> > the IETF since at least 2015.
> >
> > Well… It’s a consensus process. If your idea isn’t getting consensus,
> > then perhaps it’s simply that the group you are seeking consensus from
> > doesn’t like your idea.
>
> If the IETF has really been unable to achieve consensus on properly
> supporting the currently still dominant internet protocol, that is
> seriously problematic and a huge process failure.
>
> When vendors do that sort of thing people get up in arms. When open
> source projects do that sort of thing, they get forked. When community
> grassroots governance bodies do that sort of thing, I dont want to find
> out.
>
> Responsible stewardship of internet community standardization would be
> excluding IPv6 strategic concerns from considerations of consensus on
> IPv4 issues.
>
> In other words, if the only issues you can bring to bear on any matter
> pertaining solely to IPv4 is all about IPv6, your not relevant to the
> process and should be struck from the record.
>
> I would even go so far as to say that you are actually poisoning the
> process.
>
> >
> > Your inability to convince the members of the various working groups
> > that your idea has merit isn’t necessarily a defect in the IETF
> > process… It might simply be a lack of merit in your ideas.
> >
> > Owen
> >
> >
> This part is very good advice, perhaps restated as a lack of merit in
> the idea when combined with much wider and diverse perspectives.
>
> On the other hand, with no record and history of ideology driven
> agendas, the IETF process would be a whole lot more trustworthy.
>
> Joe
>
>
>

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Owen DeLong via NANOG wrote:
What you’re really complaining about is that it’s been virtually 
impossible to gain consensus to move anything IPv4 related forward in 
the IETF since at least 2015.


Well… It’s a consensus process. If your idea isn’t getting consensus, 
then perhaps it’s simply that the group you are seeking consensus from 
doesn’t like your idea.


If the IETF has really been unable to achieve consensus on properly 
supporting the currently still dominant internet protocol, that is 
seriously problematic and a huge process failure.


When vendors do that sort of thing people get up in arms. When open 
source projects do that sort of thing, they get forked. When community 
grassroots governance bodies do that sort of thing, I dont want to find out.


Responsible stewardship of internet community standardization would be 
excluding IPv6 strategic concerns from considerations of consensus on 
IPv4 issues.


In other words, if the only issues you can bring to bear on any matter 
pertaining solely to IPv4 is all about IPv6, your not relevant to the 
process and should be struck from the record.


I would even go so far as to say that you are actually poisoning the 
process.




Your inability to convince the members of the various working groups 
that your idea has merit isn’t necessarily a defect in the IETF 
process… It might simply be a lack of merit in your ideas.


Owen


This part is very good advice, perhaps restated as a lack of merit in 
the idea when combined with much wider and diverse perspectives.


On the other hand, with no record and history of ideology driven 
agendas, the IETF process would be a whole lot more trustworthy.


Joe

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[jim deleskie]

If then industry still hasn't adopted v6 full in 25 years maybe it's v6
that should be given up it, that it clearly wasn't what customers wanted.
Perhaps we should should have a small group working on the next iteration.

-jim

On Tue, Mar 29, 2022, 5:54 PM Jacques Latour  wrote:

> So, in 25, 50 or 100 years from now, are we still going to be dual stack
> IPv4/IPv6?
>
> When are we going to give up on IPv4?
>
> People can run IPv4 all they want inside their networks for 1000s of years.
>
> What will it take to be IPv6 only?
>
>
>
> 
>
>
>
> *From:* NANOG  *On Behalf
> Of *Owen DeLong via NANOG
> *Sent:* March 29, 2022 3:52 PM
> *To:* Abraham Y. Chen 
> *Cc:* NANOG 
> *Subject:* [EXT] Re: Let's Focus on Moving Forward Re: V6 still not
> supported re: 202203261833.AYC
>
>
>
> Submit an Internet draft, same as any other IP related enhancement gets
> introduced.
>
>
>
> What you’re really complaining about is that it’s been virtually
> impossible to gain consensus to move anything IPv4 related forward in the
> IETF since at least 2015.
>
>
>
> Well… It’s a consensus process. If your idea isn’t getting consensus, then
> perhaps it’s simply that the group you are seeking consensus from doesn’t
> like your idea.
>
>
>
> Your inability to convince the members of the various working groups that
> your idea has merit isn’t necessarily a defect in the IETF process… It
> might simply be a lack of merit in your ideas.
>
>
>
> Owen
>
>
>
>
>
> On Mar 26, 2022, at 15:43 , Abraham Y. Chen  wrote:
>
>
>
> Hi, Justin:
>
>
>
> 1)"... no one is stopping anyone from working on IPv4 ... ":
> After all these discussions, are you still denying this basic issue? For
> example, there has not been any straightforward way to introduce IPv4
> enhancement ideas to IETF since at least 2015. If you know the way, please
> make it public. I am sure that many are eager to learn about it. Thanks.
>
>
>
> Regards,
>
>
>
>
>
> Abe (2022-03-26 18:42)
>
>
>
>
>
>
>
>
>
> On 2022-03-26 11:20, Justin Streiner wrote:
>
> While the Internet is intended to allow the free exchange of information,
> the means of getting that information from place to place is and has to be
> defined by protocols that are implemented in a consistent manner (see: BGP,
> among many other examples).  It's important to separate the ideas from the
> plumbing.
>
>
>
> That said, no one is stopping anyone from working on IPv4, so what
> personal freedoms are being impacted by working toward deploying IPv6, with
> an eye toward sunsetting IPv4 in the future?
>
>
>
> Keep in mind that IPv4 started out as an experiment that found its way
> into wider use.  It's a classic case of a test deployment that suddenly
> mutated into a production service.  Why should we continue to expend effort
> to perpetuate the sins of the past, rather work toward getting v6 into
> wider use?
>
>
>
> Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain
> point of IPv4 - address space exhaustion.
>
>
>
> Thank you
>
> jms
>
>
>
> On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen  wrote:
>
>
>
> 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic /
> logic baseline that we need to sort out, first. That is, we must keep in
> mind that the Internet community strongly promotes "*personal freedom*".
> Assuming that by stopping others from working on IPv4 will shift their
> energy to IPv6 is totally contradicting such a principle. A project
> attracts contributors by its own merits, not by relying on artificial
> barriers to the competitions. Based on my best understanding, IPv6 failed
> right after the decision of "not emphasizing the backward compatibility
> with IPv4". It broke one of the golden rules in the system engineering
> discipline. After nearly three decades, still evading such fact, but
> defusing IPv6 issues by various tactics is the real impedance to progress,
> not only to IPv4 but also to IPv6.
>
>
>
>
>

IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Jacques Latour]

So, in 25, 50 or 100 years from now, are we still going to be dual stack 
IPv4/IPv6?
When are we going to give up on IPv4?
People can run IPv4 all they want inside their networks for 1000s of years.
What will it take to be IPv6 only?



From: NANOG  On Behalf Of Owen 
DeLong via NANOG
Sent: March 29, 2022 3:52 PM
To: Abraham Y. Chen 
Cc: NANOG 
Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Submit an Internet draft, same as any other IP related enhancement gets 
introduced.

What you’re really complaining about is that it’s been virtually impossible to 
gain consensus to move anything IPv4 related forward in the IETF since at least 
2015.

Well… It’s a consensus process. If your idea isn’t getting consensus, then 
perhaps it’s simply that the group you are seeking consensus from doesn’t like 
your idea.

Your inability to convince the members of the various working groups that your 
idea has merit isn’t necessarily a defect in the IETF process… It might simply 
be a lack of merit in your ideas.

Owen



On Mar 26, 2022, at 15:43 , Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

Hi, Justin:

1)"... no one is stopping anyone from working on IPv4 ... ":   After 
all these discussions, are you still denying this basic issue? For example, 
there has not been any straightforward way to introduce IPv4 enhancement ideas 
to IETF since at least 2015. If you know the way, please make it public. I am 
sure that many are eager to learn about it. Thanks.

Regards,


Abe (2022-03-26 18:42)




On 2022-03-26 11:20, Justin Streiner wrote:
While the Internet is intended to allow the free exchange of information, the 
means of getting that information from place to place is and has to be defined 
by protocols that are implemented in a consistent manner (see: BGP, among many 
other examples).  It's important to separate the ideas from the plumbing.

That said, no one is stopping anyone from working on IPv4, so what personal 
freedoms are being impacted by working toward deploying IPv6, with an eye 
toward sunsetting IPv4 in the future?

Keep in mind that IPv4 started out as an experiment that found its way into 
wider use.  It's a classic case of a test deployment that suddenly mutated into 
a production service.  Why should we continue to expend effort to perpetuate 
the sins of the past, rather work toward getting v6 into wider use?

Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain 
point of IPv4 - address space exhaustion.

Thank you
jms

On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic 
baseline that we need to sort out, first. That is, we must keep in mind that 
the Internet community strongly promotes "personal freedom". Assuming that by 
stopping others from working on IPv4 will shift their energy to IPv6 is totally 
contradicting such a principle. A project attracts contributors by its own 
merits, not by relying on artificial barriers to the competitions. Based on my 
best understanding, IPv6 failed right after the decision of "not emphasizing 
the backward compatibility with IPv4". It broke one of the golden rules in the 
system engineering discipline. After nearly three decades, still evading such 
fact, but defusing IPv6 issues by various tactics is the real impedance to 
progress, not only to IPv4 but also to IPv6.

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Owen DeLong via NANOG]

Submit an Internet draft, same as any other IP related enhancement gets 
introduced.

What you’re really complaining about is that it’s been virtually impossible to 
gain consensus to move anything IPv4 related forward in the IETF since at least 
2015.

Well… It’s a consensus process. If your idea isn’t getting consensus, then 
perhaps it’s simply that the group you are seeking consensus from doesn’t like 
your idea.

Your inability to convince the members of the various working groups that your 
idea has merit isn’t necessarily a defect in the IETF process… It might simply 
be a lack of merit in your ideas.

Owen


> On Mar 26, 2022, at 15:43 , Abraham Y. Chen  wrote:
> 
> Hi, Justin:
> 
> 1)"... no one is stopping anyone from working on IPv4 ... ":   After 
> all these discussions, are you still denying this basic issue? For example, 
> there has not been any straightforward way to introduce IPv4 enhancement 
> ideas to IETF since at least 2015. If you know the way, please make it 
> public. I am sure that many are eager to learn about it. Thanks.
> 
> Regards,
> 
> 
> Abe (2022-03-26 18:42)
> 
> 
> 
> 
> On 2022-03-26 11:20, Justin Streiner wrote:
>> While the Internet is intended to allow the free exchange of information, 
>> the means of getting that information from place to place is and has to be 
>> defined by protocols that are implemented in a consistent manner (see: BGP, 
>> among many other examples).  It's important to separate the ideas from the 
>> plumbing.
>> 
>> That said, no one is stopping anyone from working on IPv4, so what personal 
>> freedoms are being impacted by working toward deploying IPv6, with an eye 
>> toward sunsetting IPv4 in the future?
>> 
>> Keep in mind that IPv4 started out as an experiment that found its way into 
>> wider use.  It's a classic case of a test deployment that suddenly mutated 
>> into a production service.  Why should we continue to expend effort to 
>> perpetuate the sins of the past, rather work toward getting v6 into wider 
>> use?
>> 
>> Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain 
>> point of IPv4 - address space exhaustion.
>> 
>> Thank you
>> jms
>> 
>> On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen > > wrote:
>> 
>> 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic 
>> baseline that we need to sort out, first. That is, we must keep in mind that 
>> the Internet community strongly promotes "personal freedom". Assuming that 
>> by stopping others from working on IPv4 will shift their energy to IPv6 is 
>> totally contradicting such a principle. A project attracts contributors by 
>> its own merits, not by relying on artificial barriers to the competitions. 
>> Based on my best understanding, IPv6 failed right after the decision of "not 
>> emphasizing the backward compatibility with IPv4". It broke one of the 
>> golden rules in the system engineering discipline. After nearly three 
>> decades, still evading such fact, but defusing IPv6 issues by various 
>> tactics is the real impedance to progress, not only to IPv4 but also to IPv6.
>> 
>> 
>>  

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Justin:

1)        "  denying that anyone is being stopped from */working on/* 
IPv4, I'm referring to users being able to */communicate via /*IPv4.    
": The two topics are quite different. It looks that we may have some 
language issues here. So, allow me to stop.


Regards,

Abe (2022-03-27 12:31)


On 2022-03-27 12:11, Justin Streiner wrote:

Abe:

To your first point about denying that anyone is being stopped from 
working on IPv4, I'm referring to users being able to communicate via 
IPv4.  I have seen no evidence of that.


I'm not familiar with the process of submitting ideas to IETF, so I'll 
leave that for others who are more knowledgeable on that to speak up 
if they're so inclined.


Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen  wrote:


1)    "... no one is stopping anyone from working on IPv4 ...    
":   After all these discussions, are you still denying this basic
issue? For example, there has not been any straightforward way to
introduce IPv4 enhancement ideas to IETF since at least 2015. If
you know the way, please make it public. I am sure that many are
eager to learn about it. Thanks.




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Justin Streiner]

Abe:

To your first point about denying that anyone is being stopped from working
on IPv4, I'm referring to users being able to communicate via IPv4.  I have
seen no evidence of that.

I'm not familiar with the process of submitting ideas to IETF, so I'll
leave that for others who are more knowledgeable on that to speak up if
they're so inclined.

Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen  wrote:

>
> 1)"... no one is stopping anyone from working on IPv4 ... ":
> After all these discussions, are you still denying this basic issue? For
> example, there has not been any straightforward way to introduce IPv4
> enhancement ideas to IETF since at least 2015. If you know the way, please
> make it public. I am sure that many are eager to learn about it. Thanks.
>

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Justin:

1)    "... no one is stopping anyone from working on IPv4 ...     ":   
After all these discussions, are you still denying this basic issue? For 
example, there has not been any straightforward way to introduce IPv4 
enhancement ideas to IETF since at least 2015. If you know the way, 
please make it public. I am sure that many are eager to learn about it. 
Thanks.


Regards,


Abe (2022-03-26 18:42)




On 2022-03-26 11:20, Justin Streiner wrote:
While the Internet is intended to allow the free exchange of 
information, the means of getting that information from place to place 
is and has to be defined by protocols that are implemented in a 
consistent manner (see: BGP, among many other examples).  It's 
important to separate the ideas from the plumbing.


That said, no one is stopping anyone from working on IPv4, so what 
personal freedoms are being impacted by working toward deploying IPv6, 
with an eye toward sunsetting IPv4 in the future?


Keep in mind that IPv4 started out as an experiment that found its way 
into wider use.  It's a classic case of a test deployment that 
suddenly mutated into a production service. Why should we continue to 
expend effort to perpetuate the sins of the past, rather work toward 
getting v6 into wider use?


Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key 
pain point of IPv4 - address space exhaustion.


Thank you
jms

On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen  wrote:


3)    Re: Ur. Pts. 5) & 6):    I believe that there is a
philosophic / logic baseline that we need to sort out, first. That
is, we must keep in mind that the Internet community strongly
promotes "*/personal freedom/*". Assuming that by stopping others
from working on IPv4 will shift their energy to IPv6 is totally
contradicting such a principle. A project attracts contributors by
its own merits, not by relying on artificial barriers to the
competitions. Based on my best understanding, IPv6 failed right
after the decision of "not emphasizing the backward compatibility
with IPv4". It broke one of the golden rules in the system
engineering discipline. After nearly three decades, still evading
such fact, but defusing IPv6 issues by various tactics is the real
impedance to progress, not only to IPv4 but also to IPv6.



<#m_4226728999263060367_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus