Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vint Cerf on mistakes he made in TCP/IP

spectrum.ieee.org

Post reply on HN
Print view View original

141–150 of 167 posts

Re: Vint Cerf on mistakes he made in TCP/IP

#141

Post by QuercusMax »

derefr wrote: post #124
ajross wrote: post #90

Earlier quoted context omitted.

That's it. The causality analysis in the grandparent is exactly backwards. We don't live in a world of "productized prototypes" because people are too lazy to do things right. We live in the world of prototypes because prototypes are the only products that reach market . Even where beautiful works of engineering exist, then tend to be beaten to the punch by the competing prototype anyway. You don't treat this by whin…

You can also design prototypes so that they're impossible to operationalize beyond experimental scale. I forget the name of it (there are probably several by now), but there's a UX prototyping toolkit where all the components look hand-drawn, so that nobody expects to be able to interact with them and then gets mad when nothing happens. It also prevents you-the-designer from being tempted to add interactivity logic a…

I've done something like this when bootstrapping a system that would eventually have an API with proper admin tools, but we just need something quick-and-dirty to get off the ground.

So I wrote some scripts in bash to do things the "worst" way possible. Directly accessing the production DB, minimal safety checks, etc. Nobody else on the team liked writing bash, so there was no fight to replace these awful tools with proper APIs.

Re: Vint Cerf on mistakes he made in TCP/IP

#142

Post by patrakov »

labcomputer wrote: post #137
mixmastamyk wrote: post #82

Earlier quoted context omitted.

Never have gotten a good answer to this, “why is 64 bits not enough?” Here, why not an option? It’s astronomically larger than 32, not double.

> “why is 64 bits not enough?” Here, why not an option? Because then you don't really have enough bits to do some nice things: 1. It would be nice for your upstream network provider (and you) if they can delegate some network prefix and thus don't need to concern themselves with the address plan inside your subnet. That means, if there is an address collision on your prefix it's not their problem. 2. Assuming you hav…

> For example, you can (today) sign up for two (or more!) ISPs that support IPv6 Prefix Delegation and have your router(s) issue Router Advertisements (RAs) for each prefix.

As a user of OpenWrt (which does exactly this) I strongly disagree that it is the right solution. If you announce on the LAN the prefixes obtained from a fast fiber and a slow LTE link, then devices will, well, get an address for each prefix. The problem is that they have absolutely no information to choose the source address correctly - it's all just numbers! So, just by bad luck, they choose the source address from the LTE prefix and waste the LTE data and my money if I use the default setup. Which is why I don't. My network uses IPv6 NPT, but announcing one prefix at a time would have been even better (because I only want fail-over, not real multihoming), although impossible with OpenWrt.

Forum discussion, which also serves as a proof that it is really hard to explain the "don't overcomplicate fail-over by generalizing it to multi-homing" notion: https://forum.openwrt.org/t/ipv6-wan-fail-over-without-ipv6-...

Re: Vint Cerf on mistakes he made in TCP/IP

#143

Post by tomcam »

What’s amazing is not TCP/IP’s warts, but how well conceived it was. His humility overshadows the fact this has been a magnificently flexible and robust technology. It’s one of the most impressive creations of the 21st century.

Re: Vint Cerf on mistakes he made in TCP/IP

#144

Post by LegionMammal978 »

sanxiyn wrote: post #140
foobarian wrote: post #73

Earlier quoted context omitted.

Didn't they build that weird "emergency packet" feature to skip to the head of line? IIRC it was never well supported in various system stacks..

Yes, TCP header had 16 bits allocated to "Urgent Pointer". It's (unfortunately) still there for compatibility, but RFC 9293, which updated RFC 793 after more than 40 years, has the following to say about it: > As a result of implementation differences and middlebox interactions, new applications SHOULD NOT employ the TCP urgent mechanism. However, TCP implementations MUST still include support for the urgent mechanis…

As it happens, that feature is used in the FTP protocol (RFC 959) to abort the current file transfer (or to immediately print a status message), since some old implementations would have to stop listening on the control connection while a transfer was in progress and could only be woken up with an interrupt. At least vsftpd supports it, I haven't looked at any other implementations. The main difficulty is that the libc API for reading urgent data is somewhat painful, and most higher-level TCP libraries haven't bothered with it for obvious reasons.

Of course, basic ftp:// clients (the only kind that are really used today) would probably rather just close the control connection, which has the same effect.

Re: Vint Cerf on mistakes he made in TCP/IP

#145

Post by ikiris »

mixmastamyk wrote: post #87
suprjami wrote: post #70

Earlier quoted context omitted.

It's the human method of interacting with that integer which is the problem. Nobody is going to start saying IPv4 addresses as hex, people aren't used to base 16. "Just set your gateway to co.a8.0.fe" said nobody ever. A 128-bit dotted quad would be equally unwieldy. Again "The IPv6 local range is 252.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000/7" said nobody ever. Honestly 128 bits was too much. They…

64bits in hex would be reasonably compact, 1.5x the length of a MAC address.

Sure, we could even call those network subnets that way we've got plenty of space for all the internet and expansion since 32 wasn't enough, and have another 64 bits for host identifiers.

This feels familiar somehow...

Re: Vint Cerf on mistakes he made in TCP/IP

#146

Post by kortilla »

jandrese wrote: post #54
kortilla wrote: post #43

Earlier quoted context omitted.

Administrators memorized IPs a lot. This is hard to under estimate and is frequently the disconnect I see when a SWE doesn’t understand why people could possibly complain about ipv6. This is likely the #1 issue I hear from people in the field. #2, for better or worse, NAT became peoples’ comfort blanket. It’s a boneheaded stateful firewall regardless of how long people can scream “NAT isn’t security”. By forcing peop…

#1 seems pretty unavoidable. Yes, bigger numbers are harder to remember, but we're in this mess in the first place because we made the numbers too small. It's kind of like complaining that phone numbers are too hard to memorize after we switched to 10 digit dialing. That may be true, but since we all have address books built into the phones now it's really not an issue. #2 is people being nervous, but seriously the "…

> #2 is people being nervous, but seriously the "DENY incoming on $WANIF if not in state table" rule is all you need.

This didn’t exist. Many of the early implementations of “support” for ipv6 was a checkbox that said “enable”. These cheap routers (which is what the majority of people without deep pockets are on) rarely even gave you an explicit stateful firewall UI.

If you got a “firewall” option at all, it was to block stuff from getting out of your network, not in. Know why? Because “NAT already did that”. If you wanted inbound unsolicited traffic you used port forwards or the “DMZ”.

It’s not people being nervous, it’s the vast majority of network vendors not making the UX any good. I pushed people to try v6 hard, it was not the rosy transition it was supposed to be. v6 for a while ended up being a great accidental exfil path for malware for administrators that screwed this up. Don’t try to downplay it, it just makes you sound like an armchair quarterback, not smart.

> #4 A /64 is a subnet. Normally all of your devices would be on the same subnet, although with IPv6 you get a whole bunch which is nice.

A /60 is also a subnet, so is a /127. Subnetting is just breaking up larger IP spaces.

Anyway, you missed the point of the comment. What I was getting at is that doing prefix delegation for home users for anything more than a /64 is immensely wasteful. Yet a bunch of very large ISPs do just that.

Want to guess why? Once again, bone-headed implementations in off the shelf routers that do give a /64 per WiFi client. Untold waste in the v6 space because addressing guidance was (and still is) so poor.

Re: Vint Cerf on mistakes he made in TCP/IP

#147

Post by amoss »

kjs3 wrote: post #123
pmarreck wrote: post #105

Earlier quoted context omitted.

No one and I mean NO ONE had any clue how widely deployed IPv4 would end up being. It went literally beyond everyone's wildest expectations who was alive at the time of its inception.

I don't think anything I wrote disagrees. As someone who started implementing IP networks just a couple of years after RFC791 was published, I'd say that was completely correct. But more than 40 years later, the fact that it has gone beyond everyone's wildest expectations means some of those early design decisions are starting to bite. Unlike tabs in makefiles, which is just something certain types of people like to…

> Unlike tabs in makefiles, which is just something certain types of people like to complain about.

http://catb.org/~esr/writings/taoup/html/ch15s04.html

Which "certain type" are Stuart Feldman and Steve Johnson?

Re: Vint Cerf on mistakes he made in TCP/IP

#148

Post by pdimitar »

em3rgent0rdr wrote: post #5

Cerf: "I'm serious, the decision to put a 32-bit address space on there was the result of a year's battle among a bunch of engineers who couldn't make up their minds about 32, 128 or variable length. And after a year of fighting I said -- I'm now at ARPA, I'm running the program, I'm paying for this stuff and using American tax dollars -- and I wanted some progress because we didn't know if this is going to work. So…

A prominent example of: nothing more permanent than a temporary solution.

Re: Vint Cerf on mistakes he made in TCP/IP

#149

Post by account42 »

agumonkey wrote: post #115
hn_throawlles wrote: post #88

Earlier quoted context omitted.

> even the defense department doesn't need 4.3 billion of anything uhm. counterexample: they need more dollars than that

it's hard to make a bill communicate over copper wire though

Not that hard really, smart cards are a thing and the chips themselves can be tiny.

Re: Vint Cerf on mistakes he made in TCP/IP

#150

Post by commandersaki »

mncharity wrote: post #131

Around 1990, IETF had a big fight over where to go from "not enough bits" IPv4. Should we IPvNext with an incremental "mostly just add more bits"? Or attempt a "second-system syndrome" "let's punt this time on rough consensus and working code" kitchen-sink monstrosity of a... err, IPv6. Followed by years and years of "ok, IPv6 was arguably the wrong call, but here we are now, things are turning around, and it will re…

> I don't recall what Vint Cerf's position was. But attributing the last few decades of IP dysfunction to 1970's choices seems... incomplete.

Yeah, I don't really think Cerf's decision really applies to the blunder that is IPv6. There were other options available to the IPng team that were foregone for SIPP knowing there was absolutely no transition/migration plan whereas the others had at least given this area some consideration.

I'm sort of expecting in year 40 of this attempt to transition to IPv6, we'll collectively realise it's a losing battle and look at future Internet architectures as salvation.

Post reply on HN