6 ms·

TCP, the workhorse of the internet

350 points by signa11 1y ago

acosmism 1y ago
i have an idea for a new javascript framework
zkmon 1y ago
I hate to think of the future of these nice blog posts, that need to struggle to convince the readers about the organic level of their content.
stavros 1y ago
Wait, can you actually just use IP? Can I just make up a packet and send it to a host across the Internet? I'd think that all the intermediate routers would want to have an opinion about my packet, caring, at the very least, that it's either TCP or UDP.
- gsliepen 1y ago
  They shouldn't; the whole point is that the IP header is enough to route packets between endpoints, and only the endpoints should care about any higher layer protocols. But unfortunately some routers do, and if you have NAT then the NAT device needs to examine the TCP or UDP header to know how to forward those packets.
  - jadamson 1y ago
    Notably, QUIC (and thus HTTP/3) uses UDP instead of a new protocol number for this reason.
    - stavros 1y ago
      Yeah, this is basically what I was wondering, why QUIC used UDP instead of their own protocol if it's so straightforward. It seems like the answer may be "it's not as interference-free as they'd like it".
      - Twisol 1y ago
        UDP pretty much just tacks a source/destination port pair onto every IP datagram, so its primary function is to allow multiple independent UDP peers to coexist on the same IP host. (That is, UDP just multiplexes an IP link.) UDP as a protocol doesn't add any additional network guarantees or services on top of IP. QUIC is still "their own protocol", just implemented as another protocol nested inside a UDP envelope, the same way that HTTP is another protocol typically nested inside a TCP connection. It makes some sense that they'd piggyback on UDP, since (1) it doesn't require an additional IP protocol header code to be assigned by IANA, (2) QUIC definitely wants to coexist with other services on any given node, and (3) it allows whatever middleware analyses that exist for UDP to apply naturally to QUIC applications. (Regarding (3) specifically, I imagine NAT in particular requires cooperation from residential gateways, including awareness of both the IP and the TCP/UDP port. Allowing a well-known outer UDP header to surface port information, instead of re-implementing ports somewhere in the QUIC header, means all existing NAT implementations should work unchanged for QUIC.)
      - conradludgate 1y ago
        When it comes to QUIC, QUIC works best with unstable end-user internet (designed for http3 for the mobile age). Most end-user internet access is behind various layers of CGNAT. The way that NAT works is by using your port numbers to increase the address space. If you have 2^32 IPv4 addresses, you have 2^48 IPv4 address+port pairs. All these NAT middleboxes speak TCP and UDP only. Additionally, firewalls are also designed to filter out any weird packets. If the packet doesn't look like you wanted to receive it, it's dropped. It usually does this by tracking open ports just like NAT, therefore many firewalls also don't trust custom protocols.
      - lxgr 1y ago
        It's effectively impossible to use anything other than TCP or UDP these days. Some people here will argue that it actually really is, and that everybody experiencing issues is just on a really weird connection or using broken hardware, but those weird connections and bad hardware make up the overwhelming majority of Internet connections these days.
      - hylaride 1y ago
  - Hikikomori 1y ago
    Can also NAT using IP protocol.
- Twisol 1y ago
  As far as I'm aware, sure you can. TCP packets and UDP datagrams are wrapped in IP datagrams, and it's the job of an IP network to ship your data from point A (sender) to point B (receiver). Nodes along the way might do so-called "deep packet inspection" to snoop on the payload of your IP datagrams (for various reasons, not all nefarious), but they don't need to do that to do the basic job of routing. From a semantic standpoint, the information in the TCP and UDP headers (as part of the IP payload) is only there to govern interactions between the two endpoint parties. (For instance, the "port" of a TCP or UDP packet is a node-local identifier for one of many services that might exist at the IP address the packet was routed to, allowing many services to coexist at the same node.)
  - stavros 1y ago
    Hmm, I thought intermediate routers use the TCP packet's bits for congestion control, no? Though I guess they can probably just use the destination IP for that.
    - Twisol 1y ago
      They probably can do deep/shallow packet inspection for that purpose (being one of the non-nefarious applications I alluded to), but that's not to say their correct functioning relies on it. Those routers also need to support at least UDP, and UDP provides almost no extra information at that level -- just the source and destination ports (so, perhaps QoS prioritization) and the inner payload's length and checksum (so, perhaps dropping bad packets quickly). If middleware decides to do packet inspection, it better make sure that any behavioral differences (relative to not doing any inspection) is strictly an optimization and does not impact the correctness of the link. Also, although I'm not a network operator by any stretch, my understanding is that TCP congestion control is primarily a function of the endpoints of the TCP link, not the IP routers along the way. As Wikipedia explains [0]: > Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself. [0]: https://en.wikipedia.org/wiki/TCP_congestion_control https://en.wikipedia.org/wiki/TCP_congestion_control
    - toast0 1y ago
      Most intermediate routers don't care much. Lookup the destination IP in the routing table, forward to the next hop, no time for anything else. Classic congestion control is done on the sender alone. The router's job is simply to drop packets when the queue is too large. Maybe the router supports ECN, so if there's a queue going to the next hop, it will look for protocol specific ECN headers to manipulate. Some network elements do more than the usual routing work. A traffic shaper might have per-user queues with outbound bandwidth limits. A network accelerator may effectively reterminate TCP in hopes of increasing acheivable bandwidth. Often, the router has an aggregated connection to the next hop, so it'll use a hash on the addresses in the packet to choose which of the underlying connections to use. That hash could be based on many things, but it's not uncommon to use tcp or udp port numbers if available. This can also be used to chose between equally scored next hops and that's why you often see several different paths during a traceroute. Using port numbers is helpful to balance connections from IP A to IP B over multiple links. If you us an unknown protocol, even if it is multiplexed into ports or similar (like tcp and udp), the different streams will likely always hash onto the same link and you won't be able to exceed the bandwidth of a single link and a damaged or congested link will affect all or none of your connections.
- ilkkao 1y ago
  You can definitely craft an IP packet by hand and send it. If it's IPv4, you need to put a number between 0 and 255 to the protocol field from this list: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt https://www.iana.org/assignments/protocol-numbers/protocol-n... Core routers don't inspect that field, NAT/ISP boxes can. I believe that with two suitable dedicated linux servers it is very possible to send and receive single custom IP packet between them even using 253 or 254 (= Use for experimentation and testing [RFC3692]) as the protocol number
  - Twisol 1y ago
    > If it's IPv4, you need to put a number between 0 and 255 to the protocol field from this list: To save a skim (though it's an interesting list!), protocol codes 253 and 254 are suitable "for experimentation and testing".
  - stavros 1y ago
    Very interesting, thanks!
  - inglor_cz 1y ago
    This is an interesting list; it makes you appreciate just how many obscure protocols have died out in practice. Evolution in networks seems to mimic evolution in nature quite well.
  - morcus 1y ago
    What happens when the remaining 104 unassigned protocol numbers are exhausted?
    - marcosdumay 1y ago
      People will start overloading the numbers. I do hope we'll have stopped using IPv4 by then... But well, a decade after address exhaustion we are still on it, so who knows?
      - kbolino 1y ago
- LeoPanthera 1y ago
  You know I've always wondered if you could run Kermit*-over-IP, without having TCP inbetween. *The protocol.
- Karrot_Kream 1y ago
  If there's no form of NAT or transport later processing along your path between endpoints you shouldn't have an issue. But NAT and transport and application layer load balancing are very common on the net these days so YMMV. You might have more luck with an IPv6 packet.
- NooneAtAll3 1y ago
  something like this? https://en.wikipedia.org/wiki/IP_over_Avian_Carriers https://en.wikipedia.org/wiki/IP_over_Avian_Carriers
  - Twisol 1y ago
    That would be IP over some lower level physical layer, not some custom content stuffed into an IP packet :) (It's absolutely worth reading some of those old April Fools' RFCs, by the way [0]. I'm a big fan of RFC 7168, which introduced HTTP response code 418 "I'm a teapot".) [0]: https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments#List_of_April_Fools'_Day_RFCs https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
  - dilyevsky 1y ago
    That's layer below - using air+pigeon as your PHY and paper as your MAC
- immibis 1y ago
  Yes but not if you or they are behind NAT. It's a shame port numbers aren't in IP.
- nly 1y ago
  The reason you wouldn't do that is IP doesn't give you a mechanism to share an IP address with multiple processes on a host, it just gets your packets to a particular host. As soon as you start thinking about having multiple services on a host you end up with the idea of having a service id or "port" UDP or UDP Lite gives you exactly that at the cost of 8 bytes, so there's no real value in not just putting everything on top of UDP
- xorcist 1y ago
  > caring, at the very least, that it's either TCP or UDP. You left out ICMP, my favourite! (And a lot more important in IPv6 than in v4.) Another pretty well known protocol that is neither TCP nor UDP is IPsec. (Which is really two new IP protocols.) People really did design proper IP protocols still in the 90s. > Can I just make up a packet and send it to a host across the Internet? You should be able to. But if you are on a corporate network with a really strict firewalling router that only forwards traffic it likes, then likely not. There are also really crappy home routers which gives similar problems from the other end of enterpriseness. NAT also destroyed much of the end-to-end principle. If you don't have a real IP address and relies on a NAT router to forward your data, it needs to be in a protocol the router recognizes. Anyway, for the past two decades people have grown tired of that and just piles hacks on top of TCP or UDP instead. That's sad. Or who am I kidding? Really it's on top of HTTP. HTTP will likely live on long past anything IP.
  - gruturo 1y ago
    > NAT also destroyed much of the end-to-end principle. If you don't have a real IP address and relies on a NAT router to forward your data, it needs to be in a protocol the router recognizes. Not necessarily. Many protocols can survive being NATed if they don't carry IP/port related information inside their payload. FTP is a famous counterexample - it uses a control channel (TCP21) which contains commands to open data channels (TCP20), and those commands specify IP:port pairs, so, depending on the protocol, a NAT router has to rewrite them and/or open ports dynamically and/or create NAT entries on the fly. A lot of other stuff has no need for that and will happily go through without any rewriting.
    - lxgr 1y ago
      Of course NAT allows application layer protocols layered on TCP or UDP to pass through without the NAT understanding the application layer – otherwise, NATted networks would be entirely broken. The end-to-end principle at the IP layer (i.e. having the IP forwarding layer be agnostic to the transport layer protocols above it) is still violated.
      - 1y ago
- GardenLetter27 1y ago
  Probably not, loads of routers are even blocking parts of ICMP.
  - eqvinox 1y ago
    That's firewalls (or others), not routers. If it blocks things, it's by definition not a router anymore.
    - lxgr 1y ago
      You can call the things mangling IP addresses and TCP/UDP ports what you want, but that will unfortunately not make them go away and stop throwing away non-TCP/UDP traffic.
    - marcosdumay 1y ago
      Both things come on the same box nowadays. There are many routers that don't care at all about what's going through them. But there aren't any firewalls that don't route anymore (not even at the endpoints).
    - rubatuga 1y ago
      And by your definition my home router is not a router since it does NAT? There's really no point in arguing semantics like this.
      - eqvinox 1y ago
        We're discussing nonstandard IP protocols. In that context, your home router is a CPE, and not described by the term "router" without further qualifiers, because that's the level the discussion is at. I'm happy to call it a router when talking to the neighbors, when I'm not discussing IP protocols with them.
- gruturo 1y ago
  Yep it's full of IP protocols other than the well-known TCP, UDP and ICMP (and, if you ever had the displeasure of learning IPSEC, its AH and ESP). A bunch of multicast stuff (IGMP, PIM) A few routing protocols (OSPF, but notably not BGP which just uses TCP, and (usually) not MPLS which just goes over the wire - it sits at the same layer as IP and not above it) A few VPN/encapsulation solutions like GRE, IP-in-IP, L2TP and probably others I can't remember As usual, Wikipedia has got you covered, much better than my own recollection: https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
  - lxgr 1y ago
    To GPs point, though, most of these will unfortunately be dropped by most middleboxes for various reasons. Behind a NA(P)T, you can obviously only use those protocols that the translator knows how to remap ports for.
    - Hikikomori 1y ago
      Can also do 1:1 NAT for IP protocols like ipsec, or your own protocol.
      - lxgr 1y ago
        Yes, but who else does? Network effects are important in a network.
- eqvinox 1y ago
  > I'd think that all the intermediate routers would want to have an opinion about my packet, caring, at the very least, that it's either TCP or UDP. They absolutely don't. Routers are layer 3 devices; TCP & UDP are layer 4. The only impact is that the ECMP flow hashes will have less entropy, but that's purely an optimization thing. Note TCP, UDP and ICMP are nowhere near all the protocols you'll commonly see on the internet — at minimum, SCTP, GRE, L2TP and ESP are reasonably widespread (even a tiny fraction of traffic is still a giant number considering internet scales). You can send whatever protocol number with whatever contents your heart desires. Whether the other end will do anything useful with it is another question.
  - lxgr 1y ago
    > They absolutely don't. Routers are layer 3 devices; Idealized routers are, yes. Actual IP paths these days usually involve at least one NAT, and these will absolutely throw away anything other than TCP, UDP, and if you're lucky ICMP.
    - eqvinox 1y ago
      See nearby comment about terminology. Either we're discussing odd IP protocols, then the devices you're describing aren't just "routers" (and particularly what you're describing is not part of a "router"), or we're not discussing IP protocols, then we're not having this thread. And note the GP talked about "intermediate routers". That's the ones in a telco service site or datacenter by my book.
deleted 1y ago
[deleted]
gsliepen 1y ago
If you start with the problem of how to create a reliable stream of data on top of an unreliable datagram layer, then the solution that comes out will look virtually identical to TCP. It just is the right solution for the job. The three drawbacks of the original TCP algorithm were the window size (the maximum value is just too small for today's speeds), poor handling of missing packets (addressed by extensions such as selective-ACK), and the fact that it only manages one stream at a time, and some applications want multiple streams that don't block each other. You could use multiple TCP connections, but that adds its own overhead, so SCTP and QUIC were designed to address those issues. The congestion control algorithm is not part of the on-the-wire protocol, it's just some code on each side of the connection that decides when to (re)send packets to make the best use of the available bandwidth. Anything that implements a reliable stream on top of datagrams needs to implement such an algorithm. The original ones (Reno, Vegas, etc) were very simple but already did a good job, although back then network equipment didn't have large buffers. A lot of research is going into making better algorithms that handle large buffers, large roundtrip times, varying bandwidth needs and also being fair when multiple connections share the same bandwidth.
- bobmcnamara 1y ago
  > If you start with the problem of how to create a reliable stream of data on top of an unreliable datagram layer, then the solution that comes out will look virtually identical to TCP. I'll add that at the time of TCP's writing, the telephone people far outnumbered everyone else in the packet switching vs circuit switching debate. TCP gives you a virtual circuit over a packet switched network as a pair of reliable-enough independent byte streams over IP. This idea, that the endpoints could implement reliability through retransmission came from an earlier French network, Cylades, and ends up being a core principle of IP networks.
  - Karrot_Kream 1y ago
    We're still "suffering" from the latency and jitter effects of the packet switching victory. (The debate happened before my time and I don't know if I would have really agreed with circuit switching.) Latency and jitter on the modern Internet are very best effort emphasis on "effort".
iberator 1y ago
Its trivial to develop your own protocols on top of IP. It was trivial like 15 years ago in python (without any libraries) just handcrafted packets (arp, ip etc).
cynicalsecurity 1y ago
I can easily spot it's an AI written article, because it actually explains the technology in understandable human language. A human would have written it the way it was either presented to them in university or in bloated IT books: absolutely useless.
- omnimus 1y ago
  I can easily spot it's an AI written comment, because it actually explains their idea in understandable human language and brings nothing to the discussion. A human would have written it the way they understand it and bring their opinions along: absolutely useless.
- pjjpo 1y ago
  At first wanted to give the benefit of the doubt that this is sarcasm but gave a skim through history and I guess it's just a committed anti-AI agenda. Personally I found the tone of the article quite genuine and the video at the end made a compelling case for it. Well I figure you commented having actually read it. Edit: I can't downvote but if I could it probably would have been better than this comment!
shevy-java 1y ago
> The internet is incredible. It’s nearly impossible to keep people away from. Well ... he seems very motivated. I am more skeptical. For instance, Google via chrome controls a lot of the internet, even more so via its search engine, AI, youtube and so forth. Even aside from this people's habits changed. In the 1990s everyone and their Grandma had a website. Nowadays ... it is a bit different. We suddenly have horrible blogging sites such as medium.com, pestering people with popups. Of course we also had popups in the 1990s, but the diversity was simply higher. Everything today is much more streamlined it seems. And top-down controlled. Look at Twitter, owned by a greedy and selfish billionaire. And the US president? Super-selfish too. We lost something here in the last some 25 years.
- Nervhq 1y ago
  [dead]
- __MatrixMan__ 1y ago
  You're talking about the web, which is merely an app with the internet as its platform. We can scrap it and still use the internet to build a different one.
FrankWilhoit 1y ago
TCP is one of the great works of the human mind, but it did not envision the dominance of semiconnected networks.
- cpach 1y ago
  Are you referring to NAT?
  - FrankWilhoit 1y ago
    No. TCP likes zero packet loss (connected), and it understands 100% packet loss (disconnected). Its weakness is scenarios (semiconnected) in which packet loss is constantly fluctuating between substantial and nearly-total. It doesn't know what is going on, and it may cope or it may not, because its designers did not envision a future in which most networks have a semiconnected last mile; but that is where we are. Without things like forward error correction, TCP would be nearly useless over wireless. It is interesting to envision a layer-4 protocol that would incorporate FEC-like capabilities.
- convolvatron 1y ago
  if you went back to 1981 and said 'yeah, this is great. but what we really want to do is not have an internet, but kind of a piecewise internet. instead of a global address we'll use addresses that have a narrower scope. and naturally as consequence of this we'll need to start distinguishing between nodes that everyone can reach, service nodes, and nodes that no one can reach - client nodes. and as a consequence of this we'll start building links that are asymmetric in bandwidth, since one direction is only used for requests and acks and not any data volume.' they would have looked at you and asked straight out what you hoped to gain by making these things distinguished, because it certainly complicates things.
  - FrankWilhoit 1y ago
    Wireless networks are always going to have asymmetries of transmit power. Everything flows from that. ALOHAnet was 1971.
api 1y ago
It’s worth considering how the tiny computers of the era forced a simple clean design. IPv6 was designed starting in the early 90s and they couldn’t resist loading it up with extensions, though the core protocol remains fine and is just IP with more bits. (Many of the extensions are rarely if ever used.) If the net were designed today it would be some complicated monstrosity where every packet was reminiscent of X.509 in terms of arcane complexity. It might even have JSON in it. It would be incredibly high overhead and we’d see tons of articles about how someone made it fast by leveraging CPU vector instructions or a GPU to parse it. This is called Eroom’s law, or Moore’s law backwards, and it is very real. Bigger machines let programmers and designers loose to indulge their desire to make things complicated.
- rubatuga 1y ago
  What are some extensions? just curious.
  - api 1y ago
    IPSec was a big one that’s now borderline obsolete, though it is still used for VPNs and was back ported to IPv4. Many networking folks including myself consider IPv6 router advertisements and SLAAC to be inferior, in practice, to DHCPv6, and that it would be better if we’d just left IP assignment out of the spec like it was in V4. Right now we have this mess where a lot of nets prefer or require DHCPv6 but some vendors, like apparently Android, refuse to support it. The rules about how V6 addresses are chopped up and assigned are wasteful and dumb. The entire V4 space could have been mapped onto /32 and an encapsulation protocol made to allow V4 to carry V6, providing a seamless upgrade path that does not require full upgrade of the whole core, but that would have been too logical. Every machine should get like a /96 so it can use 32 bits of space to address apps, VMs, containers, etc. As it stands we waste 64 bits of the space to make SLAAC possible, as near as I can tell. The SLAAC tail must have wagged the dog in that people thought this feature was cool enough to waste 8 bytes per packet. The V6 header allows extension bits that are never used and blocked by most firewalls. There’s really no point in them existing since middle boxes effectively freeze the base protocol in stone. Those are some of the big ones. Basically all they should have done was make IPs 64 or 128 bits and left everything else alone. But I think there was a committee. As it stands we have what we have and we should just treat V6 as IP128 and ignore the rest. I’m still in favor of the upgrade. V4 is too small, full stop. If we don’t enlarge the addresses we will completely lose end to end connectivity as a supported feature of the network.
throw0101a 1y ago
Any love for SCTP? > The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP) while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability. […] > SCTP may be characterized as message-oriented, meaning it transports a sequence of messages (each being a group of bytes), rather than transporting an unbroken stream of bytes as in TCP. As in UDP, in SCTP a sender sends a message in one operation, and that exact message is passed to the receiving application process in one operation. In contrast, TCP is a stream-oriented protocol, transporting streams of bytes reliably and in order. However TCP does not allow the receiver to know how many times the sender application called on the TCP transport passing it groups of bytes to be sent out. At the sender, TCP simply appends more bytes to a queue of bytes waiting to go out over the network, rather than having to keep a queue of individual separate outbound messages which must be preserved as such. > The term multi-streaming refers to the capability of SCTP to transmit several independent streams of chunks in parallel, for example transmitting web page images simultaneously with the web page text. In essence, it involves bundling several connections into a single SCTP association, operating on messages (or chunks) rather than bytes. * https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
- nesarkvechnep 1y ago
  As a BSD enjoyer and paid to write Erlang, I have nothing but love for SCTP.
- o11c 1y ago
  No, SCTP only fixes half of a problem, but also gratuitously introduces several additional flaws, even ignoring the "router support" problem. The only good answer is "a reliability layer on top of UDP"; fortunately everybody is now rallying around QUIC as the choice for that.
mlhpdx 1y ago
TCP being the “default” meant it was chosen when the need for ordering and uniform reliability wasn’t there. That was fine but left systems working less well than they could have with more carefully chosen underpinnings. With HTTP/3 gaining traction, and HTTP being the “next level up default choice” things potentially get better. The issue I see is that QUIC is far more complex, and the new power is fantastic for a few but irrelevant to most. UDP has its place as well, and if we have more simple and effective solutions like WireGuard’s handshake and encryption on top of it we’d be better off as an industry.
bmacho 1y ago
Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- cosmic_quanta 1y ago
  Strange, the title was definitely the original title earlier today
rfmoz 1y ago
RUDP from Plan9 was a nice step between TCP and UDP - https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protoco...
tolerance 1y ago
For the record I thought the TLD for this page was ‘cerfbound’, which sounds like the name for the race horse of the internet.
unit149 1y ago
[dead]
brcmthrowaway 1y ago
How much energy does the internet use?
brcmthrowaway 1y ago
Do extraterrestrial civilizations also use TCP?
- 1970-01-01 1y ago
  No. E.T. phoned home, so likely SS7
jccx70 1y ago
[flagged]
jiggawatts 1y ago
The congestion control algorithm in TCP has some interesting effects on throughput that a lot of developers aren’t aware of. For example, sending some data on a fresh TCP connection is slow, and the “ramp up time” to the bandwidth of the network is almost entirely determined by the latency. Amazing speed ups can be achieved in a data centre network by shaving microseconds off the round trip time! Similarly, many (all?) TCP stacks count segments, not bytes, when determining this ramp up rate. This means that jumbo frames can provide 6x the bandwidth during this period! If you read about the network design of AWS, they put a lot of effort into low switching latency and enabling jumbo frames. The real pros do this kind of network tuning, everyone else wonders why they don’t get anywhere near 10 Gbps through a 10 Gbps link.
time4tea 1y ago
1200/75 is enough for anyone? (0p)
mrlonglong 11mo ago
Why, just why, does ipv6 still uses 16 bit port addresses? Why didn't they think about larger port addresses? That means we can only have up to 65,534 port addresses per IP address.

350 points by signa11 1y ago

i have an idea for a new javascript framework

I hate to think of the future of these nice blog posts, that need to struggle to convince the readers about the organic level of their content.

stavros 1y ago

Wait, can you actually just use IP? Can I just make up a packet and send it to a host across the Internet? I'd think that all the intermediate routers would want to have an opinion about my packet, caring, at the very least, that it's either TCP or UDP.

gsliepen 1y ago
They shouldn't; the whole point is that the IP header is enough to route packets between endpoints, and only the endpoints should care about any higher layer protocols. But unfortunately some routers do, and if you have NAT then the NAT device needs to examine the TCP or UDP header to know how to forward those packets.
- jadamson 1y ago
  Notably, QUIC (and thus HTTP/3) uses UDP instead of a new protocol number for this reason.
  - stavros 1y ago
    Yeah, this is basically what I was wondering, why QUIC used UDP instead of their own protocol if it's so straightforward. It seems like the answer may be "it's not as interference-free as they'd like it".
    - Twisol 1y ago
      UDP pretty much just tacks a source/destination port pair onto every IP datagram, so its primary function is to allow multiple independent UDP peers to coexist on the same IP host. (That is, UDP just multiplexes an IP link.) UDP as a protocol doesn't add any additional network guarantees or services on top of IP. QUIC is still "their own protocol", just implemented as another protocol nested inside a UDP envelope, the same way that HTTP is another protocol typically nested inside a TCP connection. It makes some sense that they'd piggyback on UDP, since (1) it doesn't require an additional IP protocol header code to be assigned by IANA, (2) QUIC definitely wants to coexist with other services on any given node, and (3) it allows whatever middleware analyses that exist for UDP to apply naturally to QUIC applications. (Regarding (3) specifically, I imagine NAT in particular requires cooperation from residential gateways, including awareness of both the IP and the TCP/UDP port. Allowing a well-known outer UDP header to surface port information, instead of re-implementing ports somewhere in the QUIC header, means all existing NAT implementations should work unchanged for QUIC.)
    - conradludgate 1y ago
      When it comes to QUIC, QUIC works best with unstable end-user internet (designed for http3 for the mobile age). Most end-user internet access is behind various layers of CGNAT. The way that NAT works is by using your port numbers to increase the address space. If you have 2^32 IPv4 addresses, you have 2^48 IPv4 address+port pairs. All these NAT middleboxes speak TCP and UDP only. Additionally, firewalls are also designed to filter out any weird packets. If the packet doesn't look like you wanted to receive it, it's dropped. It usually does this by tracking open ports just like NAT, therefore many firewalls also don't trust custom protocols.
    - lxgr 1y ago
      It's effectively impossible to use anything other than TCP or UDP these days. Some people here will argue that it actually really is, and that everybody experiencing issues is just on a really weird connection or using broken hardware, but those weird connections and bad hardware make up the overwhelming majority of Internet connections these days.
    - hylaride 1y ago
- Hikikomori 1y ago
  Can also NAT using IP protocol.
Twisol 1y ago
As far as I'm aware, sure you can. TCP packets and UDP datagrams are wrapped in IP datagrams, and it's the job of an IP network to ship your data from point A (sender) to point B (receiver). Nodes along the way might do so-called "deep packet inspection" to snoop on the payload of your IP datagrams (for various reasons, not all nefarious), but they don't need to do that to do the basic job of routing. From a semantic standpoint, the information in the TCP and UDP headers (as part of the IP payload) is only there to govern interactions between the two endpoint parties. (For instance, the "port" of a TCP or UDP packet is a node-local identifier for one of many services that might exist at the IP address the packet was routed to, allowing many services to coexist at the same node.)
- stavros 1y ago
  Hmm, I thought intermediate routers use the TCP packet's bits for congestion control, no? Though I guess they can probably just use the destination IP for that.
  - Twisol 1y ago
    They probably can do deep/shallow packet inspection for that purpose (being one of the non-nefarious applications I alluded to), but that's not to say their correct functioning relies on it. Those routers also need to support at least UDP, and UDP provides almost no extra information at that level -- just the source and destination ports (so, perhaps QoS prioritization) and the inner payload's length and checksum (so, perhaps dropping bad packets quickly). If middleware decides to do packet inspection, it better make sure that any behavioral differences (relative to not doing any inspection) is strictly an optimization and does not impact the correctness of the link. Also, although I'm not a network operator by any stretch, my understanding is that TCP congestion control is primarily a function of the endpoints of the TCP link, not the IP routers along the way. As Wikipedia explains [0]: > Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself. [0]: https://en.wikipedia.org/wiki/TCP_congestion_control https://en.wikipedia.org/wiki/TCP_congestion_control
  - toast0 1y ago
    Most intermediate routers don't care much. Lookup the destination IP in the routing table, forward to the next hop, no time for anything else. Classic congestion control is done on the sender alone. The router's job is simply to drop packets when the queue is too large. Maybe the router supports ECN, so if there's a queue going to the next hop, it will look for protocol specific ECN headers to manipulate. Some network elements do more than the usual routing work. A traffic shaper might have per-user queues with outbound bandwidth limits. A network accelerator may effectively reterminate TCP in hopes of increasing acheivable bandwidth. Often, the router has an aggregated connection to the next hop, so it'll use a hash on the addresses in the packet to choose which of the underlying connections to use. That hash could be based on many things, but it's not uncommon to use tcp or udp port numbers if available. This can also be used to chose between equally scored next hops and that's why you often see several different paths during a traceroute. Using port numbers is helpful to balance connections from IP A to IP B over multiple links. If you us an unknown protocol, even if it is multiplexed into ports or similar (like tcp and udp), the different streams will likely always hash onto the same link and you won't be able to exceed the bandwidth of a single link and a damaged or congested link will affect all or none of your connections.
ilkkao 1y ago
You can definitely craft an IP packet by hand and send it. If it's IPv4, you need to put a number between 0 and 255 to the protocol field from this list: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt https://www.iana.org/assignments/protocol-numbers/protocol-n... Core routers don't inspect that field, NAT/ISP boxes can. I believe that with two suitable dedicated linux servers it is very possible to send and receive single custom IP packet between them even using 253 or 254 (= Use for experimentation and testing [RFC3692]) as the protocol number
- Twisol 1y ago
  > If it's IPv4, you need to put a number between 0 and 255 to the protocol field from this list: To save a skim (though it's an interesting list!), protocol codes 253 and 254 are suitable "for experimentation and testing".
- stavros 1y ago
  Very interesting, thanks!
- inglor_cz 1y ago
  This is an interesting list; it makes you appreciate just how many obscure protocols have died out in practice. Evolution in networks seems to mimic evolution in nature quite well.
- morcus 1y ago
  What happens when the remaining 104 unassigned protocol numbers are exhausted?
  - marcosdumay 1y ago
    People will start overloading the numbers. I do hope we'll have stopped using IPv4 by then... But well, a decade after address exhaustion we are still on it, so who knows?
    - kbolino 1y ago
LeoPanthera 1y ago
You know I've always wondered if you could run Kermit*-over-IP, without having TCP inbetween. *The protocol.
Karrot_Kream 1y ago
If there's no form of NAT or transport later processing along your path between endpoints you shouldn't have an issue. But NAT and transport and application layer load balancing are very common on the net these days so YMMV. You might have more luck with an IPv6 packet.
NooneAtAll3 1y ago
something like this? https://en.wikipedia.org/wiki/IP_over_Avian_Carriers https://en.wikipedia.org/wiki/IP_over_Avian_Carriers
- Twisol 1y ago
  That would be IP over some lower level physical layer, not some custom content stuffed into an IP packet :) (It's absolutely worth reading some of those old April Fools' RFCs, by the way [0]. I'm a big fan of RFC 7168, which introduced HTTP response code 418 "I'm a teapot".) [0]: https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments#List_of_April_Fools'_Day_RFCs https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
- dilyevsky 1y ago
  That's layer below - using air+pigeon as your PHY and paper as your MAC
immibis 1y ago
Yes but not if you or they are behind NAT. It's a shame port numbers aren't in IP.
nly 1y ago
The reason you wouldn't do that is IP doesn't give you a mechanism to share an IP address with multiple processes on a host, it just gets your packets to a particular host. As soon as you start thinking about having multiple services on a host you end up with the idea of having a service id or "port" UDP or UDP Lite gives you exactly that at the cost of 8 bytes, so there's no real value in not just putting everything on top of UDP
xorcist 1y ago
> caring, at the very least, that it's either TCP or UDP. You left out ICMP, my favourite! (And a lot more important in IPv6 than in v4.) Another pretty well known protocol that is neither TCP nor UDP is IPsec. (Which is really two new IP protocols.) People really did design proper IP protocols still in the 90s. > Can I just make up a packet and send it to a host across the Internet? You should be able to. But if you are on a corporate network with a really strict firewalling router that only forwards traffic it likes, then likely not. There are also really crappy home routers which gives similar problems from the other end of enterpriseness. NAT also destroyed much of the end-to-end principle. If you don't have a real IP address and relies on a NAT router to forward your data, it needs to be in a protocol the router recognizes. Anyway, for the past two decades people have grown tired of that and just piles hacks on top of TCP or UDP instead. That's sad. Or who am I kidding? Really it's on top of HTTP. HTTP will likely live on long past anything IP.
- gruturo 1y ago
  > NAT also destroyed much of the end-to-end principle. If you don't have a real IP address and relies on a NAT router to forward your data, it needs to be in a protocol the router recognizes. Not necessarily. Many protocols can survive being NATed if they don't carry IP/port related information inside their payload. FTP is a famous counterexample - it uses a control channel (TCP21) which contains commands to open data channels (TCP20), and those commands specify IP:port pairs, so, depending on the protocol, a NAT router has to rewrite them and/or open ports dynamically and/or create NAT entries on the fly. A lot of other stuff has no need for that and will happily go through without any rewriting.
  - lxgr 1y ago
    Of course NAT allows application layer protocols layered on TCP or UDP to pass through without the NAT understanding the application layer – otherwise, NATted networks would be entirely broken. The end-to-end principle at the IP layer (i.e. having the IP forwarding layer be agnostic to the transport layer protocols above it) is still violated.
    - 1y ago
GardenLetter27 1y ago
Probably not, loads of routers are even blocking parts of ICMP.
- eqvinox 1y ago
  That's firewalls (or others), not routers. If it blocks things, it's by definition not a router anymore.
  - lxgr 1y ago
    You can call the things mangling IP addresses and TCP/UDP ports what you want, but that will unfortunately not make them go away and stop throwing away non-TCP/UDP traffic.
  - marcosdumay 1y ago
    Both things come on the same box nowadays. There are many routers that don't care at all about what's going through them. But there aren't any firewalls that don't route anymore (not even at the endpoints).
  - rubatuga 1y ago
    And by your definition my home router is not a router since it does NAT? There's really no point in arguing semantics like this.
    - eqvinox 1y ago
      We're discussing nonstandard IP protocols. In that context, your home router is a CPE, and not described by the term "router" without further qualifiers, because that's the level the discussion is at. I'm happy to call it a router when talking to the neighbors, when I'm not discussing IP protocols with them.
gruturo 1y ago
Yep it's full of IP protocols other than the well-known TCP, UDP and ICMP (and, if you ever had the displeasure of learning IPSEC, its AH and ESP). A bunch of multicast stuff (IGMP, PIM) A few routing protocols (OSPF, but notably not BGP which just uses TCP, and (usually) not MPLS which just goes over the wire - it sits at the same layer as IP and not above it) A few VPN/encapsulation solutions like GRE, IP-in-IP, L2TP and probably others I can't remember As usual, Wikipedia has got you covered, much better than my own recollection: https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
- lxgr 1y ago
  To GPs point, though, most of these will unfortunately be dropped by most middleboxes for various reasons. Behind a NA(P)T, you can obviously only use those protocols that the translator knows how to remap ports for.
  - Hikikomori 1y ago
    Can also do 1:1 NAT for IP protocols like ipsec, or your own protocol.
    - lxgr 1y ago
      Yes, but who else does? Network effects are important in a network.
eqvinox 1y ago
> I'd think that all the intermediate routers would want to have an opinion about my packet, caring, at the very least, that it's either TCP or UDP. They absolutely don't. Routers are layer 3 devices; TCP & UDP are layer 4. The only impact is that the ECMP flow hashes will have less entropy, but that's purely an optimization thing. Note TCP, UDP and ICMP are nowhere near all the protocols you'll commonly see on the internet — at minimum, SCTP, GRE, L2TP and ESP are reasonably widespread (even a tiny fraction of traffic is still a giant number considering internet scales). You can send whatever protocol number with whatever contents your heart desires. Whether the other end will do anything useful with it is another question.
- lxgr 1y ago
  > They absolutely don't. Routers are layer 3 devices; Idealized routers are, yes. Actual IP paths these days usually involve at least one NAT, and these will absolutely throw away anything other than TCP, UDP, and if you're lucky ICMP.
  - eqvinox 1y ago
    See nearby comment about terminology. Either we're discussing odd IP protocols, then the devices you're describing aren't just "routers" (and particularly what you're describing is not part of a "router"), or we're not discussing IP protocols, then we're not having this thread. And note the GP talked about "intermediate routers". That's the ones in a telco service site or datacenter by my book.

deleted 1y ago

[deleted]

gsliepen 1y ago

If you start with the problem of how to create a reliable stream of data on top of an unreliable datagram layer, then the solution that comes out will look virtually identical to TCP. It just is the right solution for the job. The three drawbacks of the original TCP algorithm were the window size (the maximum value is just too small for today's speeds), poor handling of missing packets (addressed by extensions such as selective-ACK), and the fact that it only manages one stream at a time, and some applications want multiple streams that don't block each other. You could use multiple TCP connections, but that adds its own overhead, so SCTP and QUIC were designed to address those issues. The congestion control algorithm is not part of the on-the-wire protocol, it's just some code on each side of the connection that decides when to (re)send packets to make the best use of the available bandwidth. Anything that implements a reliable stream on top of datagrams needs to implement such an algorithm. The original ones (Reno, Vegas, etc) were very simple but already did a good job, although back then network equipment didn't have large buffers. A lot of research is going into making better algorithms that handle large buffers, large roundtrip times, varying bandwidth needs and also being fair when multiple connections share the same bandwidth.

bobmcnamara 1y ago
> If you start with the problem of how to create a reliable stream of data on top of an unreliable datagram layer, then the solution that comes out will look virtually identical to TCP. I'll add that at the time of TCP's writing, the telephone people far outnumbered everyone else in the packet switching vs circuit switching debate. TCP gives you a virtual circuit over a packet switched network as a pair of reliable-enough independent byte streams over IP. This idea, that the endpoints could implement reliability through retransmission came from an earlier French network, Cylades, and ends up being a core principle of IP networks.
- Karrot_Kream 1y ago
  We're still "suffering" from the latency and jitter effects of the packet switching victory. (The debate happened before my time and I don't know if I would have really agreed with circuit switching.) Latency and jitter on the modern Internet are very best effort emphasis on "effort".

iberator 1y ago

Its trivial to develop your own protocols on top of IP. It was trivial like 15 years ago in python (without any libraries) just handcrafted packets (arp, ip etc).

cynicalsecurity 1y ago

I can easily spot it's an AI written article, because it actually explains the technology in understandable human language. A human would have written it the way it was either presented to them in university or in bloated IT books: absolutely useless.

omnimus 1y ago
I can easily spot it's an AI written comment, because it actually explains their idea in understandable human language and brings nothing to the discussion. A human would have written it the way they understand it and bring their opinions along: absolutely useless.
pjjpo 1y ago
At first wanted to give the benefit of the doubt that this is sarcasm but gave a skim through history and I guess it's just a committed anti-AI agenda. Personally I found the tone of the article quite genuine and the video at the end made a compelling case for it. Well I figure you commented having actually read it. Edit: I can't downvote but if I could it probably would have been better than this comment!

shevy-java 1y ago

> The internet is incredible. It’s nearly impossible to keep people away from. Well ... he seems very motivated. I am more skeptical. For instance, Google via chrome controls a lot of the internet, even more so via its search engine, AI, youtube and so forth. Even aside from this people's habits changed. In the 1990s everyone and their Grandma had a website. Nowadays ... it is a bit different. We suddenly have horrible blogging sites such as medium.com, pestering people with popups. Of course we also had popups in the 1990s, but the diversity was simply higher. Everything today is much more streamlined it seems. And top-down controlled. Look at Twitter, owned by a greedy and selfish billionaire. And the US president? Super-selfish too. We lost something here in the last some 25 years.

Nervhq 1y ago
[dead]
__MatrixMan__ 1y ago
You're talking about the web, which is merely an app with the internet as its platform. We can scrap it and still use the internet to build a different one.

FrankWilhoit 1y ago

TCP is one of the great works of the human mind, but it did not envision the dominance of semiconnected networks.

cpach 1y ago
Are you referring to NAT?
- FrankWilhoit 1y ago
  No. TCP likes zero packet loss (connected), and it understands 100% packet loss (disconnected). Its weakness is scenarios (semiconnected) in which packet loss is constantly fluctuating between substantial and nearly-total. It doesn't know what is going on, and it may cope or it may not, because its designers did not envision a future in which most networks have a semiconnected last mile; but that is where we are. Without things like forward error correction, TCP would be nearly useless over wireless. It is interesting to envision a layer-4 protocol that would incorporate FEC-like capabilities.
convolvatron 1y ago
if you went back to 1981 and said 'yeah, this is great. but what we really want to do is not have an internet, but kind of a piecewise internet. instead of a global address we'll use addresses that have a narrower scope. and naturally as consequence of this we'll need to start distinguishing between nodes that everyone can reach, service nodes, and nodes that no one can reach - client nodes. and as a consequence of this we'll start building links that are asymmetric in bandwidth, since one direction is only used for requests and acks and not any data volume.' they would have looked at you and asked straight out what you hoped to gain by making these things distinguished, because it certainly complicates things.
- FrankWilhoit 1y ago
  Wireless networks are always going to have asymmetries of transmit power. Everything flows from that. ALOHAnet was 1971.

api 1y ago

It’s worth considering how the tiny computers of the era forced a simple clean design. IPv6 was designed starting in the early 90s and they couldn’t resist loading it up with extensions, though the core protocol remains fine and is just IP with more bits. (Many of the extensions are rarely if ever used.) If the net were designed today it would be some complicated monstrosity where every packet was reminiscent of X.509 in terms of arcane complexity. It might even have JSON in it. It would be incredibly high overhead and we’d see tons of articles about how someone made it fast by leveraging CPU vector instructions or a GPU to parse it. This is called Eroom’s law, or Moore’s law backwards, and it is very real. Bigger machines let programmers and designers loose to indulge their desire to make things complicated.

rubatuga 1y ago
What are some extensions? just curious.
- api 1y ago
  IPSec was a big one that’s now borderline obsolete, though it is still used for VPNs and was back ported to IPv4. Many networking folks including myself consider IPv6 router advertisements and SLAAC to be inferior, in practice, to DHCPv6, and that it would be better if we’d just left IP assignment out of the spec like it was in V4. Right now we have this mess where a lot of nets prefer or require DHCPv6 but some vendors, like apparently Android, refuse to support it. The rules about how V6 addresses are chopped up and assigned are wasteful and dumb. The entire V4 space could have been mapped onto /32 and an encapsulation protocol made to allow V4 to carry V6, providing a seamless upgrade path that does not require full upgrade of the whole core, but that would have been too logical. Every machine should get like a /96 so it can use 32 bits of space to address apps, VMs, containers, etc. As it stands we waste 64 bits of the space to make SLAAC possible, as near as I can tell. The SLAAC tail must have wagged the dog in that people thought this feature was cool enough to waste 8 bytes per packet. The V6 header allows extension bits that are never used and blocked by most firewalls. There’s really no point in them existing since middle boxes effectively freeze the base protocol in stone. Those are some of the big ones. Basically all they should have done was make IPs 64 or 128 bits and left everything else alone. But I think there was a committee. As it stands we have what we have and we should just treat V6 as IP128 and ignore the rest. I’m still in favor of the upgrade. V4 is too small, full stop. If we don’t enlarge the addresses we will completely lose end to end connectivity as a supported feature of the network.

throw0101a 1y ago

Any love for SCTP? > The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP) while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability. […] > SCTP may be characterized as message-oriented, meaning it transports a sequence of messages (each being a group of bytes), rather than transporting an unbroken stream of bytes as in TCP. As in UDP, in SCTP a sender sends a message in one operation, and that exact message is passed to the receiving application process in one operation. In contrast, TCP is a stream-oriented protocol, transporting streams of bytes reliably and in order. However TCP does not allow the receiver to know how many times the sender application called on the TCP transport passing it groups of bytes to be sent out. At the sender, TCP simply appends more bytes to a queue of bytes waiting to go out over the network, rather than having to keep a queue of individual separate outbound messages which must be preserved as such. > The term multi-streaming refers to the capability of SCTP to transmit several independent streams of chunks in parallel, for example transmitting web page images simultaneously with the web page text. In essence, it involves bundling several connections into a single SCTP association, operating on messages (or chunks) rather than bytes. * https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...

nesarkvechnep 1y ago
As a BSD enjoyer and paid to write Erlang, I have nothing but love for SCTP.
o11c 1y ago
No, SCTP only fixes half of a problem, but also gratuitously introduces several additional flaws, even ignoring the "router support" problem. The only good answer is "a reliability layer on top of UDP"; fortunately everybody is now rallying around QUIC as the choice for that.

mlhpdx 1y ago

TCP being the “default” meant it was chosen when the need for ordering and uniform reliability wasn’t there. That was fine but left systems working less well than they could have with more carefully chosen underpinnings. With HTTP/3 gaining traction, and HTTP being the “next level up default choice” things potentially get better. The issue I see is that QUIC is far more complex, and the new power is fantastic for a few but irrelevant to most. UDP has its place as well, and if we have more simple and effective solutions like WireGuard’s handshake and encryption on top of it we’d be better off as an industry.

bmacho 1y ago

Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

cosmic_quanta 1y ago
Strange, the title was definitely the original title earlier today

rfmoz 1y ago

RUDP from Plan9 was a nice step between TCP and UDP - https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protoco...

tolerance 1y ago

For the record I thought the TLD for this page was ‘cerfbound’, which sounds like the name for the race horse of the internet.

unit149 1y ago

[dead]

brcmthrowaway 1y ago

How much energy does the internet use?

brcmthrowaway 1y ago

Do extraterrestrial civilizations also use TCP?

1970-01-01 1y ago
No. E.T. phoned home, so likely SS7

jccx70 1y ago

[flagged]

jiggawatts 1y ago

The congestion control algorithm in TCP has some interesting effects on throughput that a lot of developers aren’t aware of. For example, sending some data on a fresh TCP connection is slow, and the “ramp up time” to the bandwidth of the network is almost entirely determined by the latency. Amazing speed ups can be achieved in a data centre network by shaving microseconds off the round trip time! Similarly, many (all?) TCP stacks count segments, not bytes, when determining this ramp up rate. This means that jumbo frames can provide 6x the bandwidth during this period! If you read about the network design of AWS, they put a lot of effort into low switching latency and enabling jumbo frames. The real pros do this kind of network tuning, everyone else wonders why they don’t get anywhere near 10 Gbps through a 10 Gbps link.

time4tea 1y ago

1200/75 is enough for anyone? (0p)

mrlonglong 11mo ago

Why, just why, does ipv6 still uses 16 bit port addresses? Why didn't they think about larger port addresses? That means we can only have up to 65,534 port addresses per IP address.