Re: Famous operational issues
On Tue, 23 Feb 2021 20:46:38 -0800, Randy Bush said: > maybe late '60s or so, we had a few 2314 dasd monsters[0]. think maybe > 4m x 2m with 9 drives with removable disk packs. > > a grave shift operator gets errors on a drive and wonders if maybe they > swap it into another spindle. no luck, so swapped those two drives with > two others. one more iteration, and they had wiped out the entire > array. at that point they called me; so i missed the really creative > part. I suspect every S/360 site that had 2314's had an operator who did that, as I was witness to the same thing. For at least a decade after that debacle, the Manager of Operations was awarding Gold, Silver, and Bronze Danny awards for operational screw-ups. (The 2314 event was the sole Platinum Danny :) And yes, IBM 4341 consoles were all too easy to hit the EPO button on the keyboard, we got guards for the consoles after one of our operators nailed the button a second time in a month. And to tie the S/360 and 4341 together - we were one of the last sites that was still running an S/360 Mod 65J. And plans came through for a new server room on the top floor of a new building. Architect comes through, measures the S/360 and all the peripherals for floorspace and power/cooling - and the CPU, plus *4* meg of memory, and 3 strings of 2314 drives chewed a lot of both. Construction starts. Meanwhile, IBM announces the 4341, and offers us a real sweetheart deal because even at the high maintenance charges we were paying, IBM was losing money. Something insane like the system and peripherals and first 3 years of maintenance, for less than the old system per-year maintenance. Oh, and the power requirements are like 10% of the 360s. So we take delivery of the new system and it's looking pitiful, just one box and 2 small strings of disk in 10K square feet. Lots of empty space. Do all the migrations to the new system over the summer, and life is good. Until fall and winter arrive, and we discover there is zero heat in the room, and the ceiling is uninsulated, and it's below zero outside because this is way upstate NY. And if there was a 360 in the room, it would *still* be needing cooling rather than heating. But it's a 4341 that's shedding only 10% of the heat... Finally, one February morning, the 4341 throws a thermal check. Air was too cold at the intakes. Our IBM CE did a double-take because he'd been doing IBM mainframes for 3 decades and had never seen a thermal check for too cold before. Lots of legal action threatened against the architect, who simply said "If you had *told* me that the system was being replaced, I'd have put heat in the room". A settlement was reached, revised plans were drawn up, there was a whole mess of construction to get ductwork and insulation and other stuff into place, and life was good for the decade or so before I left for a better gig
Re: DoD IP Space
On Mon, 15 Feb 2021 10:51:51 -0800, Sabri Berisha said: > Well, considering this RIPE article that talked about IPv7 already.. > > https://lists.ripe.net/pipermail/ripe-org-closed/1993/msg00024.html Bonus points for those who remember/know where v5 and v8 were from :) pgpdrYkPJgCF0.pgp Description: PGP signature
Re: DoD IP Space
On Sun, 14 Feb 2021 22:25:56 -0800, William Herrin said: > This particular problem could be quickly resolved if the OSes still > getting updates were updated to default name resolution to prioritize > the IPv4 addresses instead. That would allow broken IPv6 > configurations to exist without breaking the user's entire Internet > experience. Which would allow them to leave it turned on so that it > resumes working when the error is eventually found and fixed. Oh, come on Bill. This ain't your first rodeo. You know damned well that if we do that, the errors are in fact *not* eventually found and fixed. In addition, if you do that, even once the error is fixed, the box will not know about that and will continue to use the IPv4 addresses.
Re: DoD IP Space
On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said: > Please explain to me how you uniquely number 40M endpoints with RFC-1918 > without running out of > addresses and without creating partitioned networks. OK.. I'll bite. What network design needs 40M endpoints and can't tolerate partitioned networks? There's eyeball networks out there that have that many endpoints, but they end up partitioned behind multiple NAT boxes. pgp05Fm5NZrWe.pgp Description: PGP signature
Re: DoD IP Space
On Fri, 05 Feb 2021 17:25:34 -0800, Doug Barton said: > I am genuinely curious, how would you explain the problem, and describe > a solution, to an almost exclusively non-technical audience who just > wants to get the bits flowing again? "The people who did Disney's software wrote it for the Internet protocols of last century, so it fails with this century's Internet. Adding insult to injury, the reason you even notice a problem is because it reacts badly to the failure, because it doesn't even include *last* century's well-known methods of error recovery". pgphNxdmn5BHj.pgp Description: PGP signature
Re: DoD IP Space
On Thu, 21 Jan 2021 11:07:42 -0800, Sabri Berisha said: > Financial incentives also work. Perhaps we can convince Mr. Biden to give a > .5% > tax cut to corporations that fully implement v6. That will create some bonus > targets. And how would you define "fully implement v6", anyhow? Case in point: I helped deploy v6 at my employer *last century*, and the entire network was (last I knew) totally v6 ready, and large segments were v6-only. Yet Google *still* says that only 80% or so traffic to them are via v6. The other 20% being end-user devices that aren't using v6 for one reason or another - I'm pretty sure that a lot of those are because companies have told the user to "turn off ipv6" to solve connection problems, and I know that a lot of them are gaming consoles from a vendor that had a brief shining chance to Get It Right on the last iteration(*) but failed to do so And when I retired, I had several clusters of file servers that weren't doing IPv6 because a certain 3-letter vendor who *really* should have been more on the ball didn't have v6 support in the relevant software. Even more problematic: What do you do with a company that's fully v6-ready, but still has several major interconnects to other companies that *aren't* ready, and thus still using v4? (*) The PS4 has ipv6 support in the OS - it will dhcpv6 and answer pings from on and off subnet. However, they didn't include ipv6 support in the development software toolkit, so nothing actually uses it. They appear to have fixed this in the PS5, but that still hits the "other company isn't ready" issue. pgpciOB0nPGnp.pgp Description: PGP signature
Re: Parler
On Wed, 13 Jan 2021 18:41:55 -0500, Matt Corallo said: > In case anyone thought Amazon was being particularly *careful* around their > enforcement of Parler's ban...this is from > today on parler's new host: > > $ dig parler.com ns > ... > parler.com. 300 IN NS ns4.epik.com. > parler.com. 300 IN NS ns3.epik.com. > ... > ns3.epik.com. 108450 IN A 52.55.168.70 It's quite possible that Amazon is playing this *entirely* by the book, and the Parler crew haven't violated the terms of the nameserver hosting agreement so Amazon hasn't cut that off. pgp0i8q7FGMwX.pgp Description: PGP signature
Re: Parler
On Sun, 10 Jan 2021 18:08:24 -0500, Izaac said: > demonstrated consistently different behavior between them, i.e. the > @potus account is used for official communications and @realdonaldtrump > for personal communications with the public. The former is indeed How does that square with the White House Press Secretary's statement (never walked back as far as I know) that @realdonaldtrump tweets were official government policy statements? pgp8E_1wQ3U1l.pgp Description: PGP signature
Re: WhatsApp's New Policy Has...
On Fri, 08 Jan 2021 14:10:41 -0600, Richard Porter said: > I missed that... *he says as he deletes Keybase* Hopefully not before you told your Keybase contacts where you were going. :) pgpytCcsAjPkH.pgp Description: PGP signature
Re: Show NOCs: OIG report: Should you charge extra for NOC tours?
On Thu, 07 Jan 2021 23:35:06 +, "Jay R. Ashworth" said: > > From: "Brandon Svec" > > It is not really different than most other tourist attractions. Some are > > amazed > > and curious to see the largest ball of twine > Those would be people who *don't* do this for a living, mostly... > > and some think it is > > ridiculous. > Those would be people who *do* this for a living, mostly. I could go "meh" about a NOC tour itself. On the other hand, I can think of a number of providers where buying the right person a beer would be significantly enlightening. :) pgpRMmw8ZUOqE.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Tue, 05 Jan 2021 15:48:47 -0500, b...@theworld.com said: > How much faster? If it took one minute of battery life off a 10 year > battery would that be a problem? 30 minutes? I suspect the proper time units are closer to months rather than minutes. > How much power would a bit of circuitry waiting for a "turn on! there's a new > message coming in!" need? You also need a much larger bit of circuitry for frequency decoders, speakers and all the rest of it, and *most* of it has to be on all the time in order to detect that there's a new message coming in. It's going to cost a lot more energy-wise to monitor a frequency continuously than what's monitored inside a smoke alarm. Can you point at NOAA weather alert radio that has a 10 year battery in it? Because you're going to need pretty much the same circuitry if you're trying to cram all this into a smoke alarm. pgp4QSi8_Vy9H.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Mon, 04 Jan 2021 15:33:10 -0500, b...@theworld.com said: > Why wouldn't we just build this into 10-year battery smoke alarms, a > simple radio receiver? First, that means your smoke alarm batteries run down faster, which is a major issue. I didn't bother thinking past that show-stopper, others can do so if they wish... pgp3oaogdfVKJ.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, 03 Jan 2021 18:00:22 -0700, "Keith Medcalf" said: > This is the same thing I tell shithead politicians and pollsters that cause > my phone to ring. If you wish to speak with me then you can pay to install > your own communications equipment at your own expense. Um... Keith? Pretty much all of them *do* pay for their end of the communications equipment. The bigger question is why you pay for *your* end rather than insisting that everybody who wants to talk to you pay for your end. (Hint: Do you require that the annoying sister in law you don't want to hear from also install gear at their expense? Does the answer change if you usually want to hear from her but not today because reasons?) pgpArJK3hSV4B.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, 03 Jan 2021 09:26:07 +, Mark Foster said:' > Yeah my family got a PS4 for Christmas. But we've had an Xbox One for > the last few years. There are quite a few streaming apps, true. But a > lot fewer of those than worldwide telcos, or jurisdictions, or emergency > services. You missed the point - Hulu would *still* have to deal with every single jurisdiction or emergency service in a secure manner. But any given ISP doing business in a given county would only have to deal with a very small number - and the local sheriff's office would only have to notify the small number of providers actually providing access in the county. > So do you want the streaming service to deliver the alert, or do you > want the underlying device doing the streaming, to deliver the alert? > Because I think you've gone down a layer and didn't need to. How do you deliver the alert if the device is on but no streaming service is currently active? And for a lot of devices, that's the usual state of affairs. As far as I know, most people who have a Google or Alexa smart device have it on close to 24/7, but the devices aren't streaming media that much. That's why I think doing it at the streaming service level is one level too high. pgpdmSdJuOZe6.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, 03 Jan 2021 18:59:37 +1300, Mark Foster said: > In my mind it's simple.� The streaming companies need to have a channel > within their streaming system to get a message to a 'currently active > customer' (emergency popup notification that appears when their app is > open or their website is active with an authenticated user).� The Oh geez. Just on my PS4, there's streaming apps for Disney+, Netflix, Hulu, Prime, Playstation Store, Peacock, Tubi, ESPN+, AppleTV, YouTube (less than half of which I actually subscribe to, but I haven't found a big enough crowbar to remove the others, they keep returning) - and that's probably not a complete list. And we get to watch them all do it in subtly different ways, often buggy. Egads. Bonus points for figuring out how to keep two streaming apps from stepping on each other's toes, as often these apps stay semi-alive in the background, which may be enough to cause an alert to be sent to the app. Now you need to avoid a "thundering herd" problem if there's 18 different streaming apps on the device, all of which just got woken up. On resource constrained systems, that's often the start of a death spiral as the system either runs totally out of memory or goes into thrashing mode. And the alternative is just saying "only the streaming app in the foreground gets to handle the alert", but that isn't correct either - I might not *have* a streaming app running in the foreground on the device at the time the alert goes out. (You hit another problem as well - now all the apps have to notify upstream So having every single "streaming" app have to include duplicate code and *still* not get the alert to the user doesn't seem the right direction to go... > streaming company will also know the location of their customer (billing > information) so will know what geographic locations are relevant to that > customer. Billing info may be good enough for stuff that stays at home. It doesn't tell you what zip code a portable device is actually in at the moment - and getting the *right* localized info to the portable device is one of the tricky parts of this. If you're out and about town while visiting your in-laws 3 time zones away from where you live, you want alerts for the town your in-laws live, not for the address the streaming company sends the bill to. And that's assuming that a streaming company even *has* the info in their billing information - I just checked, and Hulu doesn't have a street address for me. So they're going to end up having to do IP based geolocation. Meanwhile, this causes yet another problem - if Hulu has to be able to know what alerts should be piped down to my device, this now means that every single police and public safety agency has to be able to send the alerts to Hulu (and every other streaming company) - and do this securely. That's a *lot* bigger problem than "The Blacksburg VA police department only has to set up agreements with network access providers that might be providing access to devices in Blacksburg". Seriously guys - having the streaming companies do this is at the entirely wrong level. pgppzHA8EUtxt.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Fri, 01 Jan 2021 17:12:40 -0500, Matt Hoppes said: > How would that even work? Force a pop up into web traffic? That's not going to play nicely at all in a world of https:// > What if the end users is using an app on a phone? I'm having a hard time thinking of what app I could *possibly* be using on a phone where I wouldn't want an interruption for a tornado or active shooter alert. This was discussed in detail a while ago - I'm pretty sure the general consensus was that having the phone/game console/smart home control center/ whatever would be running an alert endpoint app that would talk to the ISP/ cellphone tower and register for alerts and then DTRT to notify the relevant carbon-based life forms. pgp5Q3cYZst40.pgp Description: PGP signature
Re: 10g residential CPE
On Mon, 28 Dec 2020 20:02:36 +, Mel Beckman said: > This means your staffing must be large enough to never have any queuing, or > youâre giving away your paying customers' time to non-paying customers. > Neither > approach is scalable in a competitive business environment, because SOMEBODY > is > paying for all those resources, and if itâs your customers, they will buy > elsewhere. Your approach only work until you run out of other peopleâs > money. I dunno. He's been doing it for 7 years, it sounds like it's sustainable in his environment. pgpihFY6TOwD8.pgp Description: PGP signature
Re: [External] Re: 10g residential CPE
On Sun, 27 Dec 2020 17:57:17 +0100, Baldur Norddahl said: > Here in the civilised world we bury the wires ;-) Even the long-haul 765kv and up connections across the power grid? In the US, they're out on towers for a reason - you can fly along them in a helicopter and easily spot parts of cable that are degrading and need repair because they glow brighter on an infrared scope... (Plus, as Hurricane Sandy taught Manhattan, buried wires have their own rather nasty failure modes) pgpaNvJePUX6d.pgp Description: PGP signature
Re: [External] Re: 10g residential CPE
On Sat, 26 Dec 2020 12:58:42 -0800, Michael Thomas said: > can go on for days. We have a generator because of this, but everybody > getting a generator in the middle of the Berkeley Hills would be > something of its own horror show, but it will probably come down to that. Egads. Especially if a lot of those generators are just bought at Home Depot and hooked up to the house wiring without a proper cutover switch for the mains. pgp3KpLpZtF4M.pgp Description: PGP signature
Re: 10g residential CPE
On Sat, 26 Dec 2020 17:50:28 +, Mel Beckman said: > If vendors saw a 10GbE CPE market, they would serve it. Obviously they donât > see a market. Why donât people insisting vendors build their hobby horse see > that? Itâs like theyâre being deliberately obtuse :) The number of people that want a router that does 10GbE is vastly outnumbered by the number of people that want a router that makes their Zoom sessions not suck. Admittedly, many of them don't realize they want that router, mostly because most of them don't realize it's not difficult at all to build one that does that. But that's why companies have an advertising and marketing team. :) pgpveTfXzA_oP.pgp Description: PGP signature
Re: 10g residential CPE
On Sat, 26 Dec 2020 00:32:49 -0500, b...@theworld.com said: > I suppose that depends a lot on what the actual prices of a flat-rate > 1gb vs a fully saturated 10gb. If it's $50 vs $100/mo perhaps some > would say ok I'll risk the $50 overage, if it's $50 vs $500/mo maybe > not. > > And today we have bandwidth-shaping in most any router/cpe (or could) > so even with the 10gb/metered someone in the house with the password > could rate-limit except when they needed it :-) Note that the vast majority of users either use the ISP-provided CPE, or something they picked up at Walmart or Best Buy. This leads to an interesting economic incentive problem. The ISP is obviously not motivated to supply kit that can do bandwidth shaping on a metered drop. Meanwhile, the providers of gear that gets sold at Walmart or Best Buy also have no motivation to add it until enough ISPs are providing metered high-speed service that "We can help prevent overage charges" becomes a viable market differentiation. Anybody got a feel for what percent of the third-party gear currently sold to consumers has sane bufferbloat support in 2020, when we've *known* that de-bufferbloated gear is a viable differentiatior if marketed right (consider the percent of families that have at least one gamer who cares)? pgpy2ZpJwQdKA.pgp Description: PGP signature
Re: The Real AI Threat?
On Thu, 10 Dec 2020 18:56:04 -0500, Max Harmony via NANOG said: > Programs have never done what you *want* them to do, only what you = > *tell* them to do. Amen to that - there was the time many moons ago when we launched a copy of a vendor's network monitoring system, and told it to auto-discover the network. It found all the on-campus subnets and most of the machines, and didnt seem to be doing anything else, so we all headed home. Come in the next morning, and discover that our 56k leased line to Nysernet (yes, *that* many moons ago) was clogged with the monitoring system trying to do SNMP probes against a significant fraction of the Internet in the Northeast. Things apparently went particularly pear-shaped when it discovered the MIT/Boston routing swamp... And of course, we *told* it "discover the network", when we *meant* "discover the network in this one /16.". Fortunately, it didn't support "discover the network and perform security scans on machines" - but I'm sure there's at least one security-scanning package out there that makes this same whoopsie all too easy to do, 3+ decades later... pgpCSjE5gzAPG.pgp Description: PGP signature
Re: AFRINIC IP Block Thefts -- The Saga Continues
On Tue, 17 Nov 2020 10:02:01 -0800, Jay Hennigan said: > In the old days on the NANAE newsgroup, such bogus threats of legal > action were categorized as one calling their "cartooney". People who > huff and puff and threaten to sue rarely do so. If someone actually > plans on suing you, your first hint is typically a knock on the door by > a process server, not repeated threats in an online forum. Right. The thing is that unless you're party to the lawsuit, you don't know if a process server has been involved. Somebody else replied by private email and pointed where the AfriNIC CEO wrote that they had, in fact, actually been sued. So whatever one might think of Elad Cohen, he's apparently not a cartooney. pgp43XmPOfBgS.pgp Description: PGP signature
Re: AFRINIC IP Block Thefts -- The Saga Continues
On Mon, 16 Nov 2020 09:22:33 +, Elad Cohen said: > Did I start legal proceedings with AfriNIC with conspiracy theories or with > facts and data? OK.. I'll probably end up regretting this, but... Is there any actual independently verifiable proof that legal proceeding have been started? pgpJDMI8IoFKd.pgp Description: PGP signature
Re: Telia Not Withdrawing v6 Routes
On Mon, 16 Nov 2020 17:36:58 -0800, Sabri Berisha said: > Also, in the case that I described it wasn't a Junos device. Makes me wonder > how bugs > like that get introduced. One would expect that after 20+ years of writing > BGP code, > handling a withdrawl would be easy-peasy. Handling a withdrawal is easy. Handling one correctly without race conditions when you're seeing withdrawals and additions from multiple bgp sessions concurrently, while also maintaining RIB and FIB consistency and keep forwarding customer packets is a little bit harder. pgpc7WPYbqNGy.pgp Description: PGP signature
Re: Virginia voter registration down due to cable cut
On Tue, 13 Oct 2020 17:11:53 -0400, Christopher Morrow said: > sorry I meant that: 1) yes clearly it's still the middle of > roadwork/backhoe season, 2) i'm surprised that a single path failure > for their production datacenter was enough to take the system offline. > 'spof' there meant: "Wow, a single point of failure in their outside > plant?" Given that back in 2010, they suffered a *disastrous* outage when a storage array failed and took multiple agencies with it https://www.computerworld.com/article/2515423/northrop-grumman-takes-blame-for-va--it-services-outage.html my reaction was more like Surprise, surprise, surprise... That one started when one storage array had a failed memory card, and the backup array encountered issues as well. There were a number of state agencies and universities that had fought for increased self-governance, and a *huge* part of that was "not be forced to outsource their internal IT to VITA", and those units were very glad they had won that fight pgpXflcrjyFc3.pgp Description: PGP signature
Re: Florida: Voter registration website overwhelmed at deadline
On Wed, 07 Oct 2020 22:10:07 -0700, "Constantine A. Murenin" said: > People act like 1.1 million requests per hour is a huge number. > > That's only 305 requests per second! > > Cheapest NVMe SSDs are capable of 160k+ IOPS. > > You can literally serve the whole thing from a single server on a > 100Mbps line, if you design it properly, and don't waste bandwidth on > stock images and silly front-ends. It isn't the stock images and silly front-ends that take all the effort. Those are pretty damned easy to serve up quickly. It's the twisty little maze of databases, all different. You asked for a driver's license number for ID? Well, that just bought you a call to the DMV's servers to check on the validity/status of that ID. Vetting the home address gets equally interesting, especially if it's a PO box or a "suite" at a mailbox-for-rent company. Vetting the existence of the last employer is going to take time as well. Are you going to get the unemployment system, the tax system, the DMV systems, and any others you need to talk to on this "one server"? Oh, and don't forget that the systems in the DMV and tax systems almost certainly have *other* systems they have to talk to Don't forget that these state agencies usually don't have the budget that Amazon or other large commercial organizations have, so you're looking at a *really* high chance that some server in the Department of Revenue isn't sized big/fast enough, so verifying the employer's existence hangs, so the front end hangs On top of all that, even if you're only a *little* bit too slow clearing requests, you end up sitting on a big pile of pending requests, which sucks up memory.. Get 305 requests per second, clear 304 per second, and in a few minutes you're throwing '502 Gateway Error' left right and center because things are wedged up pgpEpdF5UALvs.pgp Description: PGP signature
Re: Gaming Consoles and IPv4
On Sun, 27 Sep 2020 21:33:56 -0400, Daniel Sterling said: > It is true that I've yet to see any FPS game use ipv6. I assume that's cuz > they can't count on users having v6, so they have to support v4, and it > wouldn't be worth their while to have their gaming host support dual-stack. > just a guess there The Playstation 4's OS actually does support IPV6. I've been told that the big hold-up is that the kits sent to developers had libraries that didn't include the IPv6 sockets support, so no getaddrinfo() and friends, so developers couldn't code the support. Does anybody have info from Microsoft or Sony on what their new consoles are doing regarding IPv6? My informant has moved on and is out of the loop regarding the PS5's software innards. pgpKAXZMl3F4M.pgp Description: PGP signature
Re: SRv6
On Thu, 17 Sep 2020 18:24:36 +0200, Mark Tinka said: > On 17/Sep/20 17:56, mark seery wrote: > > Perhaps all the more reason why end-to-end encryption should be part of the > > buyer beware conversation (not arguing against operator encryption in saying > > that - privacy is something everyone in I[C]T has to think about today). > > If gubbermints mandate that l2vpn's and l3vpn's be encrypted, the cloud > bags will simply take over (not that they haven't, already). Are there any actual countries heading that way? Seems like most of them insist they have the ability to snoop unencrypted traffic (where "crypto that has a baked-in back door" counts as unencrypted). pgpwzdXuegf5e.pgp Description: PGP signature
Re: Ipv6 help
On Wed, 26 Aug 2020 18:42:14 +0200, JORDI PALET MARTINEZ via NANOG said: > The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 . Has anybody heard if they plan to fix that with the imminent Playstation 5? The PS4 OS will actually talk IPV6 far enough to DHCPv6 and answer pings from both on and off subnet, but none of the userspace does it because that API wasn't in the developer's kits at launch. pgp4TBzYh_Kka.pgp Description: PGP signature
Re: Has virtualization become obsolete in 5G?
On Fri, 07 Aug 2020 07:29:49 +0200, Mark Tinka said: > On 6/Aug/20 21:05, Christopher Morrow wrote: > > Isn't this just, really: > > 1) some network gear with SDN bits that live on the next-rack over > > servers/kubes > > 2) services (microservices!) that do the SDN functions AND NFV > > functions AND billing > > (extending IMS to the edge etc) > > I can already see how we are going to spend the next 10 years defining > this :-)... With research consultant reports tagging along every step of the way. :) pgplTTAoPAFMx.pgp Description: PGP signature
Re: questions asked during network engineer interview
On Thu, 23 Jul 2020 10:03:15 +0100, adamv0...@netconsultings.com said: > Hopefully well end up in a world where all checks one can do to figure out > why iBGP session is down along with suggested corrective actions will be coded > in some network self-healing workflow. /me places bets this concept re-surfaces as SDNv3. :) pgp6JQjIlh7Sz.pgp Description: PGP signature
Re: questions asked during network engineer interview
On Tue, 21 Jul 2020 23:04:30 +0200, Robert Raszuk said: > attempt to open innovation into networking ... allowing one to invent > protocols at will as well as setup forwarding tables with arbitrary All of which either get layered onto port 443 or you have to wait for your CGNAT vendor to provide an ALG for it. :) (I'll just note that I've seen almost no overlap between the SDN crew, and things like Google deciding to create and deploy QUIC. :) pgpXD_TFQuvU8.pgp Description: PGP signature
Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion
(re-adding Adam's text that didn't get quoted, but matters) On Wed, 08 Jul 2020 13:49:56 +0300, Saku Ytti said: > On Wed, 8 Jul 2020 at 13:46, Radu-Adrian Feurdean > wrote: > On Wed, Jul 8, 2020, at 00:09, Adam Thompson wrote: > > > Good luck with tunnelling LACP, no matter what boxes you have - LACP > > > has (de facto) hard jitter requirements of under 1msec, or you'll be > > > getting TCP resets coming out your ears due to mis-ordered packets. > > Errr sorry, but at the latest news, TCP was supposed to handle out of > > order packets and reorder them before sending them to upper layer. > Yes, however new reno and the like are tuned for practical Internet. > Practical Internet has lot more packet loss than reordering, so TCP > algorithm considers any amount of reordering a packet loss, causing an > immediate resend, destroying your performance. There's a difference between a TCP *resend*, and a *RESET*. Triggering a resend on a re-order is reasonably sane, sending an RST isn't pgpP8nAK8OtkD.pgp Description: PGP signature
Re: netflix proxy/unblocker false detection
On Fri, 26 Jun 2020 10:21:47 +0200, Mark Tinka said: > Sadly, PlayStation still don't support IPv6. Hopefully, it comes with > the PS5, although I see no reason why the PS4 and PS3 can't. The PS/4 will in fact dhcpv6 at startup, and it will answer pings from both on subnet and from elsewhere, and will properly hand you an RST when there's nobody listening on a TCP port, and a port unreachable for a UDP port. So it's very much a "lights are on but nobody's home" because nothing is using an IPv6 port. One big reason that PS4 doesn't use IPv6 is that although the OS supports it, the developer toolkit doesn't have that API in it, so no games or apps can use it without an incredible amount of pain and suffering. It wouldn't help games that want to talk to Playstation Network until Sony got *that* part working, but if the API was there at least things like the Netflix and Hulu and similar apps could use it pgpEx0LLWYFUs.pgp Description: PGP signature
Re: Contact at Ubiquiti Networks?
On Tue, 26 May 2020 21:53:55 +0200, Baldur Norddahl said: > Even the big guys like Juniper fail at basic functionality. Our brand new > MX204 fails to select the correct source address when doing ARP requests > and apparently that is a known will not fix. 1987 called and wants their bug back. Seriously, how does something *that* basic even make it out of the lab? pgpeYw74EwHOC.pgp Description: PGP signature
Re: Friday Reminder: Web Site Security
On Fri, 15 May 2020 12:15:13 -0700, "Ronald F. Guilmette" said: > This is your helpful Friday reminder to always pay close attention to > the security settings of all of the web sites under your administration. > Otherwise, anonymous skript kiddiez could show up at any moment and > deface one or more of your web sites. (It happens a lot.) Just this week, I have seen an (unconfirmed) report that there is an organized effort that's abusing SSH keys that lack passphrases - if they pwn a system and find one, they go surfing it as far as they can. And yes, I know that automated systems can't use passphrases.. so remember to check to see if you can use 'force-command=' in the known hosts file so that the key can only issue one command. (yes, this means that if the automation host has to do a dozen different things, it needs a dozen keypairs. Security is always tradeoffs.) 'ssh-keygen -H' also helps control things. pgpyxj1nakDYo.pgp Description: PGP signature
Re: RIPE NCC Executive Board election
On Wed, 13 May 2020 17:17:07 -, David Hubbard said: > LOL the IPv4+ thing was a pretty entertaining read. You clearly donât have > even a basic understanding of the v4 packet structure, or that the octet > display concept is simply for human benefit. IPv6 can be implemented with > âsoftware updatesâ too⦠Yes, it was quite the chuckle, approaching the IPv8 proposal and that guy who kept insisting that an octet was misnumbered and could represent 257 addresses... > From: NANOG on behalf of Elad Cohen > > Date: Wednesday, May 13, 2020 at 9:47 AM > To: "Ronald F. Guilmette" , "nanog@nanog.org" > > Subject: Re: RIPE NCC Executive Board election > > Hello Everyone, > My apology for not providing an official response to the first "The Ronald > Show" that took place here many months ago, I was out of hospital after full > anesthesia and it took me months to get back to myself. I'm pretty sure Elad should have used this next part for backing up his assertion that he was totally out of it during April. Because he's doing a really good job here of demonstrating that he doesn't understand how the Internet works well enough to qualify for a seat on the RIPE board: > When in reality I invented three new pantets for the best of the whole > Internet community and I will work to implement them if I will be elected: > > IPv4+ that will mitigate the "IPv4 Exhaustion" problem and will add more (...) > https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html > > Completely mitigating the global email spam problem in a clean and automatic > way: (...) > https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html > > Completely mitigating spoofed ip amplification DDoS attacks and spoofed ip > (...) > https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html > pgpNIVEs4cFUw.pgp Description: PGP signature
Re: RIPE NCC Executive Board election
On Wed, 13 May 2020 17:00:14 -0400, Jon Lewis said: > When you've convinced Cisco, Juniper, Arista, and a few other router > vendors to implement, and have submitted patches for the Linux kernel and > userspace to implement IPv4+ (good luck with all that...and expect to be > met with "Can we have some of what you've been smoking?"), then you can > start pushing your next gen IP concepts. Until then, it's a total > non-starter. At least when Dave Taht was pushing his "make the class E space usable", he had patches and testing for multiple systems. Turns out that not many systems check for 'first octet >= 240', but actually test for the class D space and using class E Just Works an amazing percent of the time (Yes, I was surprised myself, but deploying it is still very much in the "effort better spent deploying IPv6" territory...) pgpjih5Xpru8u.pgp Description: PGP signature
Re: An appeal for more bandwidth to the Internet Archive
On Wed, 13 May 2020 10:40:36 +0300, Denys Fedoryshchenko said: > What about introducing some cache offloading, like CDN doing? (Google, > Facebook, Netflix, Akamai, etc) > I think it can be rolled pretty quickly, with minimum labor efforts, at > least for heavy content. The thing is that if you're an 800 pound gorilla, you probably have enough things that would benefit from being cached to make it worthwhile. I'd expect that the Internet Archive is probably mostly long-tail hits with not much hot content. Has anybody modeled how much cache space would it take to significantly improve the bandwidth situation? pgp5Z4mdcbFov.pgp Description: PGP signature
Re: Abuse Desks
On Wed, 29 Apr 2020 11:25:19 -0400, sro...@ronan-online.com said: > Perhaps some organization of Network Operators should come up with an > objective standard of what constitutes âabuseâ and a standard format for > reporting it. > If only there was such an organization. A different organization beat you to it. 7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information. T. Takahashi, K. Landfield, Y. Kadobayashi. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7203) pgp2n9812g8Kx.pgp Description: PGP signature
Re: 24x7 vs 24x7x365 Re: Constant Abuse Reports / Borderline Spamming from RiskIQ
On Wed, 15 Apr 2020 22:06:52 -0700, Ben Cannon said: > I call our NOC â24x7x365â I hear that in my head as âtwenty-four > (hour) - BY > - Seven (days a week) - BY - 365 (days a year, indicating we donât close on > any holidays). x365 is fine, to distinguish from 24x7x360 operations that are running on autopilot on Thanksgiving, Christmas and New Year and such pgpcxn5E2m3PW.pgp Description: PGP signature
Re: The Cost of Paid Peering with Chinese ISPs
On Wed, 01 Apr 2020 20:58:17 -0700, Matt Corallo said: > If your goal is to force companies the world over to host domestically, where > they follow local licensing regimes (yes, including censorship, as well as > data > access), itâs highly effective. You missed the point. There's a distinction between "setting up conducive conditions" and "doing". Both may be morally problematic, but they're different things. Consider the US example of certain US companies who got caught giving the NSA a fiber connection at certain "interesting" points in the network - the legal exposure for the companies and for the intelligence agency were totally different. It's why our legal system recognizes the difference between committing a felony and being an accessory to the crime. We have *enough* trouble with people yelling "Censorship!" when Facebook or Quora or other social media sites owned by private actors enforce AUPs. Let's not let the word get further muddied into uselessness like "terrorism" has been over the last 2 decades. pgpynlcaNt4UE.pgp Description: PGP signature
Re: The Cost of Paid Peering with Chinese ISPs
On Wed, 01 Apr 2020 12:47:22 -0700, Matt Corallo said: > No one suggested it isnât censorship, youâre bating here. Not deploying > enough international capacity is absolutely a form or censorship deployed to > great avail - if international sites load too slow, you can skimp on GF > appliances! So.. who was being "censored" when a recent game release caused capacity problems and slow throughput for others? Censorship, *by definition*, is content-dependent. Capacity issues are either byte-count or packet-count dependent, and don't distinguish between pictures of huge rubber duckies in Tiananmen square, and pictures of Mount Kilimanjaro. pgpbQqu0qreQ8.pgp Description: PGP signature
Re: Sunday traffic curiosity
On Sun, 22 Mar 2020 13:17:59 -0600, Grant Taylor via NANOG said: > As someone who 1) wasn't around during the last Internet scale foray > into multicast and 2) working with multicast in a closed environment, > I'm curios: > > What was wrong with Internet scale multicast? Why did it get abandoned? It failed to scale for some of the exact same reasons QoS failed to scale - what works inside one administrative domain doesn't work once it crosses domain boundaries. Plus, there's a lot more state to keep - if you think spanning tree gets ugly if the tree gets too big, think about what happens when the multicast covers 3,000 people in 117 ASN's, with people from multiple ASN's joining and leaving every few seconds. pgpAD8OWKMaNy.pgp Description: PGP signature
Re: COVID-19 vs. our Networks
On Tue, 17 Mar 2020 11:43:45 -0600, "Keith Medcalf" said: > And before you ask, I get "important news" directly. I'm glad to hear you're someplace on the planet where covid-19 doesn't count as important news. Hopefully the news will arrive to you directly before the virus does. pgp1W4vwcfEXk.pgp Description: PGP signature
Re: COVID-19 vs. our Networks
On Thu, 12 Mar 2020 18:08:05 -0600, "Keith Medcalf" said: > I don't know but we just issued travel restrictions to the United States > as it is now a Hot Spot for the unrestricted spread of the coronavirus > which causes COVID-19. Hopefully they're more sensible restrictions than the US policy that prohibits travel from most of Europe except the UK... but only for foreigners. If you're a US citizen, you're still perfectly welcome to go to Italy and come home with a few extra microbes to pass around a week after you return. The word for anybody who designs a network firewall with that sort of logic is "pwned". Just sayin'. (Fortunately, I'm in a position to hide in my apartment and only emerge for grocery shopping at 2AM until things wind down... Hope everybody else has a good contingency plan) pgpbbsURAhaU5.pgp Description: PGP signature
Re: Chairman Pai Proposes Mandating STIR/SHAKEN To Combat Robocalls
On Sun, 08 Mar 2020 17:17:37 -0400, b...@theworld.com said: > Which primarily leaves the question of why this Kabuki theater by the > FCC et al pretending as if it's some vast, uncontrollable evil like > the corona virus etc.? Because even in today's climate of regulatory capture posing as proper oversight, there's a limit to just how blatant they can be in public before people start saying "Geez, get a room already". pgpkPplNyHswx.pgp Description: PGP signature
Re: China’s Slow Transnational Network
On Sun, 01 Mar 2020 21:00:05 -0800, Pengxiong Zhu said: > There are a few things noteworthy regarding the phenomenon. First of all, > all traffic types are treated equally, HTTP(S), VPN, etc., which means it > is discriminating or differentiating any specific kinds of traffic. This sentence is missing a 'not'. However, I can't tell if it's "not treated equally" or "not discriminating" pgpfNu52qo1O3.pgp Description: PGP signature
Re: ATT Microcell in Austin, TX
On Sun, 16 Feb 2020 16:57:24 -0600, Chris Boyd said: > Since people on here like to talk about the generatorn run time on cell > towers, I thought yâall might like to see an ATT microcell in downtown > Austin, > TX. No apparent generator or battery on it. > https://imgur.com/a/RY9Tg7h Looks to me like a mostly shared-fate design with the traffic signal it appears to be attached to. All depends on what ATT risk management thinks in that situation. They may have decided that sticking a 10-minute battery in the base of that thing is good enough. pgp_HwJXDraJJ.pgp Description: PGP signature
Re: akamai yesterday - what in the world was that
On Thu, 13 Feb 2020 09:39:09 -0800, Ahmed Borno said: > The thread started with bandwidth surges and now power hogging is > mentioned, I wonder what else might happen as a side effect to a small > number of console/gaming companies not taking a direct responsibility in > how they release large updates in a way that is not organized or scheduled > but is rough and abrupt. And I'd not expect it to improve - many of the game producers are leaving the "incremental patch" mode to a "just ship the current image of the whole damned thing", because for them it's cheaper to just push out a single updated image than try to build different images for upgrading from different current levels. After all - it's not like *they* are going to feel the pain of a single 106G upload, it's somebody else who feels the pain of 5 million downloads of a 106G image refresh. Economists call this sort of thing an "externality". pgp2UX7WmfpRk.pgp Description: PGP signature
Re: Prominent horse racing identities (was Re: Elad Cohen)
On Mon, 27 Jan 2020 07:10:02 +, Large Hadron Collider said: > As much as Mr Cohen's minor libel of Spamhaus and ARIN exposes him as perhaps > having something to hide on this subject, Mr Guilmette's message here, among > the other screeds of his I have read, seems to leak anti-Semitism from its > every fetid, infected pore. Man, that must be one really high-frqequency dog whistle, because I'm not seeing it. The closest I can come is the statement that "Cohen sits in impunity in Israel", which combined the next part about him having a US based lawyer, only indicated to me that getting the US legal system to get the Israel legal system to do something is difficult. And tagging on "every fetid, infected pore" certainly demonstrates that you don't have any real intention of being fair-minded. List management: I think we have a good candidate for somebody to be frog-marched to the exit. pgp31rD4Xy46l.pgp Description: PGP signature
Re: akamai yesterday - what in the world was that
On Fri, 24 Jan 2020 08:55:12 -0600, "Aaron Gould" said: > Thanks Jared, When I reminisce with my boss he reminds me that this telco/ISP > here initially started with a 56kbps internet uplink , lol I remember when a "gateway" was a Microvax II with an ethernet card and a bisync card, and fuzzballs were the big thing, and the other end of your connection was either Arpanet or Milnet, and RFCs specified octects for a reason pgp52sAiFUVQr.pgp Description: PGP signature
Re: akamai yesterday - what in the world was that
On Thu, 23 Jan 2020 17:13:15 +0100, Bryan Holloway said: > Game releases are hardly a new thing, but these last two events seem to > be almost an order of magnitude higher than what we're used to (at least > on our predominantly eyeball network.) > > Any thoughts from the community? We're taking steps to accommodate, but > from a capacity-planning perspective, this seems non-linear to me. Be prepared for an entire new world of hurt this holiday season. Sony has already confirmed that PS5 releases will ship on 100Gbyte blu-ray disks. Which means that download sizes will be comparable... pgpnh34uf9O1n.pgp Description: PGP signature
Re: FCC proposes $10 Million fine for spoofed robocalls
On Fri, 20 Dec 2019 00:14:33 -0800, Large Hadron Collider said: > Is it legally a spoofed robo-call if I robo-call someone who has > consented to be robo-called, with the caller-ID of a number that is > affiliated with me but not with the telco I'm calling from? Every 8 weeks, the vampires at the American Red Cross call me to schedule another blood donation, and I'm sure that the number on my caller-ID isn't the actual phone number attached to the specific seat at the call center. And I'm pretty sure that until I answer the call, there's no really good way to distinguish between a robo-call with a recorded message and a robo-dialed call with an actual carbon-based lifeform at the call center on the call... (If I'm wrong on that one, feel free to enlighten me.. :) pgpgLCWaxCcdR.pgp Description: PGP signature
Re: FCC proposes $10 Million fine for spoofed robocalls
On Thu, 19 Dec 2019 16:02:42 -0700, "Keith Medcalf" said: > That stupid people do stupid things has no bearing on me. If there is a > legal requirement for these people to be "notifying" then they are required to > notify. > I do not want to receive robocalls period. End of Line. No Exception. > Ever. For any reason. So... what do you recommend if it's a legally mandated robocall that says "shelter in place - active shooter" or "tornado alert"? pgpyacpY95WDK.pgp Description: PGP signature
Re: FCC proposes $10 Million fine for spoofed robocalls
On Thu, 19 Dec 2019 13:59:00 -0800, Jeff Shultz said: > I've occasionally thought that a tactical air strike on a couple of > call centers might just convince the others of the errors of their > ways. Having a US-owned A10 strafe a Philippines-based call center is probably a bad idea diplomatically. However, we're in an administration that doesn't avoid ideas simply because they're objectively bad, so I'm not going to predict it won't happen pgpdPBgN_GOd7.pgp Description: PGP signature
Re: Software Defined Networks
On Thu, 12 Dec 2019 18:47:29 -0800, Large Hadron Collider said: > Tcl still exists, though I don't think they use it for this anymore. At least on Fedora, expect 5.45.4 is linked against libtcl8.6.so. pgpW5_X20d9ag.pgp Description: PGP signature
Re: Short-circuited traceroutes on FIOS
On Wed, 11 Dec 2019 19:26:09 +0200, Saku Ytti said: > On Wed, 11 Dec 2019 at 19:14, Rob Foehl wrote: > > > Support claims that it was a mistake, but it's also been 15+ months and > > it's pretty deliberate behavior. Draw your own conclusions... > > TTL decrement issues are fairly common across multiple vendors and hw, > can be sw can be hw limit Yes, but you need to screw up gloriously on the decrement if you think that "I decremented and it's zero now" means "therefor it must have been addressed to me, so I'll send an ECHO REPLY instead of TTL EXCEEDED". pgpmaeuPEyxyP.pgp Description: PGP signature
Re: Elephant in the room - Akamai
On Thu, 05 Dec 2019 14:18:07 -0800, Michael Thomas said: > My suspicion is that the root problem was buffer bloat -- i flashed a > new router with openwrt and was a little dismayed that the bufferbloat > code is a plugin you have to enable. The buffer bloat got a lot better Friends don't let friends run factory firmware. :) Hopefully sometime soon the SQM stuff will be added to the default openwrt configs for most of the supported routers, if it hasn't been already. It's been in my config since before the Luci support for SQM got created The big problem is that a lot of eyeball networks have a lot of CPE boxes that were created before the bufferbloat work was done, and often have no real motivation to push software updates to the CPE (if they even have the ability), and a lot of customers have routers that they bought at Best Buy or Walmart that will *never* get a software update. (I also admit having no idea what percentage of the intermediate routers in the ISP's networks have gotten de-bloating code. pgpipUcFxDede.pgp Description: PGP signature
Re: Elephant in the room - Akamai
On Thu, 05 Dec 2019 14:41:30 -0600, "Aaron Gould" said: > Tarko. wow, gaming again ! It's not going away. gaming traffic is growing > in a big way it seems. And it's only going to get worse. Sony has already announced that the Playstation 5 will have a (probably) 1-2 terabyte SSD. And even with that, the game packaging is set up to support only downloading the single-player or multi-player portions of a game because images are going to be pushing 100 gigabytes RSN (some are already well over 40gig). So even with the download restructuring, we're probably going to be seeing a lot of people downloading lots of gigabytes on Day 1 (or a few days before, for games that support it), and re-downloading smaller (but still large) amounts when they want to re-play the game... pgpZd9dnF7KSd.pgp Description: PGP signature
Re: Software Defined Networks
On Wed, 04 Dec 2019 17:56:10 +, Rod Beck said: > Can someone explain what is all the fuss? SDN is like the latest telecom > craze but the articles do a poor job of explaining the advantages. I seek > concrete examples. It's called the "cycle of reincarnation". Way back when, a "router" was a Microvax-II with 2 network cards in it, and everything, down to the packet checksums, was done in software on the Microvax CPU. Then we got "routers" that did a lot of the stuff like checksumming in hardware. Then we went back to software for more advanced features, then the hardware got smart enough to do it. For a while, routers were doing IPv4 support in hardware, and the occasional IPv6 packet got tossed towards the CPU. (That was, of course, once they got smart enough to do something other than "compare first 4 bits == "0100", drop on not-equal". I think a few boxes didn't even check the first 4 bits and assumed that all packets started that way, and hilarity and hijinks ensued Lather, rinse, repeat multiple times over the past 4 decades. And now we're seeing "SDN" which just means "Now that the hardware is smarter and doing a lot of the stuff we used to do in software, the CPU has more free capacity and we can do new clever stuff in software that we couldn't do before". It's *NOT TRULY* a software-defined network. If it was, there wouldn't be any hardware support for checksumming etc, because the checksum to use would be done in software so it could be easily replaced if you had reason to use a different checksum algorithm. (Hint - it's as big a crock as "Software Defined Storage" - which just means that it's software doing things like the RAID, erasure encoding, and logical volumes rather than physical volumes, even though the logical volumes are usually really just RAID-0 concatenations of segments of physical volumes. Meanwhile, "software defined radio" really means "the physical hardware is flexible, and software is used to configure it in case you didn't want the standard channel frequencies in the 2.4 and 5ghz bands". pgpeythyrzz_W.pgp Description: PGP signature
Re: RIPE our of IPv4
On Tue, 03 Dec 2019 14:58:59 -0800, FREDERICK BAKER said: > I think he is saying that companies like Reliance JIO have started with a /22 > of IPv4 and a /32 (or more) of IPv6, As I said - you need IPv4 space to dual-stack. How does Reliance do this without any v4 address space? pgpZzt54PJqbb.pgp Description: PGP signature
Re: RIPE our of IPv4
On Wed, 04 Dec 2019 07:47:25 +1100, Mark Andrews said: > Why not use someone elseâs IPv4 addresses? Really. What is wrong with > using > someone elseâs IPv4 addresses if it achieves the need? As far as I can tell > nothing. Other than the fact that a /24 is being advertised out of one AS and it's part of some other AS's /14 and looks suspiciously like a hijack? And we currently don't deal well with identifying and preventing true hijacks and mess up false positives a lot of the time? pgpUBGTodN9bJ.pgp Description: PGP signature
Re: RIPE our of IPv4
On Tue, 03 Dec 2019 14:12:27 +1100, Mark Andrews said: > Email is often out sourced so you donât need your own IPv4 addresses for > that. > Then there is in the cloud for other services, again you donât need your > own IPv4 > addresses. Are you seriously trying to say "If you're a new company, there's no plausible reason for you to need your own IPv4 addresses, because there's no reason for you to have your own mail servers or web servers"? Because if it *were* true that people don't need v4 addresses so they can dual-stack, we wouldn't have a healthy market buying and selling v4 address space. pgpI6UkYlltNv.pgp Description: PGP signature
Re: RIPE our of IPv4
On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said: > > I believe that Dmitry's point is that we will still require IPv4 addresses > > for new > > organizations deploying dual-stack > > I think I understood what you meant, but not what you said. > If someone is dual stack, they are IPv6-capable and IPv4-capable. And they're going to need v4 addresses to be v4-capable, aren't there? A new corporation that's trying to spin up dual-stack is going to need 2 address allocations, a v4 and a v6. pgpcySEVj1r_i.pgp Description: PGP signature
Re: RIPE our of IPv4
On Sat, 30 Nov 2019 13:47:36 -0800, Matthew Kaufman said: > User apps prefer IPv6, Netflix stops, users complain And fallback to IPv4 fails to happen, why, exactly? pgphoWWsRXmVA.pgp Description: PGP signature
Re: RIPE our of IPv4
On Fri, 29 Nov 2019 23:26:04 -0500, Brandon Martin said: > definitely the lagging factor, here. I suspect it's at least partially > because high-ratio NAT44 has been the norm for enterprise deployments > for some time, and, among those who might otherwise be willing to > support first-class dual stack, many enterprise IT folks lack the > education to recognize the nuance between public addressing and > unfiltered public reachability of a given host. I suspect many of them > are already using IPv6 for LAN traffic without even realizing it given > Windows' penchant for doing so since Vista. Judging how long it took to (mostly) stamp out CLASSA/B/C nonsense, we're in for at least a decade of IPv6 firewalls that block all ICMP, plus whatever common IPv6 misconfigurations and misconceptions are out there (I was deploying this stuff literally last century, so I admit not knowing what people are screwing up currently). pgpwdX4RrpNns.pgp Description: PGP signature
Re: replaying captured traffic
On Tue, 26 Nov 2019 13:29:21 -0500, harbor235 said: > I am with you on the easy google fu, however, weeding through the > challenges and a real implementation I was hoping to leverage some > lessons learned and best practices. Well, it's going to depend a *lot* on why exactly you're doing the replay. Doing a replay for forensics, doing a replay for protocol/application correctness testing, and doing a replay for throughput test load generation are 3 very different things. pgpiXTcucXOFV.pgp Description: PGP signature
Re: RIPE our of IPv4
On Tue, 26 Nov 2019 06:46:52 +1100, Mark Andrews said: > > On 26 Nov 2019, at 03:53, Dmitry Sherman wrote: > > > >  I believe itâs Eyeball networkâs matter to free IPv4 blocks and > > move to v6. > It requires both sides to move to IPv6. Why should the cost of maintaining > working networks be borne alone by the eyeball networks? That is what is > mostly happening today with CGN. I believe that Dmitry's point is that we will still require IPv4 addresses for new organizations deploying dual-stack, and eyeball networks can more easily move a /16 or even bigger to mostly IPv6 and a small CGNAT address space than content providers can free up IPv4 addresses during the time that dual stack is still needed. pgpJWJYbH090t.pgp Description: PGP signature
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
On Tue, 19 Nov 2019 13:39:56 -0500, Tom Beecher said: > They are essentially equating 'business' with 'VPN provider'. Not at all surprised. Many moons ago, I had a Tor *relay* running on one machine in my home network, and Hulu decided that my connections from a *different* home machine were "VPN". Now, if I were running a Tor *exit* node, I'd be totally OK with them rejecting my non-Tor connections because they were NATed to the same outside IP address - but Hulu should never have seen any packets from the relay and if I *was* using a VPN I'd have a *different* IP address. Near as I could determine, they were screen scraping the list of Tor relays and conflating them with exit nodes. Never did figure out if it was stupidity or malice driving that. pgpzxIsEJcPBX.pgp Description: PGP signature
Re: Disney+ Streaming
On Tue, 12 Nov 2019 14:58:34 -0500, "Brian J. Murrell" said: > I guess the question is, will Disney content compel users who are not > already streaming to start streaming? I can foresee a lot of families subscribing to Netflix *and* Disney+ because neither one has all the content the family wants to watch. Has anybody seen a significant drop in total streaming traffic due to Netflix users jumping ship to Amazon/Hulu, or are consumers just biting the bullet, coughing up the $$, and streaming more total because across the services there's more stuff they want to watch? pgpswtN64dt8I.pgp Description: PGP signature
Re: all major US carriers received text messages overnight that appear to have been sent around Valentine's Day 2019
On Fri, 08 Nov 2019 11:23:17 -0800, Jared Geiger said: > What likely happened is that messages were queued on host to go out, SMPP > binds go down, queue fills up, host crashes. Then someone realizes the host > is down and brings it back up and the queue empties when the load is low. What I've seen happen more often than that: Server goes partly belly-up, queue fills up. Backup process runs, backing up the queue. (Optionally here: Reboot the server and lose the queue). Much later, the server hits another issue that requires recovering from backups - and they restore a truly ancient copy. I recently got a replay of a bunch of email messages from 2002. I admit not at all understanding what procedure failures (multiple) resulted in reloading a mail spool from 2002. pgpksv4F8soAg.pgp Description: PGP signature
Re: Russian government’s disconnection test
On Sat, 02 Nov 2019 14:49:58 -0400, Christopher Morrow said: > I think the disconnect idea is actually a good one... I don't know > that I want to DO IT, but :) it certainly seems like a reasonable > disaster recovery planning exercise :) (likely doing it is the only > way to really suss out the problems though) Some of us remember disconnecting the uplink when the Morris Worm first started wandering around, and then wondering how we were going to get news of the details so we could patch our boxen so it would be safe to reconnect the cable to the router As more systems moved to secure update distribution schemes with only allowing vendor-signed patches from https:// secured trusted sites, we may find ourselves in a similar "don't dare be only, but have to be to fix the problem" mess if a worm gets loose... (Yes, you can probably ACL the router. Not the sort of thing you want to be doing at oh-dark-thirty if you don't know what ACL is safe to use and you are cut off from a lot of info sources...) pgpVSEII1louV.pgp Description: PGP signature
Re: Request comment: list of IPs to block outbound
On Wed, 23 Oct 2019 09:09:05 -0600, Grant Taylor via NANOG said: > > Easing the operation of CGN at scale serves no purpose except stalling > > necessary change. It is like installing an electric blanket to cure the > > chill from bed-wetting. > > Much like humans can move passenter plains, even an electric blanket can > /eventually/ overcome cold wet bed. Unless somebody gets electrocuted first. pgp_uLaDlmrzf.pgp Description: PGP signature
Re: IP Geolocation
On Wed, 16 Oct 2019 12:50:17 -, Ryland Kremeier said: > >I believe we have found 1 customer that is infected with a botnet or malware. > I've dealt with plenty of botnets working as a repair technician in the past > but never had one change the public IP address of the user. Not entirely sure > what this would accomplish aside from making it much easier to detect. To detect that somebody isn't doing BCP38 filtering of their customers, you mean? :) pgpUmsKQcLcHE.pgp Description: PGP signature
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Fri, 11 Oct 2019 12:02:30 +0200, Warren Kumari said: > I haven't found the actual work that is being referenced here, and I > *am* quite skeptical based upon the title / premise -- but, I suspect > (well, hope) that this is just another instance of complex technical > material being munged by marketing / reporters into something > unrecognizable -- note that "This article was originally published by > the UMass News Office." > > Here is an abstract of one of Yang Song, Arun Venkataramani, Lixin > Gao's earlier papers: > "BGP is known to have many security vulnerabilities due to the very > nature of its underlying assumptions of trust among independently > operated networks. () I'm fighting *really* hard to try to avoid collapsing that abstract down to "We realized that malicious actors can force the occurrence of BGP wedgies". (I've seen far too many proposals in the last 48 hours from people who obviously never encountered section (4) of RFC1925...) pgph3KkPdSta2.pgp Description: PGP signature
Re: worse than IPv6 Pain Experiment
On Wed, 09 Oct 2019 17:43:00 -0400, b...@theworld.com said: > URLs are an obvious candidate to consider because they're in use, seem > to basically work to identify routing endpoints, and are far from a > random, out of thin air, choice. So explain in detail how a router gets from "URL" to "which interface to send the packet on". Include in your discussion how anycast works, and how to deal with things like www.google.com, which currently uses DNS and geolocation so not every host on the internet has the same view of what server(s) to contact. Problem example: My employer moved something from a 128.173/16 address to a 198.82/16 address without changing the name. How would your scheme address the fact that the routing may have changed, when the URL/hostname remains the same? Hint: If URLS or hostnames actually identified routing endpoints, we'd not have DNS. pgpDSR49wNpe0.pgp Description: PGP signature
Re: IPv6 Pain Experiment
On Wed, 09 Oct 2019 18:51:12 +0900, Masataka Ohta said: > Owen DeLong wrote: > > Yes, thanks for yet another condescending comment proving that > > you completely missed the point of my post. It's always a pleasure. > You should really feel indebted to me because it's not a pleasure > for me to answer questions having no valid points. Of course, if you missed the point, by definition you won't find any valid points. And yes, you *did* totally miss Owen's point, which was that not all ICMP packets contain port information. As another data point, enough IP options will push some or all of TCP or UDP header information out of the returned data. pgpQ1aD4sHRPq.pgp Description: PGP signature
Re: IPv6 Pain Experiment
On Tue, 08 Oct 2019 19:12:30 -, Nicholas Warren said: > Sweet deals, would you kindly share your vendor? Well, I just type "128G DIMM" into google, and the very first hit tells me that I can get a 128G DIMM for $1,398, that and 8 DiMM slots gets me to 1T just over $11K. If I have 16 DIMM slots like a decent server-class board should have, I can do 64G cards for $308 and I'm done for under $5k. I didn't dig further, because I already had evidence to support the claim: > It's not 1990 any more, a TB of RAM now costs a few thousand dollars > and is dropping rapidly (similar for fancy router RAM) > processor chips with 64 cores available practically off the shelf for > under $10K (32-core literally off the shelf, try any Microcenter), AMD 32-core Ryzen Threadripper is $1,799. Find a 2-socket motherboard and you're at 64 cores for well under $5K for the chipsets. https://www.newegg.com/amd-ryzen-threadripper-2990wx/p/N82E16819113541 pgphvPywfuB9w.pgp Description: PGP signature
Re: Update to BCP-38?
On Tue, 08 Oct 2019 11:53:33 -0600, "Keith Medcalf" said: > So while the cost of doing the thing may be near-zero, it is not zero. And in fact, there's more than just the costs of doing it. There's also the costs of having done it. Obfuscating your OpenSSH versions is a *really* good way to make your security scanners that flag backleveled systems fail to flag the systems. Which can cause a really uncomfortable conversation with the CIO about why the local newspaper's front page is running a story about how your organization got totally pwned via a backleveled OpenSSH on one cluster of 5 servers. pgpES4WWnZrxq.pgp Description: PGP signature
Re: IPv6 Pain Experiment
On Mon, 07 Oct 2019 03:03:45 -0400, Rob McEwen said: > Likewise for spam filtering - spam filtering would be knocked back to > the stone ages if IPv4 disappeared overnight. IPv6 is a spam sender's > dream come true, since IPv6 DNSBLs are practically worthless. Riddle me this: Why then have spammers not abandoned IPv4 and moved to IPv6 where we're totally powerless to stop their floods of spam? I'm tired of hearing the excuse "We can't move to IPv6 because then we couldn't stop the spam" - if that were true, then every organization that *has* moved to IPv6 would be drowning in spam. pgp308XuGGKjm.pgp Description: PGP signature
Re: IPv6 Pain Experiment
On Sun, 06 Oct 2019 17:47:24 -0400, b...@theworld.com said: > All a strictly IPv4 only host/router would need to understand in that > case is the IHL, which it does already, and how to interpret whatever > flag/option is used to indicate the presence of additional address > bits mostly to ignore it or perhaps just enough to know to drop it if > it's not implemented. So... how would a strict IPv4 router handle the case where 8.8.4.5.13.9/40 should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes because there's yet another peering war and nobody's baked a cake yet, so sending packets for either route to the wrong link will cause blackholing? pgpa4OOixbqzc.pgp Description: PGP signature
Re: Update to BCP-38?
On Sat, 05 Oct 2019 07:01:58 +0900, Masataka Ohta said: > One of a stupidity, among many, of IPv6 is that it assumes > links have millions or billions of mostly immobile hosts Can somebody hand me a match? There's a straw man argument that needs to be set afire here. pgp1MMtG4U3Ba.pgp Description: PGP signature
Re: Update to BCP-38?
On Fri, 04 Oct 2019 08:20:22 +0900, Masataka Ohta said: > As for requirements for IPv6 routers, how do you think about the > following requirement by rfc4443? 3 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed.. March 2006. (Format: TXT, HTML) (Obsoletes RFC2463) (Updates RFC2780) (Updated by RFC4884) (Also STD0089) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC4443) > rfc1812 says: 1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995. (Format: TXT, HTML) (Obsoletes RFC1716, RFC1009) (Updated by RFC2644, RFC6633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1812) I suppose you never considered that in the 11 years intervening, we decided that maybe things should be done differently. > IPv6 specification is fatally broken in various ways. Oddly enough, it doesn't seem to be fatally broken from where I am, or from where Google is, or from where Facebook is, or from where most of the cellphone companies are. You must have a different definition of "fatally broken" than the rest of us. pgpBf75WZkmZ4.pgp Description: PGP signature
Re: Update to BCP-38?
On Thu, 03 Oct 2019 15:28:30 -0600, "Keith Medcalf" said: > On Thursday, 3 October, 2019 11:50, Fred Baker > wrote: > > A security geek would be all over me - "too many clues!". > Anyone who says something like that is not a "security geek". They are a > "security poser", interested primarily in "security by obscurity" and > "security > theatre", and have no clue what they are talking about. Amen to that. If you've been pwned hard enough that vlan numbers are useful to the attacker, the fact the attacker knows your vlan numbers is the *least* of your problems pgpKSVtMGgvCY.pgp Description: PGP signature
Re: IPv6 Pain Experiment
On Thu, 03 Oct 2019 20:11:23 +0100, Alan Buxey said: > trivial-ish (these days) - you have so much choice...and eventually > decent routers doing SLAAC will finally be able to serve > other details such as DNS/time/etc via SLAAC - servers? give them Well... if you want that... > that gets me on to my small annoyance... /64 bit subnet masks for > local networks. really? ALL of that address space and then throw such Then using a /96 isn't going to work very well. You don't want SLAAC, /96's work just fine. pgp4Rt_y3Fp2A.pgp Description: PGP signature
Re: This DNS over HTTP thing
On Wed, 02 Oct 2019 01:55:13 -0600, "Keith Medcalf" said: > It is a common fallacy that TLS connections are authenticated. The vast > majority of them are not authenticated in any meaningful fashion and all that > can be said about TLS is that it provides an encrypted connection between the > two communicating applications. This is perhaps why it is call *transport* > layer security ... Another major disconnect is that TLS validates the hostname that the browser decided to connect to, not the host you thought you were connecting to.. The end result is that if a phish directs you to nan0g.org, it can still show a padlock and the user is none the wiser pgpyx4YDs6kU0.pgp Description: PGP signature
Re: This DNS over HTTP thing
On Tue, 01 Oct 2019 16:24:30 -0400, Warren Kumari said: > "More concretely, the experiment in Chrome 78 will **check if the > user’s current DNS provider** is among a list of DoH-compatible > providers, and upgrade to the equivalent DoH service **from the same > provider**. If the DNS provider isn’t in the list, Chrome will > **continue to operate as it does today.**" I suppose this is the point somebody has to put the words "nostrils", "tent", and "camel" in the same sentence? I'd not say it, except.. All the articles on how to disable this in Chrome say stuff like: If users don't want to be included in the Chrome DoH experiment, they can use a DNS provider that's not on Google's list (which most of the Chrome userbase already does), or they can disable DoH support by modifying the chrome://flags/#dns-over-https flag. However, the Linux build of "Version 79.0.3921.0 (Official Build) unknown (64-bit)" does not have that flag in chrome://flags (or at least Chrome can't find ot with control-F dns-over and the in-page search box returns 1 result for 'dns' Anonymize local IPs exposed by WebRTC. Conceal local IP addresses with mDNS hostnames. Mac, Windows, Linux, Chrome OS #enable-webrtc-hide-local-ips-with-mdns There are still 3 occurrences of the string 'dns-over-http' in the binary, but none of them seem to be wired up to the chrome://flags page. It may be a bug - I was unable to find mention of it, but I may not have had the right keywords to scare up a search hit. If it *is* a bug, I'd appreciate if somebody pointed me at the support page for it pgpuHPKskD9e6.pgp Description: PGP signature
Re: IPAM recommendations
On Thu, 05 Sep 2019 21:20:19 +0900, Mehmet Akcin said: > I was using another product till few days ago (i won’t mention name) i am > not happy and decided to go with something open source Can you mention why you're unhappy with the product? Price, a critical feature that was lacking, something else? Software in a segment never improves unless the vendors/developers know that doing XYZ well/poorly is a market differentiator pgpHlBwjcXqkD.pgp Description: PGP signature
Re: Mx204 alternative
On Mon, 02 Sep 2019 10:02:55 +0100, Aled Morris via NANOG said: > The forthcoming Juniper ACX700 sounds like a good fit for metro Ethernet > with 4x100G and 24x10G in a shallow 1U hardened form factor. Hardened? Is this just "will survive in a not-well-cooled telco closet" hardening, or something more unusual? pgpIHiAdTbYyi.pgp Description: PGP signature
Re: Weekly Routing Table Report
On Mon, 02 Sep 2019 14:02:43 +0900, Masataka Ohta said: > If you think we should blindly believe your unfounded statement > not supported by any verifiable reference, that is the > condescending behavior. Well Masataka... If "Owen DeLong, who was widely known to have been in an actual job position to know of certain facts, stating these facts" isn't sufficient evidence for you, then applying that very same standard of evidence to your assertions leads directly to "can safely be ignored" *plonk* (the sound of an email address dropping into a not-often-used ignore file) pgpA1j3jgYBYh.pgp Description: PGP signature
Re: Weekly Routing Table Report
On Sun, 01 Sep 2019 09:04:03 +0900, Masataka Ohta said: > > All I see there is some handwaving about separating something from > > something else, without even a description of why it was better than > > what was available when you wrote the draft. > > Read the first three paragraphs of abstract of the draft: And it doesn't actually explain why it's better. It says it's different, but doesn't give reasons to do it other than "it's different". > Read the title of the draft. The draft is not intended to describe > protocol details. In other words, you have a wish list, not a workable idea. > > Try attaching an actual protocol specification > > Read the title of the draft. The Architecture of End to End Multihoming However, the draft is lacking in any description of an actual architecture. Read RFC1518, which *does* describe an architecture, and ask yourself what's in that RFC that isn't in your draft. pgp3DEuIMI5Qp.pgp Description: PGP signature
Re: Weekly Routing Table Report
On Sat, 31 Aug 2019 12:04:43 +0900, Masataka Ohta said: > The solution is: > > https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03 All I see there is some handwaving about separating something from something else, without even a description of why it was better than what was available when you wrote the draft. I don't see anything about how it's supposed to work - for example, if my cell phone had an IP address via DHCP from my home wireless router but also has an IPv6 from cellular connection, how *exactly* does it *securely* fall back to cellular if a thunderstorn knocks out Comcast's gear in the area? It's little details like that which were why your IETF draft wasn't taken seriously, and your commentary today isn't doing any better. Try attaching an actual protocol specification - preferably one that you've actually got at least somewhat-working software to implement it. I guarantee that you'll learn a few things in the process... pgpjcBVqgRFRN.pgp Description: PGP signature
Re: Weekly Routing Table Report
On Sat, 31 Aug 2019 18:51:16 +0900, Masataka Ohta said: > Owen DeLong wrote: > >> With the current routing practice, the number will increase to 14M > >> with IPv4 and a lot more than that with IPv6. > > > > I$B!G(Bm curious as to why you think that the number is bounded at 14M fo r > > IPv4 and why you think there will be so many more multi homed sites > > in IPv6? > > I don't think I must explain the current routing practice here. Actually, maybe you *should* explain how it will grow to 14M IPv4 routes. Are there 13 million /24s still out there to be allocated? Where will these routes come from? pgp6anjW_odTK.pgp Description: PGP signature
Re: Weekly Routing Table Report
On Fri, 30 Aug 2019 20:27:10 -0600, Paul Ebersman said: > BGP when under 2k-ish and CLNP for sins in past lives... CLNP? Now there's a name I've not heard in a long time... (Go ahead, admit it, you read that in Alec Guiness's voice :) pgp6ZxG8xNXvp.pgp Description: PGP signature
Re: syn flood attacks from NL-based netblocks
On Mon, 19 Aug 2019 21:18:49 +0300, T�ma Gavrichenkov said: > If you're doing load balancing for *outgoing* traffic — and in exactly the > same manner as you do with incoming — then maybe. On the other hand, your servers should probably be doing non-loadbalanced outbound on a different IP address than the inbound load balancer, and thus the syn-ack should have zero trouble getting back to the box it thought the syn came from. pgpZQ9VCs8QPy.pgp Description: PGP signature
Re: syn flood attacks from NL-based netblocks
On Mon, 19 Aug 2019 20:44:47 +0300, T�ma Gavrichenkov said: > Not in a typical DC/ISP environment! With the solution you propose, a > perfect routing symmetry is a hard requirement, b/c you need to make > sure a returning SYN/ACK hits the very same machine as the initial > SYN. If your load balancer isn't doing something to make that situation work properly, you need to talk to your vendor. pgpeMouZOG2zD.pgp Description: PGP signature
Re: new BGP hijack & visibility tool “BGPalerter”
On Fri, 16 Aug 2019 11:02:41 +0200, Robert Kisteleki said: > Hi, > > On 2019-08-15 17:38, Christopher Morrow wrote: > > This looks like fun! > > (a few questions for the RIPE folk, I think though below) > > > > What is the expected load of streaming clients on the RIPE service? (I > > wonder because I was/am messing about with something similar, though > > less node and js... not that that's relevant here). > > One of the (IMO) most useful features is that you can filter what you > want to receive. In fact this makes the service useful :-) So unless you > want to tune in to a significant portion of BGP chatter, the load should > not be substantial. I think Chris's question is more "Is RIPE going to be OK if a lot of people ask for the extra-chatty feed?" pgpMrhh_gbmAg.pgp Description: PGP signature
Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)
On Wed, 14 Aug 2019 16:07:49 -, John Curran said: > > But I suspect a lot of companies are reading it as: "If a spammer sues you > > for using > > a block list that prevents them from spamming your customers, you can't end > > up > > owing money to the block list maintainers. But if you rely on the ARIN > > TAL, and get > > sued by an address hijacker, you could end up owing money to ARIN". > It's is not "you owe money to ARIN", but it could be "you need to defend both > yourself and ARIN from your customers litigation should you get it wrong." Is there any workable way to remove or diminish the perception of liability in the case of using it *correctly*? I admit that (a) I'm not a lawyer and (b) when I actually tried to read it I couldn't actually tell if it was "you promise to defend us if you screw it up and customer traffic gets accidentally dropped on the floor" or "you promise to defend us if you use it correctly and miscreant traffic is intentionally dropped on the floor"... There's obviously a disconnect where people aren't worried about indemnifying Spamhaus for using their block list, but are worried about indemnifying ARIN for using the TAL. pgpPfQJhUFewN.pgp Description: PGP signature
