Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

Apologies, I failed to realize that we were still discussing the absurdity of 240/4 and thought we were talking IPv6. All my comments below apply to v6 progress. 240/4 remains in the who knows?/who cares? Category as far as I’m concerned. OwenOn Jan 12, 2024, at 22:51, Owen DeLong wrote:Windows,

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

Windows, Mac, Linux, bad are all done. Juniper, MikroTik, even Cisco are done.Most consumer routers sold in the last 2-3 years are done. Not sure what “hardware vendor” would be necessary beyond those. There are probably some little used corner cases of routers, os, etc. but for the most part, we

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

interesting side note: when iij was deploying the v6 backbone in '97, commercial routers did not support dual stack. so it was a parallel backbone built on netbsd with the kame stack, which was developed in iij lab. we remember itojun. randy

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

Wow... There is some serious learning about the internet to be done here! When Randy was deploying IPv6 across the IIJ backbone, I was running around in kindergarten. I didn't even know what the internet was back then. Amazing what can happen in 26 years... Regards, Christopher Hawker On Sat,

okta probing

can someone explain what some child out there hopes to gain by repeatedly failing to authenticate to okta in my accound name? a couple of times a day, i have to take 40 seconds to unlock the account the kiddie has triggered. seems silly as they do not have the 2fa. it's -3c here, so i guess the

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

> I go into my cave to finish the todo list for the week, and I come out > to see Mr. Chen : > - Telling Randy Bush he should "read some history" on IPv6 > - Implying that Vint Cerf ever said anything about EzIP > > Fairly impressive sequence of self ownage. but it sure is a change to have a

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

Fair enough, I misunderstood your question. I still think it's basically not knowable. On Fri, Jan 12, 2024 at 3:16 PM Mike Hammett wrote: > I'm not talking about global, public use, only private use. > > > > - > Mike Hammett > Intelligent Computing Solutions >

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

On Fri, Jan 12, 2024 at 2:47 PM Randy Bush wrote: > > Perhaps you are too young to realize that the original IPv6 plan was > > not designed to be backward compatible to IPv4, and Dual-Stack was > > developed (through some iterations) to bridge the transition between > > IPv4 and IPv6? You may

Re: 202401100645.AYC Re: IPv4 address block

On Fri, Jan 12, 2024 at 2:43 AM Nick Hilliard wrote: > Matthew Petach wrote on 11/01/2024 21:05: > > I think that's a bit of an unfair categorization--we can't look at > > pre-exhaustion demand numbers and extrapolate to post-exhaustion > > allocations, given the difference in allocation

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

I go into my cave to finish the todo list for the week, and I come out to see Mr. Chen : - Telling Randy Bush he should "read some history" on IPv6 - Implying that Vint Cerf ever said anything about EzIP Fairly impressive sequence of self ownage. On Fri, Jan 12, 2024 at 5:46 PM Randy Bush

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

Is that a faux pas? On 13 January 2024 9:15:11 am ACDT, Randy Bush wrote: >> Perhaps you are too young to realize that the original IPv6 plan was >> not designed to be backward compatible to IPv4, and Dual-Stack was >> developed (through some iterations) to bridge the transition between >> IPv4

One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

Hi, Forrest: 0)    You put out more than one topic, all at one time. Allow me to address each briefly. 1)   "  The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible.   ":     The feeling and

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

> Perhaps you are too young to realize that the original IPv6 plan was > not designed to be backward compatible to IPv4, and Dual-Stack was > developed (through some iterations) to bridge the transition between > IPv4 and IPv6? You may want to spend a few moments to read some > history on this.

Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

Hi, Randy: 1)    " ... dual-stack mess ... it was intended. it was the original transition plan. ":     Perhaps you are too young to realize that the original IPv6 plan was not designed to be backward compatible to IPv4, and Dual-Stack was developed (through some iterations) to bridge the

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

I'm not talking about global, public use, only private use. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Tom Beecher" To: "Mike Hammett" Cc: "Ryan Hamel" , "Abraham Y. Chen" , nanog@nanog.org

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

On 1/12/24 11:54 AM, Darrel Lewis wrote: On Jan 12, 2024, at 11:47 AM, Seth David Schoen wrote: Michael Thomas writes: I wonder if the right thing to do is to create a standards track RFC that makes the experimental space officially an add on to rfc 1918. If it works for you, great, if

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

> On Jan 12, 2024, at 11:47 AM, Seth David Schoen wrote: > > Michael Thomas writes: > >> I wonder if the right thing to do is to create a standards track RFC that >> makes the experimental space officially an add on to rfc 1918. If it works >> for you, great, if not your problem. It would at

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

> > You don't need everything in the world to support it, just the things > "you" use. You run an ISP, let me posit something. Stipulate your entire network infra, services, and applications support 240/4, and that it's approved for global , public use tomorrow. Some company gets a block in

Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

Would it be possible for you to reply in-thread, rather than creating a new thread with a new subject line every time you reply to someone? Trying to follow the conversation becomes very difficult for no reason. On Friday, January 12th, 2024 at 2:55 PM, Abraham Y. Chen wrote: > Hi, Tony: > >

Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

Hi, Tony: 0)    As the saying goes, there is more than one way to skin a cat. We do not need to address a request by literally following the thought trend. In troubleshooting, engineers are taught to look for the Root-Cause which more than often turns out to be something else originally

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

Michael Thomas writes: > I wonder if the right thing to do is to create a standards track RFC that > makes the experimental space officially an add on to rfc 1918. If it works > for you, great, if not your problem. It would at least stop all of these > recurring arguments that we could salvage it

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

On 1/12/24 8:45 AM, Owen DeLong via NANOG wrote: Frankly, I care less. No matter how you use whatever IPv4 space you attempt to cajole into whatever new form of degraded service, the simple fact remains. IPv4 is a degraded technology that only continues to get worse over time. NAT was bad.

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

I wouldn't say it's unknowable, just that no one with a sufficient enough interest in the cause has been loud enough with the research they've done, assuming some research has been done.. You don't need everything in the world to support it, just the things "you" use. - Mike

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

> > How far are we from that, in reality? I don't have any intention on using > the space, but I would like to put some definition to this boogey man. It's unknowable really. Lots of network software works just fine today with it. Some don't. To my knowledge some NOS vendors have outright

Re: Feds seek to seize funds from lv.net ISP bank accounts and allege $3+ million fraud in bitcoin

And for those who have had the misfortune of actually dealing with LV.Net, this doesn't come as a huge surprise. I once had an corporate rep from them tell me about how the owners "have a bunch of schemes to make money" going on. Matt On 12/21/23 5:28 AM, Eric Kuhnke wrote:

Weekly Global IPv4 Routing Table Report

This is an automated weekly mailing describing the state of the Global IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

" every networking vendor, hardware vendor, and OS vendor" How far are we from that, in reality? I don't have any intention on using the space, but I would like to put some definition to this boogey man. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

I could NOT agree more. Even tho, I am IPv6 phobic, let IPv4 go away. At least, make it go away from mainstream commercial Internet. 90% users do NOT care about it. They want to browse web, watch movies or play games. They can do it using IPv6. I cant wait :) more IPv4 address space for people

Re: 202401100645.AYC Re: IPv4 address block

On 11/01/2024, 21:05:22, "Matthew Petach" wrote: 240/4 can be made to last a very long time, if we apply post-exhaustion rules, rather than allowing pre-exhaustion demand curves to continue forward. And ensure there are no routes for people to take them all for profit (as happened at RIPE

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

Frankly, I care less. No matter how you use whatever IPv4 space you attempt to cajole into whatever new form of degraded service, the simple fact remains. IPv4 is a degraded technology that only continues to get worse over time. NAT was bad. CGNAT is even worse (and tragically does nothing to

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

Abraham, It has existed for many years, already supported on many devices, does not require NAT, address space is plentiful, does not require additional proposals, and it accounts for 40% of the traffic at Google. Ryan From: Abraham Y. Chen Sent: Friday,

Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

> > EzIP proposes EzIP is a concept that has zero interest in the field , aside from Mr. Chen himself. It's been discussed and analysed. Legitimate issues have been raised, and Mr. Chen simply handwaves them away. The only IETF actions on it has been Mr. Chen refreshing the draft every 6

Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

* ayc...@avinta.com (Abraham Y. Chen) [Fri 12 Jan 2024, 13:09 CET]:     EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is reusable for each isolated geographical area. Thus, there is no "Burn-rate" to talk about. You have posted this statement like five times now in the past

Re: Streamline the CG-NAT Re: 202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

"Source NAT changes the source address in IP header of a packet. It may also change the source port in the TCP/UDP headers. The typical usage is to change the a private (rfc1918) address/port into a public address/port for packets leaving your network." "Destination NAT changes the destination

Re: Streamline the CG-NAT Re: 202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

Hi, Christopher: 1) "  destination/source NAT  ":     I am not sure about this terminology. Could you please elaborate? If you are referring EzIP being a bigger CG-NAT, it is exactly correct. That is, the first step of EzIP implementation is just to give CG-NAT a larger netblock to work

Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

Hi, Owen: 1)    "... it seemed the 240/4 lasting a year was an optimistic count.   ":     EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is reusable for each isolated geographical area. Thus, there is no "Burn-rate" to talk about. Regards, Abe (2024-01-12 07:07) On

IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

Hi, Ryan: 1)   " ...  Save yourself the time and effort on this and implement IPv6.    ":     What is your selling point? Regards, Abe (2024-01-12 06:44) 2024-01-11 12:39, Ryan Hamel wrote: Abraham, You're arguing semantics instead of the actual point. Residential customers want

Re: 202401100645.AYC Re: IPv4 address block

Matthew Petach wrote on 11/01/2024 21:05: I think that's a bit of an unfair categorization--we can't look at pre-exhaustion demand numbers and extrapolate to post-exhaustion allocations, given the difference in allocation policies pre-exhaustion versus post-exhaustion. Matt, the demand for

Re: 202401100645.AYC Re: IPv4 address block

>>> We don't need to extend IPv4, we need to figure out why we are in this >>> dual-stack mess, which was never intended, and how to get out of it. >> >> it was intended. it was the original transition plan. like many things >> about ipv6, it could have been a bit better thought out. > > What

RE: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

Public side of the NAT would need a huge IPv4 Public pool. Replacing Private pool to something bigger is a very corner case. Mobile Carriers identify subscribers not by the IP, they could easy tolerate many overlapping 10/8 even on one Mobile Core. Huge private pool 240/4 is needed only for Cloud