subject:"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: V6 still not supported

2022-04-04 Thread Michael Thomas




On 4/4/22 8:00 AM, Tom Beecher wrote:



( Of course, the better solution is really on the service end to have 
a better system to associate bad activity to specific users, or other 
methods that aren't reliant on reputation services , but that won't 
happen unless they start seeing revenue loss from people who want to 
pay them for a service but can't because of too much reputation 
blocking, and I think that's a long way away, if it ever gets there.)


This is the actual solution. It was always a terrible hack to rely on IP 
addresses as an identifier and that's especially true for gaming 
consoles where they can use some pre-built identifier burned into the 
box. With browser fingerprinting it would be silly to incorporate IP 
addresses into the mix as DHCP from providers changes up the IP address 
reducing its fidelity.


This is clearly a Sony et al problem. Providers should point the finger 
at them to make them fix it.


Mike, not that I think cgnat isn't a gross hack

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: Enhance CG-NAT Re: V6 still not supported

2022-04-04 Thread Abraham Y. Chen

dule is not expected to make any changes from today's 
configuration for packet transmission between it and the Internet. For 
the CDN operation, the gateway has already been performing the address 
translation between unrelated IP address blocks as a two-port device. 
For packets going through it, it will continue to perform its NAT 
function. There is no reason to announce to the world that its internal 
addresses have been updated to 240/4.


7)    "... IMHI: it would be a very dirty work-around if servers would 
need to teach their capabilities to every NAPT device.   ... ":    
Based on the above description, I hope you will change your conclusion.


I look forward to your further thoughts.


Regards,




Abe (2022-04-04 12:13 EDT)




On 2022-04-04 06:32, Vasilenko Eduard wrote:


Hi Abraham,

I propose you improve EzIP by the advice in the draft on the way how 
to randomize small sites choice inside 240/4 (like in ULA?).


To give the chance for the merge that may be needed for a business. 
Minimize probability for address duplication inside 240/4 block (that 
everybody would use).


You have not discussed in the document CGNAT case that is typically 
called NAT444 (double NAT translation).


I assume it is possible, but would be a big question how to coordinate 
one 240/4 distribution between all subscribers. Because address space 
between Carrier and Subscriber are Private too.


I do not see a big difference between EzIP and NAPT that we have right 
now. Explanation:


Initially, the majority of servers on the internet would not be 
capable to read Ez options (private 240/4 address extension).


Hence, the Web server would see just UDP:Public_IP.

The gateway (that would be exposing 240/4 options) would need 
additionally to translate UDP ports to avoid a collision (as usual for 
NAPT).


The gateway could not stop NAPT till the last server on the internet 
would be capable to read address extension (240/4) in options, because 
the gateway would not know what server is capable to parse EzIP options.


It means NEVER, at least not in this century. Hence, the additional 
value from EzIP is small, because the primary job would be still done 
by NAPT.


You could try to patch this problem. If the new server would signal to 
the gateway that it is capable to understand EzIP options then 
overlapping UDP ports from the same Public IP address would be not a 
problem, because the server may additionally use private address space 
for traffic multiplexing.


IMHI: it would be a very dirty work-around if servers would need to 
teach their capabilities to every NAPT device.


Sorry, I have not read all 55 pages, but the principal architecture 
questions are not possible to understand from the first 9 pages.


Your first pages are oriented for low-level engineers (“for dummies”).

Eduard

*From:*NANOG 
[mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] *On 
Behalf Of *Abraham Y. Chen

*Sent:* Sunday, April 3, 2022 6:14 AM
*To:* Matthew Petach ; Masataka Ohta 


*Cc:* nanog@nanog.org
*Subject:* Enhance CG-NAT Re: V6 still not supported

Hi, Matt:

1)    The challenge that you described can be resolved as one part of 
the benefits from the EzIP proposal that I introduced to this mailing 
list about one month ago. That discussion has gyrated into this thread 
more concerned about IPv6 related topics, instead. If you missed that 
introduction, please have a look at the following IETF draft to get a 
feel of what could be done:


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space 



2)   With respect to the specific case you brought up, consider the 
EzIP address pool (240/4 netblock with about 256M addresses) as the 
replacement to that of CG-NAT (100.64/10 netblock with about 4M 
addresses). This much bigger (2^6 times) pool enables every customer 
premises to get a static IP address from the 240/4 pool to operate in 
simple router mode, instead of requesting for a static port number and 
still operates in NAT mode. Within each customer premises, the 
conventional three private netblocks may be used to handle the hosts 
(IoTs).


3) There is a whitepaper that presents an overview of other 
possibilities based on EzIP approach:


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Hope the above makes sense to you.

Regards,

Abe (2022-04-02 23:10)

On 2022-04-02 16:25, Matthew Petach wrote:

On Fri, Apr 1, 2022 at 6:37 AM Masataka Ohta
 wrote:


If you make the stateful NATs static, that is, each
private address has a statically configured range of
public port numbers, it is extremely easy because no
logging is necessary for police grade audit trail
opacity.

    Masataka Ohta

Hi Masataka,

One quick question.  If every host is granted a range of public port

numbers on the static stateful NAT device, what happens when

two customers need access to the same port number?

Because

Re: V6 still not supported

2022-04-04 Thread Tom Beecher

>
> . Less so a problem inherent to IPv4. A root cause fix would address
> Sony's hostile behavior.
>

Disagree, to a point.

The problem isn't technically with IPv4 itself, but with the lack of
availability of V4 addresses. This tends to force things like CGNAT, which
then compounds the problem when companies rely too heavily on 'reputation'
services that put a scarlet letter on entire subnets, sometimes forcing
providers to spent money to buy a new range on the open market that
hopefully isn't 'tainted', and tossing the old subnet back out to make it
someone else's problem.

IPv6 itself doesn't solve that ; these reputation providers could still
mark /64s as 'bad', but it wouldn't impact entire ISPs worth of users when
they did.

( Of course, the better solution is really on the service end to have a
better system to associate bad activity to specific users, or other methods
that aren't reliant on reputation services , but that won't happen unless
they start seeing revenue loss from people who want to pay them for a
service but can't because of too much reputation blocking, and I think
that's a long way away, if it ever gets there.)



On Mon, Apr 4, 2022 at 8:02 AM Jared Brown  wrote:

> My apologies for expressing myself poorly.
>
> What I meant to say is that this is primarily a problem caused by Sony and
> the Sonys of the world. Less so a problem inherent to IPv4. A root cause
> fix would address Sony's hostile behavior.
>
>
> - Jared
>
>
>
> Jordi Palet wrote:
>
> No, isn't only a Sony problem, becomes a problem for every ISP that has
> customers using Sony PSN and have CGN (NAT444), their IP blocks are
> black-listed when they are detected as used CGN. This blocking is "forever"
> (I'm not aware of anyone that has been able to convince PSN to unblock
> them). Then the ISP will rotate the addresses that are in the CGN (which
> means some work renumbering other parts of the network).
>
> You do this with all your IPv4 blocks, and at some point, you don't have
> any "not black-listed" block. Then you need to transfer more addresses.
>
> So realistically, in many cases, for residential ISPs it makes a lot of
> sense to analyze if you have a relevant number of customers using PSN and
> make your numbers about if it makes sense or not to buy CGN vs transfer
> IPv4 addresses vs the real long term solution, which is IPv6 even if you
> need to invest in replacing the customer CPEs.
>
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 30/3/22, 21:02, "NANOG en nombre de Jared Brown"
>  nanog-isp at mail.com> escribió:
>
> Not to necessarily disagree with you, but that is more of a Sony
> problem than an IPv4 problem.
>
>
> - Jared
>
>
>
> Jordi Palet wrote:
>
> It is not a fixed one-time cost ... because if your users are gamers
> behind PSP, Sony is blocking IPv4 ranges behind CGN. So, you keep rotating
> your addresses until all then are blocked, then you need to transfer more
> IPv4 addresses ...
>
> So under this perspective, in many cases it makes more sense to NOT
> invest in CGN, and use that money to transfer up-front more IPv4 addresses
> at once, you will get a better price than if you transfer them every few
> months.
>
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 30/3/22, 18:38, "NANOG en nombre de Jared Brown"
>  nanog-isp at mail.com> escribió:
>
> Randy Carpenter wrote:
> > >> >> Owen DeLong via NANOG wrote:
> > >> >> When your ISP starts charging $X/Month for legacy protocol
> support
> > >> >
> > >> > Out of interest, how would this come about?
> > >>
> > >> ISPs are facing ever growing costs to continue providing IPv4
> services.
> > >  Could you please be more specific about which costs you are
> referring to?
> > >
> > >  It's not like IP transit providers care if they deliver IPv4
> or IPv6 bits to
> > >  you.
> >
> > Have you priced blocks of IPv4 addresses lately?
>   IPv4 address blocks have a fixed one-time cost, not an ongoing
> $X/month cost.
>
> - Jared
>
>

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: V6 still not supported

2022-04-04 Thread Joe Greco

On Mon, Apr 04, 2022 at 04:24:49PM +0200, JORDI PALET MARTINEZ via NANOG wrote:
> Related to the LEA agencies and CGN:
> 
> https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online

And how is this really horribly different than all the Napster crap
where the "owner" of an ISP account got blamed for the activities of
a family member or guest?

Maybe the LEA agencies need some better clue.  I'm fine with them
advocating for IPv6, but I have a suspicion that IPv6 is just another
can of worms, because when you have "an IPv4 internets worth of
internets" (64 bits) available as the host portion of an IPv6 address,
and stuff like RFC 4941, they're going to continue to mistarget the
account owner even in the absence of CG-NAT.

Finding a law enforcement compatible method of who generated traffic
currently ends up being an exercise in keeping detailed logs.  Which
could be done with CG-NAT.  Which makes the referenced article an
example of a failure to understand the true (and horrifying) nature
of the problem of traffic attribution.

Doesn't even begin to touch on pwnage issues.

... 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: 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: V6 still not supported

Related to the LEA agencies and CGN:

https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online

Regards,
Jordi
@jordipalet

El 4/4/22, 16:12, "NANOG en nombre de Francis Booth via NANOG" 
 escribió:

I think you’re jumping to conclusions that Sony is doing this purely from 
the darkness in their hearts. The same thing could be said about Netflix and 
Hulu blocking traffic from addresses that appear as proxies/VPNs. Like it or 
not we had many years where the primary expectation of the Internet was that 
you could map a single ISP customer back to an IP address and MANY services 
still cling to this belief.

https://news.slashdot.org/story/21/05/22/0151220/6th-grader-expelled-after-zoom-provided-possibly-inaccurate-ip-address

This is why we have situations like this where even law enforcement 
agencies can’t seem to wrap their heads around multiple customers all sharing 
the same IP address. You have to remember that a majority of people do not see 
all this behind the scenes stuff so as far as they are concerned the Internet 
will continue working as it always has and any deviation in that is a problem 
with the ISP when all of their friends can connect fine except for them.  

> On
> Apr 4, 2022, at 8:00 AM, Jared Brown  wrote:
> 
> A root cause fix would address Sony's hostile behavior.

**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: V6 still not supported

2022-04-04 Thread Francis Booth via NANOG

I think you’re jumping to conclusions that Sony is doing this purely from the 
darkness in their hearts. The same thing could be said about Netflix and Hulu 
blocking traffic from addresses that appear as proxies/VPNs. Like it or not we 
had many years where the primary expectation of the Internet was that you could 
map a single ISP customer back to an IP address and MANY services still cling 
to this belief.

https://news.slashdot.org/story/21/05/22/0151220/6th-grader-expelled-after-zoom-provided-possibly-inaccurate-ip-address

This is why we have situations like this where even law enforcement agencies 
can’t seem to wrap their heads around multiple customers all sharing the same 
IP address. You have to remember that a majority of people do not see all this 
behind the scenes stuff so as far as they are concerned the Internet will 
continue working as it always has and any deviation in that is a problem with 
the ISP when all of their friends can connect fine except for them.  

> On
> Apr 4, 2022, at 8:00 AM, Jared Brown  wrote:
> 
> A root cause fix would address Sony's hostile behavior.

Re: V6 still not supported

2022-04-04 Thread Abraham Y. Chen


Hi, Jared:

1)    " For cloud providers your IPv4 blocks become your moat. ":    It 
is interesting that your closing statement summarizing the current 
tactics of keeping customers captive and fending against competition 
mirrors well with the "Towers of Babel" metaphor of the ancient days 
mentioned by Christian a couple days' ago. That is, the cyberspace 
"Towers" are controlled virtually by multi-national businesses that 
extend far beyond conventional geographical / political borders. It 
exceeds the comprehension of most people. So, we must realize this 
situation and stop promoting such.


Regards,


Abe (2022-04-04 09:53)





On 2022-04-04 06:01, Jared Brown wrote:

Owen DeLong via NANOG wrote:
When your ISP starts charging $X/Month for legacy protocol support

Out of interest, how would this come about?

ISPs are facing ever growing costs to continue providing IPv4 services.

  Could you please be more specific about which costs you are referring to?

Costs of address acquisition
Costs of CGNAT systems in lieu of address acquisition costs
Costs of increasing support calls due to IPv4 life support measures in other 
networks.
etc.


  It's not like IP transit providers care if they deliver IPv4 or IPv6 bits to 
you.

True, but adding customers requires additional addresses at some point. IPv6 
addresses are cheap compared to IPv4 addresses.

   As an aside, all this demonstrates quite well one of the impediments to 
accelerated IPv6 adoption:

   None of these costs apply to parties not growing or ones that are only 
growing withing their existing IPv4 allocation.

   The status quo does not promote IPv6 adoption, which is obviously a problem 
since transitioning to IPv6-only requires all parties to be aboard.

   I'll even add that there is a perverse incentive for ISPs and others to 
delay IPv6 adoption in certain segments. As there is a scarcity of IPv4, ISPs 
can charge a premium for access to IPv4 addresses, something you cannot do with 
IPv6. Furthermore as IPv4 blocks are acting like an appreciating asset, there 
is both an incentive to acquire more, regardless of need, and to hoard what you 
have, even if you don't need it. For cloud providers your IPv4 blocks become 
your moat.


- Jared




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

Re: V6 still not supported

I don't think this can happen if I'm right and the reason they need to block 
"shared" IPs is because the games/apps just don't work.

If I'm a gamer, and one of my possible ISPs is using CGN, and from time to time 
stops working, and another ISP is providing me a public and/or static IPv4 
address, always working, and there is not too much price difference, what I 
will do?

And of course, as I just said in my previous email, the trend is only supported 
by transitioning to IPv6. Sony has been a lagger on that, instead XBOX had IPv6 
support quite early and developers where properly trained to use it.

(note that I'm not a gamer, neither have any game console at home, actually 
never used one!, so I've no preference or any business relation with any game 
related company ... just commenting what I can see)

Regards,
Jordi
@jordipalet

El 4/4/22, 14:06, "Joe Maimon"  escribió:

JORDI PALET MARTINEZ via NANOG wrote:
> No, isn't only a Sony problem, becomes a problem for every ISP that has 
customers using Sony PSN and have CGN (NAT444), their IP blocks are 
black-listed when they are detected as used CGN. This blocking is "forever" 
(I'm not aware of anyone that has been able to convince PSN to unblock them). 
Then the ISP will rotate the addresses that are in the CGN (which means some 
work renumbering other parts of the network).
>
> You do this with all your IPv4 blocks, and at some point, you don't have 
any "not black-listed" block. Then you need to transfer more addresses.
>
> So realistically, in many cases, for residential ISPs it makes a lot of 
sense to analyze if you have a relevant number of customers using PSN and make 
your numbers about if it makes sense or not to buy CGN vs transfer IPv4 
addresses vs the real long term solution, which is IPv6 even if you need to 
invest in replacing the customer CPEs.
>
>
> Regards,
> Jordi
> @jordipalet
>   

I would expect the trend to become that ISP's refuse to accommodate 3rd 
party vendors shenanigans to the point where it hampers their operations 
or to the point where it cost them more to do so.

Likely, they would sooner tell the customer that their vendor (whom they 
pay money) is blocking the ISP and that there must a) deal with their 
vendor and/or b) pay/use a dedicated static IP

Because as you point out, its impossible to support this trend after a 
certain point, and really, why should you?

With enough of that attitude, the trend reverses and vendors will have 
to start using other mechanisms, perhaps even ones where cooperation 
with the SP is a possibility.

Joe

**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: V6 still not supported

My guess is that fixing that means fixing tons of games/apps. They are somehow 
presuming that every user of the game has a different IP.

Note that we are talking only about PSN because it is probably the most 
affected one, but I heard about other services with similar problems and 
similar blockings.

I'm convinced that it will be cheaper and much easier to port to IPv6 those 
games/apps and at the same time be a long-term solution.

Regards,
Jordi
@jordipalet

El 4/4/22, 14:03, "NANOG en nombre de Jared Brown" 
 escribió:

My apologies for expressing myself poorly.

What I meant to say is that this is primarily a problem caused by Sony and 
the Sonys of the world. Less so a problem inherent to IPv4. A root cause fix 
would address Sony's hostile behavior.

- Jared

Jordi Palet wrote:

No, isn't only a Sony problem, becomes a problem for every ISP that has 
customers using Sony PSN and have CGN (NAT444), their IP blocks are 
black-listed when they are detected as used CGN. This blocking is "forever" 
(I'm not aware of anyone that has been able to convince PSN to unblock them). 
Then the ISP will rotate the addresses that are in the CGN (which means some 
work renumbering other parts of the network).

You do this with all your IPv4 blocks, and at some point, you don't have 
any "not black-listed" block. Then you need to transfer more addresses.

So realistically, in many cases, for residential ISPs it makes a lot of 
sense to analyze if you have a relevant number of customers using PSN and make 
your numbers about if it makes sense or not to buy CGN vs transfer IPv4 
addresses vs the real long term solution, which is IPv6 even if you need to 
invest in replacing the customer CPEs.

Regards,
Jordi
@jordipalet

El 30/3/22, 21:02, "NANOG en nombre de Jared Brown" 
 escribió:

Not to necessarily disagree with you, but that is more of a Sony 
problem than an IPv4 problem.

- Jared

Jordi Palet wrote:

It is not a fixed one-time cost ... because if your users are gamers 
behind PSP, Sony is blocking IPv4 ranges behind CGN. So, you keep rotating your 
addresses until all then are blocked, then you need to transfer more IPv4 
addresses ...

So under this perspective, in many cases it makes more sense to NOT 
invest in CGN, and use that money to transfer up-front more IPv4 addresses at 
once, you will get a better price than if you transfer them every few months.

Regards,
Jordi
@jordipalet

El 30/3/22, 18:38, "NANOG en nombre de Jared Brown" 
 escribió:

Randy Carpenter wrote:
> >> >> Owen DeLong via NANOG wrote:
> >> >> When your ISP starts charging $X/Month for legacy protocol 
support
> >> >
> >> > Out of interest, how would this come about?
> >>
> >> ISPs are facing ever growing costs to continue providing IPv4 
services.
> >  Could you please be more specific about which costs you are 
referring to?
> >
> >  It's not like IP transit providers care if they deliver IPv4 
or IPv6 bits to
> >  you.
>
> Have you priced blocks of IPv4 addresses lately?
  IPv4 address blocks have a fixed one-time cost, not an ongoing 
$X/month cost.

- Jared

**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: V6 still not supported

2022-04-04 Thread Joe Maimon





JORDI PALET MARTINEZ via NANOG wrote:

No, isn't only a Sony problem, becomes a problem for every ISP that has customers using 
Sony PSN and have CGN (NAT444), their IP blocks are black-listed when they are detected 
as used CGN. This blocking is "forever" (I'm not aware of anyone that has been 
able to convince PSN to unblock them). Then the ISP will rotate the addresses that are in 
the CGN (which means some work renumbering other parts of the network).

You do this with all your IPv4 blocks, and at some point, you don't have any "not 
black-listed" block. Then you need to transfer more addresses.

So realistically, in many cases, for residential ISPs it makes a lot of sense 
to analyze if you have a relevant number of customers using PSN and make your 
numbers about if it makes sense or not to buy CGN vs transfer IPv4 addresses vs 
the real long term solution, which is IPv6 even if you need to invest in 
replacing the customer CPEs.


Regards,
Jordi
@jordipalet
  


I would expect the trend to become that ISP's refuse to accommodate 3rd 
party vendors shenanigans to the point where it hampers their operations 
or to the point where it cost them more to do so.


Likely, they would sooner tell the customer that their vendor (whom they 
pay money) is blocking the ISP and that there must a) deal with their 
vendor and/or b) pay/use a dedicated static IP


Because as you point out, its impossible to support this trend after a 
certain point, and really, why should you?


With enough of that attitude, the trend reverses and vendors will have 
to start using other mechanisms, perhaps even ones where cooperation 
with the SP is a possibility.


Joe

Re: V6 still not supported

2022-04-04 Thread Jared Brown

My apologies for expressing myself poorly.

What I meant to say is that this is primarily a problem caused by Sony and the 
Sonys of the world. Less so a problem inherent to IPv4. A root cause fix would 
address Sony's hostile behavior.

- Jared

Jordi Palet wrote:

No, isn't only a Sony problem, becomes a problem for every ISP that has 
customers using Sony PSN and have CGN (NAT444), their IP blocks are 
black-listed when they are detected as used CGN. This blocking is "forever" 
(I'm not aware of anyone that has been able to convince PSN to unblock them). 
Then the ISP will rotate the addresses that are in the CGN (which means some 
work renumbering other parts of the network).

You do this with all your IPv4 blocks, and at some point, you don't have any 
"not black-listed" block. Then you need to transfer more addresses.

So realistically, in many cases, for residential ISPs it makes a lot of sense 
to analyze if you have a relevant number of customers using PSN and make your 
numbers about if it makes sense or not to buy CGN vs transfer IPv4 addresses vs 
the real long term solution, which is IPv6 even if you need to invest in 
replacing the customer CPEs.

Regards,
Jordi
@jordipalet

El 30/3/22, 21:02, "NANOG en nombre de Jared Brown" 
 escribió:

Not to necessarily disagree with you, but that is more of a Sony problem 
than an IPv4 problem.

- Jared

Jordi Palet wrote:

It is not a fixed one-time cost ... because if your users are gamers behind 
PSP, Sony is blocking IPv4 ranges behind CGN. So, you keep rotating your 
addresses until all then are blocked, then you need to transfer more IPv4 
addresses ...

So under this perspective, in many cases it makes more sense to NOT invest 
in CGN, and use that money to transfer up-front more IPv4 addresses at once, 
you will get a better price than if you transfer them every few months.

Regards,
Jordi
@jordipalet

El 30/3/22, 18:38, "NANOG en nombre de Jared Brown" 
 escribió:

Randy Carpenter wrote:
> >> >> Owen DeLong via NANOG wrote:
> >> >> When your ISP starts charging $X/Month for legacy protocol 
support
> >> >
> >> > Out of interest, how would this come about?
> >>
> >> ISPs are facing ever growing costs to continue providing IPv4 
services.
> >  Could you please be more specific about which costs you are 
referring to?
> >
> >  It's not like IP transit providers care if they deliver IPv4 or 
IPv6 bits to
> >  you.
>
> Have you priced blocks of IPv4 addresses lately?
  IPv4 address blocks have a fixed one-time cost, not an ongoing 
$X/month cost.

- Jared

RE: Enhance CG-NAT Re: V6 still not supported

Hi Abraham,
I propose you improve EzIP by the advice in the draft on the way how to 
randomize small sites choice inside 240/4 (like in ULA?).
To give the chance for the merge that may be needed for a business. Minimize 
probability for address duplication inside 240/4 block (that everybody would 
use).

You have not discussed in the document CGNAT case that is typically called 
NAT444 (double NAT translation).
I assume it is possible, but would be a big question how to coordinate one 
240/4 distribution between all subscribers. Because address space between 
Carrier and Subscriber are Private too.

I do not see a big difference between EzIP and NAPT that we have right now. 
Explanation:
Initially, the majority of servers on the internet would not be capable to read 
Ez options (private 240/4 address extension).
Hence, the Web server would see just UDP:Public_IP.
The gateway (that would be exposing 240/4 options) would need additionally to 
translate UDP ports to avoid a collision (as usual for NAPT).
The gateway could not stop NAPT till the last server on the internet would be 
capable to read address extension (240/4) in options, because the gateway would 
not know what server is capable to parse EzIP options.
It means NEVER, at least not in this century. Hence, the additional value from 
EzIP is small, because the primary job would be still done by NAPT.
You could try to patch this problem. If the new server would signal to the 
gateway that it is capable to understand EzIP options then overlapping UDP 
ports from the same Public IP address would be not a problem, because the 
server may additionally use private address space for traffic multiplexing.
IMHI: it would be a very dirty work-around if servers would need to teach their 
capabilities to every NAPT device.

Sorry, I have not read all 55 pages, but the principal architecture questions 
are not possible to understand from the first 9 pages.
Your first pages are oriented for low-level engineers (“for dummies”).

Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Abraham Y. Chen
Sent: Sunday, April 3, 2022 6:14 AM
To: Matthew Petach ; Masataka Ohta 

Cc: nanog@nanog.org
Subject: Enhance CG-NAT Re: V6 still not supported

Hi, Matt:

1)The challenge that you described can be resolved as one part of the 
benefits from the EzIP proposal that I introduced to this mailing list about 
one month ago. That discussion has gyrated into this thread more concerned 
about IPv6 related topics, instead. If you missed that introduction, please 
have a look at the following IETF draft to get a feel of what could be done:


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space

2)   With respect to the specific case you brought up, consider the EzIP 
address pool (240/4 netblock with about 256M addresses) as the replacement to 
that of CG-NAT (100.64/10 netblock with about 4M addresses). This much bigger 
(2^6 times) pool enables every customer premises to get a static IP address 
from the 240/4 pool to operate in simple router mode, instead of requesting for 
a static port number and still operates in NAT mode. Within each customer 
premises, the conventional three private netblocks may be used to handle the 
hosts (IoTs).

3)There is a whitepaper that presents an overview of other possibilities 
based on EzIP approach:

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Hope the above makes sense to you.

Regards,


Abe (2022-04-02 23:10)






On 2022-04-02 16:25, Matthew Petach wrote:


On Fri, Apr 1, 2022 at 6:37 AM Masataka Ohta 
mailto:mo...@necom830.hpcl.titech.ac.jp>> 
wrote:

If you make the stateful NATs static, that is, each
private address has a statically configured range of
public port numbers, it is extremely easy because no
logging is necessary for police grade audit trail
opacity.
Masataka Ohta

Hi Masataka,
One quick question.  If every host is granted a range of public port
numbers on the static stateful NAT device, what happens when
two customers need access to the same port number?

Because there's no way in a DNS NS entry to specify a
port number, if I need to run a DNS server behind this
static NAT, I *have* to be given port 53 in my range;
there's no other way to make DNS work.  This means
that if I have two customers that each need to run a
DNS server, I have to put them on separate static
NAT boxes--because they can't both get access to
port 53.

This limits the effectiveness of a stateful static NAT
box to the number of customers that need hard-wired
port numbers to be mapped through; which, depending
on your customer base, could end up being all of them,
at which point you're back to square one, with every
customer needing at least 1 IPv4 address dedicated
to them on the NAT device.

Either that, or you simply tell your customers "so sorry
you didn't get on the Internet soon enough; you're

Re: V6 still not supported

No, isn't only a Sony problem, becomes a problem for every ISP that has 
customers using Sony PSN and have CGN (NAT444), their IP blocks are 
black-listed when they are detected as used CGN. This blocking is "forever" 
(I'm not aware of anyone that has been able to convince PSN to unblock them). 
Then the ISP will rotate the addresses that are in the CGN (which means some 
work renumbering other parts of the network).

You do this with all your IPv4 blocks, and at some point, you don't have any 
"not black-listed" block. Then you need to transfer more addresses.

So realistically, in many cases, for residential ISPs it makes a lot of sense 
to analyze if you have a relevant number of customers using PSN and make your 
numbers about if it makes sense or not to buy CGN vs transfer IPv4 addresses vs 
the real long term solution, which is IPv6 even if you need to invest in 
replacing the customer CPEs.

Regards,
Jordi
@jordipalet

El 30/3/22, 21:02, "NANOG en nombre de Jared Brown" 
 escribió:

Not to necessarily disagree with you, but that is more of a Sony problem 
than an IPv4 problem.

- Jared

Jordi Palet wrote:

It is not a fixed one-time cost ... because if your users are gamers behind 
PSP, Sony is blocking IPv4 ranges behind CGN. So, you keep rotating your 
addresses until all then are blocked, then you need to transfer more IPv4 
addresses ...

So under this perspective, in many cases it makes more sense to NOT invest 
in CGN, and use that money to transfer up-front more IPv4 addresses at once, 
you will get a better price than if you transfer them every few months.

Regards,
Jordi
@jordipalet

El 30/3/22, 18:38, "NANOG en nombre de Jared Brown" 
 escribió:

Randy Carpenter wrote:
> >> >> Owen DeLong via NANOG wrote:
> >> >> When your ISP starts charging $X/Month for legacy protocol 
support
> >> >
> >> > Out of interest, how would this come about?
> >>
> >> ISPs are facing ever growing costs to continue providing IPv4 
services.
> >  Could you please be more specific about which costs you are 
referring to?
> >
> >  It's not like IP transit providers care if they deliver IPv4 or 
IPv6 bits to
> >  you.
>
> Have you priced blocks of IPv4 addresses lately?
  IPv4 address blocks have a fixed one-time cost, not an ongoing 
$X/month cost.

- Jared

**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: V6 still not supported

2022-04-04 Thread Jared Brown

>  Owen DeLong via NANOG wrote:
>  When your ISP starts charging $X/Month for legacy protocol support
> >>>
> >>> Out of interest, how would this come about?
> >>
> >> ISPs are facing ever growing costs to continue providing IPv4 services.
> >  Could you please be more specific about which costs you are referring to?
>
> Costs of address acquisition
> Costs of CGNAT systems in lieu of address acquisition costs
> Costs of increasing support calls due to IPv4 life support measures in other 
> networks.
> etc.
>
> >  It's not like IP transit providers care if they deliver IPv4 or IPv6 bits 
> > to you.
>
> True, but adding customers requires additional addresses at some point. IPv6 
> addresses are cheap compared to IPv4 addresses.
  As an aside, all this demonstrates quite well one of the impediments to 
accelerated IPv6 adoption:

  None of these costs apply to parties not growing or ones that are only 
growing withing their existing IPv4 allocation.

  The status quo does not promote IPv6 adoption, which is obviously a problem 
since transitioning to IPv6-only requires all parties to be aboard.

  I'll even add that there is a perverse incentive for ISPs and others to delay 
IPv6 adoption in certain segments. As there is a scarcity of IPv4, ISPs can 
charge a premium for access to IPv4 addresses, something you cannot do with 
IPv6. Furthermore as IPv4 blocks are acting like an appreciating asset, there 
is both an incentive to acquire more, regardless of need, and to hoard what you 
have, even if you don't need it. For cloud providers your IPv4 blocks become 
your moat.

- Jared

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: V6 still not supported

2022-04-03 Thread Masataka Ohta


Matthew Petach wrote:


Hi Masataka,


Hi,


One quick question.  If every host is granted a range of public port
numbers on the static stateful NAT device, what happens when
two customers need access to the same port number?


I mean static outgoing port number, but your concern
should be well known incoming port number, which is
an issue not specific to "static stateful" NAT.

Because there's no way in a DNS NS entry to specify a
port number, if I need to run a DNS server behind this
static NAT, I *have* to be given port 53 in my range;
there's no other way to make DNS work.


And SMTP, as is explained in draft-ohta-e2e-nat-00:

   A server port number different from well known ones may be specified
   through mechanisms to specify an address of the server, which is the
   case of URLs. However, port numbers for DNS and SMTP are, in general,
   implicitly assumed by DNS and are not changeable.


   Or, a NAT gateway may receive packets to certain ports and behave as
   an application gateway to end hosts, if request messages to the
   server contains information, such as domain names, which is the case
   with DNS, SMTP and HTTP, to demultiplex the request messages to end
   hosts.  However, for an ISP operating the NAT gateway, it may be
   easier to operate independent servers at default port for DNS, SMTP,
   HTTP and other applications for their customers than operating
   application relays.

Though the draft is for E2ENAT, situation is same
for any kind of NAT.


This means
that if I have two customers that each need to run a
DNS server, I have to put them on separate static
NAT boxes--because they can't both get access to
port 53.


See above for other possibilities.


This limits the effectiveness of a stateful static NAT
box


For incoming port, static stateful NAT is no worse than
dynamic NAT. Both may be configured to map certain
incoming ports to certain local ports and addresses
statically or dynamically with, say, UPnP.

The point of static stateful NAT is for outgoing port
that it does not require logging.


tl;dr -- "if only we'd thought of putting a port number field
in the NS records in DNS back in 1983..."


And, MX.

As named has "-p" option, I think some people were already
aware of uselessness of the option in 1983. But, putting
a port number field at that time is overkill.

Masataka Ohta

Enhance CG-NAT Re: V6 still not supported


Hi, Matt:

1)    The challenge that you described can be resolved as one part of 
the benefits from the EzIP proposal that I introduced to this mailing 
list about one month ago. That discussion has gyrated into this thread 
more concerned about IPv6 related topics, instead. If you missed that 
introduction, please have a look at the following IETF draft to get a 
feel of what could be done:


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space 



2)   With respect to the specific case you brought up, consider the EzIP 
address pool (240/4 netblock with about 256M addresses) as the 
replacement to that of CG-NAT (100.64/10 netblock with about 4M 
addresses). This much bigger (2^6 times) pool enables every customer 
premises to get a static IP address from the 240/4 pool to operate in 
simple router mode, instead of requesting for a static port number and 
still operates in NAT mode. Within each customer premises, the 
conventional three private netblocks may be used to handle the hosts (IoTs).


3)    There is a whitepaper that presents an overview of other 
possibilities based on EzIP approach:


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Hope the above makes sense to you.

Regards,


Abe (2022-04-02 23:10)






On 2022-04-02 16:25, Matthew Petach wrote:



On Fri, Apr 1, 2022 at 6:37 AM Masataka Ohta 
 wrote:



If you make the stateful NATs static, that is, each
private address has a statically configured range of
public port numbers, it is extremely easy because no
logging is necessary for police grade audit trail
opacity. 


                Masataka Ohta


Hi Masataka,
One quick question.  If every host is granted a range of public port
numbers on the static stateful NAT device, what happens when
two customers need access to the same port number?

Because there's no way in a DNS NS entry to specify a
port number, if I need to run a DNS server behind this
static NAT, I *have* to be given port 53 in my range;
there's no other way to make DNS work.  This means
that if I have two customers that each need to run a
DNS server, I have to put them on separate static
NAT boxes--because they can't both get access to
port 53.

This limits the effectiveness of a stateful static NAT
box to the number of customers that need hard-wired
port numbers to be mapped through; which, depending
on your customer base, could end up being all of them,
at which point you're back to square one, with every
customer needing at least 1 IPv4 address dedicated
to them on the NAT device.

Either that, or you simply tell your customers "so sorry
you didn't get on the Internet soon enough; you're all
second class citizens that can't run your own servers;
if you need to do that, you can go pay Amazon to host
your server needs."

And perhaps that's not as unreasonable as it first sounds;
we may all start running IPv4-IPv6 application gateways
on Amazon, so that IPv6-only networks can still interact
with the IPv4-only internet, and Amazon will be the great
glue that holds it all together.

tl;dr -- "if only we'd thought of putting a port number field
in the NS records in DNS back in 1983..."

Matt




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

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: V6 still not supported

2022-04-02 Thread Matthew Petach

On Fri, Apr 1, 2022 at 6:37 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

>
> If you make the stateful NATs static, that is, each
> private address has a statically configured range of
> public port numbers, it is extremely easy because no
> logging is necessary for police grade audit trail
> opacity.

Masataka Ohta
>

Hi Masataka,
One quick question.  If every host is granted a range of public port
numbers on the static stateful NAT device, what happens when
two customers need access to the same port number?

Because there's no way in a DNS NS entry to specify a
port number, if I need to run a DNS server behind this
static NAT, I *have* to be given port 53 in my range;
there's no other way to make DNS work.  This means
that if I have two customers that each need to run a
DNS server, I have to put them on separate static
NAT boxes--because they can't both get access to
port 53.

This limits the effectiveness of a stateful static NAT
box to the number of customers that need hard-wired
port numbers to be mapped through; which, depending
on your customer base, could end up being all of them,
at which point you're back to square one, with every
customer needing at least 1 IPv4 address dedicated
to them on the NAT device.

Either that, or you simply tell your customers "so sorry
you didn't get on the Internet soon enough; you're all
second class citizens that can't run your own servers;
if you need to do that, you can go pay Amazon to host
your server needs."

And perhaps that's not as unreasonable as it first sounds;
we may all start running IPv4-IPv6 application gateways
on Amazon, so that IPv6-only networks can still interact
with the IPv4-only internet, and Amazon will be the great
glue that holds it all together.

tl;dr -- "if only we'd thought of putting a port number field
in the NS records in DNS back in 1983..."

Matt

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


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


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


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


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


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: V6 still not supported


Hi, Owen:

The EzIP addresses (the 240/4 netblock) are proposed to be treated as 
"natural resources" without a price tag (or, "free") following the 
old-fashioned PSTN discipline, instead of "personal properties" for 
auction according to the current Internet way.


Regards,


Abe (2022-04-01 09:35)



On 2022-03-31 16:09, Owen DeLong via NANOG wrote:

On Mar 30, 2022, at 08:09 , Jared Brown  wrote:

Owen DeLong via NANOG wrote:

When your ISP starts charging $X/Month for legacy protocol support

Out of interest, how would this come about?

ISPs are facing ever growing costs to continue providing IPv4 services.

  Could you please be more specific about which costs you are referring to?

Costs of address acquisition
Costs of CGNAT systems in lieu of address acquisition costs
Costs of increasing support calls due to IPv4 life support measures in other 
networks.
etc.


  It's not like IP transit providers care if they deliver IPv4 or IPv6 bits to 
you.

True, but adding customers requires additional addresses at some point. IPv6 
addresses are cheap compared to IPv4 addresses.

Owen




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

Re: V6 still not supported

2022-04-01 Thread Masataka Ohta


Pascal Thubert (pthubert) via NANOG wrote:


- Stateful NATs the size of the Internet not doable,


Stateful NATs are necessary only near leaf edges of ISPs
for hundreds of customers or, may be, a little more
than that and is doable.

If you make the stateful NATs static, that is, each
private address has a statically configured range of
public port numbers, it is extremely easy because no
logging is necessary for police grade audit trail
opacity.

Masataka Ohta

Re: V6 still not supported

2022-04-01 Thread Ryland Kremeier

I had no idea that actually went through. That makes my morning much better 
knowing someone saw it hahaha. I'm all in on v6.

Thank you,
-- Ryland

From: Pascal Thubert (pthubert) 
Sent: Friday, April 1, 2022 6:59:19 AM
To: Owen DeLong ; Ryland Kremeier 
Cc: Philip Homburg ; nanog@nanog.org 
; 'jordi.palet' (jordi.pa...@consulintel.es) 

Subject: RE: V6 still not supported

Actually, Owen, now the day has come, I can say I love it.

No one likes tradeoffs. No one wants to compromise.

Ryland just told us we have a near perfect title for a spec that is bound to be 
hated.

Keep safe;

Pascal

From: Owen DeLong 
Sent: mercredi 30 mars 2022 22:33
To: Ryland Kremeier 
Cc: Pascal Thubert (pthubert) ; Philip Homburg 
; nanog@nanog.org; 'jordi.palet' 
(jordi.pa...@consulintel.es) 
Subject: Re: V6 still not supported

I think this message is 4 days early.

Owen

On Mar 28, 2022, at 11:03 , Ryland Kremeier 
mailto:rkreme...@barryelectric.com>> wrote:

[cid:image001.png@01D842A4.69CBE6F0]

Hmm.

-Original Message-
From: NANOG 
mailto:nanog-bounces+rkremeier=barryelectric@nanog.org>>
 On Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Monday, March 28, 2022 11:55 AM
To: Philip Homburg 
mailto:pch-nano...@u-1.phicoh.com>>; 
nanog@nanog.org<mailto:nanog@nanog.org>; 'jordi.palet' 
(jordi.pa...@consulintel.es<mailto:jordi.pa...@consulintel.es>) 
mailto:jordi.pa...@consulintel.es>>
Subject: RE: V6 still not supported

Seems that we lost sync.

I would not rephrase so I made it a draft to make it easy to socialize: 
https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-00.html

The goal is NOT to allow any IPv4 host to talk to any IPv6 host. For that I 
agree you need the traditional transition mechanisms, CG-NATs etc.

The plan has 2 phases:

- The first phase called YADA extends the reach of IPv4 using a common IPv4 
space that is like an elevator shaft.

 /--

/ /

   /  ||realm 1  /

  /  /.   /./

 /  / . shaft/ .  (current IPv4 Internet)  /

/  ||  .  /

   /   .  . .  . /

  --/

   |  . |  |

 /-||--|

/  |  . |  |  /

   /   |  |-|--|realm 2  /

  /| /. | /./

 / |/ . shaft   |/ .   /

/  ||  .  /

   /   .  . .  . /

  --/

   |  . |  |

   |  . |  |

   ||  .

   ||  .

   ..  |

   ..  |

   |  . |  |

 /-||--|

/  |  . |  |  /

   /   |  |-|--|realm N  /

  /| /  | / /

 / |/   shaft   |/ /

/  || /

   / /

  --/

There's more in the draft as to how forwarding happens. But only a few routers 
serving the shaft have to do anything and it's dead simple.

In that phase, we can now have many realms that are parallel to the IPv4 
Internet of today. IPv4 acts as normal in each realm.

The phase upgrades IPv4 host to understand an IP in IP format that allows to 
traverse the shaft. At that time, scale is no more the issue for  IPv4.

- The second phase called YATT does a stateless translation between a v4 in v4 
and a v6 address. No CG-NAT.

+-+---+--+-+

|YATT | Realm | IPv4 | Well-Known  |

|Space|Address|Address   |  IID|

+-+- -+--+-+

   <- YADA

Prefix ->

<   YATT Prefix -->

What it does is allow any node that needs to talk to a legacy device, to 1) 
obtain a YADA address (IPv4 pair), 2) form a YATT address (YADA derived IPv6 
address), and talk to the YADA node, across any of v4 or v6 networks. A 
stateful bump in the stack can NAT the IP pairs into single Ips and back. A 
bum

RE: V6 still not supported

2022-04-01 Thread Pascal Thubert (pthubert) via NANOG

Actually, Owen, now the day has come, I can say I love it.

No one likes tradeoffs. No one wants to compromise.

Ryland just told us we have a near perfect title for a spec that is bound to be 
hated.

Keep safe;

Pascal



From: Owen DeLong 
Sent: mercredi 30 mars 2022 22:33
To: Ryland Kremeier 
Cc: Pascal Thubert (pthubert) ; Philip Homburg 
; nanog@nanog.org; 'jordi.palet' 
(jordi.pa...@consulintel.es) 
Subject: Re: V6 still not supported

I think this message is 4 days early.

Owen



On Mar 28, 2022, at 11:03 , Ryland Kremeier 
mailto:rkreme...@barryelectric.com>> wrote:

[cid:image001.png@01D842A4.69CBE6F0]

Hmm.

-Original Message-
From: NANOG 
mailto:nanog-bounces+rkremeier=barryelectric@nanog.org>>
 On Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Monday, March 28, 2022 11:55 AM
To: Philip Homburg 
mailto:pch-nano...@u-1.phicoh.com>>; 
nanog@nanog.org<mailto:nanog@nanog.org>; 'jordi.palet' 
(jordi.pa...@consulintel.es<mailto:jordi.pa...@consulintel.es>) 
mailto:jordi.pa...@consulintel.es>>
Subject: RE: V6 still not supported

Seems that we lost sync.

I would not rephrase so I made it a draft to make it easy to socialize: 
https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-00.html


The goal is NOT to allow any IPv4 host to talk to any IPv6 host. For that I 
agree you need the traditional transition mechanisms, CG-NATs etc.

The plan has 2 phases:

- The first phase called YADA extends the reach of IPv4 using a common IPv4 
space that is like an elevator shaft.


 /--
/ /
   /  ||realm 1  /
  /  /.   /./
 /  / . shaft/ .  (current IPv4 Internet)  /
/  ||  .  /
   /   .  . .  . /
  --/
   |  . |  |
 /-||--|
/  |  . |  |  /
   /   |  |-|--|realm 2  /
  /| /. | /./
 / |/ . shaft   |/ .   /
/  ||  .  /
   /   .  . .  . /
  --/
   |  . |  |
   |  . |  |
   ||  .
   ||  .
   ..  |
   ..  |
   |  . |  |
 /-||--|
/  |  . |  |  /
   /   |  |-|--|realm N  /
  /| /  | / /
 / |/   shaft   |/ /
/  || /
   / /
  --/

There's more in the draft as to how forwarding happens. But only a few routers 
serving the shaft have to do anything and it's dead simple.
In that phase, we can now have many realms that are parallel to the IPv4 
Internet of today. IPv4 acts as normal in each realm.
The phase upgrades IPv4 host to understand an IP in IP format that allows to 
traverse the shaft. At that time, scale is no more the issue for  IPv4.

- The second phase called YATT does a stateless translation between a v4 in v4 
and a v6 address. No CG-NAT.

+-+---+--+-+
|YATT | Realm | IPv4 | Well-Known  |
|Space|Address|Address   |  IID|
+-+- -+--+-+
   <- YADA
Prefix ->
<   YATT Prefix -->

What it does is allow any node that needs to talk to a legacy device, to 1) 
obtain a YADA address (IPv4 pair), 2) form a YATT address (YADA derived IPv6 
address), and talk to the YADA node, across any of v4 or v6 networks. A 
stateful bump in the stack can NAT the IP pairs into single Ips and back. A 
bump in the stack on the legacy host can NAT the IP pairs into single Ips as 
well.

In that phase, IPv6 can be seen as the sphere that that encompasses the planes 
above, and a lot more. Every node that has a YADA address owns a full IPv6 
prefix automatically. Nodes and networks can migrate to IPv6 only but the nodes 
that need to talk to IPv4 nodes need an YATT address for that.

There will be corner cases, like well-known IPv4 coded in legacy application 
payload. For those arguably we'

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: V6 still not supported

2022-04-01 Thread Pascal Thubert (pthubert) via NANOG

He he, why do you think YADA starts with yet another?

The devil is in the details I guess. AA makes A twice longer, that's the easy 
piece. But then, what is the story for the A->AA transition?

The key piece the concept of the shaft, that enables to transit AA between 
levels while seeing plain IPv4 in each realm. It is as necessary for parallel 
planes as RFC 1918 is necessary for the private domains. In fact that could be 
seen as the reverse. The Internet connects multiple private domains using NATs. 
The shaft connects multiple internets using IP-in-IP. But it has to be the 
exact same (assigned) IPv4 footprint at every layer.

But for any of that to happen you need at least a IANA assignment and a Linux 
or two that play ball. We need to think that through before we waste the last 
IPv4 free land, or assign 240.0.0.0/4

Agreed, the publication for the link below day is incredibly timely. Such is 
the request to pay for natural resources with a declining currency. 

Let us assign the YADA prefix and start experiment 2, baby step 1.

Keep safe;

Pascal

> -Original Message-
> From: Rubens Kuhl 
> Sent: vendredi 1 avril 2022 12:32
> To: Pascal Thubert (pthubert) 
> Cc: nanog@nanog.org
> Subject: Re: V6 still not supported
> 
> > Are you ready for that, or should we wait another 80 years with dual stack
> and gigantic stateful NATs?
> 
> That's what this network is going to do:
> https://www.aa.net.uk/etc/news/ipv6-end-of-trial/
> 
> There is something odd about the day this was published, though.
> 
> 
> Rubens

Re: V6 still not supported

2022-04-01 Thread Rubens Kuhl

> Are you ready for that, or should we wait another 80 years with dual stack 
> and gigantic stateful NATs?

That's what this network is going to do:
https://www.aa.net.uk/etc/news/ipv6-end-of-trial/

There is something odd about the day this was published, though.


Rubens

RE: V6 still not supported

2022-04-01 Thread Pascal Thubert (pthubert) via NANOG

A very long thread.

Face it: everyone is right, and even technically correct. There's no good and 
evil. We'd know, after 20 years. 

I live in France and my country has a famous 100-years war in its long history 
with England. Do we want to beat this here?

The plain truth:

- IPv4 is here to stay. Some v4-only nodes and functionalities are here to 
stay. Plenty of reasons for that in this thread.
- IPv6 is unavoidable. New devices like phones and IOT need it, many IPv6 only 
in that space, numbers only growing


The things everyone agrees upon:
- Dual stack everywhere and forever is the worst of both worlds as it doubles 
every cost, and that will remain long as the war rages
- Stateful NATs the size of the Internet not doable, which in my book says that 
isolation not only unavoidable but already there.

An the illusions:

- any-to-any is required. In particular, any IPv4-only to any-IPv6 only. I'm 
not talking security but plain functionality. And yes, exceptions if they are 
few can be handled by expensive stateful NATs when the cost is justified
- the Internet is a big homogenous thing. The more it expands, the more we see 
domains forming where specific capabilities are deployed, and because we fail 
to handle that at L3, we mask the functionalities above UDP. 

If we agree on the above then a compromise is possible. Ideally, the compromise 
would:
- maintain the current state of v4 affairs for those who want that
- scale v4 addresses for those who want that
- provide v4 to v6 stateless NATs for this who want that, and
- allow networks to be either of the 2 versions for those who want that. 

SciFi? There's a proposed starting point for that compromise in the yada-yatt 
draft published at IETF v6ops. The key is to use baby steps between locations 
(in the transition plan) where people can be at ease and stay as long as they 
want to, as opposed to enforcing a giant zero-to-hero illusionary step.

Are you ready for that, or should we wait another 80 years with dual stack and 
gigantic stateful NATs?

Pascal

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