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

81–90 of 167 posts

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

#81

Post by elcritch »

bushbaba wrote: post #11
ksec wrote: post #2

Had TCP/IP been 64bit to begin with things would be a lot different.

I really wish we just did ipv4 on 64 but addresses. IPv6 is nearly a totally different paradigm, and has lead to adoption pain. Biggest being usability taking a back seat. People are being forced into using ipv6 not cause they want to, but from ip space exhaustion.

I used to think that, until I actually started using IPv6. It's a much more well designed protocol. The way switches and routers announce prefixes and network information using well defined UDP multicast is elegant and more robust. You can use link-local IP to always connect to a device on a local network.

The biggest benefit for most users is having a large enough IP space that devices can self-assign a unique address with the networks prefix with very low risk of collision. Many of the problems seen on wifi or home networks are due to various ARP issues and devices not properly releasing their own DHCP addresses. It's still very common. I had a work laptop get booted off my network after 10 minutes for a while until eventually figuring out another device was stealing its assigned IP.

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

#82

Post by mixmastamyk »

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…

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.

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

#83

Post by kjs3 »

amoss wrote: post #28
jandrese wrote: post #25

Earlier quoted context omitted.

It's always frustrating and amusing to read an anecdote about a design flaw in something where the creator goes "Yeah, we discovered that X was a bad idea, but there were already almost 10 people using it so it was too late to change."

Tabs in makefiles is another classic.

Except tabs in makefiles only require ones to acknowledge 'makefiles use tabs and here are the rules'. It's otherwise only something for pedants to obsess over.

IPV4 address contention has a bit more real-world impact.

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

#84

Post by kjs3 »

imtringued wrote: post #74
jandrese wrote: post #42

Earlier quoted context omitted.

IMHO TCP made the correct call here. TCP is a transport, not an application protocol. You are supposed to run your protocol over top of it, including things like blocking, substreams, etc... It's easy to add features to a simple transport, it's not so easy to work around features when you don't want them, plus they end up complicating the stack and become a possible source of bugs. Even "simple" TCP proved to be quit…

No they made the wrong decision and SCTP and QUIC fixed almost everything wrong with TCP. I personally stopped using raw TCP because it is almost always the wrong solution. If I need a bare bones protocol where I want to send raw bytes I now always use websockets because they work exactly as they should. Streaming is such a niche usecase that is only natural if you don't semantically interpret the data, i.e. arbitrar…

No, they made TCP for a particular set of use cases, and UDP for a different set, and there's always plain IP for you to build whatever you want. If you were using TCP for the wrong use case, how is that Vint Cerfs (or anyone elses) fault?

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

#85

Post by 1letterunixname »

I don't see all of the criticisms for security, but there are some fair points.

0. Gating mechanisms should live at lower and higher levels in the stack. We have 801.1x for wifi/port security and TLS between client and server.

1. DHCPv4 (and conflation with BOOTP) is messy and doesn't have a trust model. There ought to be a mechanism to validate that the DHCP server authentic, its data is valid, and it's supposed to be there. (Rogue DHCP servers can be thwarted with participation by the network gear, but requires more engineering than client simply being able to ignore bogus DHCP servers. Networks still must police and shutdown rogue endpoints nonetheless.)

2. DHCPv6 (stateful -SLAAC, stateless +SLAAC, DHCPv6-PD), SLAAC, and M and O flags make it more painful to deploy than it ought to be.

3. DNS DNSSEC/DANE hasn't really caught on (yet?). DNS needs a top-down trust model or at least make it user-friendly enough (tools) to deploy.

4. EBGP security. (Let's not talk about that.)

In general:

i. Optional features don't get used.

ii. Complexity is a barrier to adoption and a source of security issues.

iii. Over-simplicity is another source of security issues and a source of lacking functionality.

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

#86

Post by detaro »

imtringued wrote: post #78
jandrese wrote: post #33

Earlier quoted context omitted.

Routers don't care about the TCP header though, they only care about the 20 bytes of IP header. The interfaces on the router also care about the 14 byte MAC header, but that's a separate step. That said I agree that the world likely would have sucked it up and just gone with the 64 bit addresses, but there would have been a whole lot of grumbling for decades about the memory use. It's hard to imagine these days, but…

We live in a NAT and CGNAT world. Routers do care about the TCP header.

now. Not at the time were "adopting TCP or not" was a question.

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

#87

Post by mixmastamyk »

suprjami wrote: post #70
bauruine wrote: post #67

Earlier quoted context omitted.

An IPv4 address on the wire is just a 32 Bit integer in big endian. The quad-dotted notation is the most common for IPv4 but you could also use hex or decimal. There was an article on HN just recently about that. I can't find it right now but try ping 0x7F000001 to get an idea. You don't even need a new protocol you could implement something like what three words or your 999.999.999 naming scheme locally and use it o…

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.

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

#88

Post by hn_throawlles »

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…

> even the defense department doesn't need 4.3 billion of anything

uhm. counterexample: they need more dollars than that

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

#89

Post by somat »

hughesjj wrote: post #49
astrange wrote: post #27

Earlier quoted context omitted.

IPv6 itself isn't the right thing for mobile internet either; people expect their IP address to not change when they migrate towers, meaning the entire approach to routing doesn't work.

Isn't it like literally a data structure issue though? Like you have to route on prefixes? Like how else would you know where to go? Ip routing is kind of like a tree (not a graph) in the ip regards, how would you get around it? I admittedly don't know as much as I'd like about network, hence why I'm posing this question ;-) If theres a way to efficiently model hierarchical domains for stuff like DNS/IP i'd love to k…

The way it is done is to have an invisible layer underneath (mpls perhaps) that can do the routing.

However the correct ip way to do it would to have tcp(layer 4) decoupled from ip(layer 3) such that an ip address could change while maintaining the tcp stream. unfortunately this was not done, tcp has too many layer violations and is firmly interlocked with ip. I don't know much about the state of the art, does http over udp (quic) allow for ip address change?

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

#90

Post by ajross »

chrisfosterelli wrote: post #79
checkyoursudo wrote: post #7

Earlier quoted context omitted.

This is a good lesson. I've done a lot of pilot studies, prototypes, proof-of-concept experiments. It is scary^1 how many times "let's just get this tested and see if it even works" turns into "welp, that worked and we don't have time or funding to do another one, so that's the final version." The constraint is often time. Gotta get a product out, or run an follow-on experiment that depended on the first, or submit a…

On the flip side, how many times do we hear about projects that failed because the dev team was stuck building things that were never needed or never used? It's hard to see the future.

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 whining that the prototypes are winning. You treat it by finding ways to cleanly evolve prototypes[1], and by collecting intuition (c.f. the linked article) about common mistakes and how to avoid them.

[1] Once upon a time in an age lost to history, this was the idea behind something called "agile". The thing we call "agile" today is pretty much the opposite.

Post reply on HN