Re: 165 Halsey recurring power issues

Willing to bet that there was slicing on both sides of that conversation and this is what I will now refer to as the expected and resulting razor burn. Babak Pasdar wrote: Thanks James, At signup we asked for N+1 power, two circuits to different UPS units. I think they sliced it thin by

Re: 165 Halsey recurring power issues

The building itself got into the action and their goal was to make a top notch facility focusing on central patch panel fiber cross connects. They started with half of the 9th floor originally called MMR-2 and continued with multiple spaces each bigger as it was quite successful. No raised

Re: SDN Internet Router (sir)

-------- *From: *"Mel Beckman" *To: *"Mike Hammett" *Cc: *"Joe Maimon" , "NANOG" *Sent: *Thursday, January 5, 2023 2:54:27 PM *Subject: *Re: SDN Internet Router (sir) Mike, I’m not sure I understand w

Re: SDN Internet Router (sir)

ttp://www.thebrotherswisp.com/> <https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> -------- *From: *"Joe Maimon" *To: *"Mike Hammett" , "Christopher M

southeast asia phillipines hong king singapore region inter-network vendor expert

Looking to consult with someone who has in depth knowledge and experience with the way things work over in the corner, trying to round the bases on a solution and not hit it out of the ballpark. Contact direct for less public details and arrangements, of course anything of legit public

Re: SDN Internet Router (sir)

Mike Hammett wrote: I'm not concerned with which technology or buzzword gets the job done, only that the job is done. Looking briefly at the couple of things out there, they're evaluating the top X prefixes in terms of traffic reported by s-flow, where X is the number I define, and

Re: SDN Internet Router (sir)

Lots of 1M tcam fib limits in older gear... So yeah, its the same problem, bigger numbers and still not solved in any sort of non-painful or expensive way. I think Ill explore the google path and paper on it again. Joe Mike Hammett wrote: Then please bless the world with the right way.

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

John Curran wrote: On Nov 22, 2022, at 9:09 AM, John Curran wrote: ... Interoperability isn’t insurmountable, but does take some investment of effort. One can imagine any number of techniques (e.g. flag day after which “production devices” on the Internet must support 240/4, or DNS

Re: Alternative Re: ipv4/25s and above

Jay Hennigan wrote: On 11/21/22 16:30, Joe Maimon wrote: IMNSHO, if such a proposal were to gain traction, by the time that gear capable of using 240/4 as unicast were to be widely deployed, IPv6-capable gear would be much more widely deployed. Considering that is already

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

David Conrad wrote: How trivial would the change be in a product by a company that no longer exists or a product line that is no longer supported? Will Microsoft update all previous versions of Windows? Will the myriad of deployed embedded systems sitting forgotten in closets be updated?

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

David Conrad wrote: Barry, On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote: We've been trying to get people to adopt IPv6 widely for 30 years with very limited success According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

Lincoln Dale wrote: On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon <mailto:jmai...@jmaimon.com>> wrote: Indeed that is exactly what has been happening since the initial proposals regarding 240/4. To the extent that it is now largely supported or available across a wid

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

Eric Kuhnke wrote: Assume the following theoretical scenario: You have a large number of existing RIPE, ARIN, APNIC ASes which will take any ipv4 resources they can get. They're all on waiting lists or have been informed no new blocks will be forthcoming. 240/4 is something like 256

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

John Curran wrote: On Nov 21, 2022, at 7:18 PM, Joe Maimon wrote: … Further, presentment of options in this fashion presumes that we have some ability to control or decide how engineering efforts across the entirety of the internet should be spent. Joe - In the snippet above you

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

Eric Kuhnke wrote: In a theoretical scenario where somebody was global benevolent dictator of ipv4 space, even applying a policy which limited block size to a few /14 per ISP, it would be possible to exhaust 240/4/in one week/ if they handed out /14 sized pieces to every existing last mile

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

David Conrad wrote: Barry, On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote: We've been trying to get people to adopt IPv6 widely for 30 years with very limited success According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

Eric, I appreciate your willingness to actual consider this rationally. Every facet of this debate has been fully aired on this forum (and others), numerous times. Allow me to pick it apart again. Apologies to those who are ad nausem. Eric Kuhnke wrote: Option A) Spend engineering time and

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

Eric Kuhnke wrote: Quite simply, expecting the vast amount of legacy ipv4-only equipment out there in the world that is 10, 15, 20 years old to magically become compatible with the use of 240/4 in the global routing table is a non viable solution. It is not a financial reality for many

Re: ipv4/25s and above

Mark Tinka wrote: On 11/17/22 19:55, Joe Maimon wrote: You could instead use a /31. We could, but many of our DIA customers have all manner of CPE's that may or may not support this. Having unique designs per customer does not scale well. its almost 2023. /31 support is easily

Re: ipv4/25s and above

Mark Tinka wrote: For our DIA/Enterprise business, we offer customers a /30 for p2p link, and a /29 as initial standard for onward assignment within their LAN. You could instead use a /31. Or private/enterprise-private or unnumbered and route them the single /32 to use for their NAT on

Re: Scanning the Internet for Vulnerabilities

Matt Palmer wrote: On Mon, Jun 20, 2022 at 02:18:30AM +, Mel Beckman wrote: When researchers, or whoever, claim their scanning an altruistic service, I ask them if they would mind someone coming to their home and trying to open all the doors and windows every night. If there were a few

Re: V6 still not supported

Jared Brown wrote: JORDI PALET MARTINEZ via NANOG wrote: 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

Re: V6 still not supported

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

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

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

Matthew Petach wrote: Unfortunately, the reason crazy-long prepends actually propagate so widely in the internet core is because most of those decisions to prefer your peer's customers are done using a relatively big and heavy hammer. IOW if your peer or customer has prepended 5 times or

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

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

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

Joe Provo wrote: On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote: :) probably the longest prepend in the world. A thought though, is it breaking any standard or best practice procedures? That said, prepending pretty much anything more than your current view of the Internet's

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

e to admit it and learn from their mistakes. Joe On Wed, Mar 30, 2022 at 12:18 PM Joe Maimon <mailto:jmai...@jmaimon.com>> wrote: Owen DeLong via NANOG wrote: > > Well… It’s a consensus process. If your idea isn’t getting consensus, > then perhaps it

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

Owen DeLong via NANOG wrote: What you’re really complaining about is that it’s been virtually impossible to gain consensus to move anything IPv4 related forward in the IETF since at least 2015. Well… It’s a consensus process. If your idea isn’t getting consensus, then perhaps it’s simply

Re: A straightforward transition plan (was: Re: V6 still not supported)

Philip Homburg wrote: It should be clear that an IPv4-only host only speaks IPv4. This means that communication with an IPv4-only host has to be IPv4. This did not have to be true, had there been an extension/option standardized at the same time as IPv6 for IPv4 packets to be gateway'd

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

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

Owen DeLong wrote: You may be right about not being worth it. More importantly, you may be wrong. IPv6 is replete with not only a plethora of wrong predictions, but the same ones over and over again. To be clear, the only effort asked from the unwilling is to support cutting the red tape

Re: V6 still not supported

Michael Thomas wrote: On 3/24/22 3:13 PM, Owen DeLong wrote: On Mar 24, 2022, at 14:46 , Michael Thomas wrote: On 3/24/22 1:59 PM, Owen DeLong via NANOG wrote: Home users aren’t the long tail here. Enterprise is the long tail here. Android phones are, indeed, part of the enterprise

Re: V6 still not supported

Owen DeLong wrote: On Mar 24, 2022, at 03:36 , Joe Maimon wrote: In my view that takes the form of a multi-pronged strategy. Do what it takes to keep IPv4 as usable as possible for as long as possible. I think this isn’t so much preempting the vacuum as trying to pretend we can

Re: V6 still not supported

Mark Delany wrote: On 23Mar22, Owen DeLong via NANOG allegedly wrote: I would not say that IPv6 has been and continues to be a failure Even if one might ask that question, what are the realistic alternatives? 1. Drop ipv6 and replace it with ipv4++ or ipv6-lite or whatever other protocol

Re: V6 still not supported

Mark Delany wrote: On 24Mar22, Greg Skinner via NANOG allegedly wrote: straightforward transition plan in-hand working transition strategy nor a straightforward transition Any such "transition plan" whether "working" or "straightforward" is logically impossible. Why anyone thinks such a

Re: V6 still not supported

Owen DeLong wrote: The goal of IPv6, IMHO, is to become the next lingua franca of the internet, eventually rendering IPv4 unnecessary except in small pockets of legacy support. Hey Owen, Indeed, having otherwise fallen short of the mark that is what remains. I agree that has not yet

Re: V6 still not supported

John Curran wrote: About two decades later, at the time of the IPv4 central free pool runout (Feb 2011), we had neither “clearly improved functionality” nor a straightforward transition plan for "transparent access between the IPv4 and IPng communities” – I do hope I was wrong about the

Re: V6 still not supported

james.cut...@consultant.com wrote: On 23 Mar 2022, at 1:34 AM, Joe Maimon <mailto:jmai...@jmaimon.com>> wrote: ... Since IPv6 was born of the effort to fix the upcoming address shortage visible at the time and to prevent and alleviate the resulting negative effects, the fact th

Re: V6 still not supported

Michael Thomas wrote: On 3/23/22 11:53 AM, Joe Maimon wrote: Michael Thomas wrote: IETF can't force people to adopt things, film at 11. They certainly can't control people's saltiness from something that happened 30 years ago. IPv6 is manifestly deployable for operators that want

Re: V6 still not supported

John Curran wrote: On 23 Mar 2022, at 1:34 AM, Joe Maimon <mailto:jmai...@jmaimon.com>> wrote: ... Since IPv6 was born of the effort to fix the upcoming address shortage visible at the time and to prevent and alleviate the resulting negative effects, the fact th

Re: V6 still not supported

Michael Thomas wrote: SIP won't displace all legacy PSTN any time soon. So it's a failure by your definition. And by your definition IPv6 was a failure before it was even born because the internet became popular -- something I'll add that nobody knew for certain when it was being

Re: V6 still not supported

Michael Thomas wrote: On 3/22/22 10:34 PM, Joe Maimon wrote: There is this other side: I'm dualstack, and I simply dont notice. Being in transition state indefinitely is not success. The other side is when you are v6 only and you dont notice. We arent there yet. Thats the failure

Re: V6 still not supported

George Michaelson wrote: Thats partly why I find a huge personal disconnect with "failure" -It hasn't failed the way DECnet failed. Far from it. Since IPv6 was born of the effort to fix the upcoming address shortage visible at the time and to prevent and alleviate the resulting negative

Re: V6 still not supported

b...@theworld.com wrote: We know we need to get rid of fossil fuel vehicles but electric cars, at least at this point, leave quite a bit to be desired like battery technology (materials needed, disposal, cost, electricity generation, etc.) Suppose syngas becomes economical. Who said we

Re: V6 still not supported

Pascal Thubert (pthubert) via NANOG wrote: Hi: IPv4 is 40 years old. IPv6 is 25 years old. In Internet time, both are old timers. 25 years to not achieve global domination opens the door to become obsoleted before it does. Pretty sure that would be more bad than good. The rest of the

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

John Levine wrote: It appears that Abraham Y. Chen said: C.Recently, we were made aware of the Int-Area activities. Attempts to reach the Group Chairs have not received any responses. D.I just received an Int-Area Digest Vol 199, Issue 14 requesting IETF to reactivate the

Re: Making Use of 240/4 NetBlock

Christopher Morrow wrote: On Sun, Mar 13, 2022 at 10:39 AM William Herrin <mailto:b...@herrin.us>> wrote: On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon mailto:jmai...@jmaimon.com>> wrote: > The true dilemma is that any amelioration of IPv4 scarcity may indee

Re: Making Use of 240/4 NetBlock

JORDI PALET MARTINEZ via NANOG wrote: Because it is a single Internet, and what we do in some parts of Internet will affect others? Because, at least in my case, I'm investing my efforts in what it seems to be the best in the long-term for the global community, not my personal preferences?

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

Saku Ytti wrote: What if many/most large CDN, cloud, tier1 would commonly announce a plan to drop all IPv4 at their edge 20 years from now? How would that change our work? What would we stop doing and what would we start doing? I cant see how it would change or do anything IPv6-related

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

Grant Taylor via NANOG wrote: I believe that talking about removing IPv4 in any capacity /now/ is a disservice to the larger conversation. We mostly agree. Except that there is a significant vocal portion of the IPv6 spectrum that would like to start obsoleting IPv4 now. I have my

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

Ca By wrote: Google’s number represents how many users reach it over ipv6. Given Google’s ubiquity in the usa, it is a fair barometer for the usa at large. Given google's popularity on handheld platforms, the users of which tend to be much less sensitive to IPv4 translation mechanisms

Re: V6 still not supported

b...@theworld.com wrote: I could offer a more philosophical assessment of IPv6 deployment. Perhaps we're there, we're doing fine. This is how it is going to go. It's out there, it works (glitches aside), those who want it use it tho they can't force others to use it so still need to

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

Tom Beecher wrote: The only way IPv6 will ever be ubiquitous is if there comes a time where there is some forcing event that requires it to be. Unless that occurs, people will continue to spend time and energy coming up with ways to squeeze the blood out of v4 that could have been used

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

Owen DeLong via NANOG wrote: One thing is for certain… If folks had put 0.10 as much effort into deploying IPv6 as has been put into arguing about whether or not ~17 /8s worth of IPv4 makes a meaningful difference to the internet as a whole, IPv4 would long since have become irrelevant as

Re: home router battery backup

Mark Tinka wrote: On 1/18/22 18:15, Joe Maimon wrote: Now how about some programming available so you can decide what thresholds and conditions remote start your genny which powers the rectifier which substitutes|augments the solar array? Any half decent battery inverters

Re: home router battery backup

Mark Tinka wrote: On 1/18/22 00:26, Jordan wrote: Wow, that's a nice program. Do you know what they keep the "reserve percentage" set to, the proportion of stored energy that will never be discharged for grid-support, but held back for island-mode use in case of an outage? I don't use

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

Jay Hennigan wrote: On 11/19/21 10:27, William Herrin wrote: Howdy, That depends on your timeline. Do you know many non-technical people still using their Pentium III computers with circa 2001 software versions? Connected to the Internet? There are lots of very old networked industrial

Re: Redploying most of 127/8 as unicast public

Max Harmony via NANOG wrote: On 21 Nov 2021, at 00.00, Joe Maimon wrote: There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you

Re: Redploying most of 127/8 as unicast public

Owen DeLong wrote: Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here. My right to attempt to discourage it by opposing proposed standards is exactly equal to your

Re: Redploying most of 127/8 as unicast public

Owen DeLong wrote: On Nov 20, 2021, at 19:11 , Joe Maimon wrote: Owen DeLong wrote: I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6

Re: Redploying most of 127/8 as unicast public

Owen DeLong via NANOG wrote: (snips for brevity and reply relevancy) This is a common fallacy… The real concept here isn’t “universal reachability”, but universal transparent addressing. Policy then decides about reachability. Think stateful firewall without NAT. No, NAT is not a

Re: Redploying most of 127/8 as unicast public

Owen DeLong wrote: I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

Tom Beecher wrote: The biggest impediment to IPv6 adoption is that too many people invest too much time and resources in finding ways to squeeze more blood from the IPv4 stone. Reverse that. IPv6 has impediments to adoption, which is why more time and resources are being spent to keep

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

Zu wrote: One anecdote (the non-technical grandma) illustrates a very real problem that would need to be addressed -- there are non-technical people (of all ages, if your concerned about ageism) which will need to implement technical changes for which they are not equipped with the skills

Re: Redploying most of 127/8 as unicast public

Owen DeLong wrote: LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of these qualities. And if we implement the proposal at hand, which as near as I can tell you are supporting, that changes. Having trouble following your

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

Nick Hilliard wrote: Joe Maimon wrote on 19/11/2021 14:30: Its very viable, since its a local support issue only. Your ISP can advise you that they will support you using the lowest number and you may then use it if you canall you may need is a single patched/upgraded router

Re: WKBI #586, Redploying most of 127/8 as unicast public

Owen DeLong via NANOG wrote: I don’t see the difference between 6 and 7 usable addresses on all the /29s in the world as actually making a significant impact on the usable lifespan of IPv4. Owen This idea gets better each time I think about it. The changes and support required would

Re: Redploying most of 127/8 as unicast public

Owen DeLong wrote: On Nov 17, 2021, at 21:33 , Joe Maimon wrote: And I think the basic contention is that the vast majority of 127/8 is not in use. Apples to oranges, indeed. This contention is provably false for some definitions of “in use”. Determining the extent of this would

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

Nick Hilliard wrote: John Gilmore wrote on 19/11/2021 01:54: Lowest address is in the most recent Linux and FreeBSD kernels, but not yet in any OS distros. lowest addresses will not be viable until widely supported on router (including CPE) platforms. This is hard to test in the wild -

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

Nick Hilliard wrote: John Gilmore wrote on 18/11/2021 19:37: There will be no future free-for-all that burns through 300 million IPv4 addresses in 4 months. this is correct not necessarily because of the reasons you state, but because all the RIRs have changed their ipv4 allocation

Re: Redploying most of 127/8 as unicast public

Fred Baker wrote: I have read through this thread, and you'll pardon me if it sounds like yet another rehash on yet another list. You might take a look at https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/, which responds to

Re: Redploying most of 127/8 as unicast public

Jonathan Kalbfeld via NANOG wrote: How much runway would a single /8 give us? Up to 65280 /24's becoming available through registrars would be quite welcome to lots of small organizations or startups. Is it worth the headache to gain a single /8 ? I support serious consideration be

Re: WKBI #586, Redploying most of 127/8 as unicast public

John R. Levine wrote: The only effort involved on the IETF's jurisdiction was to stop squatting on 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly be better used elsewhere by others who may choose to do so. The IETF is not the Network Police, and all IETF

Re: WKBI #586, Redploying most of 127/8 as unicast public

Dave Taht wrote: I am sad to see the most controversial of the proposals (127/16) > first discussed here. > > Try this instead? > > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ > > > in my mind, has the most promise for making the internet better in the

Re: WKBI #586, Redploying most of 127/8 as unicast public

Mark Andrews wrote: CIDR is much older than that and we still have to avoid .0 and .255 addresses in class C space. I use .0 all the time. Similarly for .0.0 and .255.255 for class B space and .0.0.0 and .255.255.255 for class A space. Getting everybody you want to contact and the path

Re: WKBI #586, Redploying most of 127/8 as unicast public

John Levine wrote: It appears that Joe Maimon said: For example https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 from 2008 which fell prey to the "by the time this is usable IPv6 will have taken over" groupthink. Objectively wrong. I will agree that your e

Re: Redploying most of 127/8 as unicast public

Mark Andrews wrote: On 18 Nov 2021, at 11:58, Joe Maimon wrote: Mark Andrews wrote: It’s a denial of service attack on the IETF process to keep bringing up drafts like this that are never going to be approved. 127/8 is in use. It isn’t free. There are so many things wrong

Re: Redploying most of 127/8 as unicast public

Mark Andrews wrote: It’s a denial of service attack on the IETF process to keep bringing up drafts like this that are never going to be approved. 127/8 is in use. It isn’t free. There are so many things wrong with this statement that I am not even going to try to enumerate them.

Re: Facebook post-mortems...

Mark Tinka wrote: So I'm not worried about DNS stability when split across multiple physical entities. I'm talking about the actual services being hosted on a single network that goes bye-bye like what we saw yesterday. All the DNS resolution means diddly, even if it tells us that DNS

Re: IPv6 woes - RFC

b...@uu3.net wrote: Well, I see IPv6 as double failure really. First, IPv6 itself is too different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine. IPv4 was extendable, with header

Re: Rack rails on network equipment

Andrey Khomyakov wrote: Hi folks, Happy Friday! Interesting tidbit is that we actually used to manufacture custom rails for our Juniper EX4500 switches so the switch can be actually inserted from the back of the rack (you know, where most of your server ports are...) and not be blocked

Re: IPv6 woes - RFC

Owen DeLong wrote: On Sep 23, 2021, at 13:26 , Joe Maimon wrote: I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty

Re: IPv6 woes - RFC

Owen DeLong via NANOG wrote: There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell. I don’t disagree, but a reversion to IPv4-only

Re: IPv6 woes - RFC

Baldur Norddahl wrote: On Mon, Sep 13, 2021 at 8:22 PM Randy Bush > wrote: real compatibility with ipv4 was disdained. the transition plan was dual stack and v4 would go away in a handful of years. the 93 transition mechanisms were desperate add-ons

Re: A crazy idea

Owen DeLong wrote: On Jul 29, 2021, at 14:06 , Joe Maimon wrote: t...@pelican.org wrote: On Monday, 19 July, 2021 14:04, "Stephen Satchell" said: The allocation of IPv6 space with prefixes shorter than /64 is indeed a consideration for bigger administrative domains li

Re: A crazy idea

t...@pelican.org wrote: On Monday, 19 July, 2021 14:04, "Stephen Satchell" said: The allocation of IPv6 space with prefixes shorter than /64 is indeed a consideration for bigger administrative domains like country governments, but on the other end, SOHO customers would be happy with /96,

Re: Anycast but for egress

Vimal wrote: (Unsure if this is the right forum to ask this question, but here goes:) From what I understand, IP Anycast can be used to steer traffic into a server that's close to the client. I am curious if anyone here has/encountered a setup where they use anycast IP on their

Re: Looking for transit with full table bgp cloud options

Joe Maimon wrote: Hey all, I am looking for some cloud services, that would support Transit and full table BGP to the cloud provided vm(s). I am specifically not referring to the various BGP private vpn routing/interconnect options available with the big guys. If anyone has any

Looking for transit with full table bgp cloud options

Hey all, I am looking for some cloud services, that would support Transit and full table BGP to the cloud provided vm(s). I am specifically not referring to the various BGP private vpn routing/interconnect options available with the big guys. If anyone has any suggestions or ideas I would

Re: De-bogonising 2a10::/12

Baldur Norddahl wrote: Hello What is the purpose of null routing bogons? As it is, my network being default free zone, traffic to bogons will be returned to sender with no route to host. The only way for me to send out traffic to bogons is if one my peers announces a bogon prefix. Even

Re: power to the internet

never had a power interruption at any site. The requirements here are 48 hours of backup by law. Telecom is declared to be part of emergency and defense, so they put in a requirement for resilience. Regards Baldur tor. 26. dec. 2019 11.33 skrev Joe Maimon <mailto:jmai...@jmaimon.

Re: power to the internet

Unless telecom infrastructure has been diligently changing out the lead acid battery approach at all their remote terminals, powered gpon, hfc and antennae plants will never last more than minutes. If at all. A traditional car has between a 100-200amp alternator @12volts How much generating

Re: Short-circuited traceroutes on FIOS

t -d 1.4.5.6 Tracing route to 1.4.5.6 over a maximum of 30 hops 115 ms 5 ms<1 ms 172.18.24.1 2 3 ms23 ms24 ms 192.168.2.33 3 3 ms 6 ms 3 ms 1.4.5.6 Trace complete. Joe Joe Maimon wrote: > Anyone have an idea

Re: Short-circuited traceroutes on FIOS

ms 5 ms<1 ms 172.18.24.1 2 3 ms23 ms24 ms 192.168.2.33 3 3 ms 6 ms 3 ms 1.4.5.6 Trace complete. Joe Joe Maimon wrote: Anyone have an idea why there are some destinations that on residential verizon fios here in NY area terminate right on first extern

Short-circuited traceroutes on FIOS

Anyone have an idea why there are some destinations that on residential verizon fios here in NY area terminate right on first external hop? There seems to be a CDN common denominator here. On other networks with more typical BGP paths and traceroutes, users are reporting issues accessing

Re: fuzzy subnet aggregation

Good news, bad news. With an inefficient bash script on an inefficient platform, 120k processes in less than 15minutes. Thus far, the best I have is less than 10% reduction with barely acceptable aggressiveness. The distribution is too varied or the level of aggressiveness has to be

  1   2   3   >