subject:"Let's Focus on Moving Forward Re\: V6 still not supported"

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

2022-04-04 Thread 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

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

2022-04-04 Thread 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

2022-04-04 Thread 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

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

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

2022-04-04 Thread 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

2022-04-04 Thread 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

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

2022-04-04 Thread 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

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

2022-04-02 Thread Fred Baker

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

> On Apr 2, 2022, at 5:57 AM, Abraham Y. Chen  wrote:
> 
> 1)" ...  darknet ...  ":I am not aware of this terminology. 
> Nonetheless, I believe that bringing in a not commonly known word into a 
> discussion like this is just distraction tactic.

It’s actually a pretty common word for a prefix or other set of addresses used 
to detect address scans. If an address is unused and not in DNS, a packet sent 
to it is not obviously benign, nor is the systemvv be sending it.

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-04-02 Thread Abraham Y. Chen

Hi, Christian:

1) I am a person who normally does not do hearsay. This was why I put
the unverified "street legend" about ancient Lord in parentheses to just
hint the possible extreme. Without it, the flow of my short story really
does not change. Since you spotted on it, I went back to search for the
online article that I had in mind. The following URL is likely what I
read because the keyword "Celtic" linked my vague understanding of
Ireland to England in general:

https://www.smithsonianmag.com/smart-news/tollund-man-europe-bog-body-meal-food-history-mummy-180978247/

There were several hypotheses in the above hinting the
interpretation that I got. The following citation seems to be more
specific.

“In Ireland, the king is the pivotal member of society, so when things
go wrong, he pays the price,” says Kelly. “All the new bodies discovered
since then have reaffirmed this theory.

For sure, this subject is off topic on this mailing list. Have fun to
dig into it, if you like. I will be glad to carry on with you offline.

2) " I am not assured that my interests are protected from anybody by
being told I have no direct access to people I want to communicate with
but have to go through a third party. ... ": I am not sure that I
can properly decipher your precise preference through a long paragraph.
But, based on your general tone, I get the sense that you prefer the
current "Internet way" than a more explicit and rigid communication
system convention that EzIP proposes. If so, you might be living in fantasy:

A. Note that the privacy and security issues are multi-faceted.
One has to look at them from the perspectives of both the victims and
the perpetrators. There was a "classic" paper a long time ago (2006)
that made this painfully clear.

Internet Geolocation and Evasion

https://www.ccsl.carleton.ca/paper-archive/muir-computingsurveys-09.pdf

It was a long research paper. But, a concise summary was given in
Section 6 Concluding Remarks:

*
We note that even if accurate IP geolocation is possible for 99% of IP
addresses, if the remaining 1% is fixed and predictable by an adversary,
and such that the adversary can place themselves within this subspace,
then they can evade geolocation 100% of the time.

Judging by the facts that the targeted marketing is very successful
these days, while it is very challenging to identify, let alone to
locate, a perpetrator, the above is most likely still true.

B. On the other hand, governments have been taking advantage of
the current Internet privacy practices as the excuse to actually invade
individual's privacy. See below for a recent status report:

'A free pass to seize and sift': Federal court upholds terrorism
conviction in controversial mass surveillancecase

https://www.usatoday.com/story/news/2021/12/08/federal-court-upholds-terrorism-conviction-mass-surveillance-case/6440325001/

3) Based on the master/slave relationship, the current sever/client
operation model dominates the Content Delivery Networks (CDN) that even
handles eMail services (probably by offering their off-peak spare
capacity, since eMail is time insensitive). This was evidenced by eMail
services got interrupted when Netflix service was down recently. This
means that, like it or not, individual's communications have been
buffered, relayed, etc. along the way, giving more than enough
opportunities for the "free service" third, or fourth party providers to
do whatever they wish, anyway. So, we should stop the current kind of
ostrich mentality for our own good. What EzIP proposes is to forget
about all these current fictitious "protections", but go back to the
explicit communications disciplines of yesterday years. So that, the
behind-the-scene mass surveillance will be outlawed again. Then,
whenever there is any need to monitor a suspected party, an explicit
request must be first made by a law enforcement agency to the court.
Sorry to those businesses who provide surveillance and analysis
equipment (computers and memories) as well as service to law enforcement
agencies.

Regards,

Abe (2022-04-02 17:50)

On 2022-04-02 12:13, christian de larrinaga wrote:

Your take on English history is a delightful fantasy but it is
just that a delightful fantasy. Norman barons were not typically
concerned with the health of their anglo saxon/british serfs / yoemen
other than providing the required tithes.

But taking you at what seems to be your intention. Speaking as a digital
peasant I am not assured that my interests are protected
from anybody by being told I have no direct access to people I want to
communicate with but have to go through a third party. Any addressing
model that terminates address space between me and

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

2022-04-02 Thread 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

2022-04-02 Thread christian de larrinaga via NANOG



Your take on English history is a delightful fantasy but it is
just that a delightful fantasy. Norman barons were not typically
concerned with the health of their anglo saxon/british serfs / yoemen
other than providing the required tithes.

But taking you at what seems to be your intention. Speaking as a digital 
peasant I am not assured that my interests are protected
from anybody by being told I have no direct access to people I want to
communicate with but have to go through a third party. Any addressing
model that  terminates address space between me and someone I
communicate with also terminates my communications and security and by
so doing introduces a number of uncertainties potentially rather
arbitrary to what would otherwise be under my direct policy domain.

C


"Abraham Y. Chen"  writes:

> Hi, Christian:
>
> 0)    Allow me following your "towers of babel world" metaphor to tell
> a short story.
>
> 1)    In the ancient days, peasants labored under the shadow of the
> Tower, following the rules of and paid tax to the Lord living in the
> Tower. In return, they expected protection from the Lord against
> harms. (Sometime ago, I read an archaeological article reporting
> certain evidence that the Load somewhere in England during medieval
> time might have been expected to protect his peasants from any harm,
> including even paid his life for famine.)
>
> 2)    In the modern world, the peasants still live around the Tower
> following the rules, paying taxes and expecting protection from the
> Lord, now represented by the government agencies such as local police,
> FCC, FTC, DoD, DHS, etc.
>
> 3)    In the Internet era, the peasants roam everywhere around the
> cyberspace freely enjoying the Internet way. However, their wealth is
> now being siphoned out to the invisible Lords (the multi-national
> businesses with virtual presence in each and every Tower). However,
> little can be expected in return when perpetrators attack, because no
> Lord assumes the responsibility, nor any can be held responsible.
>
> 4)    EzIP proposes an overlay cyberspace with geographic flavor to
> restore the society infrastructure back to Pt. 2) above, while
> providing the daily services of Pt. 3). It essentially offers a
> parallel Internet for the peasants who can again expect protection
> from their local government who collects taxes, while without losing
> the benefits of the digital revolution.
>
> 5)    The two cyberspaces are expected to coexist and none-interfering
> to each other. Peasants have the freedom of choice by living in either
> or try both then decide.
>
> The above is just a quick rough thought, far from polished. It is
> intended to be a preliminary framework so that we can hang some meat
> on it for starting meaningful discussions.
>
> Regards,
>
>
> Abe (2022-04-01 14:17)
>
>
>
>
>
>
> On 2022-03-27 11:03, Christian de Larrinaga wrote:
>>
>>
>> On 27 March 2022 15:53:25 Brandon Butterworth 
>> wrote:
>>
>>> On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:
 EzIP proposes to deploy 240/4
 address based RANs, each tethering off the current Internet via
 one IPv4
 public address.
>>>
>>> So each RAN has no possibility of redundant connections? Nobody
>>> of scale would accept such a limitation. It also looks like an
>>> opportunity for telcos/governments to partition their part
>>> of the internet and impose whatever censorship they wish.
>>>
 As such, the collection of RANs forms an overlay network
 layer wrapping around the current Internet core. Consequently, only the
 SPRs in the RAN need to be able to transport 240/4 addressed packets.
>>>
>>> You previously described this as like connecting CG-NATs together via a
>>> VPN. I don't see why we'd want to add maintaining a global VPN to
>>> already difficult peering relationships. It could be used to exlude non
>>> EzIP club members.
>>>
 This is why we talk about enabling new (but based on existing design)
 routers to use 240/4 netblock for serving as SPRs, but not perturbing
 any routers in the current Internet.
>>>
>>> As it's a CG-NAT variant why are you delaying yourself by requiring
>>> new address space that will take a long time to become available? Why
>>> not use the already allocated space for CG-NAT? Sure it's only a /10
>>> but that's an already (probably too) large RAN.
>>>
>>> It also seems unfeasibly optimistic that if the work was done globally
>>> to make 240/4 useable that they'd want to dedicate it to the as yet
>>> undeployed EzIP. You might stand more chance if you gained some
>>> critical mass using the existing available 100.64/10 & rfc1918 space,
>>> and then those that find they need more in one RAN will make the case
>>> for 240/4 when it becomes necessary for them. Is 240/4 special to
>>> EzIP such that alternative numbers may not be used?
>>>
 I would like to share one intriguing graphics (see URL below) that
 is almost perfect for depicting the EzIP

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-04-02 Thread Abraham Y. Chen


Hi, Ant:

1)    " ...  darknet ...  ":    I am not aware of this terminology. 
Nonetheless, I believe that bringing in a not commonly known word into a 
discussion like this is just distraction tactic.


2)    " ...  progress ...  ":    EzIP proposes a parallel cyberspace to 
the current Internet which not only is none interfering to each other, 
but also promises to require bare minimum engineering efforts to deploy. 
This can settle the long debates on which way the Internet should go via 
true experiments. If this is not regarded as progress, I am not sure 
what qualifies so under your definition.



Regards,


Abe (2022-04-02 08:55)



On 2022-04-02 00:21, ant+nanog@antiphase.net wrote:

On 1 Apr 2022, at 11:17, Abraham Y. Chen wrote:


4)    EzIP proposes an overlay cyberspace with geographic flavor to restore the 
society infrastructure back to Pt. 2) above, while providing the daily services 
of Pt. 3). It essentially offers a parallel Internet for the peasants who can 
again expect protection from their local government who collects taxes, while 
without losing the benefits of the digital revolution.

So essentially a darknet whose implementation happens to be patent-encumbered 
by you. This doesn’t sound like progress to me.

Ant




--
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

2022-04-02 Thread 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

2022-04-01 Thread Anthony Newman via NANOG




On 1 Apr 2022, at 11:17, Abraham Y. Chen wrote:

>
> 4)    EzIP proposes an overlay cyberspace with geographic flavor to restore 
> the society infrastructure back to Pt. 2) above, while providing the daily 
> services of Pt. 3). It essentially offers a parallel Internet for the 
> peasants who can again expect protection from their local government who 
> collects taxes, while without losing the benefits of the digital revolution.

So essentially a darknet whose implementation happens to be patent-encumbered 
by you. This doesn’t sound like progress to me.

Ant

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-04-01 Thread Michael Thomas




On 3/31/22 9:26 PM, Owen DeLong via NANOG wrote:



On Mar 31, 2022, at 20:51, Masataka Ohta  
wrote:

Owen DeLong wrote:


It still suffers from a certain amount of opacity across administrative domains.

So, if an IPv6 prefix is assigned to an apartment building and
the building has no logging mechanism on how addresses are used
within the building, the problem of audit trail opacity is
suffered.

Thank you very much to have proven IPv6 useless.

Masataka Ohta


No, the problem of address correlation to end user may still exist, but the 
address
Is transparent. The address in log files at the apartment complex matches the 
address
In log files at intervening networks matches the address in log files at the 
victim network.

Obviously, if the apartment complex has no log files, then yes, it remains 
relatively useless
In your one contrived corner case… That not being the more general and widely 
deployed
Case, I think that calling that proof that IPv6 is worthless proves more about 
your inane
Bias than anything else.


It's really quite something to see 30 year old grudges and foot stamping 
all because something in the distant past didn't happen in their 
preferred way. It's nearly impossible to even know what the preferred 
way actually was because, you know, grudge. I started a thread on what 
that might be and it was singularly uninformative about what they 
consider wrong. I'm going to go on a limb and say that an apartment 
building not logging something sinking 30 years of work and deployment 
is a little, um, yeah.


Mike

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

2022-04-01 Thread Seth David Schoen

Owen DeLong via NANOG writes:

> Just because there is a small code snippet you found that prevents casting 
> 240/4 as unicast on an interface doesn’t mean that removing that code will 
> magically make 240/4 usable in the entire stack.
> 
> [...]
> 
> The code you found may just be a safety valve to prevent the user from doing 
> something stupid that will have undefined consequences down the line if 
> executed. What you appear to have found is, quite likely, the equivalent of a 
> buffer bounds check on input. Removing the check doesn’t inherently make the 
> buffer infinite.

We've found remarkably few other places in Unix userspace that made
assumptions that would forbid the use of 240/4.  When we do find such
a thing, we propose a patch for that too.

Obviously, this can't prove that there is no application left that
treats 240/4 specially somehow.  Here is one!

# Refuse reserved peer addresses in userspace.

import socket
import sys

s = socket.socket()
s.bind(("0.0.0.0", int(sys.argv[1])))
s.listen()
conn, addr = s.accept()
if socket.inet_aton(addr[0])[0] >= 240:
conn.close()
raise ValueError("Reserved peer address {}".format(addr[0]))
conn.send(b"Hello, world!\n")
conn.close()

As long as people are running that application, their systems won't
be fully compatible with use of 240/4.

However, I haven't seen documentation that specifically encourages
network developers to do this kind of check for themselves (instead,
it's usually left to the OS).  I would be surprised if it were common
in userspace anywhere.

The way we will find out about these issues (and to some extent the way
we have been finding out about them already) is by running networks
that use these addresses with already-patched OSes, and seeing what
works or doesn't work.  I've noted in several talks that you can easily
try this for yourself if you run a wifi network that gives out internal
addresses in 240/4 and NATs them.  You can actually use this for
day-to-day work -- if you're not on Windows -- and gain more experience
and data about any possible problems.

There _are_ somewhat more often special cases in dynamic routing,
(to a lesser extent) autoconfiguration tools, and dedicated routers.
However, those we've seen and fixed have also represented tiny code
changes within those tools.

> It’s also important to note that there are at least a dozen IPv4 stacks in 
> common use with differing code implementations and underlying assumptions 
> baked into the code in various places.

Yes, for example I found a printer that was unhappy with 240/4.
Although I'm confident that the software changes needed are also
tiny, it may be difficult to get the vendor to issue them officially.

It's too bad that we couldn't officially agree back in 2008 to ask
the printer vendor, or its embedded OS developer, to make those
changes then.  If it gets to be 2036 and we've had 14 more years of
printers being manufactured with this behavior, that will be
unfortunate, too.

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

2022-04-01 Thread 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

2022-04-01 Thread Abraham Y. Chen


Hi, Christian:

0)    Allow me following your "towers of babel world" metaphor to tell a 
short story.


1)    In the ancient days, peasants labored under the shadow of the 
Tower, following the rules of and paid tax to the Lord living in the 
Tower. In return, they expected protection from the Lord against harms. 
(Sometime ago, I read an archaeological article reporting certain 
evidence that the Load somewhere in England during medieval time might 
have been expected to protect his peasants from any harm, including even 
paid his life for famine.)


2)    In the modern world, the peasants still live around the Tower 
following the rules, paying taxes and expecting protection from the 
Lord, now represented by the government agencies such as local police, 
FCC, FTC, DoD, DHS, etc.


3)    In the Internet era, the peasants roam everywhere around the 
cyberspace freely enjoying the Internet way. However, their wealth is 
now being siphoned out to the invisible Lords (the multi-national 
businesses with virtual presence in each and every Tower). However, 
little can be expected in return when perpetrators attack, because no 
Lord assumes the responsibility, nor any can be held responsible.


4)    EzIP proposes an overlay cyberspace with geographic flavor to 
restore the society infrastructure back to Pt. 2) above, while providing 
the daily services of Pt. 3). It essentially offers a parallel Internet 
for the peasants who can again expect protection from their local 
government who collects taxes, while without losing the benefits of the 
digital revolution.


5)    The two cyberspaces are expected to coexist and none-interfering 
to each other. Peasants have the freedom of choice by living in either 
or try both then decide.


The above is just a quick rough thought, far from polished. It is 
intended to be a preliminary framework so that we can hang some meat on 
it for starting meaningful discussions.


Regards,


Abe (2022-04-01 14:17)






On 2022-03-27 11:03, Christian de Larrinaga wrote:



On 27 March 2022 15:53:25 Brandon Butterworth  
wrote:



On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

EzIP proposes to deploy 240/4
address based RANs, each tethering off the current Internet via one 
IPv4

public address.


So each RAN has no possibility of redundant connections? Nobody
of scale would accept such a limitation. It also looks like an
opportunity for telcos/governments to partition their part
of the internet and impose whatever censorship they wish.


As such, the collection of RANs forms an overlay network
layer wrapping around the current Internet core. Consequently, only the
SPRs in the RAN need to be able to transport 240/4 addressed packets.


You previously described this as like connecting CG-NATs together via a
VPN. I don't see why we'd want to add maintaining a global VPN to
already difficult peering relationships. It could be used to exlude non
EzIP club members.


This is why we talk about enabling new (but based on existing design)
routers to use 240/4 netblock for serving as SPRs, but not perturbing
any routers in the current Internet.


As it's a CG-NAT variant why are you delaying yourself by requiring
new address space that will take a long time to become available? Why
not use the already allocated space for CG-NAT? Sure it's only a /10
but that's an already (probably too) large RAN.

It also seems unfeasibly optimistic that if the work was done globally
to make 240/4 useable that they'd want to dedicate it to the as yet
undeployed EzIP. You might stand more chance if you gained some
critical mass using the existing available 100.64/10 & rfc1918 space,
and then those that find they need more in one RAN will make the case
for 240/4 when it becomes necessary for them. Is 240/4 special to
EzIP such that alternative numbers may not be used?


I would like to share one intriguing graphics (see URL below) that
is almost perfect for depicting the EzIP deployment configuration.
Consider the blue sphere as the earth or the current Internet core and
the golden colored land as the RANs. By connecting each continent,
country or all the way down to a Region to the earth via one IPv4
address, we have the EzIP configuration. With this architecture, each
RAN looks like a private network.


That sounds an entirely undesirable goal for the internet.

brandon


It isn't the Internet. It's at best a very poorly connected spur gateway.

Too many today don't remember the towers of Babel world prior to the 
Internet. If they did they'd understand that building on this type of 
idea is like burying yourself And any customers so unwise to get 
involved


C




--
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

2022-04-01 Thread James R Cutler

On Mar 31, 2022, at 11:51 PM, Masataka Ohta  
wrote:
> 
> Owen DeLong wrote:
> 
>> It still suffers from a certain amount of opacity across administrative 
>> domains.
> 
> So, if an IPv6 prefix is assigned to an apartment building and
> the building has no logging mechanism on how addresses are used
> within the building, the problem of audit trail opacity is
> suffered.
> 
> Thank you very much to have proven IPv6 useless.
> 
>   Masataka Ohta

You appear to attribute to IPv6 a problem due to building management. Please 
explain how IPv6 is “useless” by some other measure that that of building 
management errors.

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

2022-04-01 Thread 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

2022-04-01 Thread 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

2022-04-01 Thread 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

2022-04-01 Thread 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

2022-04-01 Thread Masataka Ohta


Owen DeLong wrote:


It still suffers from a certain amount of opacity across administrative domains.


is the corner case.


Obviously, if the apartment complex has no log files, then yes, it remains
relatively useless


It is completely useless for the opacity required by police.


In your one contrived corner case


That's your problem.

Masataka Ohta

Re: Let's Focus on Moving Forward Re: V6 still not supported

> On Mar 31, 2022, at 20:51, Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
>> It still suffers from a certain amount of opacity across administrative 
>> domains.
> 
> So, if an IPv6 prefix is assigned to an apartment building and
> the building has no logging mechanism on how addresses are used
> within the building, the problem of audit trail opacity is
> suffered.
> 
> Thank you very much to have proven IPv6 useless.
> 
>   Masataka Ohta

No, the problem of address correlation to end user may still exist, but the 
address
Is transparent. The address in log files at the apartment complex matches the 
address
In log files at intervening networks matches the address in log files at the 
victim network.

Obviously, if the apartment complex has no log files, then yes, it remains 
relatively useless
In your one contrived corner case… That not being the more general and widely 
deployed
Case, I think that calling that proof that IPv6 is worthless proves more about 
your inane
Bias than anything else.

Owen

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-31 Thread Masataka Ohta


Owen DeLong wrote:


It still suffers from a certain amount of opacity across administrative domains.


So, if an IPv6 prefix is assigned to an apartment building and
the building has no logging mechanism on how addresses are used
within the building, the problem of audit trail opacity is
suffered.

Thank you very much to have proven IPv6 useless.

Masataka Ohta

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

2022-03-31 Thread 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

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




> 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

> 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

2022-03-31 Thread 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

2022-03-31 Thread 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

2022-03-31 Thread 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




> 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




> 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: Let's Focus on Moving Forward Re: V6 still not supported




> On Mar 29, 2022, at 17:51 , Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
>>> As I repeatedly pointed out, end to end NAT is clean preserving
>>> the universal peer to peer nature of the Internet.
>> Nope… It really isn’t.
> 
> Wrong.
> 
>> The problem of audit trail opacity is still a major issue with any form
>> of stateful NAT.
> 
> How poorly you understand NAT.
> 
> As I wrote in my draft:
> 
>   Depending on how port numbers are shared, there are static and
>   dynamic E2ENAT or combinations of them. With static E2ENAT, an end
>   host is assigned port numbers statically, which is necessary for a
>   server with a stable IP address and a port number.
> 
> static E2ENAT is not, with your questionable terminology, stateful.
> 
> It is even possible to construct legacy NAT which dynamically,
> thus statefully, assign ports only from some static range,
> which does not need state maintenance, for each private IP
> address.
> 
>   Masataka Ohta

It still suffers from a certain amount of opacity across administrative domains.

Owen

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

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

2022-03-31 Thread Masataka Ohta


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)


IP mobility WG of IETF was formed in 1992.


- Hardware forwarding (PFE) would be invented (1997) that would have
a big additional cost to implement Enhanced Headers


Optional IPv4 headers was considered harmful, IIRC before 1992,
which has nothing to do with TCAM.


- Encryption would never have a small enough cost to make it
mandatory


Cost of encryption is small enough. The problem is to securely
share keys, for example, between a source and a router to let
the router generate secure ICMP.


- Router would be available in every smallest thing that makes
distributed address acquisition redundant (hi SLAAC)


Local router is always available for a network with two
or more links, which was why SLAAC were a good idea.


We should be fair


You should.

Masataka Ohta

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

2022-03-31 Thread 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

2022-03-31 Thread 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

2022-03-31 Thread 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

2022-03-30 Thread 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

2022-03-30 Thread 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

2022-03-30 Thread John Kristoff

On Wed, 30 Mar 2022 04:47:08 -0700
John Gilmore  wrote:

>   https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/

The draft touches on IANA considerations, but this seems inadequate to
make any more progress and gain wider acceptance.

It seems to me there has been compelling arguments made about the
ability to rx, tx, and relay packets with these addresses, but the real
challenge remains, how should they be allocated? The document should
probably request that they be changed from reserved to experimental
explicitly.  Suggesting the IETF/IANA just figure out what to do with
them later seems unsatisfying.

Perhaps the equivalent of an IAB-style workshop report or position paper
that goes into potential allocation choices and effects in detail is
worthwhile?

I'd imagine you'd get lots of interesting presentations on a possible
allocation strategies and challenges if you decide to organize
something like this. I'd like to see some options for the IANA/IETF.
Let's see someone dissect what if anything RIRs should get and what the
effect of different policies for the new blocks might be.  Let's hear
about some interesting new special-use ideas.  I'd love to see someone
suggest a spectrum-like auction to the highest bidder and get doused
with rotten fruit... etc :-)

John

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

2022-03-30 Thread 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

2022-03-30 Thread 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: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-30 Thread John Gilmore

Tom Beecher  wrote:
> I'd be curious to see the data you guys have collected on what it has been
> confirmed to work on if that's available somewhere.

The Implementation Status of unicast 240/4 is in the Appendix of our draft:

  https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/

Enjoy -- it's a long list.

In addition to what's in the published draft, some research that I did
last night also determined that 240/4 as unicast was released in Fedora
9 in May 2008, and in Ubuntu 8.10 in October 2008.

John

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-29 Thread Masataka Ohta


Owen DeLong wrote:


As I repeatedly pointed out, end to end NAT is clean preserving
the universal peer to peer nature of the Internet.


Nope… It really isn’t.


Wrong.


The problem of audit trail opacity is still a major issue with any form
of stateful NAT.


How poorly you understand NAT.

As I wrote in my draft:

   Depending on how port numbers are shared, there are static and
   dynamic E2ENAT or combinations of them. With static E2ENAT, an end
   host is assigned port numbers statically, which is necessary for a
   server with a stable IP address and a port number.

static E2ENAT is not, with your questionable terminology, stateful.

It is even possible to construct legacy NAT which dynamically,
thus statefully, assign ports only from some static range,
which does not need state maintenance, for each private IP
address.

Masataka Ohta

Re: Let's Focus on Moving Forward Re: V6 still not supported




> On Mar 26, 2022, at 17:30 , Masataka Ohta  
> wrote:
> 
> Owen DeLong via NANOG wrote:
> 
>> It still looks like NAT to me.
> 
> Almost all the people, perhaps other than you, accept NAT
> as is to keep IPv4 Internet or as part of transition
> plan from IPv4 to IPv6.
> 
>> NAT is a disgusting hack and destroys the universal peer to peer
>> nature of the internet in favor of a consumer/provider model.
> 
> As I repeatedly pointed out, end to end NAT is clean preserving
> the universal peer to peer nature of the Internet.

Nope… It really isn’t.

The problem of audit trail opacity is still a major issue with any form
of stateful NAT.

Owen

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

2022-03-29 Thread 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

2022-03-29 Thread 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

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: 20220326125.AYC

Just because there is a small code snippet you found that prevents casting 
240/4 as unicast on an interface doesn’t mean that removing that code will 
magically make 240/4 usable in the entire stack.

It’s also important to note that there are at least a dozen IPv4 stacks in 
common use with differing code implementations and underlying assumptions baked 
into the code in various places. Your Q.E.D. is, in fact, a demonstration of 
the fact that you are still lack some background and experience in networking 
software.

The code you found may just be a safety valve to prevent the user from doing 
something stupid that will have undefined consequences down the line if 
executed. What you appear to have found is, quite likely, the equivalent of a 
buffer bounds check on input. Removing the check doesn’t inherently make the 
buffer infinite.

Owen

> On Mar 26, 2022, at 09:38 , Abraham Y. Chen  wrote:
> 
> Hi, Paul:
> 
> 1)" ...  may be in fact: /writing/* and */deploying/* the code  ... ":
> Having no idea why and how the 240/4 netblock became so mysteriously kept 
> away from being used while the IPv4 was officially already on its way to "Sun 
> Set", we started the conventional approach as you stated. It was quite 
> frustrating since we did not have the background in networking software. One 
> day, we came across a short program code fragment that did the function of 
> disabling 240/4 addressed IP packets. It is the "there exists an example" 
> moment for us, like proofing a mathematics theorem. After all, there was no 
> magic separating 240/4 from the rest of the IPv4 address pool to start with. 
> It cleared our mind about this particular task. Now, we only cite 
> this reference to challenge those software engineers who may state that using 
> the 240/4 in their code is a lot more involved.    Q.E.D.  
> 
> Regards,
> 
> 
> Abe (2022-03-26 12:37 EDT)
> 
> 
> 
> 
> On 2022-03-26 09:52, Paul Rolland wrote:
>> Hello,
>> 
>> On Sat, 26 Mar 2022 09:35:30 -0400
>> "Abraham Y. Chen"   wrote:
>> 
>>> touching the hardware, by implementing the EzIP technique (*/disabling/* 
>>> the program code that has been */disabling/* the use of the 240/4 
>>> netblock), an existing CG-NAT module becomes a RAN! As to universal 
>> Have you ever considered that this may be in fact:
>> 
>> */writing/* and */deploying/* the code that will allow the use of 240/4 the
>> way you expect 
>> 
>> 
>> Paul
> 
> 
>  
> 
>   Virus-free. www.avast.com 
> 
>

Re: Let's Focus on Moving Forward Re: V6 still not supported



> On Mar 26, 2022, at 09:37 , Tom Beecher  wrote:
> 
> Have you ever considered that this may be in fact:
> 
> */writing/* and */deploying/* the code that will allow the use of 240/4 the
> way you expect
> 
> While Mr. Chen may have considered that, he has repeatedly hand waved that 
> it's 'not that big a deal.', so I don't think he adequately grasps the scale 
> of that challenge.

It’s certainly clear that he does not understand that in terms of cost-benefit 
ratio, the benefit of deploying his idea divided by the cost is a significantly 
lower number (in my estimation) than the much larger benefit of deploying IPv6 
divided by the rather limited remaining costs involved in doing so.

Owen

>  
> 
> On Sat, Mar 26, 2022 at 9:53 AM Paul Rolland  > wrote:
> Hello,
> 
> On Sat, 26 Mar 2022 09:35:30 -0400
> "Abraham Y. Chen" mailto:ayc...@avinta.com>> wrote:
> 
> > touching the hardware, by implementing the EzIP technique (*/disabling/* 
> > the program code that has been */disabling/* the use of the 240/4 
> > netblock), an existing CG-NAT module becomes a RAN! As to universal 
> 
> Have you ever considered that this may be in fact:
> 
> */writing/* and */deploying/* the code that will allow the use of 240/4 the
> way you expect 
> 
> 
> Paul

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-29 Thread Tom Beecher

>
> A traceroute from my machine to 240.1.2.3 goes through six routers at my
> ISP before stopping (probably at the first default-route-free router).
>

My experience is the opposite. My home edge router (dd-wrt) will pass it,
but nothing in my ISP's network will. $DayJob networks aren't worth
checking, as I know I have 224/3 bogonized.

I'd be curious to see the data you guys have collected on what it has been
confirmed to work on if that's available somewhere. ( More for curiosity's
sake ; I still think that making 224/3 universally available isn't worth
the effort it would take to make it happen. )

On Sat, Mar 26, 2022 at 9:42 PM John Gilmore  wrote:

> Tom Beecher  wrote:
> > > */writing/* and */deploying/* the code that will allow the use of
> 240/4 the
> > > way you expect
> >
> > While Mr. Chen may have considered that, he has repeatedly hand waved
> that
> > it's 'not that big a deal.', so I don't think he adequately grasps the
> > scale of that challenge.
>
> From multiple years of patching and testing, the IPv4 Unicast Extensions
> Project knows that 240/4 ALREADY WORKS in a large fraction of the
> Internet.  Including all the Linux servers and desktops, all the Android
> phones and tablets, all the MacOS machines, all the iOS phones, many of
> the home wifi gateways.  All the Ethernet switches.  And some less
> popular stuff like routers from Cisco, Juniper, and OpenWRT.  Most of
> these started working A DECADE AGO.  If others grasp the scale of the
> challenge better than we do, I'm happy to learn from them.
>
> A traceroute from my machine to 240.1.2.3 goes through six routers at my
> ISP before stopping (probably at the first default-route-free router).
>
> Today Google is documenting to its cloud customers that they should use
> 240/4 for internal networks.  (Read draft-schoen-intarea-unicast-240 for
> the citation.)  We have received inquiries from two other huge Internet
> companies, which are investigating or already using 240/4 as private
> IPv4 address space.
>
> In short, we are actually making it work, and writing a spec for what
> already works.  Our detractors are arguing: not that it doesn't work,
> but that we should instead seek to accomplish somebody else's goals.
>
> John
>
> PS: Mr. Abraham Chen's effort is not related to ours.  Our drafts are
> agnostic about what 240/4 should be used for after we enable it as
> ordinary unicast.  His EzIP overlay network effort is one that I don't
> fully understand.  What I do understand is that since his effort uses
> 240/4 addresses as the outer addresses in IPv4 packets, it couldn't work
> without reaching our goal first: allowing any site on the Internet to
> send unicast packets to or from 240.0.0.1 and having them arrive.
>
>

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-28 Thread Owen DeLong via NANOG



> On Mar 26, 2022, at 06:35 , Abraham Y. Chen  wrote:
> 
> Hi, Owen:
> 
> 0)Re: Ur. Pt. 2):This topic is such a tongue-twister. Let's put it 
> aside for now, until I can properly convey the EzIP concept and scheme to you.
> 
> 00)Re: Ur. Pt. 4):Okay, I was concerned about how to decipher this 
> cryptic exchange. So let's put it aside as well.
> 
> 1)Re: Ur. Pt. 1):Yes, you are correct that the EzIP network 
> architecture looks like that of CG-NAT. In fact, it is exactly the same. This 
> is actually the beauty of the EzIP solution. That is, without touching the 
> hardware, by implementing the EzIP technique (disabling the program code that 
> has been disabling the use of the 240/4 netblock), an existing CG-NAT module 
> becomes a RAN! As to universal peer-to-peer, where is any of such today? On 
> the other hand, upon fully implemented the EzIP proposal (the second phase: 
> making use of the Option Word in RFC791), an IoT in one RAN can directly 
> reach a second IoT in another RAN world-wide. So that the original promise of 
> the Internet will be finally fulfilled and for the long haul.

The fact that we gave up universal peer to peer in the name of survival until 
we could deploy a protocol with enough addresses doesn’t mean that giving it up 
is a good long term solution.

To me, the goal is to get away from address scarcity as quickly as possible. 
IPv6 does that. EzIP doesn’t. I have no desire to support prolonging the misery 
that has existed since NAT became popular. I view it as a disability to the 
internet and IPv6 eliminates that disability. EzIP arguably makes it even 
worse. So, what you call beauty is, IMHO, damage.

> 2)Re: Ur. Pt. 3):Similarly, you probably only recognized the part 
> that EzIP proposes to classify the 240/4 netblock as the fourth private 
> address in RFC1918, but overlooked that such capacity will enable a RAN to 
> cover a geographic area as big as Tokyo Metro, or 75% of smaller countries 
> around the world, even before utilizing the conventional three private 
> netblocks. This puts 240/4 into a different league from the other three 
> conventional private netblocks, although all four have basically the same 
> technical characteristics. Now, visualizing each RAN is tethered from the 
> existing Internet core by one umbilical cord (one IPv4 address), it appears 
> like a private network. So that each RAN can provide Internet services by 
> utilizing existing technologies, while avoiding those undesired. Combining 
> these RANs around the world, an overlay layer of routers (SPRs) can operate 
> in parallel to the current Internet. Under such a configuration, the latter 
> no long is involved with daily local activities, but only carries inter-RAN 
> traffic, very much like the division between national and international 
> telephone networks. This creates quite a different operation landscape. 
> Please have a look at slide # 11 of the below whitepaper for a rough 
> breakdown of the available addresses under the EzIP scheme. Furthermore, if 
> used diligently, (treating IP address as "natural resources" instead of 
> "personal properties"), the assignable "EzIP addresses" can last quite awhile.

I didn’t overlook it, I routed around it as damage in the truest of internet 
traditions. Geographical-based addressing hierarchies have been proposed 
before. They have a long history of failing in the face of actual topology and 
actual operational concerns. This doesn’t look significantly different to me. 
It’s yet another entirely bad idea which serves only to prolong the IPv4 misery 
while diverting resources from useful work to enable the deprecation of IPv4 as 
the lingua franca of the internet backbone.

> 
> https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf 
>   
> 
> 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.

I’m not stopping anyone from anything. I’m stating that I believe resources 
would be better spent deploying IPv6 than being wasted on this project. Anyone 
who disagrees with me is, of course, free to waste their resources however they 
see fit.

In

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-28 Thread Masataka Ohta


Joshua Mallad wrote:


I am growing extremely frustrated by the lack of available internet address
space.


Then, let's have NAT with 32bit port numbers.


How many times are you going to extend and hack away at IPv4,


Perhaps, only once, which means NAT.

Anyway, it is a lot less than hacks to try to have IPv6 with IPv4.

Masataka Ohta

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-28 Thread Joshua Mallad

I usually keep quiet on this list, but this topic is relevant to me as a
smaller (non-BGP level) network operator who would really love to see more
IPv6 deployment.
I don't have experience deploying internet technologies at the highest
level, so I can't say I fully understand the difficulties surrounding it.
What I can say, however, is that
I am growing extremely frustrated by the lack of available internet address
space.

>From my perspective, IPv6 is the obvious way forward, and honestly, I see a
whole lot of whining any time it is brought up. You guys seem to be so
averse to actually doing your jobs sometimes. Yes, problems may arise when
introducing a new technology. You may have to actually fix some things that
break. The benefit is that we finally get enough address space for everyone
to do what they want with.

How many times are you going to extend and hack away at IPv4, claiming its
easier than just setting up IPv6? It is so silly. Watching this circus is
getting boring. Upgrade your infrastructure. Many devices that can't be
patched to support this "ezip" nonsense don't support IPv6 either, so I see
the "legacy devices" argument as moot either way.

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-28 Thread Masataka Ohta


james.cut...@consultant.com wrote:


Overlap here refers to network address space address space, a
fundamental part of this discussion.  Formerly separate networks
containing separately managed rfc1918 spaces are prone to overlap
require ingenious solutions for end-to-end traffic without
renumbering.


If you are not satisfied with static punch holing and require
to use many connections with fully dynamically generated
port numbers by end systems, then, as I wrote:

: The basic idea is to let NAT boxes perform address translations
: only without adjusting check sums or translating ports and
: to let end systems perform reverse address translations,
: which restores correct check sums, and port number
 ^^^
: restrictions.
  ^

end to end NAT is your solution, because a locally provided
port number combined with a globally unique address is
a globally unique identifier at the transport layer.


Mergers do not cause relocation of an office, which is not germane to
this discussion.


As mergers often cause office mergers, which imply relocations, it
is your fault to have failed to clarity details.


Or, if you mean network merger remotely with VPN, small number of
hosts requiring E2E transparency may be renumbered, but it is not
so painful.


Nobody mentioned VPN or limiting the number of hosts requiring E2E.


It is also your fault not to have considered VPN at all, even
though VPN could reduce renumbering efforts a lot.

> "not so painful" is not  meaningful metric in this discussion.

Then, IPv6 is just painful. PERIOD.

Masataka Ohta

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-28 Thread John Gilmore

Christopher Morrow  wrote:
> I think the advice in the draft, and on the quoted page of Google cloud
> docs is that you can use whatever address space you want for your voc
> network. I think it also says that choosing poorly could make portions if
> the internet unreachable.
> 
> I don't see that the docs specify usage of 240/4 though.

Thank you for catching this!  Draft-schoen-intarea-unicast-240 links its
reference [VPC] to:

  https://cloud.google.com/vpc/docs/vpc#valid-ranges

As late as March 18, 2022, that page included a table of "Valid ranges"
that include "240.0.0.0/4", which you can see in the Internet Archive's
"Wayback Machine" copy of the page:

http://web.archive.org/web/20220318080636/https://cloud.google.com/vpc/docs/vpc

  A subnet's primary and secondary IP address ranges are regional
  internal IP addresses. The following table describes valid ranges.  ...

  240.0.0.0/4   Reserved for future use (Class E) as noted in
RFC 5735 and RFC 1112.

Some operating systems do not support the
use of this range, so verify that your OS
supports it before creating subnets that use
this range.

However, as of March 20, Google moved that table into a subsidiary page,
the "Subnets overview", which is now linked from the original page:

http://web.archive.org/web/20220320031522/https://cloud.google.com/vpc/docs/vpc

http://web.archive.org/web/20220328102630/https://cloud.google.com/vpc/docs/subnets

The same information about 240/4 is there.

Thanks again for the bug report!  We'll update the URL in the next
version of the draft.

John

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-27 Thread Abraham Y. Chen


Hi, Brandon:

1)    "So each RAN has no possibility of redundant connections?  ..  
":    There is difference between "via one IPv4 public address" and 
"wide bandwidth or multiple channels". The former is called "numbering 
plan". The latter is part of "traffic engineering". The former defines 
the configuration / architecture of the latter, but not restricts its 
capability. One simple analogy is that a corporation headquarters 
publishes only one (representative) telephone number. But, everyone 
knows that there are multiple physical channels to carry the 
simultaneous conversations. So, we discuss about network architecture 
here. Then, the implementation engineering will take care of the details.


2)    " It also looks like an opportunity for telcos/governments to 
partition their part of the internet and impose whatever censorship they 
wish. ...  ":    The EzIP scheme provides an alternative to the current 
"Internet way" operation model and can operate in parallel while 
none-interfering to each other. There is no intention for EzIP to 
replace the current Internet. The hope is to let the two models operate 
in real time for the consumer to make the informed choice, as in a free 
market.


3)    " You previously described this as like connecting CG-NATs 
together via a VPN. ...   ":    I do not believe that I have ever 
mentioned VPN in any of our literature, nor correspondence. I would 
appreciate learning where did you find such a connection.


4)    " As it's a CG-NAT variant why are you delaying yourself by 
requiring new address space that will take a long time to become 
available?    ": As it has become evident recently through various 
posting, the 240/4 netblock has been used "behind-the-scene" by many 
projects without the explicit permission by ICANN. Since packets with 
240/4 addressing get dropped by existing routers, it actually makes the 
deployment of the new project easier. EzIP can be deployed in the same 
fashion as well. However, with the Unicast Extension Project became 
known, we would like to go along with their efforts to make the EzIP 
process more "Kosher".


5)    "... Why not use the already allocated space for CG-NAT? Sure it's 
only a /10 but that's an already (probably too) large RAN    ":    
The CG-NAT netblock of /10 is only one fourth of the largest private 
netblock 10/8. So, it is not big enough for the next level of challenge. 
Making use of the 240/4 netblock allows EzIP to serve a large enough 
geographical area, so that a true "Regional" Area Network characteristic 
may be achieved. A RAN can serve a population of upto 39M, even before 
employing the three conventional private netblocks. So, it is possible 
to experiment the wish of the "Country" networks idea proposed by ITU 
about one decade ago. Whether it is better or worse than the current 
Internet, EzIP provides a separate test bed for such, instead of verbal 
debates forever.


6)    " It also seems unfeasibly optimistic that if the work was done 
globally to make 240/4 useable that they'd want to dedicate it to the as 
yet undeployed EzIP. ...  ":    As have been hinted a couple times 
already on this forum, the ideal EzIP initial deployment beds are the 
existing CG-NAT modules. All we need to do is to enable the routers in a 
CG-NAT module to route 240/4 netblock and retire the 100.64/10 netblock. 
Since every customer premises can have a static 240/4 address, the DHCP 
process in the CG-NAT can fade out. The current communication between 
this CG-NAT with the Internet core remains unchanged. This process can 
be done gradually, one CG-NAT module at a time. No one outside of each 
of such tranistin will even notice something has happened. There is no 
need to do this globally in one shot, at all.


7)    "Is 240/4 special to EzIP such that alternative numbers may not be 
used?   " No, nothing is special here. The only reason that 240/4 is 
attractive is because it is big, continuous as well as being "Reserved 
for Future use" for so long. It is like a never-never land, fresh enough 
to do something really grand and for the long term.


8)    " That sounds an entirely undesirable goal for the internet.    
":    As I state above, EzIP offers a configuration for experimenting a 
(or more) parallel Internet(s). they will not interfere the current 
Internet, nor one another. So, what is your concern or reservation?


Regards,


Abe (2022-03-27 16:35)




On 2022-03-27 10:49, Brandon Butterworth wrote:

On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

EzIP proposes to deploy 240/4
address based RANs, each tethering off the current Internet via one IPv4
public address.

So each RAN has no possibility of redundant connections? Nobody
of scale would accept such a limitation. It also looks like an
opportunity for telcos/governments to partition their part
of the internet and impose whatever censorship they wish.


As such, the collection of RANs forms an overlay network
layer

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

2022-03-27 Thread Fred Baker

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

> On Mar 27, 2022, at 12:18 PM, Abraham Y. Chen  wrote:
> 
> I am baffled by why does it cause problems on this mailing list.

Are you aware that NANOG is not an IETF list? What would you guess might be the 
topic of a list associated with a Network Operator Group?

Permit me to comment on what I have seen in this discussion, and what I haven’t 
seen. I would guess that your objective is primarily to build a constituency 
for a replacement paradigm for the Internet - instead of connectivity between 
endpoints, you want it to be connectivity between PABX-like islands. What I 
have observed is a steady patter of email indicating that everyone except you 
is wrong. What I have not observed is an emerging consensus in the direction 
your posted draft suggests.

Food fir thought.

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

2022-03-27 Thread Fred Baker

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

> On Mar 27, 2022, at 12:18 PM, Abraham Y. Chen  wrote:
> 
> Honestly, I am still trying to figure out what is the "required" etiquette, 
> since what I have received were mostly "complaints" not constructive 
> "instructions" (i.e., how about a cheat sheet of what to do and what not to?).

I suspect there are two important rules.

1) every mailing list has a topic.  Post on that topic.

2) a mailing list discussion is a conversation. We all get involved in 
conversations every day. Act as you would in polite conversation.

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

2022-03-27 Thread Abraham Y. Chen


Hi, Randy:

1)    " ...  does not mean it is trivial to get it done on *billions* of 
device.  ... ":    It looks that your mind is focused on upgrading 
existing IoTs. They are not to be perturbed according to the initial and 
short term EzIP deployment plans, because it basically is following the 
existing CG-NAT network configuration and master / client service model. 
Many RGs (Residential / Routing Gateways) are already capable of being a 
240/4 DHCP client. (If not, commenting out one single line is likely all 
what is needed.). For the long term, it will be only those*/new/* IoTs 
desiring for end-to-end communication across RAN borders to have the 
ability of handling Option Words in the IP header.


2)    " ... Your refusal to follow simple mailing list etiquette ...  
":    Sorry for the inconvenience that I have caused. Honestly, I am 
still trying to figure out what is the "required" etiquette, since what 
I have received were mostly "complaints" not constructive "instructions" 
(i.e., how about a cheat sheet of what to do and what not to?). So, I 
have been adjusting my writing style. (My best guess of the issue is 
mostly likely due to the Subject line which according to my business 
correspondence training is my own choice. I am baffled by why does it 
cause problems on this mailing list.)


Regards,


Abe (2022-03-27 15:16)



On 2022-03-26 18:53, Randy Carpenter wrote:

- On Mar 26, 2022, at 6:16 PM, Abraham Y. chenayc...@avinta.com  wrote:


Hi, Tom & Paul:
1) " ... hand waved ... ": Through my line of work, I was trained to behave
exactly the opposite. I am surprised at you jumping to the conclusion, even
before challenging me about where did I get my viewpoint from. The fact is, it
has been clearly documented in our IETF draft for the last couple years (since
Rev-06 on 2019 Dec. 1)! For your convenience, please see below a copy of the
potential target code fragment and critique. It appears to me that our software
member suggested to comment out only one line (1047).

Just because it is trivial to make the modification in a single, specific 
firmware for one particular device sdoes not mean it is trivial to get it done 
on *billions* of device. Even if each one was as trivial as your example, it 
would still be ludicrously difficult.

Beyond that, I am still not understanding what you are actually trying to 
propose here. Your refusal to follow simple mailing list etiquette even after 
numerous requests makes it very difficult to decipher what you are saying.

-Randy




--
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

2022-03-27 Thread Christopher Morrow

On Sat, Mar 26, 2022, 21:42 John Gilmore  wrote:

>
> Today Google is documenting to its cloud customers that they should use
> 240/4 for internal networks.  (Read draft-schoen-intarea-unicast-240 for
> the citation.)  We have received inquiries from two other huge Internet
> companies, which are investigating or already using 240/4 as private
> IPv4 address space.
>

I think the advice in the draft, and on the quoted page of Google cloud
docs is that you can use whatever address space you want for your voc
network. I think it also says that choosing poorly could make portions if
the internet unreachable.

I don't see that the docs specify usage of 240/4 though.

>

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-27 Thread John Levine

According to james.cut...@consultant.com :
>> which, in general, requires provider change and renumbering
>> of globally unique addresses, unless you own /24.
>
>Moot since we are not discussing office moves. However, renumbering to global 
>IPv6 addressing allows easy coexistence with the global Internet

Alternatively, if you have network addresses that you want to be sure
don't leak to the global Internet, ULAs work well, too. If you pay
attention to RFC 4193 and select your Global ID randomly, when you
merge two networks there is no meaningful chance that the ULAs will
overlap.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-27 Thread james.cut...@consultant.com

> On Mar 27, 2022, at 5:00 AM, Masataka Ohta  
> wrote:
> 
> james.cut...@consultant.com wrote:
> 
> > I have yet to find an economical way to manage a business merger
> > involving two large rfc1918 networks where end to end peering is
> > required and which partially or fully overlap.
> 
> As you mention "overlap", you should mean business merger implies
> network and office merger, which causes relocation of a office,

Overlap here refers to network address space address space, a fundamental part 
of this discussion.  Formerly separate networks containing separately managed 
rfc1918 spaces are prone to overlap require ingenious solutions for end-to-end 
traffic without renumbering.

Mergers do not cause relocation of an office, which is not germane to this 
discussion. 

> which, in general, requires provider change and renumbering
> of globally unique addresses, unless you own /24.

Moot since we are not discussing office moves. However, renumbering to global 
IPv6 addressing allows easy coexistence with the global Internet
> 
> > Ignoring short-sighted
> > financial management views, the best long term solution is globally
> > unique IPv6 addressing wherever possible.
> 
> See above.

See previous.

> 
> Or, if you mean network merger remotely with VPN, small
> number of hosts requiring E2E transparency may be renumbered,
> but it is not so painful.

Nobody mentioned VPN or limiting the number of hosts requiring E2E. “not so 
painful” is not  meaningful metric in this discussion.

> 
>   Masataka Ohta

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

2022-03-27 Thread 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

2022-03-27 Thread 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

2022-03-27 Thread Christian de Larrinaga via NANOG




On 27 March 2022 15:53:25 Brandon Butterworth  wrote:


On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

EzIP proposes to deploy 240/4
address based RANs, each tethering off the current Internet via one IPv4
public address.


So each RAN has no possibility of redundant connections? Nobody
of scale would accept such a limitation. It also looks like an
opportunity for telcos/governments to partition their part
of the internet and impose whatever censorship they wish.


As such, the collection of RANs forms an overlay network
layer wrapping around the current Internet core. Consequently, only the
SPRs in the RAN need to be able to transport 240/4 addressed packets.


You previously described this as like connecting CG-NATs together via a
VPN. I don't see why we'd want to add maintaining a global VPN to
already difficult peering relationships. It could be used to exlude non
EzIP club members.


This is why we talk about enabling new (but based on existing design)
routers to use 240/4 netblock for serving as SPRs, but not perturbing
any routers in the current Internet.


As it's a CG-NAT variant why are you delaying yourself by requiring
new address space that will take a long time to become available? Why
not use the already allocated space for CG-NAT? Sure it's only a /10
but that's an already (probably too) large RAN.

It also seems unfeasibly optimistic that if the work was done globally
to make 240/4 useable that they'd want to dedicate it to the as yet
undeployed EzIP. You might stand more chance if you gained some
critical mass using the existing available 100.64/10 & rfc1918 space,
and then those that find they need more in one RAN will make the case
for 240/4 when it becomes necessary for them. Is 240/4 special to
EzIP such that alternative numbers may not be used?


I would like to share one intriguing graphics (see URL below) that
is almost perfect for depicting the EzIP deployment configuration.
Consider the blue sphere as the earth or the current Internet core and
the golden colored land as the RANs. By connecting each continent,
country or all the way down to a Region to the earth via one IPv4
address, we have the EzIP configuration. With this architecture, each
RAN looks like a private network.


That sounds an entirely undesirable goal for the internet.

brandon


It isn't the Internet. It's at best a very poorly connected spur gateway.

Too many today don't remember the towers of Babel world prior to the 
Internet. If they did they'd understand that building on this type of idea 
is like burying yourself And any customers so unwise to get involved


C

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-27 Thread Brandon Butterworth

On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:
> EzIP proposes to deploy 240/4 
> address based RANs, each tethering off the current Internet via one IPv4 
> public address.

So each RAN has no possibility of redundant connections? Nobody
of scale would accept such a limitation. It also looks like an
opportunity for telcos/governments to partition their part
of the internet and impose whatever censorship they wish.

> As such, the collection of RANs forms an overlay network 
> layer wrapping around the current Internet core. Consequently, only the 
> SPRs in the RAN need to be able to transport 240/4 addressed packets.

You previously described this as like connecting CG-NATs together via a
VPN. I don't see why we'd want to add maintaining a global VPN to
already difficult peering relationships. It could be used to exlude non
EzIP club members.

> This is why we talk about enabling new (but based on existing design) 
> routers to use 240/4 netblock for serving as SPRs, but not perturbing 
> any routers in the current Internet.

As it's a CG-NAT variant why are you delaying yourself by requiring
new address space that will take a long time to become available? Why
not use the already allocated space for CG-NAT? Sure it's only a /10
but that's an already (probably too) large RAN.

It also seems unfeasibly optimistic that if the work was done globally
to make 240/4 useable that they'd want to dedicate it to the as yet
undeployed EzIP. You might stand more chance if you gained some
critical mass using the existing available 100.64/10 & rfc1918 space,
and then those that find they need more in one RAN will make the case
for 240/4 when it becomes necessary for them. Is 240/4 special to
EzIP such that alternative numbers may not be used?

> I would like to share one intriguing graphics (see URL below) that 
> is almost perfect for depicting the EzIP deployment configuration. 
> Consider the blue sphere as the earth or the current Internet core and 
> the golden colored land as the RANs. By connecting each continent, 
> country or all the way down to a Region to the earth via one IPv4 
> address, we have the EzIP configuration. With this architecture, each 
> RAN looks like a private network.

That sounds an entirely undesirable goal for the internet.

brandon

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-27 Thread Masataka Ohta

james.cut...@consultant.com wrote:

> I have yet to find an economical way to manage a business merger
> involving two large rfc1918 networks where end to end peering is
> required and which partially or fully overlap.

As you mention "overlap", you should mean business merger implies
network and office merger, which causes relocation of a office,
which, in general, requires provider change and renumbering
of globally unique addresses, unless you own /24.

> Ignoring short-sighted
> financial management views, the best long term solution is globally
> unique IPv6 addressing wherever possible.

See above.

Or, if you mean network merger remotely with VPN, small
number of hosts requiring E2E transparency may be renumbered,
but it is not so painful.

Masataka Ohta

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-26 Thread Joe Maimon





james.cut...@consultant.com wrote:

On Mar 26, 2022, at 8:30 PM, Masataka Ohta  
wrote:

Owen DeLong via NANOG wrote:


It still looks like NAT to me.

Almost all the people, perhaps other than you, accept NAT
as is to keep IPv4 Internet or as part of transition
plan from IPv4 to IPv6.


NAT is a disgusting hack and destroys the universal peer to peer
nature of the internet in favor of a consumer/provider model.

As I repeatedly pointed out, end to end NAT is clean preserving
the universal peer to peer nature of the Internet.

https://datatracker.ietf.org/doc/html/draft-ohta-e2e-nat-00

The basic idea is to let NAT boxes perform address translations
only without adjusting check sums or translating ports and
to let end systems perform reverse address translations,
which restores correct check sums, and port number
restrictions.

Masataka Ohta

I have yet to find an economical way to manage a business merger involving two 
large rfc1918 networks where end to end peering is required and which partially 
or fully overlap. Ignoring short-sighted financial management views, the best 
long term solution is globally unique IPv6 addressing wherever possible. Local 
islands of IPv4 gatewayed or NATted with local management continue to be 
possible.


In other words, once its merger time, IPv6 fixes nothing.

Can one really incentivize an enterprise to standardize on IPv6 on the 
basis of it will make a future merger much more economical? And this is 
well before any such prospect usually exists.


Is there any activity that enterprises choose to engage in on that basis?

Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-26 Thread Joe Maimon





John Gilmore wrote:

Tom Beecher  wrote:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved that
it's 'not that big a deal.', so I don't think he adequately grasps the
scale of that challenge.

>From multiple years of patching and testing, the IPv4 Unicast Extensions
Project knows that 240/4 ALREADY WORKS in a large fraction of the
Internet.


And this is without the removal of reserved status.

There is no real reason to think it would not have been practically 
universal if that had happened a decade ago.




Today Google is documenting to its cloud customers that they should use
240/4 for internal networks.  (Read draft-schoen-intarea-unicast-240 for
the citation.)  We have received inquiries from two other huge Internet
companies, which are investigating or already using 240/4 as private
IPv4 address space.


240/4 becoming a de-facto super rc1918 in its totality is actually a net-loss. Has 240/4 
been unreserved for potential global internet purposes a decade ago, much more 
constructive purposes could have been standardized as well. So all the delay is not a 
"no harm no foul" situation.


In short, we are actually making it work, and writing a spec for what
already works.  Our detractors are arguing: not that it doesn't work,
but that we should instead seek to accomplish somebody else's goals.

John


At this point, its more like you have publicly accepted all the blame 
for the current incomplete state of IPv6 by acknowledging that you chose 
to take on the daunting task of 240/4 and refused to direct yours and 
everyone you knew efforts into IPv6, which was missing only that.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

Dear John:

0) Appreciate very much for your comments.

1) "A traceroute from my machine to 240.1.2.3 goes through six
routers at my ISP before stopping (probably at the first
default-route-free router). ": Great, this confirms our experience.
While our team's skill is far inferior than yours, we did use Xubuntu
based PCs to send TraceRoute packets with 240/4 addresses into the
Internet and got records indicating that they had traveled through at
least a couple routers into Verizon's network a few years ago. Those
observations kept us going, even though all we heard from the Internet
community was "240/4 could not and should not be used".

2) " What I do understand is that since his effort uses 240/4
addresses as the outer addresses in IPv4 packets, it couldn't work
without reaching our goal first: ": Exactly, We are in sync. I am
glad that your team is doing the ground work of enabling 240/4 for
unicast. EzIP is a specific application of such a capability as a
private netblock. Yet, due to its size, it is possible to consider a
global deployment configuration.

3) " ... I don't fully understand. ... allowing any site on the
Internet to send unicast packets to or from 240.0.0.1 and having them
arrive. ": Sorry that I have not made our presentation clear enough,
thus misled you to this uncertainty. EzIP proposes to deploy 240/4
address based RANs, each tethering off the current Internet via one IPv4
public address. As such, the collection of RANs forms an overlay network
layer wrapping around the current Internet core. Consequently, only the
SPRs in the RAN need to be able to transport 240/4 addressed packets.
This is why we talk about enabling new (but based on existing design)
routers to use 240/4 netblock for serving as SPRs, but not perturbing
any routers in the current Internet.

4) I would like to share one intriguing graphics (see URL below) that
is almost perfect for depicting the EzIP deployment configuration.
Consider the blue sphere as the earth or the current Internet core and
the golden colored land as the RANs. By connecting each continent,
country or all the way down to a Region to the earth via one IPv4
address, we have the EzIP configuration. With this architecture, each
RAN looks like a private network. Thus, everything proposed by EzIP can
be done in the RANs, independent of the current Internet.

https://dotconnectafrica.org/icann-wins-by-technical-knockout-dca-blocked-from-being-heard-on-its-merit/

I do realize that the EzIP concept is rather unorthodox, making it
difficult to visualize at a glance. Hope this clarifies the overall
picture a bit.

Regards,

Abe (2022-03-27 00:31)

On 2022-03-26 21:42, John Gilmore wrote:

Tom Beecher wrote:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved that
it's 'not that big a deal.', so I don't think he adequately grasps the
scale of that challenge.

>From multiple years of patching and testing, the IPv4 Unicast Extensions
Project knows that 240/4 ALREADY WORKS in a large fraction of the
Internet. Including all the Linux servers and desktops, all the Android
phones and tablets, all the MacOS machines, all the iOS phones, many of
the home wifi gateways. All the Ethernet switches. And some less
popular stuff like routers from Cisco, Juniper, and OpenWRT. Most of
these started working A DECADE AGO. If others grasp the scale of the
challenge better than we do, I'm happy to learn from them.

A traceroute from my machine to 240.1.2.3 goes through six routers at my
ISP before stopping (probably at the first default-route-free router).

Today Google is documenting to its cloud customers that they should use
240/4 for internal networks. (Read draft-schoen-intarea-unicast-240 for
the citation.) We have received inquiries from two other huge Internet
companies, which are investigating or already using 240/4 as private
IPv4 address space.

In short, we are actually making it work, and writing a spec for what
already works. Our detractors are arguing: not that it doesn't work,
but that we should instead seek to accomplish somebody else's goals.

John

PS: Mr. Abraham Chen's effort is not related to ours. Our drafts are
agnostic about what 240/4 should be used for after we enable it as
ordinary unicast. His EzIP overlay network effort is one that I don't
fully understand. What I do understand is that since his effort uses
240/4 addresses as the outer addresses in IPv4 packets, it couldn't work
without reaching our goal first: allowing any site on the Internet to
send unicast packets to or from 240.0.0.1 and having them arrive.

--
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

2022-03-26 Thread Joe Maimon





Paul Rolland wrote:

Hello,

On Sat, 26 Mar 2022 09:35:30 -0400
"Abraham Y. Chen"  wrote:


touching the hardware, by implementing the EzIP technique (*/disabling/*
the program code that has been */disabling/* the use of the 240/4
netblock), an existing CG-NAT module becomes a RAN! As to universal

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect


Paul


While we cant really know, the odds are strong that there are only a few 
lines in any particular product that need to be removed or reworked. Its 
a safe expectation that its a trivial change, as far as changes go.


The bigger hurdle is deployment. All 240/4 discussions have usually 
opined that:


There is every expectation that if 240/4 reserved distinction is removed 
that any particular product still being updated would likely have such a 
change incorporated as part of its normal update process.


And that all non supported products that would not get such a change 
would over time fade away to become a very distinct minority, as they do 
normally.


There is strong evidence that this is an accurate prediction, as even 
without the removal of reserved status, mere public discussion and 
debate over the matter has been sufficient that today a large amount of 
that change has actually occurred, organically so to speak.


If IPv6 would have had such a migration strategy it would have been over 
already.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-26 Thread Jay Hennigan


On 3/26/22 17:38, Joe Greco wrote:


It seems like it should only require changes on a few billion nodes,
given the size of the IPv4 address space, right?

Oh, wait, NAT...


Oh, wait again, several million of those few billion nodes have their 
code burned into ROM soldered to the board.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-26 Thread John Gilmore

Tom Beecher  wrote:
> > */writing/* and */deploying/* the code that will allow the use of 240/4 the
> > way you expect
> 
> While Mr. Chen may have considered that, he has repeatedly hand waved that
> it's 'not that big a deal.', so I don't think he adequately grasps the
> scale of that challenge.

>From multiple years of patching and testing, the IPv4 Unicast Extensions
Project knows that 240/4 ALREADY WORKS in a large fraction of the
Internet.  Including all the Linux servers and desktops, all the Android
phones and tablets, all the MacOS machines, all the iOS phones, many of
the home wifi gateways.  All the Ethernet switches.  And some less
popular stuff like routers from Cisco, Juniper, and OpenWRT.  Most of
these started working A DECADE AGO.  If others grasp the scale of the
challenge better than we do, I'm happy to learn from them.

A traceroute from my machine to 240.1.2.3 goes through six routers at my
ISP before stopping (probably at the first default-route-free router).

Today Google is documenting to its cloud customers that they should use
240/4 for internal networks.  (Read draft-schoen-intarea-unicast-240 for
the citation.)  We have received inquiries from two other huge Internet
companies, which are investigating or already using 240/4 as private
IPv4 address space.

In short, we are actually making it work, and writing a spec for what
already works.  Our detractors are arguing: not that it doesn't work,
but that we should instead seek to accomplish somebody else's goals.

John

PS: Mr. Abraham Chen's effort is not related to ours.  Our drafts are
agnostic about what 240/4 should be used for after we enable it as
ordinary unicast.  His EzIP overlay network effort is one that I don't
fully understand.  What I do understand is that since his effort uses
240/4 addresses as the outer addresses in IPv4 packets, it couldn't work
without reaching our goal first: allowing any site on the Internet to
send unicast packets to or from 240.0.0.1 and having them arrive.

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-26 Thread james.cut...@consultant.com

On Mar 26, 2022, at 8:30 PM, Masataka Ohta  
wrote:
> 
> Owen DeLong via NANOG wrote:
> 
>> It still looks like NAT to me.
> 
> Almost all the people, perhaps other than you, accept NAT
> as is to keep IPv4 Internet or as part of transition
> plan from IPv4 to IPv6.
> 
>> NAT is a disgusting hack and destroys the universal peer to peer
>> nature of the internet in favor of a consumer/provider model.
> 
> As I repeatedly pointed out, end to end NAT is clean preserving
> the universal peer to peer nature of the Internet.
> 
>   https://datatracker.ietf.org/doc/html/draft-ohta-e2e-nat-00
> 
> The basic idea is to let NAT boxes perform address translations
> only without adjusting check sums or translating ports and
> to let end systems perform reverse address translations,
> which restores correct check sums, and port number
> restrictions.
> 
>   Masataka Ohta

I have yet to find an economical way to manage a business merger involving two 
large rfc1918 networks where end to end peering is required and which partially 
or fully overlap. Ignoring short-sighted financial management views, the best 
long term solution is globally unique IPv6 addressing wherever possible. Local 
islands of IPv4 gatewayed or NATted with local management continue to be 
possible.

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-26 Thread Masataka Ohta


Owen DeLong via NANOG wrote:


It still looks like NAT to me.


Almost all the people, perhaps other than you, accept NAT
as is to keep IPv4 Internet or as part of transition
plan from IPv4 to IPv6.


NAT is a disgusting hack and destroys the universal peer to peer
nature of the internet in favor of a consumer/provider model.


As I repeatedly pointed out, end to end NAT is clean preserving
the universal peer to peer nature of the Internet.

https://datatracker.ietf.org/doc/html/draft-ohta-e2e-nat-00

The basic idea is to let NAT boxes perform address translations
only without adjusting check sums or translating ports and
to let end systems perform reverse address translations,
which restores correct check sums, and port number
restrictions.

Masataka Ohta

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-26 Thread Joe Greco

On Sat, Mar 26, 2022 at 12:37:59PM -0400, Tom Beecher wrote:
> >
> > Have you ever considered that this may be in fact:
> >
> > */writing/* and */deploying/* the code that will allow the use of 240/4 the
> > way you expect
> >
> 
> While Mr. Chen may have considered that, he has repeatedly hand waved that
> it's 'not that big a deal.', so I don't think he adequately grasps the
> scale of that challenge.

It seems like it should only require changes on a few billion nodes,
given the size of the IPv4 address space, right?

Oh, wait, NAT...

So I guess the question here is how do you plan to incentivize the
patching of all these devices, many of which are legacy devices with
no maintainer for the firmware/software, in roles where they may not
be accessible, and protected by firewalls that understand Class E to
be unusable space.

I am unclear on the desirability of "fixing" the IPv4 network by
touching lots of nodes, in a manner which will never be comprehensive,
in order to free up a relatively small block of space.  It's going to
be crippled, less-valuable space.  It seems to me like it'd be much
more productive, if you're going to be touching gear, to move towards
IPv6.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

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

2022-03-26 Thread Randy Carpenter

- On Mar 26, 2022, at 6:16 PM, Abraham Y. Chen ayc...@avinta.com wrote:

> Hi, Tom & Paul:

> 1) " ... hand waved ... ": Through my line of work, I was trained to behave
> exactly the opposite. I am surprised at you jumping to the conclusion, even
> before challenging me about where did I get my viewpoint from. The fact is, it
> has been clearly documented in our IETF draft for the last couple years (since
> Rev-06 on 2019 Dec. 1)! For your convenience, please see below a copy of the
> potential target code fragment and critique. It appears to me that our 
> software
> member suggested to comment out only one line (1047).

Just because it is trivial to make the modification in a single, specific 
firmware for one particular device does not mean it is trivial to get it done 
on *billions* of devices. Even if each one was as trivial as your example, it 
would still be ludicrously difficult.

Beyond that, I am still not understanding what you are actually trying to 
propose here. Your refusal to follow simple mailing list etiquette even after 
numerous requests makes it very difficult to decipher what you are saying.

-Randy

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


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

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

Hi, Tom & Paul:

1)    " ... hand waved ...  ":    Through my line of work, I was trained 
to behave exactly the opposite. I am surprised at you jumping to the 
conclusion, even before challenging me about where did I get my 
viewpoint from. The fact is, it has been clearly documented in our IETF 
draft for the last couple years (since Rev-06 on 2019 Dec. 1)! For your 
convenience, please see below a copy of the potential target code 
fragment and critique. It appears to me that our software member 
suggested to comment out only one line (1047).

Regards,

Abe (2022-03-26 18:16)

D.1 
. 
Candidate Code for Modification

   The following short JavaScript function named "ifip" in the TP-Link
   Archer C20 V4 source code has been shown to selectively reject
   specific ranges of IP addresses. In particular, Line 1047 uses a "2's
   Complement" technique to identify the 240/4 netblock as "PRESERVED",
   thus rejecting it. A quick scan of the firmware code in the router
   indicates that this function is a popular utility because there are
   numerous processes calling for it. So, this should be the best
   candidate to start testing our concept.

   lib.js:1040:ifip: function(ip, unalert) {
   lib.js-1041-if ((ip = $.ip2num(ip)) === false) return $.alert(ERR_IP_FORMAT, 
unalert);
   lib.js-1042-if (ip == -1) return $.alert(ERR_IP_BROADCAST, unalert);
   lib.js-1043-var net = ip >> 24;
   lib.js-1044-if (net == 0) return $.alert(ERR_IP_SUBNETA_NET_0, unalert);
   lib.js-1045-if (net == 127) return $.alert(ERR_IP_LOOPBACK, unalert);
   lib.js-1046-if (net >= -32 && net < -16) return $.alert(ERR_IP_MULTICAST, 
unalert);
   lib.js-1047-if (net >= -16 && net < 0) return $.alert(ERR_IP_PRESERVED, 
unalert);
   lib.js-1048-return 0;
   lib.js-1049-},

D.2 
. 
Proposed Modification

   To stop rejecting the 240/4 netblock addressed packets, below is a
   modification that comments out Line 1047, a modification that has
   been shown to eliminate javascript pre-validation of 240/4 IP
   addresses, allowing them to be sent within the router, where a second
   layer of validation rejects them in a different way.

   lib.js:1040:   ifip: function(ip, unalert) {
   lib.js-1041- if ((ip = $.ip2num(ip)) === false) return 
$.alert(ERR_IP_FORMAT, unalert);
   lib.js-1042- if (ip == -1) return $.alert(ERR_IP_BROADCAST, unalert);
   lib.js-1043-   var net = ip >> 24;
   lib.js-1044- if (net == 0) return $.alert(ERR_IP_SUBNETA_NET_0, unalert);
   lib.js-1045- if (net == 127) return $.alert(ERR_IP_LOOPBACK, unalert);
   lib.js-1046- if (net >= -32 && net < -16) return $.alert(ERR_IP_MULTICAST, 
unalert);
   lib.js-1047- //if (net >= -16 && net < 0) return $.alert(ERR_IP_PRESERVED, 
unalert);
   lib.js-1048- return 0;
   lib.js-1049-},

On 2022-03-26 12:37, Tom Beecher wrote:

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of
240/4 the
way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved 
that it's 'not that big a deal.', so I don't think he 
adequately grasps the scale of that challenge.

On Sat, Mar 26, 2022 at 9:53 AM Paul Rolland  wrote:

Hello,

On Sat, 26 Mar 2022 09:35:30 -0400
"Abraham Y. Chen"  wrote:

> touching the hardware, by implementing the EzIP technique
(*/disabling/*
> the program code that has been */disabling/* the use of the 240/4
> netblock), an existing CG-NAT module becomes a RAN! As to universal

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of
240/4 the
way you expect

Paul

--
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: 20220326125.AYC

2022-03-26 Thread Tom Beecher

>
> It was quite frustrating since we did not have the background in
> networking software


You clearly still do not, if you sincerely believe that commenting out a
single function in every vendor software implementation is all that it
would take.

No need to respond ; I will be filtering all future messages from you to
/dev/null . Good luck with your efforts.

On Sat, Mar 26, 2022 at 12:42 PM Abraham Y. Chen  wrote:

> Hi, Paul:
>
> 1)" ...  may be in fact: /writing/* and */deploying/* the code  ...
> ":Having no idea why and how the 240/4 netblock became so mysteriously
> kept away from being used while the IPv4 was officially already on its way
> to "Sun Set", we started the conventional approach as you stated. It was
> quite frustrating since we did not have the background in networking
> software. One day, we came across a short program code fragment that did
> the function of *disabling* 240/4 addressed IP packets. It is the "there
> exists an example" moment for us, like proofing a mathematics theorem.
> After all, there was no magic separating 240/4 from the rest of the IPv4
> address pool to start with. It cleared our mind about this particular
> task. Now, we only cite this reference to challenge those software
> engineers who may state that using the 240/4 in their code is a lot more
> involved.    Q.E.D.  
>
> Regards,
>
>
> Abe (2022-03-26 12:37 EDT)
>
>
>
>
> On 2022-03-26 09:52, Paul Rolland wrote:
>
> Hello,
>
> On Sat, 26 Mar 2022 09:35:30 -0400
> "Abraham Y. Chen"   wrote:
>
>
> touching the hardware, by implementing the EzIP technique (*/disabling/*
> the program code that has been */disabling/* the use of the 240/4
> netblock), an existing CG-NAT module becomes a RAN! As to universal
>
> Have you ever considered that this may be in fact:
>
> */writing/* and */deploying/* the code that will allow the use of 240/4 the
> way you expect
>
>
> Paul
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-7532339818749475379_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

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