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

james.cut...@consultant.com wrote: On Mar 26, 2022, at 8:30 PM, Masataka Ohta wrote: Owen DeLong via NANOG wrote: It still looks like NAT to me. Almost all the people, perhaps other than you, accept NAT as is to keep IPv4 Internet or as part of transition plan from IPv4 to IPv6. NAT

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

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

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

Dear John: 0)    Appreciate very much for your comments. 1)    "A traceroute from my machine to 240.1.2.3 goes through six routers at my ISP before stopping (probably at the first default-route-free router).   ":    Great, this confirms our experience. While our team's skill is far inferior

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

Paul Rolland wrote: Hello, On Sat, 26 Mar 2022 09:35:30 -0400 "Abraham Y. Chen" wrote: touching the hardware, by implementing the EzIP technique (*/disabling/* the program code that has been */disabling/* the use of the 240/4 netblock), an existing CG-NAT module becomes a RAN! As to

Re: V6 still not supported

Owen DeLong wrote: On Mar 24, 2022, at 21:18 , James R Cutler mailto:james.cut...@consultant.com>> wrote: On Mar 24, 2022, at 9:25 PM, Owen DeLong via NANOG > wrote: I think that we’re still OK on allocation policies. What I’d like to see is an end to the

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

On 3/26/22 17:38, Joe Greco wrote: It seems like it should only require changes on a few billion nodes, given the size of the IPv4 address space, right? Oh, wait, NAT... Oh, wait again, several million of those few billion nodes have their code burned into ROM soldered to the board. --

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

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

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

On Mar 26, 2022, at 8:30 PM, Masataka Ohta wrote: > > Owen DeLong via NANOG wrote: > >> It still looks like NAT to me. > > Almost all the people, perhaps other than you, accept NAT > as is to keep IPv4 Internet or as part of transition > plan from IPv4 to IPv6. > >> NAT is a disgusting hack

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

Owen DeLong via NANOG wrote: It still looks like NAT to me. Almost all the people, perhaps other than you, accept NAT as is to keep IPv4 Internet or as part of transition plan from IPv4 to IPv6. NAT is a disgusting hack and destroys the universal peer to peer nature of the internet in favor

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

On Sat, Mar 26, 2022 at 12:37:59PM -0400, Tom Beecher wrote: > > > > Have you ever considered that this may be in fact: > > > > */writing/* and */deploying/* the code that will allow the use of 240/4 the > > way you expect > > > > While Mr. Chen may have considered that, he has repeatedly hand

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

- On Mar 26, 2022, at 6:16 PM, Abraham Y. Chen ayc...@avinta.com wrote: > Hi, Tom & Paul: > 1) " ... hand waved ... ": Through my line of work, I was trained to behave > exactly the opposite. I am surprised at you jumping to the conclusion, even > before challenging me about where did I

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

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

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

Hi, Tom & Paul: 1)    " ... hand waved ...  ":    Through my line of work, I was trained to behave exactly the opposite. I am surprised at you jumping to the conclusion, even before challenging me about where did I get my viewpoint from. The fact is, it has been clearly documented in our IETF

Re: MAP-T (was: Re: V6 still not supported)

It comes from actual measurements in residential networks that already offer IPv6. In typical residential networks, a very high % of the traffic is Google/Youtube, Netflix, Facebook, CDNs, etc., which all are IPv6 enabled. Typically, is also similar in mobile networks, and this has been

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

> > It was quite frustrating since we did not have the background in > networking software You clearly still do not, if you sincerely believe that commenting out a single function in every vendor software implementation is all that it would take. No need to respond ; I will be filtering all

Re: MAP-T (was: Re: V6 still not supported)

It appears that JORDI PALET MARTINEZ via NANOG said: >At the end, if you turn on IPv6 to residential customers, typically you will >get 70-80% IPv6 traffic, so the state in the NAT64 using 464XLAT is lower and >lower every day. Not disagreeing, but where does that number come from?

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

Hi, Paul: 1)    " ...  may be in fact: /writing/* and */deploying/* the code  ... ":    Having no idea why and how the 240/4 netblock became so mysteriously kept away from being used while the IPv4 was officially already on its way to "Sun Set", we started the conventional approach as you

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

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

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

Mostly what Matt said. ( I should have also said 'ride the 0/0 train INTO the DFZ, my mistake.) Essentially, if ASN X is announcing a prefix with an excessive number of prepends, they are saying to the world 'This path exists , but it is hot garbage.' I'm more than happy to oblige those

v6ops-transition-comparison (was: Re: MAP-T (was: Re: V6 still not supported))

Jordi - Very nice indeed! Please pass along my thanks to your coauthors for this most excellent (and badly needed) document! :-) /John > On 25 Mar 2022, at 4:53 PM, JORDI PALET MARTINEZ via NANOG > wrote: > > The cost of deploying MAP in CPEs is a bit higher than 464XLAT, which

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

Hello, On Sat, 26 Mar 2022 09:35:30 -0400 "Abraham Y. Chen" wrote: > touching the hardware, by implementing the EzIP technique (*/disabling/* > the program code that has been */disabling/* the use of the 240/4 > netblock), an existing CG-NAT module becomes a RAN! As to universal Have you

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

Hi, Owen: 0)    Re: Ur. Pt. 2): This topic is such a tongue-twister. Let's put it aside for now, until I can properly convey the EzIP concept and scheme to you. 00)    Re: Ur. Pt. 4):    Okay, I was concerned about how to decipher this cryptic exchange. So let's put it aside as well. 1)   

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

On Fri, Mar 25, 2022 at 6:19 PM Amir Herzberg wrote: > Hi Matthew and NANOG, > > I don't want to defend prepending 255 times, and can understand filtering > of extra-prepended-announcements, but I think Matthew may not be correct > here: > >> Anyone that is prepending to do traffic engineering