71–80 of 109 posts
[flagged]
Has IPv6 been a failure? All I know is that IPv4 is still around. And without knowing the IP Addresses of devices on my LAN, by home network would be harder to manage!
[flagged]
Has IPv6 been a failure? All I know is that IPv4 is still around. And without knowing the IP Addresses of devices on my LAN, by home network would be harder to manage!
Earlier quoted context omitted.
Nothing in the world can work with IPv7. That means need to update all the software and replace all the hardware. This takes years of effort, and years of time. What more familiar techniques? How are they going to be worth the millions of man-hours to implement? How are they going to be so much better that people will abandon IPv6 and switch from IPv4? Could this be accomplished by changing part of IPv6? It is quite…
> Nothing in the world can work with IPv7. That means need to update all the software and replace all the hardware. This takes years of effort, and years of time. Uh, you mean like IPv6? IPv6 once was new, and it was radical at the time (still mostly is). IPv4 should have just been extended to a 128 bit address space, breaking changes implemented around that, and then everything else would have been easier to adopt.…
Why do you think your IPv7 will magically just work? There will be problems with it and IT departements will still disable it.
What a great story. The spanning tree algo is under appreciated: this allowed people who didn’t understand networking to plug networks together the way you would plug extension power cables together,* making networking simple ( or alternatively insanely broken, when people had 400 computers on a single LAN with a rat’s nest of bridges and hubs…but unlike the extension cord case, nothing would catch literal fire). * d…
STP is basically magic - and being able to reliably optimize it to reduce reconvergence time makes you a magician.
STP handles this through sending little messages with every node receiving the message appending themselves after whoever sent it. Then a node just checks if it sees itself in the message. If I DO see myself in the chain, I know now I need to not send information to the previous node that sent me the message.
The message just needs to be something that'll never succeed but flow through the network. If I have three nodes labeled "A", "B", and "C" then I could send a message intended for "D" (which does not exist in my network). A has a path to B and A has a path to C. B has a path to C and vice versa. Each node can talk to another.
A send to B. B checks if its in the chain and if not, it appends itself in the chain. A -> B. B knows it received the message from A so it will ignore this connection and send the message to all of its neighbors. C receives the message from B. C checks if its in the chain and if not, it appends itself in the chain. A > B -> C. C got the message from B so it ignores this path and sends the message to all of its other neighbors (in this case, A).
A receives the message and checks if its in the chain (it is). A knows it received the message from C. A now knows that a cycle has been detected, so A disables its connection to C.
Congrats! You've designed a tree! Its a graph that contains no cycles. All we had to do was send a message and check if we see ourselves in the chain. If we do, we disable our path to the last node that sent us a message.
Of course STP gets more complicated from here as we factor in path costs as weights to measure the decision to axe a connection. Maybe A -> B is a 1G connection and A -> C is a 10G connection, in this case A may disable the path to B.
I do agree that reducing reconvergence time is magic. I don't understand that one.
Earlier quoted context omitted.
It is impossible to address hosts behind NAT. Only the public IPv4 address is visible. It might have been possible to extend IPv4 by having each NAT hop add the internal IPv4 address as option header. Then it would be possible to refer to inside host directly with a list of addresses. That isn't worth doing now because it would require rewriting everything to deal with the new protocol. For one thing, lots of NAT box…
Not a counterexample exactly, but your remark reminded me of this eldritch horror: https://blog.cloudflare.com/cloudflare-servers-dont-own-ips-... TLDR: Cloudflare is using five bits from the port number as a subnetting & routing scheme, with optional content policy semantics, for hosts behind anycast addressing and inside their network boundary. Filed in my bookmarks under "abominations".
Already 1 sentence in and we've already got Eldritchian horrors with customers described as just their watery orbs in their skull.
Earlier quoted context omitted.
Ha ha, it came from Wikipedia so possibly.
As a barely relevant point, Using google, I can't find references to the quote (or John Carmack) by searching 'Little tiny steps using local information winds up leading to all the best answers'. Other search engines seems to do a bit better on retrieving the Wiki article. What gives, is google really becoming worse?
I started using Kagi last month, and am really enjoying it - it's like Google at it's prime.
[flagged]
I think the great architectural challenge would be - how does one add that byte to the IP header in a non-breaking way?
I always wondered why it took so long to go from 10 Mbit/s to 100Mbit/s. For sure in that time they invented things like Ethernet Switching. But still, it seems like that standard took forever to move on. And then once it did it went from 100Mbit/s to 1000Mbit/s per second pretty damn fast.
I recall using a business desktop back in the day with a common IDE disk, and also attached to a NetWare share. The NetWare share was much faster than the local drive although the network was only 10BASE-T. Around that time meetings began: how much was it going to cost to replace all the cable (half of which was still coax) and buy 100BASE-T switches? (Answer: a couple hundred dollars per drop.) That process took two years and another six months to do the work: a quarter of a decade.
1000BASE-T was specified for Cat 5: the floorboards didn't have to be torn up to replace all that cable everyone just paid for. The cost of PHY/SERDES components fell greatly during that time and made 1000BASE-T hardware affordable. Moving from 100BASE-T to 1000BASE-T was, therefore, cheap and easy and took correspondingly less time.
What a great story. The spanning tree algo is under appreciated: this allowed people who didn’t understand networking to plug networks together the way you would plug extension power cables together,* making networking simple ( or alternatively insanely broken, when people had 400 computers on a single LAN with a rat’s nest of bridges and hubs…but unlike the extension cord case, nothing would catch literal fire). * d…
> people who didn’t understand networking A couple of decades ago I witnessed a classic demonstration of Weinberg's Corollary¹ when a spanning tree misconfiguration on a freshly-installed BlackDiamond disabled LINX for hours, throwing half of Britain's ISP peering into chaos. The switch in question was evidently cursed: it'd been dropped on my foot earlier that week, thus disabling me for hours, and everyone else inv…
That's ... quite a legacy.
Earlier quoted context omitted.
Ha ha, it came from Wikipedia so possibly.
As a barely relevant point, Using google, I can't find references to the quote (or John Carmack) by searching 'Little tiny steps using local information winds up leading to all the best answers'. Other search engines seems to do a bit better on retrieving the Wiki article. What gives, is google really becoming worse?