32 ms·

The world in which IPv6 was a good design

677 points by dbenamy 9y ago

tyingq 9y ago
>One person at work put it best: "layers are only ever added, never removed." Find this in the software world as well. Something about the java culture seems especially fascinated with multiple layers of abstraction. Edit: Ok, some factions of the culture. "Convenient proxy factory bean superclass for proxy factory beans that create only singletons"
- nebabyte 9y ago
  Computers don't understand concepts and people only do. Our gradual ascent from hardware to intuitively-usable mechanisms involves abstracting away the repeated "okay, given these primitives, here's how we'd use them" to go the next layer up.
  - beagle3 9y ago
    But that's non necessarily a good way. It's the easy way out of "I don't like these details, so I'll try to hide them under something". A good abstraction is worth its weight in gold. A bad abstraction (the vast majority) is worth its weight in dung.
- Terr_ 9y ago
  Hopefully some of the static-strictness features in the language will offer people tools to remove layers of abstraction... if they can get permission from humans to do the refactoring :p
- aidenn0 9y ago
  Some infamous examples of such java classes (For some reason Spring always seemed to have more verbose names than other DI frameworks, which is saying something): SimpleBeanFactoryAwareAspectInstanceFactory SerializedEntityManagerFactoryBeanReference And this is totally not related to that sort of naming scheme, but in trying to remember those spring names, I stumbled upon this gem: http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.aspectj.matcher/src/org/aspectj/weaver/patterns/HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor.java http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.as...
  - floatboth 9y ago
    http://java.metagno.me/ http://java.metagno.me/
- moomin 9y ago
  Speaking as a fan of C#, Clojure and Haskell, I'd say the problem is caused by having insufficiently powerful abstractions in the base platform. Phil Freeman has said that there are entire libraries on npm that just implement traverse.
- kqr 9y ago
  That is funny. I am doing some temporary consulting work in a Java shop. I created a layered and complicated solution to a complicated problem. I spent a lot of time defending the complexity of the solution as the necessity it was. When the requirements appeared to change, I was all like, "Are you sure about that? That's great news because that means we can remove these layers from my solution and simplify the code a lot." Apparently they had never heard about someone wanting to get rid of their own layers, because they just sat there in silence trying to come up with reasons to keep the (now) unnecessary layers. In the end, I think they agreed that the new requirements must be incorrect, and the old ones still cover both cases. Imagine that! Throwing away new requirements solely to keep layers.
mjevans 9y ago
Ok, so QUIC or some other common layer 4/4+5 'Modern TCP over UDP for network compatibility' solution. Lets just throw away the concept of 'addresses' for authentication and actually use a cryptographic authentication identifier of somekind, combined with some mux iteration ID.
- __s 9y ago
  Drop the idea of ports too. Every program gets its own IP Mentioning ideas like that at work get queer looks about how it'd be impossible to configure a firewall at that point But keep going further. End up with 128 bit CPU where every byte is IP addressable. Necessary security to block random outsiders from reading your memory, but capable of potentially running various parts remotely transparently
  - mjevans 9y ago
    Not even IP. Source/destinations would both only be crypto identifiers. The multiplexing part is just a convenient way of expressing different data streams to simpler protocols for QoS and other activities. That does imply that there should be a way (possibly host to host, possibly build in to some kind of service resolution system) of looking up a 'name entry' and 'service type'.
  - johncolanduoni 9y ago
    > But keep going further. End up with 128 bit CPU where every byte is IP addressable. Necessary security to block random outsiders from reading your memory, but capable of potentially running various parts remotely transparently This is already a thing: https://en.wikipedia.org/wiki/Remote_direct_memory_access https://en.wikipedia.org/wiki/Remote_direct_memory_access
    - dullgiulio 9y ago
      Cool, although the name sounds much more like a vulnerability than a feature.
  - ComputerGuru 9y ago
beagle3 9y ago
I am very glad IPv6 didn't catch on. The world in which it was designed was not a world in which everyone (NSA, Google, Facebook) was trying to document and correlate every tiny thing you do, whether it is related to them or not. If IPv6 eventually becomes widespread, I hope it comes with ISPs that will let you replace your prefix, and phones/hardware that will randomize your suffix - otherwise, the internet becomes completely pseudonymous.
- beagle3 9y ago
  Would a down voter care to explain why I am so wrong in their opinion?
  - azernik 9y ago
    Because a) statements in your comment are false, b) some proposals in your comment have already been implemented, and c) the ones that haven't are bad ideas. IPv6 has caught on (I'm commenting from an IPv6-only connection right now, on a residential US ISP). Most clients do perform RFC4941 suffix randomization. Replacing the prefix destroys one of the most useful features of IP addresses and in particular the larger IPv6 address space - routability (the property that getting to two addresses that share a prefix usually uses the same next-hop router).
    - beagle3 9y ago
      Thank you for taking the time to explain. Let me try to word things a little better: What is the percentage of US homes who are on an IPv6? What is the percentage of websites on IPv6? What are the number of web site hits that are IPv6 to IPv6? (in the US? in the world?) The highest estimate I've ever seen for any of these is less than 20%, which - 20 years into IPv6, is in my opinion "not caught on". The mobile world when 3G arrived preferred carrier-grade-NAT to IPv6 (which was technically a better solution), which is in my opinion "not caught on". Suffix randomization has been implemented, but is not universal in my experience; and it is essentially useless for privacy in one's home. It slightly blurs the distinction between my laptop and my son's iPad. And that's ALL it does. Right now I enjoy getting an address from a pool of 16K addresses every time I reset my cable modem; And it is likely to transition soon to a carrier-grade NAT which would give me even more privacy. It is likely that I should be taking crazy pills - I seem to remember the snowdens of yesteryear and facebook shadow profiles, which either I'm hallucinating or no one else seems to care about. On the other hand, I have a startup idea to profit from the impending v6-complete-lack-of-privacy that I should probably start working on. If you can't beat them, profit off them.
Aloha 9y ago
Part of the difficulty here - is you're not just upgrading the whole stack, you're instead layering on whatever stack is already there - its a needed part of deploying any new technology without replacing everything from the basement up. I'm not sure what this guy would do instead however - as someone with a decent networking background, I got completely lost in the end.
- ktRolster 9y ago
  Maybe you should read it again and let us know which of those options it is.
- loeg 9y ago
  The author has a verbose writing style, and may not be a genius, but they are clearly familiar with networking protocols and do a good job explaining the general scene and history.
  - Aloha 9y ago
    I just disagree with some of his premise - I don't think its feasible to get away from any and all layer two broadcast messages - even limiting yourself to IPv6 Mulitcast still leaves you with some pseudo-broadcast messages for either housekeeping or auto-discovery purposes - its part of what makes IP based networking in general work - and I'm talking services that run at layer four - that rely on that primitive to exist to make certain functionality happen. Routing still adds complexity, and I see no way for it to not add complexity - he talks about each switch being a router for example - you then need a way to determine where a particular subnet you're trying to get to lies - which means a routing able (akin to a mac address table, but for prefix), and some way to feret out which interface a particular device lies (akin to arp, but instead searching for a prefix to route to) - in the end, you end up with the same primitives and complexity, but you've just moved it up a layer in the stack - which does nothing to get rid of complexity - it just adds to it. IP networks are often a tree in organizations - ethernet is often deployed with different topologies, relying to spanning-tree to give you more redundancy without extra configuration (at the expense of some delay on re-convergence) I think also that so long as we're dragging along the legacies of the disparate layer one technologies (which in any case, would not and could not go away) - we're kinda stuck with what we have.
ktRolster 9y ago
We'll switch to IPv6, and every service will still go through port 80.
- ploxiln 9y ago
  minor correction: port 443
- deleted 9y ago
  [deleted]
- xroche 9y ago
  And using a dozen of IPs most of the time (Google, Facebook, Youtube, etc.)
gridscomputing 9y ago
"QUEER"?!
- josteink 9y ago
  Don't be a triggered snowflake. Queer is a real, non-offensive word with a real, non-offensive meaning. https://duckduckgo.com/?q=queer+definition&t=ffip&ia=definition https://duckduckgo.com/?q=queer+definition&t=ffip&ia=definit...
  - sctb 9y ago
    You can please leave out the name-calling while making your point, like the guidelines ask. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- sctb 9y ago
  We detached this subthread from https://news.ycombinator.com/item?id=14986630 https://news.ycombinator.com/item?id=14986630 and marked it off-topic.
undoware 9y ago
Easily the best technical document I've ever read. Holy heck. "Now I see with pulse serene, the heart of the machine"
- mulle_nat 9y ago
  Somehow it's always old network guys, who write the best articles.
Animats 9y ago
What he's really arguing for is a circuit-switched network, so that connections can be persistent over moves. He just needs a unique connection ID. One amusing possibility would be to do this at the HTTPS layer. With HTTPS Everywhere, most HTTP connections now have a unique connection ID at the crypto layer - the session key. If you could move an HTTP connection from one IP address to another on the fly, it could be kept alive over moves. HTTPS already protects against MITM attacks, and if the transfer is botched or intercepted, that will break the connection. I'm not recommending this, but it meets many of his criteria. The trouble with low-level connection IDs that don't force routing is forgery. You can fake a source IP address, but that won't get you the reply traffic, so this is useful only for denial of service attacks. If you have connection IDs, you need to secure them somehow against replication, playback, etc.
- runeks 9y ago
  > One amusing possibility would be to do this at the HTTPS layer. With HTTPS Everywhere, most HTTP connections now have a unique connection ID at the crypto layer - the session key. As a network-ignoramus, who likes cryptography, I’ve long dreamt of a networking protocol where endpoints are defined, primarily, by a public key. All messages would be encrypted with the destination public key, and signed by the source private key. When a destination node receives a packet from a neighboring node, and ACK would constitute the destination node’s signature over the received packet, thus making ACKs provable and portable (“this node has already received that packet, here’s the proof”). Packet sources addresses would no longer be fake-able, as that would constitute breaking asymmetric cryptography. The protocol would have no concept of a “connection”. Routing would be left out of this protocol completely, and networks would use whichever routing protocols they find most efficient. I wouldn’t be surprised if there were countless issues with a protocol like this, but something about it just seems so elegant to me that I haven’t stopped considering it yet.
  - apenwarr 9y ago
    You should read about QUIC, which is designed to be able to do this, almost exactly like you describe. https://www.chromium.org/quic https://www.chromium.org/quic
akshayn 9y ago
"If, instead, we had identified sessions using only layer 4 data, then mobile IP would have worked perfectly." Mobile IP can still work with the current infrastructure -- https://en.wikipedia.org/wiki/Mobile_IP https://en.wikipedia.org/wiki/Mobile_IP This proposal was basically a service which would host a static IP for you (similar to the LTE structure but with IP underneath instead of L2), and forward to whatever your "real" IP was using IP-in-IP encapsulation. As the author states, layers are only ever added :)
- apenwarr 9y ago
  That's basically just an IPIP tunnel. It works, but adds tons of latency. A "good" mobile IP (which would be possible with eg. QUIC) would add no per-packet latency.
  - Dagger2 9y ago
    Correspondent node functionality in Mobile IPv6 does exactly that, by sending the packets directly between the two nodes involved. Basically it works by associating the connection with a 128-bit GUID instead of with the node's current network address, which allows the network address to change without breaking connections. So... basically exactly what the suggested solution would look like, if it was modified to work with all protocols and not just TCP/UDP.
femto 9y ago
The "Internet Mobile Host Protocol" (IMHP) was written as a draft RFC in 1994. As far as I know it was never adopted, but is it still relevant, even as an inspiration for IPv6? [1] https://www.cs.rice.edu/~dbj/pubs/draft-johnson-imhp-00.txt https://www.cs.rice.edu/~dbj/pubs/draft-johnson-imhp-00.txt Edit: Its official entry at the IETF: https://datatracker.ietf.org/doc/draft-johnson-imhp/ https://datatracker.ietf.org/doc/draft-johnson-imhp/
fumigator 9y ago
I just read in New Scientist mag that the Internet was developed to survive a nuclear attack. I recall reading somewhere that one of the original inventors has stated that the issue never came up. I can't find the exact quote, could anyone here help me out. ppps: OK, found it, "the creation of the ARPANET was not motivated by considerations of war", Robert Taylor 2004 https://motherboard.vice.com/en_us/article/d77k7j/dear-internet-you-were-invented-by-the-government https://motherboard.vice.com/en_us/article/d77k7j/dear-inter... ref: https://www.newscientist.com/article/mg23531383-300-we-can-stop-hacking-and-trolls-but-it-would-ruin-the-internet/ https://www.newscientist.com/article/mg23531383-300-we-can-s... ps: Is IPV6 a bit like a camel, as in, a camel is a horse designed by committee :) pps: This has to be the only forum on the Internet where you get modded down for a) asking a question and b) making a joke. I didn't figure my comment could trigger any camels, committees or horses reading this. https://www.newscientist.com/ https://www.newscientist.com/
peterburkimsher 9y ago
That is a beautifully-written article. The IEEE hardware and IETF software guys have been busy adding complexity to the networks, with so many legacy protocols (when everyone just uses TCP/IP) and extra ports (when everything happens on port 80 - seriously, even email is now on cloud services). I can't get LTE because of political problems. So I just gave up trying to be online, and started caching everything possible. Meanwhile, storage is getting larger capacity, smaller size, and cheaper. I've got a 512GB SD card in my pocket all the time, with a backup of my laptop in case my bag gets stolen. My phone does everything offline if possible. Offline MP3 music. Offline maps. Wikipedia. StackOverflow. Hacker News. FML. UrbanDictionary. XKCD. The few YouTube videos I actually want to see again. The only thing I need Internet for is communication. To send a message, I walk around looking for open WiFi and type my message to them on Facebook Messenger. If they need to reach me urgently, they can just use my phone number (which keeps changing every 6 months for the same political problems). What if access points had large caches with mirrors of the content people want? Instead of asking Google's server in the US to send me a map tile, what if I could just get it from the local WiFi AP's web server? It would be much faster, and save so much trouble with networking. Sure, there are some things that people need the network for (e.g. new content, copyrighted material). But so much else is free of licenses, and would be possible to mirror locally everywhere.
- isostatic 9y ago
  One look at ntop tells me very little of our traffic is port 80 or 443
- arcbyte 9y ago
  +1 for thinking outside the box
marasal 9y ago
This was a great read.
hueving 9y ago
>In truth, that really is just complicating things. Now your operating system has to first look up the ethernet address of 192.168.1.1, find out it's 11:22:33:44:55:66, and finally generate a packet with destination ethernet address 11:22:33:44:55:66 and destination IP address 10.1.1.1. 192.168.1.1 is just a pointless intermediate step. This is completely wrong, it's not pointless. First, this can be used to easily swap out routers in a network without reconfiguring any clients or even incurring downtime. Without the intermediary gateway IP representation, this would mean you would either have to spoof the MAC on the second router or reconfigure all of the clients to point to the new gateway. Second, ethernet addresses are a layer-2 construct and IP routes are a layer 3 construct. Your default gateway is a layer-3 route to 0.0.0.0/0. There are protocols for exchanging layer-3 routes like BGP/RIP/etc that should not have to know anything about the layer-2 addressing scheme to provide the next-hop address. Third, routers still need to have an IP address on the subnet anyway to originate ICMP messages (e.g. TTL expired, MTU exceeded, etc). Fourth, ARP is still necessary even for the router itself to know how to take incoming IP traffic from the outside and actually forward it to the appropriate device on the local network. Otherwise you would have to statically configure a mapping of local IP addresses to MAC addresses on the router. So ARP is critical for separation of concerns between L2 and L3. We don't live in an ethernet-only world. >excessive ARP starts becoming one of your biggest nightmares. It's especially bad on wifi. Broadcast can become a nightmare. Excessive ARP is a drop in the bucket compared to other discovery crap that computers spew onto networks. The pattern of most computers now is to communicate with the external world (from the LAN perspective) and not much else. So on a network of 1000 computers (an already excessively large broadcast domain), your ARP traffic is going to be a couple of thousand ARP messages every few hours. If this is taking down your WiFi network, you have much bigger problems considering all of those are about a modern webpage load of traffic.
- lwansbrough 9y ago
  > This is completely wrong, it's not pointless. Pretty reliable rule of software is: if you think it's pointless you probably don't understand it well enough.
  - pjmorris 9y ago
hueving 9y ago
>They have to be special, because an IP node has to be able to transmit them before it has an IP address, which is of course impossible, so it just fills the IP headers with essentially nonsense Not nonsense! The global IP broadcast is specified as 255.255.255.255 and is used by other protocols. The source IP address for the initial discovery is indeed 0.0.0.0, which is not intuitive, but the rest of the DHCP exchange is handled with real IP addresses like normal IP traffic. DHCP is very much an IP protocol (see DHCP relay for how it transits IP networks). >Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that. Ugh, come on! RARP doesn't provide you with a route to get out of the network or other extremely useful things like a DNS server. >and DHCP, which is an IP packet but is really an ethernet protocol, and so on. No, it's not an ethernet protocol. It's a layer-3 address assignment protocol that runs inside of IP, which is normally encapsulated in ethernet frames. You can have a remote DHCP server running any arbitrary L2 non-ethernet protocol and if it receives a relayed DHCP request it will reply with IP unicast perfectly fine with no ethernet involved.
- azernik 9y ago
  In fact, most residential ISP modems run DHCP over whatever their L2 technology is - cable or DSL.
  - dom0 9y ago
    DSL usually uses PPPoA (or PPPoE in a MPoA tunnel like below) over a subset of ATM (=DSL). PPP itself transports IP and provides configuration. When modem and router are separate, the modem only provides an MPoA tunnel to provide Ethernet access to the DSL link, while the router connects to the AC via PPPoE over said tunnel.
    - Hikikomori 9y ago
      Another common option is RFC 1483 bridging (IPoEoATM) where DHCP is typically used for address assignment.
okket 9y ago
> Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that. Actually, no. You can only set an IP address with RARP, not even a netmask (RARP comes from pre-CIDR age) or other important stuff like default gateway, DNS server, etc like you can with DHCP.
- bluGill 9y ago
  Right, but those are all things we are not talking about here, so RARP worked just fine.
hueving 9y ago
>Network operators basically choose bridging vs routing based on how fast they want it to go and how much they hate configuring DHCP servers, which they really hate very much, which means they use bridging as much as possible and routing when they have to. Very rarely does a network operator use bridging to avoid configuring DHCP. All modern protocols are built on IP so you still need an addressing scheme and most people want the Internet so the 169 auto addressing is out. So even in big bridged networks, you still have a DHCP server. In fact, you configure less DHCP in a big bridged network than DHCP for a ton of tiny networks. The advantage to big bridging networks is that you have to setup very little routing (just the router to get in and out). If you routed between every port on the network, there would be an excessive amount of configuration involved to setup prefixes on every single interface.
hueving 9y ago
>And nowadays big data centers are basically just SDNed, and you might as well not be using IP in the data center at all, because nobody's routing the packets. It's all just one big virtual bus network. The opposite trend is true in large data centers. L3 fabrics where everything is routed have become extremely popular because BGP (or custom SDN setups) can be used to migrate IPs and you get to utilize multiple paths (rather than the single path offered by STP convergence).
- Duckeh 9y ago
  But then you're tunneling your L2 across your L3. So if you provide connectivity to a customer in a datacenter all they'll see is the L2. But you're right. Underneath everything is an IP fabric these days.
- imbriaco 9y ago
  This is extra delicious irony given the fact that the typical, and often only, requirement for these SDN layers is IP connectivity.
- Natales 9y ago
  Exactly. Virtually all new DCs are being build using Leaf-Spine architectures that leverages pure IP routing and optimize for East-West traffic internally. I'm also starting to see the rapid proliferation of L3-only SDN systems like Project Calico [1] in fairly large Fortune 100 companies, for any sort of end point, particularly containers these days. [1] https://www.projectcalico.org/learn/ https://www.projectcalico.org/learn/
tardo99 9y ago
What if the server needs to send you a packet while you're mobile but you haven't sent it a packet yet so it can update its cache? That packet will be lost in his scheme. Nice try.
- dcposch 9y ago
  IP is best effort. Packets get lost all the time. Higher protocols, like TCP and QUIC, all handle packet loss--typically by trying again. Losing a packet is better than losing all open connections.
  - elihu 9y ago
    I think it may be worse than a lost packet, though. If the destination host is truly gone from that network, the nearest router might reply that no such computer exists, causing the socket to be disconnected. (It's been awhile since I've studied TCP/IP; I'm not sure what the exact correct reply would be...) Perhaps this could be mitigated by adding a timeout that keeps sockets alive for awhile in case the destination shows up somewhere else.
- zAy0LfpBZLC8mAC 9y ago
  In a sensible (i.e., NAT-free) world, the end point knows when its global address changes, which it can use to trigger an address update to its peer.
seanwasere 9y ago
utilise port numbers. and cue the port number fascists
anilgulecha 9y ago
One big UX mistake of IPv6: it was not made backward compatible with IPv4. (v6)0.0.192.168.1.10 == 192.168.1.10(v4). This simple design when planning and rolling it out would have meant incrementally updating the networking stack to also support v6. Now it turns out v4 and v6 are completely different, and no one has a big enough reason to make the change until everyone else makes the change. Hard chicken-egg problem.
- okket 9y ago
  Backwards compatibility can not work. You can not answer an IPv6 packet with IPv4. There is no room in the header for the much bigger source/return address. You can try to do hacks like NAT (like you probably do in your home IPv4 network, which breaks/stops any peer-2-peer protocol). The IPv6 version is called DNS64/NAT64, and it breaks even more things, e.g. DNSSEC. Because it not only requires network address translation (lying about your IP), but also rewriting DNS records (lying about signed DNS records). The only sane way forward is get rid of IPv4 as fast as possible (even if 'fast' means a decade or two).
  - mSparks43 9y ago
    IPv4 + NAT is much more sane than IPv6 IMHO. Seriously, it should not be the default that every single device on your network is visible to the great wide world. Therein be demons. Especially not all these internet of things devices that any script kiddy can make surrender all its secrets. Plus, have you ever actually even tried a setup of an IPv6 local network? You try typing 2001:0db8:85a3:0000:0000:8a2e:0370:7334 into the address bar 50 times in a week to tweek router settings and see how enamoured you are with the protocol. Furthermore, you know whats easier to type in? rrcc5uuudhh4oz3c.onion
  - anilgulecha 9y ago
    I don't mean it that way. Yes, on-the-wire format would have changed, maybe there would have been a required transition from v4 to v4.1, which could then have been backward compatible to v6. To be fair, I don't think the authors of v6 at the time realized how much friction an alternative IP stack would cause.
mirimir 9y ago
I found the piece informative and entertaining. But I'm not technical enough to comment much. I would have liked to see what he thought of MPTCP as a replacement for TCP.
killjoywashere 9y ago
Bookmark
_pmf_ 9y ago
> To save on electronics, people wanted to have a "bus" network It was also to save sanity and avoiding having to rip apart every office building for installing hundreds of cables.
Hikikomori 9y ago
Interesting article, but it contains some weird statements. >It is literally and has always been the software-defined network you use for interconnecting networks that have gotten too big. But the problem is, it was always too hard to hardware accelerate, and anyway, it didn't get hardware accelerated, and configuring DHCP really is a huge pain, so network operators just learned how to bridge bigger and bigger things. IP forwarding (longest prefix match) is more complicated than mac forwarding yes, but it has been done in hardware (ASICs, typically NPUs today) for a long time now. Operators (I assume ISPs) do not build large bridged networks as they need their networks to scale as they grow, or they will hit a breaking point where their network collapses. ISP's typically use centralised DHCP servers (as opposed to configuring their access routers) and configure their routers to use DHCP relay. DHCP server configuration is easily automated by just reading your IPAM data, it's a non-issue.
fundabulousrIII 9y ago
This article was some of the most egregious nonsense I've read in a while.
davidreiss 9y ago
Is anyone else shocked at the low level of adoption of IPv6? I remember how in the late 90s people were saying we were going to run out of addresses and everyone need to migrate to IPv6 ASAP. Now, it seems that IPv4 is going to be around for a long while.
- laythea 9y ago
  not shocked.
- marcosdumay 9y ago
  Keep in mind that we are currently running out of IPv6 addresses. The slow adoption is pushed by entities that control a big number of IPv4 addresses. I have no idea how long this situation can sustain itself.
  - mrunkel 9y ago
    Citation needed for both wild statements.
- betaby 9y ago
  US IPv6 adoption is above 50% for mobile networks. Wouldn't call it 'low level'
djrogers 9y ago
> In truth, that really is just complicating things. Now your operating system has to first look up the ethernet address of 192.168.1.1, find out it's 11:22:33:44:55:66, and finally generate a packet with destination ethernet address 11:22:33:44:55:66 and destination IP address 10.1.1.1. 192.168.1.1 is just a pointless intermediate step. Bollocks. The abstraction allowed by using an IP address instead of a MAC address is essential, considering that IP addresses are dynamic (even when statically configures, devices can and do get replaced) and MAC adresses are set at the factory. Can you imagine updating the routing table of every device in your network because you had to replace a core router and the MAC address was different? It’s the equivalent of publishing your website on an IP address instead of a DNS hostname... * yes, I know MAC addresses can be configured by software in many devices, but that’s even more of a hack than using arp to determine a MAC address.
- mritun 9y ago
  What he is saying is that in a routed network (instead of bridged), you don't need MAC address. At least not at layer 2.
noahl 9y ago
This was a very informative article for me, but there was one thing I didn't understand. At the end he made the case that mobile routing needed essentially two layers: a fixed per-device (or per session) identifier, and then a separate routing-layer address that could change as a device moved. QUIC has session identifiers, and that's great and could solve the problem. But earlier in that very article, he already pointed out that every device already has a globally unique identifier used in layer 2 routing ... the ethernet MAC address. Would someone please explain to me why we can't use MAC addresses as globally unique device IDs? (Is MAC spoofing the issue?)
- ajdecon 9y ago
  Among other reasons: there are still a fair number of non-Ethernet devices with IP addresses out there...
- ara24 9y ago
  I think, he explains it early in the article, "The problem with ethernet addresses is they're assigned sequentially at the factory, so they can't be hierarchical. That means the "bridging table" is not as nice as a modern IP routing table, which can talk about the route for a whole subnet at a time."
- scurvy 9y ago
  MACs aren't unique and can be changed. Certain fly by night Asian manufacturers just make up MACs randomly. It's a big problem with counterfeit gear, too. They are supposed to be unique, but in the real world they are not.
- nayuki 9y ago
  In theory we can use MAC addresses, but there are problems: 0) Privacy: You don't want all traffic to be labeled with your hardware ID. 1) Flatness: MACs are essentially random, and a router would need a huge table to keep track of who's where. IP (v4/v6) assigns addresses hierarchically, making routing tables manageable.
  - noahl 9y ago
deleted 9y ago
[deleted]
luckydude 9y ago
This is an awesome read and hilarious if you have any historical knowledge of networking. +1 highly recommend even if all you want is a few chuckles. Well done.
- luckydude 9y ago
  BTW, the best read in networking is "The Elements of Networking Style" by Mike Padlipsky. https://en.wikipedia.org/wiki/Michael_A._Padlipsky https://en.wikipedia.org/wiki/Michael_A._Padlipsky It's hard to find a copy of that book but oh, man, if you know the stack and you lived through the ISO/OSI proposals, it's so so good. I got lucky and read that book after I had ported Lachman's streams based networking stack into the ETA-10 and SCO's Unix. I didn't know what I was doing but I had to get the job done, I was just dealing with shorts that weren't 16 bits, stuff like that. So I was a grunt thrashing around. At some point I wanted to know more about I was doing, I still have a notebook where I wrote down every packet format, all the IP stuff, TCP stuff, UDP stuff, ARP stuff, etc. Shout out to Masscomp because I was a sys admin on their machines in college and they had a great intro to networking that formed the basis of my limited understanding of networking. It was Padlipsky's book that brought the whole thing into focus. I dunno if you guys have had that clarity problem, I had it again when I went to Sun and was working on the kernel, had no idea what I was doing, thrashed about, and slowly, slowly, the architecture of what Sun had done came into focus. It was amazing to me when I got it. It took a lot of time just looking, reading the code, trying to see the picture. Padlipsky's book made me get networking long before I came to Sun, I was a n00b at everything and he made me get it. And it was funny as heck. "Do you want protocols that look nice or work nice?" "If you know what you are doing 3 layers are enough, if you don't 7 aren't" His book was full of that stuff and it made you get the stack. If you are into the network stack, and especially if you are trying to figure it out, get that book. In fact, if you contact me and say "that's me but I'm broke", I'll see if I can find a copy on ebay or some place and send it to you. That book rocks.
  - luckydude 9y ago
    If HN doesn't upvote this to the stars, you suck. It is the essence of what HN likes, it's great tech presented well. Go find that book, go read about Mike, come on people, dig a little. I don't care about the upvotes, I care that you go read. And read something that will help you see. Maybe this thread is dead and I need to do a top level post about Mike.
collinmanderson 9y ago
A little off topic, but the TCP BBR Congestion Control they mention looks promising. I've been annoyed by "Bufferbloat" for over a decade and find different solutions to the problem pretty fascinating. The nice part about this solution is that it doesn't require making changes to the individual nodes on the network (e.g. cable modem) in the way that other solutions have required (small and fair queues). It also appears to be able to avoid the usual packet-drops of regular TCP congestion control.
ChuckMcM 9y ago
It would be interesting to put that post into Genius and annotate its errors. At some level the premise is both true and false. I lived the IPV6 debate, I went to IETF meetings, I worked on network services that would be affected one way or the other, I debated with others the various ways to "improve" or "replace" V4 to get a better system. And all through that time, while everyone felt there would be billions and billions of IP addresses, I was not aware of any discussion of dynamic routing such that a network endpoint could be found anywhere in the world without configuration. For everyone at the time felt network infrastructure was fixed, and network clients moved. In that way a network client would move from one network to another, and then in that new network it would have to establish itself and then advertise somehow its new status. Everyone agreed that there would be some disruption during this change of status but things like TCP were designed to tolerate lossy networks. The network would adapt. That pre-supposes a lot of little networks, with their own sets of rules. Except that isn't the way cellular carriers think, they have one network and your relationship to it rarely changes. If you aren't on their network you are 'roaming' and there are fixed rules in place for that. So they trade a lot of tracking and management for ease of use on the customer. And it enables some annoying things like 'header injection' in Verizon's case. Dumb networks versus smart networks. AT&T's original switched network around the world vision versus Bob Metcalf's self organizing collection of independent nodes following a small set of rules. Architecturally its a debate that has been going on for a long long time.
betaby 9y ago
We have to stop IPv6 debate, it's already the reality. Even if you don't like it, even if you think it's ugly - doesn't matter. US IPv6 mobile traffic passed 50% some time ago https://engineering.linkedin.com/blog/2017/07/linkedin-passes-ipv6-milestone https://engineering.linkedin.com/blog/2017/07/linkedin-passe... IPv6 at least on mobile is real and many of us even didn't notice it's there.
feelin_googley 9y ago
Suprising to see a recommendation for QUIC by someone who seems to ackowledge djb's contributions and incredible attention to detail. http://apenwarr.ca/log/?m=201103#28 http://apenwarr.ca/log/?m=201103#28 Correct me if wrong, but QUIC was inspired by djb's CurveCP? Would you rather have djb implement your trusted UDP congestion-controlled overlay or a company with 70,000+ employees who are paid from the sale of online ads? @hashbreaker Apr 15 CurveCP's zero-padding (curvecp.org/messages.html) was designed years before ringroadbug.com, explicitly to stop that type of attack. http://ringroadbug.com http://ringroadbug.com Ring-Road Leaking Sensitive Data in Security Protocols What is Ring-Road? The Ring-Road Bug is a serious vulnerability in security protocols [e.g, QUIC but not CurveCP] that leaks the length of passwords allowing attackers to bypass user authentication. The Internet Engineering Task Force for HTTP/2 led by Google is working to create a patch to protect security protocols vulnerable to Ring-Road. Researchers a part of Purdue University identified a major security issue with Google's QUIC protocol (Quick UDP Internet Connections, pronounced quick).
therealwardo 9y ago
I gave a talk about a lot of the same concepts this piece covers - https://www.youtube.com/watch?v=g2czluHsmog https://www.youtube.com/watch?v=g2czluHsmog it has a more visual explanation of the OSI model and how it relates to routing and different kinds of hardware. I also tried to explain some of the interesting problems in actually building out a network in the second half of my talk. if anyone is just trying to learn the basics of networking I'd also strongly recommend the Juniper Networking Fundamentals online class, its free at https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=769 https://learningportal.juniper.net/juniper/user_activity_inf... or you can find videos of it on YouTube.
bullen 9y ago
I would like the extension of IPv4 to be that you have the option to specify the internal IP you are trying to reach too... so x.x.x.x:192.169.0.100 for example? That would be backwards compatible and give 8 bytes which is more than enough for all futures.
Hnrobert42 9y ago
The best post I've ever read on HN.
teh_klev 9y ago
There's quite a good (as usual) BBC Radio 4 "In Our Time" episode about Robert Hooke: http://www.bbc.co.uk/programmes/b070h6ww http://www.bbc.co.uk/programmes/b070h6ww

677 points by dbenamy 9y ago

>One person at work put it best: "layers are only ever added, never removed." Find this in the software world as well. Something about the java culture seems especially fascinated with multiple layers of abstraction. Edit: Ok, some factions of the culture. "Convenient proxy factory bean superclass for proxy factory beans that create only singletons"

nebabyte 9y ago
Computers don't understand concepts and people only do. Our gradual ascent from hardware to intuitively-usable mechanisms involves abstracting away the repeated "okay, given these primitives, here's how we'd use them" to go the next layer up.
- beagle3 9y ago
  But that's non necessarily a good way. It's the easy way out of "I don't like these details, so I'll try to hide them under something". A good abstraction is worth its weight in gold. A bad abstraction (the vast majority) is worth its weight in dung.
Terr_ 9y ago
Hopefully some of the static-strictness features in the language will offer people tools to remove layers of abstraction... if they can get permission from humans to do the refactoring :p
aidenn0 9y ago
Some infamous examples of such java classes (For some reason Spring always seemed to have more verbose names than other DI frameworks, which is saying something): SimpleBeanFactoryAwareAspectInstanceFactory SerializedEntityManagerFactoryBeanReference And this is totally not related to that sort of naming scheme, but in trying to remember those spring names, I stumbled upon this gem: http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.aspectj.matcher/src/org/aspectj/weaver/patterns/HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor.java http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.as...
- floatboth 9y ago
  http://java.metagno.me/ http://java.metagno.me/
moomin 9y ago
Speaking as a fan of C#, Clojure and Haskell, I'd say the problem is caused by having insufficiently powerful abstractions in the base platform. Phil Freeman has said that there are entire libraries on npm that just implement traverse.
kqr 9y ago
That is funny. I am doing some temporary consulting work in a Java shop. I created a layered and complicated solution to a complicated problem. I spent a lot of time defending the complexity of the solution as the necessity it was. When the requirements appeared to change, I was all like, "Are you sure about that? That's great news because that means we can remove these layers from my solution and simplify the code a lot." Apparently they had never heard about someone wanting to get rid of their own layers, because they just sat there in silence trying to come up with reasons to keep the (now) unnecessary layers. In the end, I think they agreed that the new requirements must be incorrect, and the old ones still cover both cases. Imagine that! Throwing away new requirements solely to keep layers.

mjevans 9y ago

Ok, so QUIC or some other common layer 4/4+5 'Modern TCP over UDP for network compatibility' solution. Lets just throw away the concept of 'addresses' for authentication and actually use a cryptographic authentication identifier of somekind, combined with some mux iteration ID.

__s 9y ago
Drop the idea of ports too. Every program gets its own IP Mentioning ideas like that at work get queer looks about how it'd be impossible to configure a firewall at that point But keep going further. End up with 128 bit CPU where every byte is IP addressable. Necessary security to block random outsiders from reading your memory, but capable of potentially running various parts remotely transparently
- mjevans 9y ago
  Not even IP. Source/destinations would both only be crypto identifiers. The multiplexing part is just a convenient way of expressing different data streams to simpler protocols for QoS and other activities. That does imply that there should be a way (possibly host to host, possibly build in to some kind of service resolution system) of looking up a 'name entry' and 'service type'.
- johncolanduoni 9y ago
  > But keep going further. End up with 128 bit CPU where every byte is IP addressable. Necessary security to block random outsiders from reading your memory, but capable of potentially running various parts remotely transparently This is already a thing: https://en.wikipedia.org/wiki/Remote_direct_memory_access https://en.wikipedia.org/wiki/Remote_direct_memory_access
  - dullgiulio 9y ago
    Cool, although the name sounds much more like a vulnerability than a feature.
- ComputerGuru 9y ago

beagle3 9y ago

I am very glad IPv6 didn't catch on. The world in which it was designed was not a world in which everyone (NSA, Google, Facebook) was trying to document and correlate every tiny thing you do, whether it is related to them or not. If IPv6 eventually becomes widespread, I hope it comes with ISPs that will let you replace your prefix, and phones/hardware that will randomize your suffix - otherwise, the internet becomes completely pseudonymous.

beagle3 9y ago
Would a down voter care to explain why I am so wrong in their opinion?
- azernik 9y ago
  Because a) statements in your comment are false, b) some proposals in your comment have already been implemented, and c) the ones that haven't are bad ideas. IPv6 has caught on (I'm commenting from an IPv6-only connection right now, on a residential US ISP). Most clients do perform RFC4941 suffix randomization. Replacing the prefix destroys one of the most useful features of IP addresses and in particular the larger IPv6 address space - routability (the property that getting to two addresses that share a prefix usually uses the same next-hop router).
  - beagle3 9y ago
    Thank you for taking the time to explain. Let me try to word things a little better: What is the percentage of US homes who are on an IPv6? What is the percentage of websites on IPv6? What are the number of web site hits that are IPv6 to IPv6? (in the US? in the world?) The highest estimate I've ever seen for any of these is less than 20%, which - 20 years into IPv6, is in my opinion "not caught on". The mobile world when 3G arrived preferred carrier-grade-NAT to IPv6 (which was technically a better solution), which is in my opinion "not caught on". Suffix randomization has been implemented, but is not universal in my experience; and it is essentially useless for privacy in one's home. It slightly blurs the distinction between my laptop and my son's iPad. And that's ALL it does. Right now I enjoy getting an address from a pool of 16K addresses every time I reset my cable modem; And it is likely to transition soon to a carrier-grade NAT which would give me even more privacy. It is likely that I should be taking crazy pills - I seem to remember the snowdens of yesteryear and facebook shadow profiles, which either I'm hallucinating or no one else seems to care about. On the other hand, I have a startup idea to profit from the impending v6-complete-lack-of-privacy that I should probably start working on. If you can't beat them, profit off them.

Aloha 9y ago

Part of the difficulty here - is you're not just upgrading the whole stack, you're instead layering on whatever stack is already there - its a needed part of deploying any new technology without replacing everything from the basement up. I'm not sure what this guy would do instead however - as someone with a decent networking background, I got completely lost in the end.

ktRolster 9y ago
Maybe you should read it again and let us know which of those options it is.
loeg 9y ago
The author has a verbose writing style, and may not be a genius, but they are clearly familiar with networking protocols and do a good job explaining the general scene and history.
- Aloha 9y ago
  I just disagree with some of his premise - I don't think its feasible to get away from any and all layer two broadcast messages - even limiting yourself to IPv6 Mulitcast still leaves you with some pseudo-broadcast messages for either housekeeping or auto-discovery purposes - its part of what makes IP based networking in general work - and I'm talking services that run at layer four - that rely on that primitive to exist to make certain functionality happen. Routing still adds complexity, and I see no way for it to not add complexity - he talks about each switch being a router for example - you then need a way to determine where a particular subnet you're trying to get to lies - which means a routing able (akin to a mac address table, but for prefix), and some way to feret out which interface a particular device lies (akin to arp, but instead searching for a prefix to route to) - in the end, you end up with the same primitives and complexity, but you've just moved it up a layer in the stack - which does nothing to get rid of complexity - it just adds to it. IP networks are often a tree in organizations - ethernet is often deployed with different topologies, relying to spanning-tree to give you more redundancy without extra configuration (at the expense of some delay on re-convergence) I think also that so long as we're dragging along the legacies of the disparate layer one technologies (which in any case, would not and could not go away) - we're kinda stuck with what we have.

ktRolster 9y ago

We'll switch to IPv6, and every service will still go through port 80.

ploxiln 9y ago
minor correction: port 443
deleted 9y ago
[deleted]
xroche 9y ago
And using a dozen of IPs most of the time (Google, Facebook, Youtube, etc.)

gridscomputing 9y ago

"QUEER"?!

josteink 9y ago
Don't be a triggered snowflake. Queer is a real, non-offensive word with a real, non-offensive meaning. https://duckduckgo.com/?q=queer+definition&t=ffip&ia=definition https://duckduckgo.com/?q=queer+definition&t=ffip&ia=definit...
- sctb 9y ago
  You can please leave out the name-calling while making your point, like the guidelines ask. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
sctb 9y ago
We detached this subthread from https://news.ycombinator.com/item?id=14986630 https://news.ycombinator.com/item?id=14986630 and marked it off-topic.

undoware 9y ago

Easily the best technical document I've ever read. Holy heck. "Now I see with pulse serene, the heart of the machine"

mulle_nat 9y ago
Somehow it's always old network guys, who write the best articles.

Animats 9y ago

What he's really arguing for is a circuit-switched network, so that connections can be persistent over moves. He just needs a unique connection ID. One amusing possibility would be to do this at the HTTPS layer. With HTTPS Everywhere, most HTTP connections now have a unique connection ID at the crypto layer - the session key. If you could move an HTTP connection from one IP address to another on the fly, it could be kept alive over moves. HTTPS already protects against MITM attacks, and if the transfer is botched or intercepted, that will break the connection. I'm not recommending this, but it meets many of his criteria. The trouble with low-level connection IDs that don't force routing is forgery. You can fake a source IP address, but that won't get you the reply traffic, so this is useful only for denial of service attacks. If you have connection IDs, you need to secure them somehow against replication, playback, etc.

runeks 9y ago
> One amusing possibility would be to do this at the HTTPS layer. With HTTPS Everywhere, most HTTP connections now have a unique connection ID at the crypto layer - the session key. As a network-ignoramus, who likes cryptography, I’ve long dreamt of a networking protocol where endpoints are defined, primarily, by a public key. All messages would be encrypted with the destination public key, and signed by the source private key. When a destination node receives a packet from a neighboring node, and ACK would constitute the destination node’s signature over the received packet, thus making ACKs provable and portable (“this node has already received that packet, here’s the proof”). Packet sources addresses would no longer be fake-able, as that would constitute breaking asymmetric cryptography. The protocol would have no concept of a “connection”. Routing would be left out of this protocol completely, and networks would use whichever routing protocols they find most efficient. I wouldn’t be surprised if there were countless issues with a protocol like this, but something about it just seems so elegant to me that I haven’t stopped considering it yet.
- apenwarr 9y ago
  You should read about QUIC, which is designed to be able to do this, almost exactly like you describe. https://www.chromium.org/quic https://www.chromium.org/quic

akshayn 9y ago

"If, instead, we had identified sessions using only layer 4 data, then mobile IP would have worked perfectly." Mobile IP can still work with the current infrastructure -- https://en.wikipedia.org/wiki/Mobile_IP https://en.wikipedia.org/wiki/Mobile_IP This proposal was basically a service which would host a static IP for you (similar to the LTE structure but with IP underneath instead of L2), and forward to whatever your "real" IP was using IP-in-IP encapsulation. As the author states, layers are only ever added :)

apenwarr 9y ago
That's basically just an IPIP tunnel. It works, but adds tons of latency. A "good" mobile IP (which would be possible with eg. QUIC) would add no per-packet latency.
- Dagger2 9y ago
  Correspondent node functionality in Mobile IPv6 does exactly that, by sending the packets directly between the two nodes involved. Basically it works by associating the connection with a 128-bit GUID instead of with the node's current network address, which allows the network address to change without breaking connections. So... basically exactly what the suggested solution would look like, if it was modified to work with all protocols and not just TCP/UDP.

femto 9y ago

The "Internet Mobile Host Protocol" (IMHP) was written as a draft RFC in 1994. As far as I know it was never adopted, but is it still relevant, even as an inspiration for IPv6? [1] https://www.cs.rice.edu/~dbj/pubs/draft-johnson-imhp-00.txt https://www.cs.rice.edu/~dbj/pubs/draft-johnson-imhp-00.txt Edit: Its official entry at the IETF: https://datatracker.ietf.org/doc/draft-johnson-imhp/ https://datatracker.ietf.org/doc/draft-johnson-imhp/

fumigator 9y ago

I just read in New Scientist mag that the Internet was developed to survive a nuclear attack. I recall reading somewhere that one of the original inventors has stated that the issue never came up. I can't find the exact quote, could anyone here help me out. ppps: OK, found it, "the creation of the ARPANET was not motivated by considerations of war", Robert Taylor 2004 https://motherboard.vice.com/en_us/article/d77k7j/dear-internet-you-were-invented-by-the-government https://motherboard.vice.com/en_us/article/d77k7j/dear-inter... ref: https://www.newscientist.com/article/mg23531383-300-we-can-stop-hacking-and-trolls-but-it-would-ruin-the-internet/ https://www.newscientist.com/article/mg23531383-300-we-can-s... ps: Is IPV6 a bit like a camel, as in, a camel is a horse designed by committee :) pps: This has to be the only forum on the Internet where you get modded down for a) asking a question and b) making a joke. I didn't figure my comment could trigger any camels, committees or horses reading this. https://www.newscientist.com/ https://www.newscientist.com/

peterburkimsher 9y ago

That is a beautifully-written article. The IEEE hardware and IETF software guys have been busy adding complexity to the networks, with so many legacy protocols (when everyone just uses TCP/IP) and extra ports (when everything happens on port 80 - seriously, even email is now on cloud services). I can't get LTE because of political problems. So I just gave up trying to be online, and started caching everything possible. Meanwhile, storage is getting larger capacity, smaller size, and cheaper. I've got a 512GB SD card in my pocket all the time, with a backup of my laptop in case my bag gets stolen. My phone does everything offline if possible. Offline MP3 music. Offline maps. Wikipedia. StackOverflow. Hacker News. FML. UrbanDictionary. XKCD. The few YouTube videos I actually want to see again. The only thing I need Internet for is communication. To send a message, I walk around looking for open WiFi and type my message to them on Facebook Messenger. If they need to reach me urgently, they can just use my phone number (which keeps changing every 6 months for the same political problems). What if access points had large caches with mirrors of the content people want? Instead of asking Google's server in the US to send me a map tile, what if I could just get it from the local WiFi AP's web server? It would be much faster, and save so much trouble with networking. Sure, there are some things that people need the network for (e.g. new content, copyrighted material). But so much else is free of licenses, and would be possible to mirror locally everywhere.

isostatic 9y ago
One look at ntop tells me very little of our traffic is port 80 or 443
arcbyte 9y ago
+1 for thinking outside the box

marasal 9y ago

This was a great read.

hueving 9y ago

>In truth, that really is just complicating things. Now your operating system has to first look up the ethernet address of 192.168.1.1, find out it's 11:22:33:44:55:66, and finally generate a packet with destination ethernet address 11:22:33:44:55:66 and destination IP address 10.1.1.1. 192.168.1.1 is just a pointless intermediate step. This is completely wrong, it's not pointless. First, this can be used to easily swap out routers in a network without reconfiguring any clients or even incurring downtime. Without the intermediary gateway IP representation, this would mean you would either have to spoof the MAC on the second router or reconfigure all of the clients to point to the new gateway. Second, ethernet addresses are a layer-2 construct and IP routes are a layer 3 construct. Your default gateway is a layer-3 route to 0.0.0.0/0. There are protocols for exchanging layer-3 routes like BGP/RIP/etc that should not have to know anything about the layer-2 addressing scheme to provide the next-hop address. Third, routers still need to have an IP address on the subnet anyway to originate ICMP messages (e.g. TTL expired, MTU exceeded, etc). Fourth, ARP is still necessary even for the router itself to know how to take incoming IP traffic from the outside and actually forward it to the appropriate device on the local network. Otherwise you would have to statically configure a mapping of local IP addresses to MAC addresses on the router. So ARP is critical for separation of concerns between L2 and L3. We don't live in an ethernet-only world. >excessive ARP starts becoming one of your biggest nightmares. It's especially bad on wifi. Broadcast can become a nightmare. Excessive ARP is a drop in the bucket compared to other discovery crap that computers spew onto networks. The pattern of most computers now is to communicate with the external world (from the LAN perspective) and not much else. So on a network of 1000 computers (an already excessively large broadcast domain), your ARP traffic is going to be a couple of thousand ARP messages every few hours. If this is taking down your WiFi network, you have much bigger problems considering all of those are about a modern webpage load of traffic.

lwansbrough 9y ago
> This is completely wrong, it's not pointless. Pretty reliable rule of software is: if you think it's pointless you probably don't understand it well enough.
- pjmorris 9y ago

hueving 9y ago

>They have to be special, because an IP node has to be able to transmit them before it has an IP address, which is of course impossible, so it just fills the IP headers with essentially nonsense Not nonsense! The global IP broadcast is specified as 255.255.255.255 and is used by other protocols. The source IP address for the initial discovery is indeed 0.0.0.0, which is not intuitive, but the rest of the DHCP exchange is handled with real IP addresses like normal IP traffic. DHCP is very much an IP protocol (see DHCP relay for how it transits IP networks). >Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that. Ugh, come on! RARP doesn't provide you with a route to get out of the network or other extremely useful things like a DNS server. >and DHCP, which is an IP packet but is really an ethernet protocol, and so on. No, it's not an ethernet protocol. It's a layer-3 address assignment protocol that runs inside of IP, which is normally encapsulated in ethernet frames. You can have a remote DHCP server running any arbitrary L2 non-ethernet protocol and if it receives a relayed DHCP request it will reply with IP unicast perfectly fine with no ethernet involved.

azernik 9y ago
In fact, most residential ISP modems run DHCP over whatever their L2 technology is - cable or DSL.
- dom0 9y ago
  DSL usually uses PPPoA (or PPPoE in a MPoA tunnel like below) over a subset of ATM (=DSL). PPP itself transports IP and provides configuration. When modem and router are separate, the modem only provides an MPoA tunnel to provide Ethernet access to the DSL link, while the router connects to the AC via PPPoE over said tunnel.
  - Hikikomori 9y ago
    Another common option is RFC 1483 bridging (IPoEoATM) where DHCP is typically used for address assignment.

okket 9y ago

> Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that. Actually, no. You can only set an IP address with RARP, not even a netmask (RARP comes from pre-CIDR age) or other important stuff like default gateway, DNS server, etc like you can with DHCP.

bluGill 9y ago
Right, but those are all things we are not talking about here, so RARP worked just fine.

hueving 9y ago

>Network operators basically choose bridging vs routing based on how fast they want it to go and how much they hate configuring DHCP servers, which they really hate very much, which means they use bridging as much as possible and routing when they have to. Very rarely does a network operator use bridging to avoid configuring DHCP. All modern protocols are built on IP so you still need an addressing scheme and most people want the Internet so the 169 auto addressing is out. So even in big bridged networks, you still have a DHCP server. In fact, you configure less DHCP in a big bridged network than DHCP for a ton of tiny networks. The advantage to big bridging networks is that you have to setup very little routing (just the router to get in and out). If you routed between every port on the network, there would be an excessive amount of configuration involved to setup prefixes on every single interface.

hueving 9y ago

>And nowadays big data centers are basically just SDNed, and you might as well not be using IP in the data center at all, because nobody's routing the packets. It's all just one big virtual bus network. The opposite trend is true in large data centers. L3 fabrics where everything is routed have become extremely popular because BGP (or custom SDN setups) can be used to migrate IPs and you get to utilize multiple paths (rather than the single path offered by STP convergence).

Duckeh 9y ago
But then you're tunneling your L2 across your L3. So if you provide connectivity to a customer in a datacenter all they'll see is the L2. But you're right. Underneath everything is an IP fabric these days.
imbriaco 9y ago
This is extra delicious irony given the fact that the typical, and often only, requirement for these SDN layers is IP connectivity.
Natales 9y ago
Exactly. Virtually all new DCs are being build using Leaf-Spine architectures that leverages pure IP routing and optimize for East-West traffic internally. I'm also starting to see the rapid proliferation of L3-only SDN systems like Project Calico [1] in fairly large Fortune 100 companies, for any sort of end point, particularly containers these days. [1] https://www.projectcalico.org/learn/ https://www.projectcalico.org/learn/

tardo99 9y ago

What if the server needs to send you a packet while you're mobile but you haven't sent it a packet yet so it can update its cache? That packet will be lost in his scheme. Nice try.

dcposch 9y ago
IP is best effort. Packets get lost all the time. Higher protocols, like TCP and QUIC, all handle packet loss--typically by trying again. Losing a packet is better than losing all open connections.
- elihu 9y ago
  I think it may be worse than a lost packet, though. If the destination host is truly gone from that network, the nearest router might reply that no such computer exists, causing the socket to be disconnected. (It's been awhile since I've studied TCP/IP; I'm not sure what the exact correct reply would be...) Perhaps this could be mitigated by adding a timeout that keeps sockets alive for awhile in case the destination shows up somewhere else.
zAy0LfpBZLC8mAC 9y ago
In a sensible (i.e., NAT-free) world, the end point knows when its global address changes, which it can use to trigger an address update to its peer.

seanwasere 9y ago

utilise port numbers. and cue the port number fascists

anilgulecha 9y ago

One big UX mistake of IPv6: it was not made backward compatible with IPv4. (v6)0.0.192.168.1.10 == 192.168.1.10(v4). This simple design when planning and rolling it out would have meant incrementally updating the networking stack to also support v6. Now it turns out v4 and v6 are completely different, and no one has a big enough reason to make the change until everyone else makes the change. Hard chicken-egg problem.

okket 9y ago
Backwards compatibility can not work. You can not answer an IPv6 packet with IPv4. There is no room in the header for the much bigger source/return address. You can try to do hacks like NAT (like you probably do in your home IPv4 network, which breaks/stops any peer-2-peer protocol). The IPv6 version is called DNS64/NAT64, and it breaks even more things, e.g. DNSSEC. Because it not only requires network address translation (lying about your IP), but also rewriting DNS records (lying about signed DNS records). The only sane way forward is get rid of IPv4 as fast as possible (even if 'fast' means a decade or two).
- mSparks43 9y ago
  IPv4 + NAT is much more sane than IPv6 IMHO. Seriously, it should not be the default that every single device on your network is visible to the great wide world. Therein be demons. Especially not all these internet of things devices that any script kiddy can make surrender all its secrets. Plus, have you ever actually even tried a setup of an IPv6 local network? You try typing 2001:0db8:85a3:0000:0000:8a2e:0370:7334 into the address bar 50 times in a week to tweek router settings and see how enamoured you are with the protocol. Furthermore, you know whats easier to type in? rrcc5uuudhh4oz3c.onion
- anilgulecha 9y ago
  I don't mean it that way. Yes, on-the-wire format would have changed, maybe there would have been a required transition from v4 to v4.1, which could then have been backward compatible to v6. To be fair, I don't think the authors of v6 at the time realized how much friction an alternative IP stack would cause.

mirimir 9y ago

I found the piece informative and entertaining. But I'm not technical enough to comment much. I would have liked to see what he thought of MPTCP as a replacement for TCP.

killjoywashere 9y ago

Bookmark

_pmf_ 9y ago

> To save on electronics, people wanted to have a "bus" network It was also to save sanity and avoiding having to rip apart every office building for installing hundreds of cables.

Hikikomori 9y ago

Interesting article, but it contains some weird statements. >It is literally and has always been the software-defined network you use for interconnecting networks that have gotten too big. But the problem is, it was always too hard to hardware accelerate, and anyway, it didn't get hardware accelerated, and configuring DHCP really is a huge pain, so network operators just learned how to bridge bigger and bigger things. IP forwarding (longest prefix match) is more complicated than mac forwarding yes, but it has been done in hardware (ASICs, typically NPUs today) for a long time now. Operators (I assume ISPs) do not build large bridged networks as they need their networks to scale as they grow, or they will hit a breaking point where their network collapses. ISP's typically use centralised DHCP servers (as opposed to configuring their access routers) and configure their routers to use DHCP relay. DHCP server configuration is easily automated by just reading your IPAM data, it's a non-issue.

fundabulousrIII 9y ago

This article was some of the most egregious nonsense I've read in a while.

davidreiss 9y ago

Is anyone else shocked at the low level of adoption of IPv6? I remember how in the late 90s people were saying we were going to run out of addresses and everyone need to migrate to IPv6 ASAP. Now, it seems that IPv4 is going to be around for a long while.

laythea 9y ago
not shocked.
marcosdumay 9y ago
Keep in mind that we are currently running out of IPv6 addresses. The slow adoption is pushed by entities that control a big number of IPv4 addresses. I have no idea how long this situation can sustain itself.
- mrunkel 9y ago
  Citation needed for both wild statements.
betaby 9y ago
US IPv6 adoption is above 50% for mobile networks. Wouldn't call it 'low level'

djrogers 9y ago

mritun 9y ago
What he is saying is that in a routed network (instead of bridged), you don't need MAC address. At least not at layer 2.

noahl 9y ago

This was a very informative article for me, but there was one thing I didn't understand. At the end he made the case that mobile routing needed essentially two layers: a fixed per-device (or per session) identifier, and then a separate routing-layer address that could change as a device moved. QUIC has session identifiers, and that's great and could solve the problem. But earlier in that very article, he already pointed out that every device already has a globally unique identifier used in layer 2 routing ... the ethernet MAC address. Would someone please explain to me why we can't use MAC addresses as globally unique device IDs? (Is MAC spoofing the issue?)

ajdecon 9y ago
Among other reasons: there are still a fair number of non-Ethernet devices with IP addresses out there...
ara24 9y ago
I think, he explains it early in the article, "The problem with ethernet addresses is they're assigned sequentially at the factory, so they can't be hierarchical. That means the "bridging table" is not as nice as a modern IP routing table, which can talk about the route for a whole subnet at a time."
scurvy 9y ago
MACs aren't unique and can be changed. Certain fly by night Asian manufacturers just make up MACs randomly. It's a big problem with counterfeit gear, too. They are supposed to be unique, but in the real world they are not.
nayuki 9y ago
In theory we can use MAC addresses, but there are problems: 0) Privacy: You don't want all traffic to be labeled with your hardware ID. 1) Flatness: MACs are essentially random, and a router would need a huge table to keep track of who's where. IP (v4/v6) assigns addresses hierarchically, making routing tables manageable.
- noahl 9y ago

deleted 9y ago

[deleted]

luckydude 9y ago

This is an awesome read and hilarious if you have any historical knowledge of networking. +1 highly recommend even if all you want is a few chuckles. Well done.

luckydude 9y ago
BTW, the best read in networking is "The Elements of Networking Style" by Mike Padlipsky. https://en.wikipedia.org/wiki/Michael_A._Padlipsky https://en.wikipedia.org/wiki/Michael_A._Padlipsky It's hard to find a copy of that book but oh, man, if you know the stack and you lived through the ISO/OSI proposals, it's so so good. I got lucky and read that book after I had ported Lachman's streams based networking stack into the ETA-10 and SCO's Unix. I didn't know what I was doing but I had to get the job done, I was just dealing with shorts that weren't 16 bits, stuff like that. So I was a grunt thrashing around. At some point I wanted to know more about I was doing, I still have a notebook where I wrote down every packet format, all the IP stuff, TCP stuff, UDP stuff, ARP stuff, etc. Shout out to Masscomp because I was a sys admin on their machines in college and they had a great intro to networking that formed the basis of my limited understanding of networking. It was Padlipsky's book that brought the whole thing into focus. I dunno if you guys have had that clarity problem, I had it again when I went to Sun and was working on the kernel, had no idea what I was doing, thrashed about, and slowly, slowly, the architecture of what Sun had done came into focus. It was amazing to me when I got it. It took a lot of time just looking, reading the code, trying to see the picture. Padlipsky's book made me get networking long before I came to Sun, I was a n00b at everything and he made me get it. And it was funny as heck. "Do you want protocols that look nice or work nice?" "If you know what you are doing 3 layers are enough, if you don't 7 aren't" His book was full of that stuff and it made you get the stack. If you are into the network stack, and especially if you are trying to figure it out, get that book. In fact, if you contact me and say "that's me but I'm broke", I'll see if I can find a copy on ebay or some place and send it to you. That book rocks.
- luckydude 9y ago
  If HN doesn't upvote this to the stars, you suck. It is the essence of what HN likes, it's great tech presented well. Go find that book, go read about Mike, come on people, dig a little. I don't care about the upvotes, I care that you go read. And read something that will help you see. Maybe this thread is dead and I need to do a top level post about Mike.

collinmanderson 9y ago

A little off topic, but the TCP BBR Congestion Control they mention looks promising. I've been annoyed by "Bufferbloat" for over a decade and find different solutions to the problem pretty fascinating. The nice part about this solution is that it doesn't require making changes to the individual nodes on the network (e.g. cable modem) in the way that other solutions have required (small and fair queues). It also appears to be able to avoid the usual packet-drops of regular TCP congestion control.

ChuckMcM 9y ago

It would be interesting to put that post into Genius and annotate its errors. At some level the premise is both true and false. I lived the IPV6 debate, I went to IETF meetings, I worked on network services that would be affected one way or the other, I debated with others the various ways to "improve" or "replace" V4 to get a better system. And all through that time, while everyone felt there would be billions and billions of IP addresses, I was not aware of any discussion of dynamic routing such that a network endpoint could be found anywhere in the world without configuration. For everyone at the time felt network infrastructure was fixed, and network clients moved. In that way a network client would move from one network to another, and then in that new network it would have to establish itself and then advertise somehow its new status. Everyone agreed that there would be some disruption during this change of status but things like TCP were designed to tolerate lossy networks. The network would adapt. That pre-supposes a lot of little networks, with their own sets of rules. Except that isn't the way cellular carriers think, they have one network and your relationship to it rarely changes. If you aren't on their network you are 'roaming' and there are fixed rules in place for that. So they trade a lot of tracking and management for ease of use on the customer. And it enables some annoying things like 'header injection' in Verizon's case. Dumb networks versus smart networks. AT&T's original switched network around the world vision versus Bob Metcalf's self organizing collection of independent nodes following a small set of rules. Architecturally its a debate that has been going on for a long long time.

betaby 9y ago

We have to stop IPv6 debate, it's already the reality. Even if you don't like it, even if you think it's ugly - doesn't matter. US IPv6 mobile traffic passed 50% some time ago https://engineering.linkedin.com/blog/2017/07/linkedin-passes-ipv6-milestone https://engineering.linkedin.com/blog/2017/07/linkedin-passe... IPv6 at least on mobile is real and many of us even didn't notice it's there.

feelin_googley 9y ago

Suprising to see a recommendation for QUIC by someone who seems to ackowledge djb's contributions and incredible attention to detail. http://apenwarr.ca/log/?m=201103#28 http://apenwarr.ca/log/?m=201103#28 Correct me if wrong, but QUIC was inspired by djb's CurveCP? Would you rather have djb implement your trusted UDP congestion-controlled overlay or a company with 70,000+ employees who are paid from the sale of online ads? @hashbreaker Apr 15 CurveCP's zero-padding (curvecp.org/messages.html) was designed years before ringroadbug.com, explicitly to stop that type of attack. http://ringroadbug.com http://ringroadbug.com Ring-Road Leaking Sensitive Data in Security Protocols What is Ring-Road? The Ring-Road Bug is a serious vulnerability in security protocols [e.g, QUIC but not CurveCP] that leaks the length of passwords allowing attackers to bypass user authentication. The Internet Engineering Task Force for HTTP/2 led by Google is working to create a patch to protect security protocols vulnerable to Ring-Road. Researchers a part of Purdue University identified a major security issue with Google's QUIC protocol (Quick UDP Internet Connections, pronounced quick).

therealwardo 9y ago

I gave a talk about a lot of the same concepts this piece covers - https://www.youtube.com/watch?v=g2czluHsmog https://www.youtube.com/watch?v=g2czluHsmog it has a more visual explanation of the OSI model and how it relates to routing and different kinds of hardware. I also tried to explain some of the interesting problems in actually building out a network in the second half of my talk. if anyone is just trying to learn the basics of networking I'd also strongly recommend the Juniper Networking Fundamentals online class, its free at https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=769 https://learningportal.juniper.net/juniper/user_activity_inf... or you can find videos of it on YouTube.

bullen 9y ago

I would like the extension of IPv4 to be that you have the option to specify the internal IP you are trying to reach too... so x.x.x.x:192.169.0.100 for example? That would be backwards compatible and give 8 bytes which is more than enough for all futures.

Hnrobert42 9y ago

The best post I've ever read on HN.

teh_klev 9y ago

There's quite a good (as usual) BBC Radio 4 "In Our Time" episode about Robert Hooke: http://www.bbc.co.uk/programmes/b070h6ww http://www.bbc.co.uk/programmes/b070h6ww