1. 77
  1.  

  2. 27

    I like apenwarr’s writing in general, so it is painful and irritating that this article’s history of Ethernet networking and IP(v4) on Ethernet is utterly wrong, with events completely out of order. IP(v4) was being used on Ethernet by the early 1980s (RFC 826 for ARP dates from November 1982, for example), which is far before IPX and Netware and other LAN-only PC networking protocols were created. Even the start of IPv6 work predates much of the 1990s PC LAN networking boom (it began around 1992).

    It may be apenwarr’s intention to present things as a just-so story instead of history, but if so I wish it was far more explicitly labelled as such.

    1. 16

      One person at work put it best: “layers are only ever added, never removed.”

      That just stings so painfully true.

      1. 7

        Every problem in computers can be solved with another level of abstraction–except for the problem of too many levels of abstraction!

        1. 5

          Nonono, I don’t need to care about those five layers there. By using a layer of abstraction to hide that those layers exist, I can make it look like there are only three layers instead of seven.

      2. 12

        Why is IPv6 such a complicated mess compared to IPv4? Wouldn’t it be better if it had just been IPv4 with more address bits?

        Do people really feel that way? To me, IPv6 seems to be a lot better designed for today’s use, even when there’s still a separate Layer 2 protocol below. To increase address lengths, you’d have to re-specify IPv4 and all its supporting protocols anyways. Going for an integrated solution where address autoconfiguration “just works” and where multicast isn’t just an afterthought looks like the best course of action to me.

        I feel like most people think of IPv6 as “complicated” mostly because they already know IPv4 well and IPv6 actually is different. I wish e.g. university courses would teach IPv6 as the main protocol and not in terms of changes from IPv4.

        1. 6

          The argument I see more often (e.g. from djb, whose opinions I generally respect) is that IPv6 was designed without sufficient consideration for how the transition would happen in practice. The better choice, according to djb, would have been to embed the entire IPv4 address space in the IPv6 space, thereby allowing interoperability.

          1. 2

            I agree, but for a lot of people day one is confusing as it is natural to have more than a single IP address, it is quite normal to have five or more pubically routable ones in addition to the link layer address. This actually solves a pile of technical real problems (ie. HA for LAN routing without VRRP).

            I am unaware of any documentation that describes what to expect and cool new topologies you can call upon. This documentation also does not exist for IPv4, but that’s the devil we know, right?

            Now throw in that until recently, since some governments mandated IPv6 support during procurement, that vendor support was straight up awful; arguably some would say it still is…Cisco I am looking at you.

            Add to that you often pay a premium either in time, money or both to obtain native IPv6 connectivity

            PI space and local LAN addressing (a la RFC1918) for IPv6 is a really recent thing too.

            So to a lot of people nothing really still works and it takes some mental work to realise that you often end up doing more work to light up an IPv4 service. That work though in our minds it is latent that we are all used to; NAT, renumbering, deep packet inspection for connection tracking, service design with rendezvous points (STUN/TURN) and central servers, etc.

            What vexes me though is that IPv6 multicast over the Internet is next to non-existent; anyone know who does xDSL to the home with this?

            I would have really like to see the collaboration (and game benefits) of such support. Plus, legal issues aside, you could run a radio/TV stream from your home as a hobby.

              1. 2

                I am unaware of any documentation that describes what to expect and cool new topologies you can call upon. This documentation also does not exist for IPv4, but that’s the devil we know, right?

                Now throw in that until recently, since some governments mandated IPv6 support during procurement, that vendor support was straight up awful; arguably some would say it still is…Cisco I am looking at you.

                Add to that you often pay a premium either in time, money or both to obtain native IPv6 connectivity

                Would any of this really have been any less true with an IPv4v2 though? You’d have had the awful initial vendor support to accommodate government mandates, the unfamiliarity with the new thing, the software that needed rewriting to accommodate the longer addresses, etc

                It just seems like almost every complaint about IPv6 boils down to “it’s not a mature protocol” and short of literal magic making more than 32 bits worth of address fit into IPv4 that would have been true no matter what.

                1. 1

                  Would any of this really have been any less true with an IPv4v2 though?

                  I am quite certain it would have been.

            1. 11

              On an unrelated note, the author really got into my good books when his page ended with “Why would you follow me on twitter? Use RSS.”

              (I bemoan not the existence of Twitter, but the decline of RSS.)

              1. 3

                I wonder what he’d make of “Patterns in Network Architecture by John Day

                It’s a book that I truly wish that had one tenth of the words it does….

                …but somewhere down there are some good ideas.

                I will let you know when I have them cornered well enough to utter in a few terse notes.

                Trying to “Do It Right” is what these guys are up to… http://pouzinsociety.org/

                1. 1

                  Thanks for the pointer! This is really interesting stuff.

                  You may find cjdns and hyperboria worth looking into as well.

                2. 1

                  QUIC is cool, but is updating TCP really impossible? Multipath TCP is a thing, and Apple is already using it for Siri.

                  1. 4

                    MTCP does not solve the stalling flow problem (head of line blocking) due to packet loss and waiting on that retransmit to get through.

                    QUIC also has a 0 (zero) RTT cryptographically secure(ish) HTTP request mode; akin to the whole TCP 3 way handshake, SSL handshake and HTTP request rolled up into a single compact UDP packet so the request is serviced immediately by the server.

                    1. 5

                      QUIC annoys me, because it’s a massive layering violation. It bakes in HTTP, when all I want is a better TCP – Something like CurveCP, which has zero roundtrips, and does encryption and authentication in one go.

                      1. 5

                        Guess you hate BTRFS and ZFS too?

                        I don’t think Google designed QUIC for you, so kinda irrelevant what you want or what I want :-)

                        Besides you said you have CurveCP so what is the problem?

                        CurveCP violates ‘layering’ in the same way that QUIC does, so I am not sure what you mean here? Nothing about QUIC prevents you sending non-HTTP traffic over it. QUIC is more a DCCP+DTLS+TLSv1.3-RTT0 rolled into one; done outside of the IETF initially as it was a prototype that no-one knew what would work?

                        What would you have done differently to avoid layering violation and to make your entire service (inc browser support) 0RTT in a span of months?

                        If you wanted to gripe about something you should probably grumble about DCCP/SCTP, but then this ignores the sane technical reasons QUIC (and CurveCP) violate these layers is because of all the god awful middleware that make up the routing hops.

                        If you have the time, read about RINA and also the fun presentation by John Day title Shortening the Dark Ages of Networking (.mov)…it might sway your opinion to maybe that layering is actually sometimes the problem. :-)

                        1. 1

                          maybe long-term public keys could be a replacement for ip numbers.

                          1. 1

                            What are your thoughts on routing and what does a public key improve on over an 2^80 IP block allocation?

                            1. 1

                              If it’s all public keys, encryption is the default (although with tiny keys).

                              1. 1

                                What advantages does this have over just setting a reverse DNS lookup record and including the public key in something like a TXT RR or maybe some formalised X509 RR?

                                We could do this with IPv4 today, but as no one is I am not really sure what this would solve over host transport IPsec?

                                Plus routing is the hard part of a protocol…not how many bits are in the address or if you slip something cryptographic in there, surely?

                              2. 1

                                Definitely not thought through: but public key can be self allocated and works well in a encrypt-by-default world. You’d need something like dns …

                              3. 1

                                networking ASIC designers would like to have a few words with you…