back to article APNIC: Big Tech's use of carrier-grade NAT is holding back internet innovation

Carriers and Big Tech are happily continuing to use network address translation (NAT) and IPv4 to protect their investments, with the result that transition to IPv6 is glacial while the entire internet is shaped in the image of incumbent players. That's the opinion of Geoff Huston, chief scientist at regional internet registry …

  1. Pascal Monett Silver badge
    Windows

    That old chestnut

    We're running out of IPv4 addresses ! We must transition to IPv6 !

    Oh really ? Why ?

    IPv4 still works.

    When I'm running out of nails, I don't start thinking about buying a new hammer.

    Besides, all that IoT shit works on IPv6, right ? That'll transition things for you just fine.

    1. Fred Daggy Silver badge
      Childcatcher

      Re: That old chestnut

      IPv6 has really lost the marketing war. It may be a technically superior solution (perhaps, depending upon your problem).

      If one accepts that IPv4 address space is the biggest issue, then the next IPvX just needs to address that problem. Backwards compatibility would be a issue - but there are solutions. IPv4 is NOT going to go away overnight - $ billions in infrastructure currently exist, anything that follows had better work with that.

      Not to say IPv4 is perfect.

      1. AMBxx Silver badge
        Windows

        Re: That old chestnut

        Maybe if they hadn't made IPv6 so effing complicated, we'd have all switched years ago.

        I'm not a network bod, but I do have some involvement in some network stuff. I've still not plucked up the courage to spend a load of time understanding what IPv6 is all about, so I stick to v4.

        1. tip pc Silver badge

          Re: That old chestnut

          The basics of ipv6 are the same as ipv4, they are both hierarchical.

          IPv6 has far more address space, you will still use the left most portions to know where to send your stuff and the right most gets you closer to the host.

          Complications come when you find you need to replace things that work perfectly fine in ipv4 with new concepts and procedures in ipv6 that don’t quite work the same or need an extra step.

          When you have thousands of servers and routers that need work to run ipv6 to do exactly what it does with ipv4 you wonder if it’s all worth the effort.

        2. Old Used Programmer

          Re: That old chestnut

          I suspect that there are a very large number of people in that same position. Millions that have given up on figuring out IPv6, so they're content to just stick with IPv4 as long as it works.

          1. teknopaul

            Re: That old chestnut

            I see a big problem with IPv4 and Nat is that it breaks push. You can push over nat just pull.

            That means essentially either each app does polling (battery intensive) or you use Apple/Google proprietary services.

            Apple/Google are very happy about that I'm sure but it's not in Internet citizens interest.

            IMHO Ipv4+nat works for Google/Apple but it doesn't work for you.

            1. Charles 9

              Re: That old chestnut

              Ever thought about things like the Ping of Death? Do you really want to be pwned by a push?

              1. bombastic bob Silver badge
                Linux

                Re: That old chestnut

                it is true that ALL IPv6 addresses are public. Without adequate built-in firewall and network stack reliability in windows workstations and servers (your 'ping of death' comment for example) universal IPv6 rollout could be THE reason why ISPs do not want to support it, translating into "not available".

                I've had an IPv6 tunnel for (probably) more than a decade. I think it was 2010-ish when I set it up through a free tunnel service. Works fine.

                (and I very carefully firewall the incoming IPv6 knowing the effect of publicly visible IPv6 addresses on any windows machines that might be running - all of those OPEN PORTS)

            2. Alan Brown Silver badge

              Re: That old chestnut

              IPv4 via NAT is semi-broken

              IPv4 over multiple levels of NAT is badly broken and a nightmare - even web pages can take minutes to update

              Half of Asia can ONLY get online via multiple levels of NAT (at one point the entire country of Vietnam was on one /24), whilst western countries mostly have adequate IPv4 holdings. I've had connections in Myanmar and Laos which make 300bps modems look snappy

              CGN suits telcos and The Powers That Be (TPTB) because it converts a two-way communications system into a mostly-broadcast one of centralised control (essentially cutting off endpoints from hosting their own resources as globally accessible entities) - you can think of this as a "Great Firewall" without the political controversy

        3. Anonymous Coward
          Anonymous Coward

          Re: That old chestnut

          Seriously?

          You chastise IPv6, yet you admit to not having spent much time with it?

      2. Anonymous Coward
        Anonymous Coward

        Re: That old chestnut

        Get used to it.

        People like you may be slowing the takeover by IPv6, but it's going to happen.

        There will be no "IPv7" until IPv6 has become lacking - and when in the future that happens, IPv4 will already be long dead.

        1. MrBanana

          Re: That old chestnut

          "There will be no "IPv7" until IPv6 has become lacking"

          It already is lacking, that's the issue. Maybe we're at the point of skipping a broken generation, that was never embraced by the major players, and thinking of something else.

          1. teknopaul

            Re: That old chestnut

            Yeah but what?

            Google are happy that all push to Android goes via them. Apple likewise.

            If you ask me it is efficient push that's missing from Internet infra and currently that needs fixed IPs, nat breaks it. Or you have to wake your phone for each app and poll. IPv4 plus nat just doesn't work and with Google and Apple happy about that everyone loses except them. If you try to poll they flag up your app as "inefficient".

            If your device had at least a semi permanent Internet routeable address without Google/Apple involvement you have some chance of breaking the monopoly.

            As it is you can't really write apps without Play.

            Big tech won't change without a hefty incentive or a direct order.

        2. Alan Brown Silver badge

          Re: That old chestnut

          IPv7 (TP/IX - RFC 1475) and IPv9 (TuBA - RFC1347) were are both attempts to extend IPv4 which broke its backwards compatibility whilst being more complicated and less usable than IPv6

          IPv5 and 8 were voice protocols and merged into SIP

          NAT "firewalls" are dangerous coincidences (They're an artifact of the translation process, not an actual firewall) and anyone relying on NAT for protection is simply counting down to WHEN they get pwned, not IF

          (TuBA encapsulated IPv4 in CLNP packages, TP/IX extended addressing AND port ranges)

          Ironically, IPv4 was originally proposed with 128-bit addressing but shouted down as being too big for a research network with v4 intended for a 5-year lifespan

          The basic problem is that no matter _how_ you slice it, adding address space breaks IPv4 - IPv6 hosts can still reach IPv4 hosts but not the other way around. Remaining on IPv4 is building a self-inflicted walled-garden around your horizons and sooner or later it's easier to switch networking stacks than to keep piling on kludges

    2. Warm Braw

      Re: That old chestnut

      IPv4 still works

      The cases in which it works are diminishing. Suppose you want to a VPN between two locations? Originally, no problem because each location would have a fixed IP address. Later, it might probably work if you could use DDNS to determine the currently-assigned dynamic IP address With CGNAT (absent something like PCP) you can't even do that because the dynamically-assigned IP addresses are shared between users and port numbers become meaningless (and inbound connections are often blocked).

      1. tip pc Silver badge

        Re: That old chestnut

        I can already vpn from my LAN (behind a nat), but yes going to a fixed dst on a fixed port.

        That is most peoples use cases and works fine even when 1 of the connections is behind cgnat.

        Obviously if you want site to site vpn you can’t initiate a vpn to an address behind cgnat.

        You typically need an intermediary or a proxy that both ends are connected to.

        People turn to what is more and more becoming edge cases for justification as to why we need ipv6 and why things like cgnat should not be used but for most use cases the perceived limitations do not materialise.

        How many people want to initiate a vpn to a site that is on cgnat?

        You will know it’s a limitation so engineer around it, have the cgnat side initiate the connection, or perhaps have it poll something every x mins and initiate if some condition is met. Problems are rarely insurmountable.

        I’m not against ipv6, I just think it was unduly flawed by original notions like no NAT.

        Not everyone wants every device in their home to have a publicly addressable ip by default, while an original aim of ipv4, nat provides a convenient boundary that precludes inbound connectivity without some config or being a return of an existing flow. Modern use of IPv4 makes the client security easier and ups the emphasis on securing the server side.

        With ipv6 suddenly every connected device can be a server in need of greater security from unsolicited inbound connections.

        1. Graham Cobb Silver badge

          Re: That old chestnut

          The problem the article (and, presumably, the original paper) highlights is that because of this one-way communication, new ideas for new protocols and new services are just not happening, except within the private networks of the largest players (Facebook, Google, ...).

          If you have an idea for a great new service which relies on communication being initiated from your server to your client, you can't do it - unless you are Google or Facebook (which almost everyone keeps a live connection to all the time).

          We see that with email polling. It is an abomination that every phone needs to keep an open TCP connection all the time to its email host in order to be told about new emails.

          Yes, it is true that the security and privacy implications of discarding NAT need to be better addressed (particularly for the cheapest of devices - like typical domestic IoT). But they haven't been because NAT is hiding the real underlying problems.

          1. Anonymous Coward
            Anonymous Coward

            Re: That old chestnut

            Only working behind NAT is largely a solved problem, as both TCP and UDP traffic can breach NAT from the inside using off the shelf libraries. This could have been added as a base extension to the IP4 IP protocol 10 years ago, and would have if those that drunk the IPv6 "this is the one true way" coolaid would stop BLOCKING it.

            Most of the rest of the argument presented involves the authors apparently delusional idea that we are all going to allow unchecked inbound traffic on arbitrary protocols into our networks. That's not an IPv4 or routing issue. It's a firewalling issue. Moving to IPv6 will not ever "fix" that. I could allow that now on IPv4 if I was either dumb or insane.

            We have seen over an over again that there is always an idiot whinging on the internet because someone is blocking their obviously bad idea instead of listening and understanding why they are. The decades of UPNP vulnerabilities we are still mopping up are a great example of where taking this kind of advice gets you.

            People will move off IPv4 when they finish fixing it's erstwhile replacement so that is solves issues they actually have, and doesn't cause undue problems they can't work around. The people pushing IPv6 made it to solve their problems, not mine. So they increased the address space to a ridiculous amount, and re-tuned the routing logic to take pressure off of routers. That's great for *NIC registries and backbone operators that literally just push traffic.

            Want to get people on IPv6? All it will take is to fix a couple problems and add a little sweetener. UP the minimum MTU on the backbone to support some reasonable approximation of jumbo frames to take pressure off of big TCP connections, and fix the multiple internet connection/failover problem without handwaving some BGP noise that can't even fail over in the order of seconds, let alone transparently.

            Until then, the IPv6 traffic I see will continue to be mostly garbage that I should and am blocking, and the IPv6 link will be unneeded pain that necessitates complexity, instability, and unreliability and offers nothing in return. Based on the track record of failure, I expect this to go like the endless wars over CAT 7 or later cable specifications, so I'm not holding be breath.

            1. Jellied Eel Silver badge

              Re: That old chestnut

              Well said.

              Security was certainly the main objection I heard, especially in the early days when IPv6 firewalls were problematic.

              1. SImon Hobson Bronze badge

                Re: That old chestnut

                And which was a solved problem a long time ago - called a firewall. A half decent firewall with suitable defaults will give you at least as much protection as NAT does - but in a more controllable way.

                Of course, you can always buy cheap sh*t and then complain that because you bought cheap sh*t the firewall is sh*t - but that's because you bought cheap sh*t, not because of any fundamental problem with IPv6.

            2. Solviva

              Re: That old chestnut

              "UP the minimum MTU on the backbone" do you mean the maximum? Upping the minimum won't help much.

              Then most backbone equipment does support jumbo frames. That they aren't enabled is mostly because they aren't enabled by the peers, so 1500 it is. Even if the backbone all went jumbo, your router & local devices would still be sat at 1500 unless you went and changed them all (assuming they support jumbo frames).

          2. Steve K

            Re: That old chestnut

            unless you are Google or Facebook (which almost everyone keeps a live connection to all the time,

            Citation?

            Businesses - really?

          3. Roland6 Silver badge

            Re: That old chestnut

            >If you have an idea for a great new service which relies on communication being initiated from your server to your client, you can't do it

            There is IPv6...

            So get prototyping and create demand for IPv6. However, probably best to market it as something like "Internet 3.0"...

            Okay accept there is a big lead time challenge, however...

          4. bombastic bob Silver badge
            Unhappy

            Re: That old chestnut

            Google or Facebook (which almost everyone keeps a live connection to all the time).

            I do not think 'almost everyone' is an accurate assessment. Your perception may be grossly inaccurate.

            Consider the popularity of search engines like 'Duck Duck Go' for starters. Add to that the large number of people who REFUSE to have anything to do with Faece-Ban. Or Tw[a,i]tter for that matter.

            Although a typical 'droid phone may have applications that attempt to stay in contact with Google or Faece-Ban, I rarely [if ever] use those applications (which would do that) and make sure that many similar applications are ALWAYS OFF. And I do not use phones/slabs much anyway. So no TRACKING MONSTER breathing down my neck. And I am pretty sure I am NOT alone.

            1. Charles 9

              Re: That old chestnut

              "I do not think 'almost everyone' is an accurate assessment. Your perception may be grossly inaccurate."

              And there are those who believe (and have the evidence to corroborate) that your supposed misperception is itself a misperception. Facebook has a tremendous population of subscribers and have pretty captive audiences in many parts of the world (thanks to them basically subsidizing Internet access in many countries--we're talking feature phones with Facebook on them).

              "Consider the popularity of search engines like 'Duck Duck Go' for starters."

              Compared to the juggernauts that are Alphabet and Meta? Potato chips. Frankly, if DDG were genuine competition for either of those two, DDG would likely be under a lot more pressure, some of which is likely to fall into "offer you can't refuse" territory.

              "Although a typical 'droid phone may have applications that attempt to stay in contact with Google or Faece-Ban, I rarely [if ever] use those applications (which would do that) and make sure that many similar applications are ALWAYS OFF. And I do not use phones/slabs much anyway. So no TRACKING MONSTER breathing down my neck. And I am pretty sure I am NOT alone."

              Can you say "a drop in the ocean"?

        2. Warm Braw

          Re: That old chestnut

          That is most peoples use cases

          I VPN to my home network quite a bit, but it requires DDNS (an application-layer kludge) and only works because my ISP currently doesn't share IP addresses between customers. They won't be able to do that forever. Much as you won't be able to get a static IPv4 address at a reasonable cost in perpetuity.

          I know someone who's wired broadband has been out of action for some weeks thanks to OpenReach and can't replicate their current VPN connectivity with their temporary wireless connection for this precise reason. The continuing contortions to avoid IPv6 are slowly, but gradually, undermining perfectly reasonable use cases.

          1. tip pc Silver badge

            Re: That old chestnut

            Use WireGuard with ddns

            https://www.wireguard.com/

            https://en.wikipedia.org/wiki/WireGuard

            I use that to connect back to my home connected to vm.

            My ip hasn’t changed in a long time but it can change.

            1. Solviva

              Re: That old chestnut

              If you're on CGNAT good luck making a connection TO the device behind the CGNAT. Wireguard doesn't do anything magic in that respect.

              1. Charles 9

                Re: That old chestnut

                The only reliable way to connect behind a CGNAT is to use an intermediary. Pure peer-to-peer is simply not possible without at least one endpoint being directly visible on the Internet. If both ends are behind a CGNAT, they're cut off, especially if one end or the other is unable to use or trust an intermediary.

          2. Altrux

            Re: That old chestnut

            Either switch to a top-class ISP that offers static IP (such as A&A, worth the extra cost), or buy a virtual cloud server (£2/month) and use that as a 'hub & spoke' WireGuard VPN host. We do something similar on our commercial networks, and a single minimum-spec cloud server happily handles a stack of simultaneous WireGuard networks with 100 clients, without even panting.

          3. Roland6 Silver badge

            Re: That old chestnut

            >and can't replicate their current VPN connectivity with their temporary wireless connection for this precise reason.

            There are solutions:

            A&A L2TP VPN

            Draytek VPN Matcher

            1. Charles 9

              Re: That old chestnut

              "There are solutions:

              A&A L2TP VPN

              Draytek VPN Matcher"

              Both of those solutions require a third party. Do you really want to trust your connection like that?

              1. Roland6 Silver badge

                Re: That old chestnut

                >Both of those solutions require a third party. Do you really want to trust your connection like that?

                If your problem is CGNAT I suggest using third-party overlays over a third-party network is the least of your worries.

                Additionally, unless you actually own your own fixed IP address, you are trusting a third-party for that address...

        3. Solviva

          Re: That old chestnut

          "How many people want to initiate a vpn to a site that is on cgnat?"

          More and more as CGNAT spreads further & further.

          1. jtaylor

            Re: That old chestnut

            It's not just VPNs that get blocked.

            A friend invited me to join his game (Valheim, I think). I could never connect to the game on his PC. He could connect to mine no problem. We dug a bit: his router wasn't receiving packets to the game port. I suspected CGNAT, but his ISP wouldn't discuss.

        4. No 3

          Re: That old chestnut

          'Publicly addressable' doesn't infer 'publicly accessible'.

          Your gateway can restrict incoming requests in the same way that you get with NAT, there is no real different there.

          The big difference is not everything from your network would appear to be from one IP anymore, this has both advantages and disadvantages.

        5. Roland6 Silver badge

          Re: That old chestnut

          >How many people want to initiate a vpn to a site that is on cgnat?

          Probably very few, however, with the promotion of 4G/5G as a backup to a fixed-line router, the need to sensibly handle inbound connections over mobile and CGNAT services does arise and will arise more often.

          Obviously, you can buy at a price, business mobile data SIMs that do have fixed IP addresses. However, for many. consumer SIMs are readily available and can do the job if you can solve the inbound connection issue in other ways.

          From what I remember of EE's 4G network, whilst it is IPv6, they don't want customers getting anywhere near it and reputedly assign consumer devices private IPv6 addresses which can change as you travel.

        6. jRivers

          Re: That old chestnut

          This is an incredibly short sighted and especially Myopic view, two decades ago we didn't have cool stuff because the tooling for it didn't exist, today we can't have cool stuff because now that we have the tooling for it but there is no more reliable infrastructure for it.

          If you think end-to-end connectivity is some random small issue you're way out of your league in discussing anything related to the subject, this is currently causing absolutely ludicrous amounts of excess traffic, electricity consumption and ergo high costs for things that used to be so free that people didn't even charge money for them unless you wanted them in lots of thousands, now if you go outside of the bubble you live in a single IP address can go for anywhere between 2€ - 15€ / per Month.

          It's been no more than a few days since i last had to implement an insanely convoluted setup that wastes about 70% of the traffic it generates that was absolutely and utterly pointless waste of effort if the internet actually worked like it's architecture is designed to, with end-to-end connectivity.

          That was simply to connect two devices together where both endpoints are behind cgnat, using play or apple push isn't an option often, it has gotten to the point that the internet of today does not infact function as an open and disruption resilient system. Ever stopped to wonder how a few routers messing up can result in millions losing connectivity? More than half the time some horrible NAT architecture has infested that corner of the net.

          And the western networking "giants" are about to be absolutely trashed on the software side, some 2.5-3.2 billion people on the planet are moving to IPv6-only networks over the next 5-10 years, with mandatory implementation on pain of bankruptcy level fines or prison time. Those nations will be producing more advanced software for IPv6 services in no time if we give them a decades headstart, we've already given them half a decade.

          At this point any opposition to IPv6 is beoynd ridiculous, such critiques had their time in 1998-2002 and Nobody had a good argument against it back then and today you make yourself a clown if you do.

        7. Alan Brown Silver badge

          Re: That old chestnut

          "You typically need an intermediary or a proxy that both ends are connected to"

          Congratulations. You just created a backdoor into your network that can be exploited (and was (still is) - heavily - by hackers attacking Chinese IP-based cameras/DVRs)

      2. DevOpsTimothyC
        Facepalm

        Re: That old chestnut

        Suppose you want to a VPN between two locations?

        That in a nutshell is part of the problem with IPv6. The purists fought (and won) in IPv6 that there MUST be end to end connectivity without anything that resembles NAT. As such in an IPv6 world VPN's shouldn't exist as both ends are fully routable. The only thing you should need to consider is the authentication and encryption (TLS/HTTPS anyone?)

        The initial IPv6 Specs had

        * Internet (Public Address space)

        * Org

        * Site local (link local stuff)

        The Org stuff was removed as it might tempt people into IPv6 NAT and that would be a "Bad Thing", after all what's wrong with putting databases and similar on public address space and then relying on the firewall?

        1. Kristian Walsh Silver badge

          Re: That old chestnut

          First, “static” does not mean “public”; and second, by using NAT you are already “relying on the firewall” - your NAT rules are, in effect, an allow-list for outbound and inbound traffic.

        2. SImon Hobson Bronze badge

          Re: That old chestnut

          The purists fought (and won) in IPv6 that there MUST be end to end connectivity without anything that resembles NAT. As such in an IPv6 world VPN's shouldn't exist as both ends are fully routable.

          The former does not demand the latter. You CAN run a VPN carrying IPv6 traffic over an IPv6 internet - and the reason you would do that is for the extra security if gives you.

          While doing so for IPv4 is as much a necessity for making connections as it is for security.

          1. tip pc Silver badge

            Re: That old chestnut

            >” The former does not demand the latter. You CAN run a VPN carrying IPv6 traffic over an IPv6 internet - and the reason you would do that is for the extra security if gives you.”

            End to end encryption is a standard component of ipv6 so why do a vpn?

            What people are calling a vpn is those commercial offerings like nord vpn which, while the client Vpn provider connection may be a vpn, the service of actual use is the onwards connection from that provider which is actually proxying.

            You might want to obfuscate what you are doing from your local provider by going through an intermediary but that breaks server client too.

            I think people want ipv6 because it’s perceived as newer and better but ultimately it’s transport and it’s like getting excited over smart motorways when actually what’s needed is more real lanes not repurposing an existing lane and adding technology that is continually exposed as flawed.

            1. Charles 9

              Re: That old chestnut

              The overall point is that CGNAT forced through address exhaustion is breaking endpoint visibility, which is critical to various Internet activities. It's not a matter of whether you want to or not, many are increasingly not even being given the option, which makes them beholden to gatekeepers you may not want to trust (Google, Facebook, untrustworthy ISPs, etc.). With some 4 billion hosts out there, there simply isn't enough space in 32 bits anymore. That's all IPv4 provides, no ifs, ands, or buts, especially for legacy/EOL hardware. The most basic gist of IPv6 is to at least allow for this again. Turn it down if you want, but at least have the ability.

            2. Nanashi

              Re: That old chestnut

              > it’s like getting excited over smart motorways when actually what’s needed is more real lanes not repurposing an existing lane and adding technology that is continually exposed as flawed.

              You've got your analogy backwards. NAT is the thing that's repurposing what we've got, and which is continually exposed as flawed. v6 is the thing that's giving us more real lanes.

            3. SImon Hobson Bronze badge

              Re: That old chestnut

              End to end encryption is a standard component of ipv6 so why do a vpn?

              It may be a standard, but optional, part of IPv6 - but is it actually widely implemented ?

              And I am NOT referring to the likes of NordVPN. My background here is in setting up and managing multi-site networks for both my employer and clients. That's all been IPv4 (and hence RFC1918 addressing) because of the issues people raise - mostly the "why am I bothered when everything seems to work OK" attitude.

              Going to IPv6 it would make sense to use ULAs for internal traffic - that way, you can have a stable addressing setup, properly configure the DNS, etc, etc and be independent of what the upstream ISP does - and yes, some ISPs do "interesting" things. Running site-site tunnels using whatever tunnelling protocol is in fashion* at the time allows you to do that - while hiding not only the contents of the packets, but also the individual flows**. E-E encryption within IPv6 doesn't hide the device-device flows as both source and destination addresses have to remain visible for routing to work.

              * For a given set of vendor support and security considerations

              ** Yes, it's possible to infer flows given a deep enough analysis of packet sizes, timing, etc - but that's getting into the "if you have to worry about someone putting the effort in to do that, then you have bigger issues to worry about" territory.

              1. tip pc Silver badge

                Re: That old chestnut

                Going to IPv6 it would make sense to use ULAs for internal traffic - that way, you can have a stable addressing setup, properly configure the DNS, etc, etc and be independent of what the upstream ISP does - and yes, some ISPs do "interesting" things. Running site-site tunnels using whatever tunnelling protocol is in fashion* at the time allows you to do that - while hiding not only the contents of the packets, but also the individual flows**. E-E encryption within IPv6 doesn't hide the device-device flows as both source and destination addresses have to remain visible for routing to work.

                What’s the point of ipv6 of you don’t need end to end and your going to tunnel?

                A load of complexity to do basic networking?

          2. DevOpsTimothyC

            Re: That old chestnut

            You CAN run a VPN carrying IPv6 traffic over an IPv6 internet - and the reason you would do that is for the extra security if gives you.

            It will give extra obscurity by being able to mask source and destination IP's, but what extra security is it going to give you?

    3. Nanashi

      Re: That old chestnut

      > When I'm running out of nails, I don't start thinking about buying a new hammer.

      Sure you don't. But when the entire world is out of nails, and nobody can make any more of them, but you still need to nail stuff down, wouldn't you start thinking about using screws instead?

      1. TRT Silver badge

        Re: That old chestnut

        I know people who hammer screws so...

        1. Anonymous Coward
          Anonymous Coward

          Re: That old chestnut

          I hear Stephanie Burrell regularly screws a Hammer.

      2. Richard Jones 1

        Re: That old chestnut

        If there were a shortage of nails, the differing legal status of nails vs screws would become an issue. Nails are easy and cheap to make, unless you are using some fancy nailer, almost any nail source is OK. Do not forget, to the person with a hammer, everything is a potential nail.

        1. Charles 9

          Re: That old chestnut

          The problem becomes if the world is only allowed some 4 billion nails for purely physical reasons (IPv4 has a fixed address header of 32 bits--no legacy hardware will be able to look beyond that--any that can be upgraded can just adopt IPv6).

          1. TRT Silver badge

            Re: That old chestnut

            But thanks to Nail Address Translation, I only need to know which house the nails are being used in. That way we can have way more than 4 billion nails. Indeed some of them could even be screws, even if to the outside world it just looks like a nail.

            1. Charles 9

              Re: That old chestnut

              But it generally only works one way. And if the carrier is doing the translating, it's only allowing the translations for outbound connections. Meaning if the house you need is behind an uncooperative carrier (as is happening in much of Asia and Africa where there was a serious metal shortage at the time the nails were distributed), there's no way to connect TO them, only FROM them. And let's not begin with the increasingly-likely scenario that BOTH ends are behind carrier-based screens.

              1. TRT Silver badge

                Re: That old chestnut

                Are you talking scrap? Well, it is true that nails that can be recycled become very valuable indeed... but only whilst there is a demand for nails. It's odd how valuable nails are given that screws are available and have been for some time.

    4. Anonymous Coward
      Anonymous Coward

      Re: That old chestnut

      > When I'm running out of nails, I don't start thinking about buying a new hammer.

      You do if the nails that work with your current hammer are no longer available.

    5. No 3

      Re: That old chestnut

      To this day I remember the first time someone described IPv6 to me, and my first question was: does it play with IPv4?

      When the answer was no I was shocked, and immediately felt it would simply never be adopted.

      I'm really sad to see that initial impression will probably pan out.

      1. SImon Hobson Bronze badge

        Re: That old chestnut

        No viable "update" to IPv4 was going to work. Fundamentally, if you alter the protocol then things doing the new vesion won't talk with devices still using the old one. So lets say we "just" added another few bytes to the address - that's fundamentally altered the packet header so that older devices won't understand them.

        And you'd need to add "a few" bytes to make it worthwhile - just (picking one example suggested) of nicking a byte from the port number isn't going to give you much of a boost.

        An IPv6 device can talk to an IPv4 device via a suitable gateway - there's even (from memory) a specific prefix for embedding IPv4 addresses in an IPv6 packet. Obviously there's no general way for an IPv4 only device to talk to the much larger IPv6 as it's 12 bytes short of address space.

        So having clients on IPv6 only networks is a solved problem - it is possible TODAY to ditch IPv4 as long as there's a transition mechanism in place to talk to legacy IPv4 services. And there are already IPv6 only services that can't be reached from IPv4 only devices - and they will increase over time.

        And for good measure, there are hosting outfits that will give you a chunk of IPv6 space with your hosting, but will charge for IPv4 addresses.

  2. John Sager

    Google and :face:b00c: both support v6 on their networks. It's the mobile networks that seem to be stuck in CGNAT, at least in the UK. One pernicious feature is ISP IP address pools rather than fixed v4 addresses that dynamic DNS only partially solves. This made sense in the era of dial-up where sessions would be relatively short, but most people now leave the router on 24/7. That would be pretty pointless on v6 but experience shows the network architects are much lower down the totem pole than the bean counters so who knows?

    1. Captain Hogwash

      Re: It's the mobile networks that seem to be stuck in CGNAT

      The fixed line providers are also, for the most part, stuck on IPv4.

      1. John Sager

        Re: It's the mobile networks that seem to be stuck in CGNAT

        Uk, yes. I went to Hawaii in 2017 and was surprised to find the cable service in the place we were staying at had IPv6 (and an Arris cable modem with default credentials...). That may not be typical of the rest of US though.

        1. tip pc Silver badge

          Re: It's the mobile networks that seem to be stuck in CGNAT

          Other than ipv6 being newer, what’s the mystical attraction to it?

          It’s an addressing protocol, it enables connectivity from 1 location to another, just like a phone can connect from 1 location to another or even a letter or package.

          It sits in the background doing its stuff. Ipv4 or ipv6 they both enable connectivity in similar ways, ipv6 has more available addresses and some limitations not in ipv4.

          I don’t understand the allure and lust for ipv6 when for 99.9999999% it will make no discernible difference to their internet experience.

          1. doublelayer Silver badge

            Re: It's the mobile networks that seem to be stuck in CGNAT

            I'm far from a zealot, but it does have a few benefits for some users, me included. One of the aspects that is nice is that I don't have to do weird things to have some dedicated addresses. With an ISP that gives me an IPV4 address through DHCP, I have to forward ports to individual devices, remember what the ports are should I have two or more of them operating there, have a method if they switch my address, etc. If they used CGNAT, I might not be able to do it at all. With IPV6, I just configure the static IPs and firewalls on my end and put the devices online, and since there's so much address space for now, they're not going to change my block. Getting dedicated IPV4 addresses from an ISP is usually not easy. I could get a business package, which will definitely cost more, may require extra equipment from the ISP, and might not be available in a clearly residential area.

            IPV6 is extra work, no doubt. It has some problems that impair its usefulness and require a configuration change to remediate (multiple IPs for end-user devices on the same network, I don't think so). If IPV4 was good enough, these could be enough to simply ignore IPV6. Unfortunately, IPV4 is not good enough. It's a little pathetic that I have a weird network setup just because we have run out of numbers, and it's a terrible reason for everywhere on the planet to keep getting more snarled in the organization of a limited resource. At least with other resources, the scarcity is due to physical limits. With addresses, it's a shortage we can fix ourselves.

          2. Charlie Clark Silver badge

            Re: It's the mobile networks that seem to be stuck in CGNAT

            Presumably you live in a region where there is a relative abundance of IPv4 addresses: Europe or the US. This is definitely not the case in Asia where sometimes multiple NATs are required and these bring their own problems.

            You can do a lot with IPv4 but you can't do everything, which is why IPv6 solves more than just the address space problem. That it's not 100% backwards compatible lies in the nature of the thing. It's not perfect but it is better and it is here. Fortunately, in the decades since it was approved, many of the problems of integration have been ironed out so that, indeed, most users neither know nor care. FWIW my ISP went IPv6 for all new customers for a couple of years now. But, unless I run things like traceroute6 www.theregister.com, I never notice.

            1. DevOpsTimothyC

              Re: It's the mobile networks that seem to be stuck in CGNAT

              From an average consumer point of view IPv6 SHOULD be backwards compatible with IPv4.

              The average consumer is just interested in going to facebook or google or whatever website. IPv6 spec has IPv4 address space mapped into it and there are things like NAT64.

            2. Kristian Walsh Silver badge

              Re: It's the mobile networks that seem to be stuck in CGNAT

              Yes. Some parts of India, traffic goes through more than ten levels on NAT. That’s ten levels that can break, or mis-route or block your traffic.

              Problem is, the big network vendors make their money from making equipment that can do this kind of insanity without breaking. Asking them to adopt a technology that removes the need for their competitive advantage is always going to be difficult.

          3. Richard 12 Silver badge

            Re: It's the mobile networks that seem to be stuck in CGNAT

            Peer-to-peer video calling, for example.

            Right now that's impossible for a lot of people, they must call via an intermediary - who then knows who they called and for how long.

            I remember when Skype was genuinely peer-to-peer.

            A business who needs their employees to VPN in cannot be behind CGNAT.

            This is one of the reasons ISPs charge more for business connections - but they are running out.

      2. Giles C Silver badge

        Re: It's the mobile networks that seem to be stuck in CGNAT

        Yep just checked my main broadband link - ipv4 address (BT)

        My mobile - ipv4 address (telephonica O2)

        So two of the biggest providers in the uk both using ipv4.

        Mind you even network engineers get confused by ipv6 - due to not using it regularly I have to go and look up the details if I need it.

    2. NeilPost Silver badge

      ISP’s

      Perhaps some/lots of the blame need to go to the ISP’s for IPv4 still being the apparent default.

      Looking at my U.K. ISP’s relatively recent Sagemcom router and IPv6 not enabled. Firmware has a 2022 on the splash screen.

      IP v6 available via my Microsoft DirectAccess VPN into work.

      1. Altrux

        Re: ISP’s

        Some of the big ones (including BT) have supported it out of the box for a few years now. Virgin Media is the biggest laggard I'm aware of. No excuses, but then they're fairly hopeless anyway. Speed uber alles, but reliable service? Forget it!

  3. steelpillow Silver badge
    Megaphone

    I've said it before and I'll say it again

    Breaking backwards compatibility in IPv6 was the dumbest thing to do.

    What we need now is an IPv10 (v7-9 have already been taken by non-starters) which is backwards compatible with both v4 and v6.

    Sheesh! It's not rocket science, it just needs the v6 world-dominators to put their dicks and boobs away so we can all see the table again.

    1. yoganmahew

      Re: I've said it before and I'll say it again

      Absolutely and until technical simpletons like me can look at a nextgen IP address and understand it, nextgen is doomed. Why? Because most of what is done is done by simpletons. IPv6 looks too complicated (it doesn't matter if it is, it looks is).

      One solution we folk in the mainframe world hit on often is to make the leading value 'different' so starting at 256.0.0.0. It's convention that says all parts of the address should be the same value. That would let intercarrier communications use an expanded range while leaving the NAT'd addresses within networks still unchanged.

      Or is that too simplistic?

      1. Charles 9

        Re: I've said it before and I'll say it again

        Yes, it's too simplistic because IPv4 was designed to use all 256 values for each octet. It only specifies 32 bits for the address, and you cannot physically cram more tham 2^32 addresses into that, much like you cannot cram more than 12 eggs in a carton only built for 12 without breaking either. It's at the limit of its fundamental design.

        1. KSM-AZ

          Re: I've said it before and I'll say it again

          Not really too simplistic. 128 bits is just too long to grok by mere mortals. Adding in hex nomenclature vs dotted decimal, and it goes totally geek. Then start leaving out the middle if it's 0 and it becomes unintelligable gobblygook to the help desk. There were some inherent security issues in ipv4, but they shouldn't have thrown out the baby with the bathwater. Making an ip address 64 bits and only using 5 octets to start an mapping ipv4 into 0.0.0.0.x.x.x.x like you would do say going from uh 32 to 64 bit architecture. Then hack the tcp header with a protocol marker that signifies a longer header, or some other mech, and you keep people from losing their minds. If you want to let someone comminicate tranparently at will to your toaster I wish you well. Have we run out of phone numbers in the US yet?

          1. Anonymous Coward
            Anonymous Coward

            Re: I've said it before and I'll say it again

            "Making an ip address 64 bits"

            This should have been the foundation of the solution for a new IP scheme. Had it been, we wouldn't even be having this discussion, nor any of the earlier ones from the past 20+ years. No holy wars. No hurt feelings. Most addressing stuff would be comprehensible without the tremendous amount of gobblygook that the current IPv6 requires. Yeah, there would be a transition, but resistance by admins would be far less since concepts and addresses would still be somewhat manageable. We'd all chit-chat about how we're getting used to the 8-byte addressing while we're drinking our beers. What happens when the 64-bit space gets short of addresses? Well, that will be a problem for the great-great grandkids, we didn't need to solve it today.

            But no, the IPv6 guys decided that every atom for a parsec needs to be able to have a unique IP address, so they started from there and worked their way out. And it's been a slogging bloodbath every since. Bright-eyed evangelists preaching down to those of us who don't see and agree with The Way Things Are Gonna Be One Day. Fuck it, retirement is only 12 years away, maybe I can hold out.

            1. Richard Jones 1
              WTF?

              Re: I've said it before and I'll say it again

              Anonymous Coward, I went on IPv6 training courses some years ago. It was only slightly tarnished at that point. Time passed and I retired 20 years ago. It is 'interesting' to see that the debate has not really changed, and neither has the deployment of IPv6.

              I have forgotten most of what the courses covered, and shredded and composted my notes years ago. I am probably the exception in not keeping things like Facebook open all the time, I am almost certain I am one of the few who has no dealing with Facebook, though my wife has an account, she might look once or twice a week. Perhaps I really wish I could see a useful benefit to me from IPv6, but I suspect that the number of current internet users who are happy not to have to deal with the work of any change over is large. There is no advantage to my, TVs and PVRs, having a direct IP address. I am not even sure they are IPv6 capable, anyway.

              Do not get he started on the withdrawal of PSTN services, aka the ones that work at my home. I joked with an ISP person that broadband service probably suffered as I killed a few snails. I suspected they might have been delivering part of my service.

          2. Brewster's Angle Grinder Silver badge

            PEBCAK

            I often see films or TV shows where one of the octets its greater than 255. So Lets do that for real. Let's allow each octet to range to 999 (a 10 bit field). You now have a trillion addresses in four dotted quads. If every value is an octet then it's IPv4. If one of them is above 255 it's next gen.

            Now, write the spec around that human side.

            1. Charles 9
              FAIL

              Re: PEBCAK

              You only have EIGHT bits with which to cram a TEN-bit value. It's in the spec, and can't be changed without breaking all that legacy hardware everyone's so scared about.

              Try again.

            2. bombastic bob Silver badge
              Boffin

              Re: PEBCAK

              your theory breaks when you look at an IP header structure and realize that each digit of the IP address is a single byte in the header. When the binary structure format changes to accommodate a 10 bit value it is NO LONGER IPv4.

              And then every bit of hardware that expects IPv4 will have to be upgraded.

              might as well adopt IPv6 which has available hardware already.

        2. Rob Daglish

          Re: I've said it before and I'll say it again

          I've just been in the kitchen for a play. I've got a fiver says you're wrong about the egg carton... ;)

          1. doublelayer Silver badge

            Re: I've said it before and I'll say it again

            I suppose it depends how your cartons are set up. I could see a possibility if yours has a lid that is flat all the way over, and thus you could balance an egg between some others and have the lid go over that. I think the analogy requires that you not break an egg or the carton and it still has to close though, and although I can't prove it, I think the cartons I know can't do that.

      2. Fred Daggy Silver badge

        Re: I've said it before and I'll say it again

        Slightly, both destination and source address are too short to hold that value. 4 x 8 bit bytes. 256 needs 9 bits to represent.

        But, according to Wikipedia's description of a IPv4 packet, there is 40 byte option field. If this isn't exhausted, then that could be perhaps used. But again, you'd need a way to deal with IPv4 only devices that only look at source and destination address.

        1. Charles 9

          Re: I've said it before and I'll say it again

          That's been the problem. Theoretically, an IPv4 stack could stick a v6 address into the option field and stick a reserved address into the IP field, letting the router fix the connection, but that still requires upgrading the firmware. And if you're going to update the firmware, why not go whole hog and just add a v6 stack?

          1. Anonymous Coward
            Anonymous Coward

            Re: I've said it before and I'll say it again

            That isn't really an IPv6/v4 issue, we can stuff IPv6 packets in IPv4 or vice versa already. That stuff works out of the box, and if the client device is aware of it IPv4 clients can reach IPv6 already. Squeezing it into the header space doesn't gain much in the way of space, and it will bump into every other genius that has tried stuffing data in those fields.

            There IS overhead in stuffing that extra data into a packet though, and while encapsulation will work it isn't ideal as it is slower, has overhead, etc. So if we could ever get them to raise the bloody MTU/packet size that would at least let us limp along until we sort out IPv10. We are still using MTU defaults from the 1990s and sub megabit internet links and 10mb LANs. LAN client ports are shipping with 2.5G links and switch cores in offices are 10G-40G. The Internet's MTU stayed under the 1500 ethernet frame from 10Base. From 1990. We are a civilization of idiots.

            That however will require assigning different people to the job than the ones that made the current mess of the IPv6 rollout. They have been remarkably consistent at their job performance though.

            1. Solviva

              Re: I've said it before and I'll say it again

              MTU is only an issue for a single TCP stream. If you have stream going across the world and want Gbit+ speeds then 1500 MTU will cause you some teeth gnashing. Fire up multiple streams and the aggregate bandwidth across the link will support it. There's a minimal reduction in packet overheads on the wire with larger MTUs, but that in itself is negligible.

              1. jtaylor

                Re: I've said it before and I'll say it again

                "MTU is only an issue for a single TCP stream....multiple streams and the aggregate bandwidth across the link will support it."

                I agree, but sometimes the use case is a single TCP stream. I believe the above mention of MTU was for encapsulation, which can play merry hell with a TCP connection when some upstream device adds a few bytes to your packet which pushes it over 1500. Then the router frags 1 packet into 2. For various reasons, this is a common situation. If the client uses Path MTU Discovery, the connection just failed.

        2. Graham Cobb Silver badge

          Re: I've said it before and I'll say it again

          The problem with IPv6 adoption isn't the change in packet format. Almost all devices (i.e. all IP software stacks for over 20 years) can cope with IPv6 packets - there is no need to play around with trying to fit longer addresses in IPv4 packets.

          The problems are: 1) user (including IT professionals) unfamiliarity with IPv6 addressing, 2) interoperation and gateways (IPv4 and IPv6 addressed devices can't interoperate and there is no easy way to gateway between them), 3) security and privacy issues due to global visibility of devices.

          The first is the most obvious but is the easiest to solve: training and experience will rapidly catch up once the other problems are solved.

          The second is the hardest issue. It needs some more engineering to create gateways that (i) meet the main needs of translating the main dozen or so protocols, and (ii) do something useful for the remaining 50,000 (just a guess) private/proprietary/unusual protocols. This hasn't happened because the IETF still takes the attitude that it isn't advisable to do anything which prolongs the use of IPv4 - forgetting that this issue is exactly what is prolonging the use of IPv4.

          The third is the one that is stopping a lot of migrations. I used to design and develop routers for a living and was in the IETF when IPv6 was being created, but I don't run it at home! I find the easy protection and privacy of IPv4 NAT too easy and I always have other things more interesting to do whenever I say "I really must do that IPv6 conversion of my home and VPN network".

          1. John Sager

            Re: I've said it before and I'll say it again

            Um. IPv6 protection in my border router is a handful of nftables rules and it was a similar number of ip6tables rules before I moved to nftables. I agree it'll be snowing in hell before the cheapo router manufacturers support it all though. Some of them still use version 2 Linux kernels for god's sake!

            1. John Sager

              Re: I've said it before and I'll say it again

              Downvotes? The nftables stuff is factual and I thought people might be interested in how easy it is. This anti v6 stuff runs deep, a bit like something else beginning with v...

              Now cue the downvotes!

              1. Anonymous Coward
                Anonymous Coward

                Re: I've said it before and I'll say it again

                Have and Upvote then, as nothing in your post was cheerleading v6, and your comments on the firewall rules are on point. IPv6 isn't evil. It needs a few things fixed, and for people to stop shoving it down down other people's throats without listening to them. You did none of those things in your post.

                The only equipment manufacturers that still have real IPv6 issues are at the very bottom end. That gear should not be connected to the internet by anyone, ever.

              2. Anonymous Coward
                Anonymous Coward

                Re: I've said it before and I'll say it again

                "This anti v6 stuff runs deep, a bit like something else beginning with v..."

                So you're saying v6 is the Emacs of the OSI stack, and the v4 guys fighting against it are from the vi camp?

                1. bombastic bob Silver badge
                  Unhappy

                  Re: I've said it before and I'll say it again

                  how did IPv4 vs IPv6 become a religious war?

                  Other apparent religious wars:

                  a) emacs vs vi

                  b) gnome vs Mate (or KDE)

                  c) 2D FLATSO vs 3D Skeuomorphic

                  d) Windows vs Linux

                  e) PC vs Mac

                  f) sysV vs systemd

                  g) pulseaudio vs OSS

                  h) apt vs rpm

                  a long list, yeah

            2. doublelayer Silver badge

              Re: I've said it before and I'll say it again

              You're right that it's simple, but this still worries me because it's very unlikely to be the default. The benefits of nontechnical people on a NAT system include the assumption that, purely for the ISP's self-interest, the default config is likely going to prevent publicly-accessible ports for the user. That helps when they bring in untested devices or software. It's not hard for me to have a firewall which prevents incoming traffic by default, but many cheap, ISP-supplied routers I see leave that to the device's own firewall which, if it's a security nightmare already, probably won't do it.

              I've dealt with this by having devices on my IPV6 home network connect to a NATed subnet unless configured to have statics or to be trusted, but I can't set that up for my friends or family, let alone trust that the rest of the public is going to get it. This doesn't mean that IPV6 is to blame, but I would like to see a general improvement in default router configs and I don't think it's going to happen.

      3. John Robson Silver badge

        Re: I've said it before and I'll say it again

        There are some "reserved" spaces which we could use here... but the difficulty is what do you do when your address isn't a "valid, routable" address, but just indicates you should use IPvX?

        Because there isn't an invalid IPv4 address, you can't put 256 into an octet, you just wrote zero, and overwrote someone else's data somewhere.

        1. KSM-AZ
          Stop

          Re: I've said it before and I'll say it again

          You can't put 256 in an octet, becuase it represents an 8 bit value 0-255 within a 32 bit . 256 does not become 0 via overflow, it is illegal notation. You can substitue a true DECIMAL value behint a URI http://4096 = http://0.0.16.0. An ip adress is a 32 bit value displayed as 4 'octets' 0.0.0.255 + 1 = 0.0.1.0. 255.255.255.255 + 1 = OVERFLOW. The resilt is not defined. This Nomenclature was done for readability. IPv6 is somewhat more arcane. Maybe we should have used BCD values/maths instead.

          1. Roger Greenwood

            Re: I've said it before and I'll say it again

            "Maybe we should have used BCD values/maths instead."

            BCD is to maths as Vogon poetry is to English.

          2. John Robson Silver badge

            Re: I've said it before and I'll say it again

            You have an allocated area of memory for an eight bit number... you put in 254, then add one, then add one... what will the computer do.

            11111110 -> 11111111 -> ????????

            It might crash, if it has decent memory bounds protections.

            More likely it will add one and you end up with 00000000 in your eight bits, and a 1 written just before them - i.e. an overflow bug.

            1. KSM-AZ
              Boffin

              8 bit overflow

              Adding 1 *might* overflow to zero. IPV4 addressing was designed so one could do things like (inet >> 8) << 8 undocumented in your code. Then again the last shifted bit may reappear and bite you in the *ss. Overflow is overflow. The result generally by definition is undefined. Something about engineers programmers, bridges, and programs comes to mind.

              As a base10 thinker I like BCD. 64 bits of signed BCD gives you 16 significant unsigned integer digits

              I'd notate it as 000 000 000 000 0000

              I think the point about allowing 0-9. ie making addresses decimal would be an interesting excercise, but bit shifting and masking would go out the window. ;-)

              1. John Robson Silver badge

                Re: 8 bit overflow

                only 64 bits of addressing in there though, which is one IPv6 subnet (whether IPv6 was over specified is left as a question for the reader).

      4. Warm Braw

        Re: I've said it before and I'll say it again

        As others have said, the problem for an IPv4 end system is that if there are more than 2**32 hosts in the Internet there is no way it can distinguish between all of them with only a 32 bit field. Backwards compatibility at the network layer is simply physically impossible. People who argue otherwise will often suggest packing additional bits into optional or unused fields, but that's exactly the same solution as IPv6, just with the extra bits in a different place - it doesn't alter the fundamental problem.

        There are possible multi-layer solutions. For example, an iPv4 host could look up a domain name in a specially-crafted DNS server. If the domain name had only an IPv6 address, the server could allocate a temporary IPv4 address to represent the IPv6 address, inform the network layer of the mapping and have the ingress/egress point perform a translation. From a technical point of view, it could well have been worth doing this 10 years ago - or even 5 - when there were fewer IPv6 stacks available. But it would still leave the control in the hands of the network provider as they'd need to provide both the DNS and the boundary translation for this to work.

        However, there's no technical value in doing that now as the only thing preventing IPv6 deployment is carrier inertia. The end systems are pretty much all ready.

        I do think there is a potential consumer issue, though. Most of the support documentation for years has focussed on users visiting "192.168.1.1" or variants thereof to manage their router and I suspect carriers fear a tsunami of support calls from funny-looking addresses. However, it's not as if local IPv4 stacks will stop working and the only real way to evaluate the support demand is to start doing it.

        1. Jellied Eel Silver badge

          Re: I've said it before and I'll say it again

          Most consumers probably don't ever look at IP addresses.

          I think a lot of the problems have been political. IPv6 is the future, IPv4 is deprecated, so hurry up and make the leap. Once that decision had been made, there was little interest in doing anything to IPv4.

          But it's not a new problem, telecomms has been dealing with address space depletion for over a century. London recently added 020 4x as an example. A simple, time tested solution that works, even with the occasional fun, like Dublin. So a similar solution was proposed, and rejected by the IETF.

          As previously mentioned, there's wasted space inside v4 headers.There's a lot of wasted v4 addresses that are reserved and not assigned that could be routable with a simple update to a bogons filter. Ok, that might cause some fun for anyone currently using those addresses, but they shouldn't be.

          Plus IPv6 helps solve some v4 'problems'. It's now 128bits wide, so v6 compatible hardware could (or should) be able to support a 64 or 128bit v4+ header. But given the efforts expended to encourage (or force) v6 migration, simply extending v4 space by adding octets would be politically unacceptable.

          It's also somewhat ironic that some of the biggest champions of packet bloat were the mobile folks. Partly due to the address pool, but also the ability to carry MAC or IMSEI addresses inside the header. Of course that created it's own set of problems because you often don't want hardware addresses exposed to the outside world.

          But such is politics. It's been nearly 30yrs since the introduction of IPv6, and adoption is still met with apathy. And that also makes me feel old.

          1. Roland6 Silver badge

            Re: I've said it before and I'll say it again

            >Most consumers probably don't ever look at IP addresses.

            Agree, and probably many here don't know or care that their ipad/Windows PC etc. is most likely talking to their Bonjour attached printer via IPv6, although their ISP provided router can only handle IPv4.

        2. Anonymous Coward
          Anonymous Coward

          Re: I've said it before and I'll say it again

          Yeah, that's not really an insoluble limit, and we are already living in the world where IPv4 clients aren't directly routing to each other. There is so much address translation happening that the reality of modern IPv4 delivery is that the 90s style routing you describe is only really happening on endpoints. Even cheap layer 3 switches are in reality routing traffic to a target address that knows how to reach the destination, not necessarily the destination itself. The amount of address manipulation that happens on the cloud side of the modern internet is CRAZY. Try to operate services at cloud scale without load balancers, CDNs, etc.

          This isn't really crazy, as routing through the internet works in a pretty similar way already, and routing between LANs was already addressing these issues.

          You are correct in one sense, which is that with the IPv4 address space you can't build a directly addressed flat network over a certain size. We don't need or want to do that though, and IP networks never really worked that way. At no point in the public internet area did every ethernet/ip device run on the same public address space. We neither need it to or want it to. The fact that you theoretically could in IPv6 doesn't make it a problem for IPv4.

          The reason IPv6 is stalling is that the workarounds to make IPv4 handle this stuff are holding the line, and IPv6 still can't handle stuff enterprise connection traffic failovers at speeds that meet users expectations.

          1. Charles 9

            Re: I've said it before and I'll say it again

            So you're against peer-to-peer protocols?

          2. SImon Hobson Bronze badge

            Re: I've said it before and I'll say it again

            One of the problems is that key workarounds involve "3rd party gateway".

            So, want to access your ${something} at home from elsewhere ? Well you get your ${something} to talk to a 3rd party service and then you talk to that 3rd party service. This is actually one (not the only) reason I don't use any of these ${something}s - I'm not prepared to hand over my network/personal/home security to some 3rd party who may, or may not, ditch the service next week (ask (ex) Revolv users what they thing of Google !); and who almost certainly will decide that all that juicy data would be nicely profitable to them when aggregated, diced, sliced, and sold to the highest bidder.

            Look at pretty well all the modern "home tech" and it doesn't work - either fully, or in some cases AT ALL - if it can't phone home. This is in large part due to the problems of dynamic IPs and NAT - but it also suit an industry which, taking it's cues from Google, Faesesborg, Amazon, etc, etc, has realised that the people who buy it's product are "users" but "product" to be sold on for a profit.

    2. Nanashi

      Re: I've said it before and I'll say it again

      Why say it repeatedly when it's wrong? v6 is backwards compatible with v4.

      Describe a method of backwards compatibility that would actually work with v4, and v6 most likely already has it or something functionally similar. There's at least a dozen different methods available, depending on what your use-case, limitations, goals etc are.

      If there's anything v6 lacks, it's not backwards compatibility.

      1. Charles 9

        Re: I've said it before and I'll say it again

        The problem isn't that v6 is not backwards-compatible with v4 (v6 has a reserved space just for that). The problem is that v4 was not designed to be forward-compatible. It wasn't even meant to be used long-term, but circumstances flew out of the designers' conteol.

      2. Anonymous Coward
        Anonymous Coward

        Re: I've said it before and I'll say it again

        v6 is backwards compatible with v4.... If there's anything v6 lacks, it's not backwards compatibility."

        You must be on really good drugs. Where can I buy them?

        1. Nanashi

          Re: I've said it before and I'll say it again

          You don't need good drugs to see this. Between dual stack, Teredo, 6to4, 6rd, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E and more, v6 has plenty of backwards compatibility.

          Why do you think it doesn't?

          1. R Soul Silver badge

            Re: I've said it before and I'll say it again

            The things you've listed are proof IPv6 isn't backwards compatible with IPv4. If it was, these things would not [need to] exist. QED. They probably shouldn't exist at all but that's another story.

            Something is seriously fucked up if someone has to use Teredo or whatever to make IPv4 and IPv6 play nicely together. That would have "just worked" if IPv6 actually was backwards compatible with IPv4. It isn't. The packet formats on the wire are completely different. A v4-only device can't talk to a v6-only device - and vice-versa - unless some sort of proxy or one of the ugly kludges you mentioned is involved.

            1. Graham Cobb Silver badge

              Re: I've said it before and I'll say it again

              Wire-level compatibility isn't the problem. All commercially available IPv4 stacks also have IPv6 capability.

              It is infrastructure level compatibility that is the problem.

            2. Nanashi

              Re: I've said it before and I'll say it again

              Those things are the backwards compatibility. How did you expect it to work? Magic?

              v4 isn't forwards compatible to address spaces wider than 32 bits. That's not v6's fault; it's v4's fault. There's no way to make it "just work" without some form of backwards compatibility method, and that's what v6 implements -- because it's the only thing that's compatible with v4.

              If you think I'm wrong about this, all you need to do is explain how they should've designed it to make it possible for a v4-only device to talk to a v6-only device. If you can describe a way to do it, you'll prove I'm wrong. Just remember that whatever you come up with needs to a) be something that v6 doesn't already do, and b) actually work.

              I've asked a lot of "v6 should've been backwards compatible" people to do this, and not one has been able to. Perhaps you will finally be the one to share the secret...?

              1. Anonymous Coward
                Anonymous Coward

                Re: I've said it before and I'll say it again

                > There's no way to make it "just work"

                Since they reserved the class E address 240.0.0.0/4 they could use one of these to indicate that the packet is actually a different type. From then on you can do as you please. OK, you'd end up sending slightly larger packets but you're doing that anyway.

                1. Charles 9

                  Re: I've said it before and I'll say it again

                  That still doesn't solve the problem of older hardware that can't grok more than 32 bits. If you need to update stuff, why not do it so you don't have to do it again sooner than you thought. Think about this. Why did ZFS settle on 128-bit vales? For much the same reason: so as not to have to deal with overflow.

                  1. KSM-AZ
                    FAIL

                    Older Hardware can't do what? . . .

                    Older hardware can deal just fine with more than 32 bits. Older SOFTWARE maybe not so much. A 256K floppy disk has a million or so bits... You can run ZFS on 32-bit hardware just fine. 'bc' is an arbitrary precision calculator, ran just fine on 16-bt Xenix 86, I think max precision was 128 or 256 DECIMAL places ,lots and lots of bits.

                    The lowly intel 8080 with an 8-bit accumulator could even manage large bunches of bits... Albeit only 8 at the time. There were some 128 bit binary floating point libraries for it even.

                2. Nanashi

                  Re: I've said it before and I'll say it again

                  That doesn't help in the slightest. There are already multiple ways to indicate that a packet is a different type, two of which (the "IP version" header and the next protocol header) v6 already uses.

                  I said that you need to come up with something that v6 doesn't already do.

        2. Warm Braw

          Re: I've said it before and I'll say it again

          Actually, it is, in the sense that IPv4 can be carried through an IPv6 network without any loss of information. The optimistic assumption was that the backbone would convert to IPv6, and then the hosts, using IPv4 addresses before the IPv4 address space ran out. At which point, IPv6 addresses could be assigned to new hosts.

          The flaw in this reasoning is that the protocol designers didn't operate the networks and hadn't accounted for the inertia resulting from not wanting to invest in change when it wasn't immediately necessary.

          I was never a particular fan of IPv6 technically - and it's increasingly behind the times - but it works. I was always concerned about the likelihood of the transition not happening in line with its designers' optimism and that considerably more needed to be done on the presumption of long-term coexistence. The trouble is we're now running out of kludges, especially for things like push notifications and always-on devices, and they're become significantly more painful than simply moving to IPv6 for all its problematic legacy.

          1. tip pc Silver badge

            Re: I've said it before and I'll say it again

            Push notifications work fine to all our devices behind our ipv4 Nat.

            1. SImon Hobson Bronze badge

              Re: I've said it before and I'll say it again

              Err, what LOOKS like push notifications might work.

              But what actually is going on is that the client is keeping a connection live through the NAT - all the time, whenever the client is running - just in case that service wants to send something back. To cater for all the possibilities, that probably means the client sending several packets a minute - NAT gateways can have some fairly short timers. And depending on the type of connection, that may mean the service replying.

              What is NOT happening is true push notifications - where the client just sits there doing absolutely nothing but listen on a port and waiting for the service to send a notification WHEN IT HAS ONE.

          2. Anonymous Coward
            Anonymous Coward

            Re: I've said it before and I'll say it again

            And it's not just inertia, so I really wish people would stop saying that it is.

            We have multiple IPv6 handoffs. We have multiple internet connections for both capacity and redundancy. I have to block my clients from seeing those IPv6 handoffs because IPv6 was designed without the ability to transparently load balance, or to fail over without waiting for BGP advertisements.

            So my clients run on IPv4, and only a handful of applications have to reconnect or show a blip, as opposed to all the clients on one connection going down and losing EVERY open connection both when something fails over and when it fails back.

            That's a real and non-trivial problem, not inertia.

      3. thondwe

        Re: I've said it before and I'll say it again

        If anything there were two many mechanisms for transitioning from IPv4 to IPv6 - if they'd been able to set up a set of big public transition gateways or make it easy for ISPs to do so, then we'd have seen faster progress?

    3. Yes Me Silver badge

      Re: I've said it before and I'll say it again

      No, it's not rocket science, it's simply mathematically and physically impossible.

      IPv4 contains no features that allow backwards compatibility from any future version of IP.

      IPv6 could have been designed differently (and many different designs were considered) but none of them would have been backwards compatible. You can argue that IPv6 is too different from IPv4 for your taste, but that doesn't affect the mathematical impossibility of backwards compatibility.

      Also, IPv6 just works in consumer situations, if your ISP cares to support it. That's been true for ten years in my personal experience, using Windows, Mac, Linux, Android. The problems are that enterprise network ops people generally haven't been motivated to deploy IPv6, and what Geoff Huston says: there are perverse economic effects of the restrictive nature of IPv4+NAT that give some players every reason to resist progress. Consumers lose.

    4. Solviva

      Re: I've said it before and I'll say it again

      IPv6 didn't break backwards compatibility. If you have an OS that doesn't support IPv4 with IPv6 then that's the OS breaking backwards compatibility.

      There's no sensible way to extend IPv4 to include more addresses. Any attempt at using extra fields in the header could work - except when talking to a device that doesn't know about 'IPv4.1' i.e. pretty much every home router. So you're back to square 1 - IPv4.

    5. DevOpsTimothyC

      Re: I've said it before and I'll say it again

      The biggest issue is not backwards compatibility IPv6 can get to IPv4 via NAT64 gateways. The problem is forwards compatibility IPv4 cannot get to IPv6.

      IPv10 (or whatever) is never going to solve this problem because ALOT of things on the internet are so old they can only do IPv4 and they will never get a firmware update. Eg I have an old HP Laser printer with a Jet Direct card that will only do IPv4. Can I print to it from an IPv6 only host (with a NAT64 gateway)? Yes I can! Can it send a message to any IPv6 host? No, but then again why would it need to.

      Many big companies see "We cannot upgrade that printer" as a reason to NOT do IPv6

  4. Julz

    I

    Think the address space argument is not really the main point here. My reading of Geoff Huston's main points are that the architecture of the protocols available currently (v4, v6, UDP, TCP, IP, DNS etc etc.) are limiting the networks to client initiated (mostly), client server interaction when there could be other richer modes. And that the current situation is being kept that way by numerous vested interests. Given it's something I've be arguing (to anyone who would listen) for a while, I tend to agree with him :) However, I do think that there are other ways we could use our wonderfully connected world that would be of benefit to us all. In the same way that the internet isn't just the world wide web, the connected world doesn't have to just be the internet.

    1. Anonymous Coward
      Anonymous Coward

      Re: "when there could be other richer modes"

      Well, I suppose that sounds as if it might be pretty cool.

      But what are these "richer modes", exactly; and -- more importantly -- how will they improve my day-to-day internet use?

      1. SImon Hobson Bronze badge

        Re: "when there could be other richer modes"

        The classic problem is peer-peer connections.

        People will tell you that this is solved. Well it's "sort of" solved - by a lot of people wasting a lot of time on designing ways to detect and work around NAT. These work "a lot" of the time, but not "all" the time. As a result, if you use a VoIP service then you'll almost certainly be told to use a NAT proxy rather than directly to the VoIP service. That's because the common VoIP protocol SIP needs knowledge of the IP and port number combination - and with all the varieties of NAT (including some particularly grotesque ideas from Zyxel - may they rot in hell) it's just not reliable enough.

        But SIP should be capable of proper peer-peer communications. You pick up your phone, dial another phone, and after going through the SIP gateways to set up the call - the phones talk directly to each other. If you try this, expect to fail in the presence of NAT as it rarely works.

        So your VoIP service costs more than it needs to because of the extra hardware the service provider needs in order to "just work" in the presence of NAT.

        And all this is of benefit to those who provide services. It makes it harder to alternatives that don't hand all your information to someone running the service. So it makes it easier for them to consolidate control and the amount of your information they can amass.

    2. Anonymous Coward
      Anonymous Coward

      Not cool

      Yes, because sane people are going to build a version of the internet where people who they don't know have presumed direct access to every host on their network.

      This is a what firewalls do, and it is NOT a routing problem. Eliminating NAT and implementing global addressing won't enable this magical push based network to materialize in the real world, because that's not what's blocking it. My firewall is, on both IPv4 and v6.

      What the author fails to mention is that if I have to change my firewall rules to allow connections inbound for a specific site, host, and service, IPv6 isnt really an issue. What the author seems to be whining about is that he can't dream up another insecure mess like UPnP or the MAC address leaking version of SLAAC that we will have to clean up.

      What the author should be pushing for instead is a way for applications to politely ask for their access to be approved, which would actually solve problems as well as work on both IPv4 and v6. But big surprise that someone who would write such a whinge can't be bothered to understand why they aren't just handed the power they shouldn't be trusted with. Or probably why giving knives to monkeys is a bad idea.

      1. Julz

        Re: Not cool

        Well one of the interesting ways the interconnected world could develop is by applications politely asking for access. We just have to define politely. IP isn't the connected world it's just what we have now. There were other protocols, there can be others in the future. The fact that we have lots of things things wired'ish together is an opportunity for growth.

        1. Brewster's Angle Grinder Silver badge

          This is why we can't have nice things...

          And how do you handle all the spammed requests?

      2. Jellied Eel Silver badge

        Re: Not cool

        That's a bit harsh.

        Geoff knows his stuff, and coming from a land down under, is well aware of the challenges. Which were largely historical. So the US and Europe got allocated large chunks of v4 space, and regions like Asia Pacific, Africa and the Middle East got much smaller blocks.

        That's an accident of history and the ad-hoc way address blocks were originally handed out, ie US companies ending up with class A blocks, just because they asked the right people nicely. But I think what's really needed to drive v6 adoption is the killer app that's a must-have, and requires v6.

  5. McAron

    Thanks, but no thanks

    From my perspective as a privacy-conscious individual, a widespread IPv6 adoption would be a nightmare. Staying at dynamically assigned IPv4s, or even better behind a CGNAT, protects me from being mercilessly tracked across the whole internet.

    If my network provider would assign me an IPv6 address, I'm sure it will be a static one, maybe even containing my customer number / contract / router ID etc. It's just much cheaper, and with the IPv6 they just wouldn't need to pool available addresses anymore.

    I can then kiss my privacy goodbye - no amount of ad blockers would fix the situation where my traffic always comes from the same, unique source IP. Think of Verizon PrecisionID tracking headers, but on steroids.

    1. Julz

      Re: Thanks, but no thanks

      What makes you think carrier NATing protects you form tracking?

      1. Tom Chiverton 1

        Re: Thanks, but no thanks

        Under v6, my phone has a long lived identification that persists across all WiFi, mobile connections etc.

        So not a good plan

        1. Nanashi

          Re: Thanks, but no thanks

          No it doesn't. It'll get an IP from the network's subnet, which is different for each network, so the left-hand half of the address will change when you move between networks. The right-hand half will be randomly generated and change regularly due to privacy extensions, so it'll change even if you don't move between networks.

          (Of course your apps etc will still track you by IMEI, UUID or whatever, but that has nothing to do with v6...)

          1. Anonymous Coward
            Anonymous Coward

            He's actually mostly right here

            Gotta run counter to the downvoters here.

            1) most of the way they are tracking you isn't your IP address, it's browser fingerprinting, port tracking, supercookies, web bugs, etc etc etc

            2) Even Apple is managing to do local MAC and IP address randomization on both IPv4 and IPv6. If you use IPv4 NAT you lose control of that unless you, and not your carrier, is assigning those IPs, and the trick used in part 1) above can separate the individual traffic if more than one person is behind the same NATed IP >99.9% of the time.

          2. Anonymous Coward
            Anonymous Coward

            Re: Thanks, but no thanks

            The right-hand half will be randomly generated and change regularly due to privacy extensions, so it'll change even if you don't move between networks.

            Well now, maybe, but in yearly times the use of EUI-64 to set the system ID half of the IPv6 address shows that early on people in the IPv6 world weren't thinking of this issue.

            RFC7217's stable privacy extension provides different system IDs when a node moves between networks but stable addresses while on a network. If the whole address is changing how are systems going to be able stay connected to you?

          3. DevOpsTimothyC

            Re: Thanks, but no thanks

            IPv6 addresses are typically network portion + host portion, with "device's mac address with predictable padding being the host portion"

            Yes you can manually assign addresses but most consumer devices will use RA + DHCPv6, and some OS's can obscure this so they don't give the mac address, but they aren't always generating new ones each time the connect to the network.

            If you look at your link local address it is typically fe80::<mac address removing ever other : >/64 eg if you had a mac address 11:22:33:44:55:66 then your link local would be fe80::1122:3344:5566/64.

            For public addresses it use to be as simple as putting FFFF in the middle eg <network>:1122:33ff:ff44:5566. There are a few other predictable ways but part of IPv6 design was that the host could move from network to network and easily re-establish sessions in the same way IPv4 TCP connections handle packet loss

            1. SImon Hobson Bronze badge

              Re: Thanks, but no thanks

              "device's mac address with predictable padding being the host portion"

              May I suggest you upgrade yourself to the 21st Century ? That was deprecated a loooooooooong time ago, and all the major OSs don't do it, and haven't done it for some time.

              There are a few other predictable ways but part of IPv6 design was that the host could move from network to network and easily re-establish sessions in the same way IPv4 TCP connections handle packet loss

              Rubbish, that was never a design intent and doesn't work. If you implement roaming then you can do that, but that involves you actively setting up the roaming service on your home network so that you can use IP addresses from your home network when elsewhere.

              If you look at your link local address it is typically fe80::mac address ...

              Err, link local addresses are just that - link local and cannot be seen by anything not directly connected to that network. ANYTHING on the local link knows about your device simply because Ethernet uses the MAC address for delivering packets. It's trivially easy to scan a network and discover devices - having link-local addresses include the MAC address really doesn't make any difference whatsoever. In fact, once you've received a packet from a device, it's MAC address will be in the hosts neighbour table for you to look up.

              1. DevOpsTimothyC

                Re: Thanks, but no thanks

                Rubbish, that was never a design intent and doesn't work.

                Go take a look at Mobile IPv6 and RFC 3775. It WAS a design intent. I'll agree that it doesn't work.

                In terms of the link local address, go re-read what I said. I used the link local address so people could take a look at their own addresses.

                ANYTHING on the local link knows about your device simply because Ethernet uses the MAC address for delivering packets

                You're mixing what was considered layer 2 and layer 3 there. The POINT I was making was that link local has not deprecated the mac address padding approach for generating it's IP addresses.

                Either way the thing I was responding to was using that information as part of tracking.

        2. doublelayer Silver badge

          Re: Thanks, but no thanks

          "Under v6, my phone has a long lived identification that persists across all WiFi, mobile connections etc."

          No, it doesn't. It will have separate addresses for each network. The system doesn't have your devices keep their IP wherever they go because that would make routing a lot more complicated. You're right if you stay on one network, but if you move between them, the address will change when you do.

          The trackability of addresses is one reason I prefer to use NAT for nonpublic devices, even under IPV6. However, don't interpret it to be more powerful than it is. For example, you may think that using a dynamically-assigned IPV4 address makes it hard to track you, and it would if it changed a lot, but it probably doesn't. If you leave your router turned on all the time, then your ISP probably just extends your DHCP lease. The IPV4 address is assigned dynamically, but you've probably been assigned the same one for the last few months continuously. CGNAT does provide more; you probably also kept the same address but there's a lot of people sharing it with you. However, tracking companies know about both of these things and find better ways to identify you. It's certainly a problem, but it's not the biggest problem.

  6. mark l 2 Silver badge

    I am not sure I want all my internet connected devices to have publicly routable IPs if were were to go a IPv6 only world. I think I would still want all my devices behind my routers firewall and NAT to private IP addresses for my own security.

    1. Charles 9

      Um...you can do that with IPv6. Nothing prevents you from performing private routing or from relegating parts of your home net to just the locally-addressable net. It's just a matter of configuration just like you do now. Just set your IPv6 firewall accordingly to deny incoming by default like you're supposed to do with IPv4 and work from there. And yes, you can NAT on IPv6.

      1. Anonymous Coward
        Anonymous Coward

        Yeah, that's not the whole issue.

        As endpoint IP visibility is still an issue.That forced changes to the way SLAAC was supposed to work, makes tracking, censorship, and persecution much easier to implement and scale.

        And throw an * on that line about IPv6 and NAT, because the protocol is pretty specific about how it must NEVER be used in a way that could solve ANY of those issues for IPv6 traffic between IPv6 hosts.

        But at least you do understand that IPv6 just shifts some stuff from NAT/routing rules to firewall rules. Also that there are blocks of IPv6 space that are local just like 10, 172, and 192.168 in v4.

        On v6 or v4, better VPN support is really shortest distance to something resembling privacy. Wireguard is 99% of the way there.

        1. sreynolds

          Re: Yeah, that's not the whole issue.

          yeah and proton's VPN only needs one IP adress - the same one for all users. Shove that down 128 bits.

    2. Nanashi

      NAT isn't a security layer. It's not necessary for security and gives you none; all it does is make your network more complicated, which makes its security properties harder to understand.

      You'll still be behind a firewall, which will still be secure.

  7. thx1111

    Is that still a thing?

    IPv4? Is that still a thing? Is anyone still using IPv4?

    Hmm - let me think - yes, there are some old websites that I can only reach through IPv4.

    There is one called "theregister.com" that comes to mind. That one only has those old IPv4 addresses. I still run some IPv4 stack for that stuff.

    1. Pigeon

      Re: Is that still a thing?

      The register keeps cropping up in these discussions. Som 'tards understand more than I do, but these lines from my hosts file could help:

      # 2606:4700::6812:eb56 theregister.co.uk via cloudflare nat64

      #2606:4700:7::a29f:894f www.theregister.co.uk theregister.co.uk # doesnt work

      2606:4700::6812:eb56 theregister.co.uk www.theregister.co.uk

      2606:4700::6812:516 theregister.com www.theregister.com

      They evolved, and probably depend on where you are located. I am ipv6 only at home, and the address for theregister.co.uk works from the uk. The issues against publicly advertising the AAAA addresses are probably security/log related. We have been warned about forums possibly not working properly.

      Cheers

      1. thx1111

        Re: Is that still a thing?

        $ host -6 -t A theregister.com

        theregister.com has address 104.18.4.22

        theregister.com has address 104.18.5.22

        $ host -6 -t AAAA theregister.com

        theregister.com has no AAAA record

  8. steelpillow Silver badge
    Devil

    FFS!

    Just re-read this. Some guru is whining that "The use of NATs forces the interactions into client-initiated transactions". FFS! This is a mantra among security architects; never, ever allow servers to initiate links - only clients may do so. He wants the whole shebang to be exploitable by push services and those who pwn them.

    Nor is there any serious meat to the claim that NAT's thus stifling insecurity somehow also stifles innovation. Yes, Dr. Evil is a little stifled by the restriction in opportunities, but I hardly see that we users are.

    More than ever, I thank our stars for IPv4 and NAT.

    1. Anonymous Coward
      Anonymous Coward

      Never say never

      Unless it's never allow by default, and only by carefully considered and deliberate exemption.

      The internet is a terrible place filled with terrible people, and above all else, it is not to be trusted.

    2. John Sager

      Re: FFS!

      What's a server and what's a client? The actual point of the article was that the v4 net as it's evolved forces us into that kind of working, whereas a lot of useful stuff could be done peer-to-peer with symmetric connection establishment protocols if only the network would allow it. And you set up the security to be appropriate for the kind of service you want. That a lot of net traffic is actually client to server, with browser traffic the canonical example, is really a non-sequitur. The network shouldn't force that paradigm.

      1. tip pc Silver badge

        Re: FFS!

        Nothing to stop anyone having bi directional connections over a websocket, it’s just that the client must initiate the connection.

        If you want security then there must be interaction & authentication. It’s far easier and more secure for a client server concept, the server being centralised. A client initiating a websocket is trivial and works over cgnat and provides for bi directional connectivity. I can’t see a good use case for commercial inbound initiated connectivity to something on cgnat, yes a home user behind cgnat May want an inbound connection but they will be an exception and should source a non cgnat connection or engineer around it.

        If you procure a cgnat connection you will know it’s limitations and will need to pay more for a non cgnat connection or for a solution that works across a cgnat.

        1. Charles 9
          Big Brother

          Re: FFS!

          So you're basically saying peer-to-peer connections can just shove it? Think of the implications if everything has to go through a gatekeeper.

        2. doublelayer Silver badge

          Re: FFS!

          "If you procure a cgnat connection you will know it’s limitations and will need to pay more for a non cgnat connection or for a solution that works across a cgnat."

          Oh please. Most users will not know the limitations of CGNAT, but let's just assume that anyone who doesn't know won't operate the things that need it. The problem is that if an ISP is doing that, you probably have little or no option to get around it. If they're very short on IPV4 addresses, which is why they wanted to do CGNAT in the first place, they're going to be expensive for you to purchase a static one from them. That is if they offer it at all. A lot of ISPs have different packages for business and residential users to the extent that business service cannot be purchased in some areas.

          Furthermore, this proves why IPV4 is unfit for some purposes. When we get to the point where I have to pay extra because we have a shortage of numbers, but not for any technical reason such as needing more reliability or bandwidth, there's something wrong with the system. This is especially true when I could have all the numbers I could feasibly use if they just enabled a protocol that already works on their equipment.

        3. SImon Hobson Bronze badge

          Re: FFS!

          the server being centralised

          Which suits those running centralised services nicely thank you - users willingly tell them so much about what they do. For those that actually care, it's unnecessarily difficult to do your own thing in the presence of dynamic IPs and NAT.

          Why should your doorbell rely on someone's web server (and your internet connection) to work ? Why should your central heating rely on someone else's server to get a message from your living room to the boiler ? Ditto for all that other stuff that doesn't work properly or at all without a "big brother" to track everything you do.

          The classic reasonexcuse given for many of the services is to make it easy for you to access stuff from your phone when away from home - because NAT stops it working in a way that's easily explainable to your average user.

      2. steelpillow Silver badge

        Re: FFS!

        Once you get above the link layer, you get into the logical niceties which have to be independent of the hardware routing/forwarding. If Alice wants to connect to Bob across a complex network, she emits a request, which Bob then services. That is how peer-to-peer connections are also set up. There is no such thing as a user-level connection request without the distinction between sender (client process) and receiver (server process). Trying to bury the distinction by implementing peer-to-peer at the logical level destroys the security model; it allows a user to pwn a remote machine and get their exploit pushed out everywhere. Reversing roles explicitly (the X11 remote desktop being the classic example) has the same problem. It's not an IPv4/6/... problem as such, it's a p2p security problem when employing logical connections such as IP. Far safer to implement the p2p business status further up the stack, where the firewalls and stuff can look after themselves.

        1. Charles 9

          Re: FFS!

          But at least allow the option is what the designers of IPv6 have been saying all along. NAT and the like at the user end is the user's choice and a delegation tool, OK. But once you get to NAT at the carrier level, something being pretty much forced by address exhaustion in many parts of the world, then you start to see the situation where end users no longer even have the option of being visible. IPv6 at least re-opens that critical option. Whether or not the user takes it up should be up to that user. However, various institutions are exploiting the status quo so are against it (like the one comment earlier about India carriers). Do we really want an Internet beholden to those kinds of gatekeepers?

        2. SImon Hobson Bronze badge

          Re: FFS!

          Far safer to implement the p2p business status further up the stack

          As long as you trust those "further up the stack". Ask (ex) Revolv users how that worked out for them when Google bought the company and shut down the servers - bricking the devices. There are numerous examples of where a service has been shut down and stuff stops working, or of services being found to be mining users' data for their own profit.

          Put another way, in the general case, "further up the chain" can't be trusted.

  9. sreynolds

    The real problem with ipv6....

    it was designed before people realized that people did have something to hide. I mean just look at the original addressing - adding the MAC address to every single packet, wasing the top 16 bits for private and public addresses - link local addresses that nobody is every going to use and then initially not providing a mechanism for managment that was present in DHCP - back in the mid 90s.

    They might as well redesign a new version and call it IpNG.

    1. Nanashi

      Re: The real problem with ipv6....

      RFC7217 and privacy extensions fix the first problem. The second problem doesn't exist; I'm not sure where you got it from, but the top 16 bits are available for allocations. Link-local addresses are used by everybody as part of bootstrapping a global address.

      A redesign to fix these problems that aren't problems wouldn't be a good use of anybody's time.

      As for DHCP, v6 was developed before DHCP was common. The DHCP RFC only predates the v6 RFC by two years (1993 vs 1995), plus v6 was in development long before the 1995 RFC date and DHCP wasn't ubiquitous until the late 90s, long after the 1995 date. There were multiple other address autoconfig mechanisms in common use until then.

      It's kinda unfair to blame them for being unable to predict the future, don't you think?

      1. SImon Hobson Bronze badge

        Re: The real problem with ipv6....

        And it must be remembered that most OSs do actually support DHCPv6.

        Notable is that Google not only won't support it in Android, but actively block the means for the user to add their own DHCPv6 client where they want it.

        You see, Google work on the basis that users' privacy is sacrosanct at the network level - it's Google's job to invade that. So they actively refuse to allow Android devices to use DHCPv6 which they see as allowing network engineers to constrain what a device can do - while actively tracking which device used which addresses when. The fact that well managed networks do actually need this ability - and in some cases it's an absolute legal requirement - makes it difficult to actively use DHCPv6 and be able to support all popular OSs.

        It is actually one reason (just one) for some networks not implementing IPv6 - Android, or rather Google's petulant refusal to allow Android to use DHCPv6, is a problem.

        BLAME GOOGLE FOR P1SSING IN THE WELL

    2. DevOpsTimothyC

      Re: The real problem with ipv6....

      Not exactly. When IPv6 was first being proposed there were "site local" addresses similar to RFC1918 and RFC6762 ones.

      However as it was going through the motions that got dropped because it would be the basis for NAT in IPv6 which had to be avoided at all costs

      1. Nanashi

        Re: The real problem with ipv6....

        No, site local was dropped because it was awkward and pointless. There was no reasonable way to specify which site an address was in, and site local addresses gave no benefit over ULA, so they were just dropped.

        Nothing to do with NAT, which is mostly pointless in v6 because of the vastly increased address space.

        1. DevOpsTimothyC

          Re: The real problem with ipv6....

          No, site local was dropped because it was awkward and pointless

          I can see quite a good point in having a database which does not have a globally routable address, but can be accessed from hosts not on the local subnet

  10. Terry2000

    I knew this would hapoen

    When I first saw IPV6 I wondered why the idiots that botched WEP security were allowed to go off in a vacuum and build a new 100% incompatible protocol. And how they envisaged anyone, anywhere, would ever use it.

    For a new addressing scheme to be adopted it HAD to be an extension of IPV4. This would have been trivial to do. But the authors were either too stupid or too full of hubris to even consider that. No. You MUST adopt their vision and throw away everything that came before.

    Color me surprised that that didn’t happen. News flash boys: it isn’t going to happen either.

    Bonus news flash: even people that are using IPV6 e.g. Hugjsnet are NOT using it correctly. That have intentionally broken the entire scheme and turned it into just a NAT with a bigger pool. It is NOT routable from outside their network.

    It is not too late for IPV7 which could be a proper superset of IPV4.

    Or we could just complain that no one wants to be the first to lose all their customers by switching to a new network that doesn’t connect (in any reasonable manner) with, you know, THE INTERNET.

    1. Nanashi

      Re: I knew this would hapoen

      > For a new addressing scheme to be adopted it HAD to be an extension of IPV4. This would have been trivial to do

      Can you explain how?

      The fundamental problem that needs to be solved is that v4 is limited to 32 bits. After all, if it wasn't, we wouldn't need a new protocol in the first place. Can you explain how to make a new protocol, with addresses longer than 32 bits, that extends v4 in the way you claim is trivial to do?

      The reality is that this isn't possible, and all of the possible workarounds are supported by v6 (...meaning it's not 100% incompatible at all). I think it's a bit unfair to describe the people that designed v6 as "either too stupid or to full of hubris to even consider that" just because they couldn't do the impossible.

      But perhaps all of them were wrong, and you're right, and it was actually trivially possible, in which case you'll be able to tell us how to do it.

      Or was your own post the result of either stupidity or hubris?

      1. gotes

        Re: I knew this would hapoen

        Can you explain how?

        I thought the same thing. There's quite a difference between saying something's trivial to do, and it actually being trivial, even if it may appear so.

      2. Terry2000

        Re: I knew this would hapoen

        The way this is usually done is you take 1 bit and use it as a flag to say look for the rest of the address somewhere else. There is no requirement that the bits are contiguous in the headers.

        I would suggest something like taking the SECOND class A network assigned to the "Defense Information Systems Agency" whatever the hell they do. I find it quite unlikely that they need TWO Class A network ranges.

        Thus the 28 dot class A network becomes the high order part of a 56 bit address. Or make it a 128 bit address. It doesn't matter. Just have the routers look for the new extension header on all 28 dot class A routing.

        That the DoD spooks would then be relegated to ONLY THIRTEEN Class A networks seems a lot smaller ask than clearing scores of satellites and thousands of user terminals from C-Band RF to make way for 5G cell phones.

        1. Nanashi

          Re: I knew this would hapoen

          Yes, and that's the approach v6 takes. The third bit is set to 1 to indicate that clients should look for a v6 address rather than a v4 one. It also has a second mode, used for routing over routers that don't understand the normal mode, where that bit is left at 0, and the "protocol" header is set to 41, which indicates that the v6 address can be found at the start of the payload section.

          Your suggestion of squatting on someone's existing, in-use v4 range for this has no benefits over the two locations already being used. Existing v4 software and hosts will be unable to use it, a problem which you offered no means of working around.

          Apparently it's not so trivial, huh?

  11. Nate Amsden

    bandwidth and caps

    (did a quick search in the comments for keywords bandwith and cap and saw no mention of them)

    If anything is holding the internet back from being more creative on the end user front it's bandwidth limits and data caps, I think 1000x more than what version of IP people happen to be using.

    When I say bandwidth I am mostly referring to in MOST cases I think the upload speeds of broadband connections are crippled compared to their download speeds. Certainly not true everywhere of course.

    That and of course data caps, most especially on mobile where IPv6 is more widely deployed. Also there is wide spread data caps on hard wired broadband connections as well, I could only guess that perhaps maybe greater than 60% of broadband connections have data caps(I'm not against data caps personally as long as they are disclosed in advance, and preferably clearly indicated on the user's bills, Comcast for example only lets me see my data cap if I login to their site, I think it's a no brainer to put the data usage info in the bill they send, much like the power company does or phone company does), and probably in excess of 90% of mobile plans have data caps.

    I've never been a fan of IPv6 myself just comes down to complexity in addressing scheme, IPv4 numbers are easy to remember MAC addresses(which have a similar format to IPv6) are not. I realize DNS exists as a DNS admin since 1996, but I do regularly deal with IP addresses/configuration/etc as well. I realize there are shortcuts to addressing in IPv6 as well. It also comes down to IPv4 being good enough (not personally needing peer to peer or online gaming myself) so am not in a rush. I do run websites though, I figure worst case if it comes to it and I need inbound IPv6 then I use a IPv6 proxy at a CDN to handle the translation for me.

  12. iced.lemonade

    Addressing only the problem that v4 has?

    i am no network engineer, but if the problem of IPv4 is the scarcity of available address, is it possible to prepend the existing 1.2.3.4 to 0.0.0.0.1.2.3.4, update the IPv4 devices that recognize this extension, and call it IPv4 R2? seems that existing v4 devices, ideally, will recognize a subset of the R2 address pool but can still function until it makes the transition to R2...

    1. KSM-AZ

      Re: Addressing only the problem that v4 has?

      I mentioned this as well. Basically you enhance the existing ipv4 stack to recognize a packet that has a 64 bit ip address and 32 bit port number. Have a fallback mech to a standard packet if the target won't grok it. At some point most ip stacks support the extension start offering new net blocks. Internal rfc1918 space or existing spaces don't notice, their address is just stored in a larger bucket. But nooooo. There is a reason Itanium flopped, along with a bunch of other superior architectures for CPU's. It's the same reason the world did not jump on ipv6.

      1. sthen

        Re: Addressing only the problem that v4 has?

        It's not just IP stacks that would need to recognise it. Application software (servers, clients, management systems, log processing, etc) too. Also routing protocols so that different networks know how to reach each other. Address registries (RIPE, ARIN etc). DNS. Hardware designs in routers/switches - many ISP networks and even home routers rely on hw acceleration of various sorts to be able to send packets quickly.

        The additions/changes needed in this pile of tech is exactly one of the main reasons why IPv6 adoption is not fast. Going to a completely different scheme wouldn't help and would nullify much of the work already done for IPv6.

    2. Nanashi

      Re: Addressing only the problem that v4 has?

      This is basically what v6 did.

    3. iced.lemonade

      Re: Addressing only the problem that v4 has?

      after reading much of the comments in this post i was finally inclined to study the ipv6 specifications and features and, yes, it is designed to end the limitation presented in the ipv4 designed for the yesterworld, just like storing dates in 32bit vs 64bit number.

      maybe it is that the ipv6, at the first glance, is so foreign, and that unfamiliarity turns away people at the first glance. perhaps more information on the subject to layman (or those work in IT with technical knowledge not much more than a layman) will go a long way for public adoption of it.

      1. SImon Hobson Bronze badge

        Re: Addressing only the problem that v4 has?

        Yes, a big part of the problem is that "it's not IPv4"<period>

        NAT is an abomination, but because it appears to work, too many people see that there's no problem with IPv4 so why fix what isn't broken.

        To be blunt, IPv4 internet is like something held together with gaffer tape - not that I'm knocking gaffer tape. But NAT, and all the kludges to work around what it breaks, is an enormous lump of gaffer tape.

        But as long as people see that IPv6 is "new and scary", they'll shy away from implementing it. It's not actually all that hard. OK, addresses are longer, but in a properly set up network the user shouldn't ever be using them - which is another problem, too many networks are, to be blunt, steaming middens with poorly setup service that require users to understand IP addresses.

  13. Anonymous Coward
    Anonymous Coward

    Welcome to MUMSnet

    The Register commentards are usually a sound group, but whenever the subject of IPv6 comes up, the comment section turns into something from Mumsnet or the Daily Mail - lots of loud uninformed opinions based on "research" that would embarass a flat-earther.

    It's obvious that many of the complainants have looked at the address containing colons and hex and decided it's too hard.

    Here are some facts:

    Addressing

    IPv4 addresses are 32 bit - part of the leftmost bits are a network address, and the rest are either a host address or a further division of more net/host splits. When you get down to the final local network, the rightmost bits are associated with the host on the LAN.

    IPv6 addresses are 128 bit - part of the leftmost bits are a network address, and the rest are either a host address or a further division of more net/host splits. When you get down to the final local network, the rightmost bits are associated with the host on the LAN.

    The only difference apart from size is visual - conceptually they are the same : "net/routing part" and "other part"

    Now, it seems many people want an expanded address range, but don't want longer numbers. How would you do that?

    A 128bit IP address in the IPv4 address style would be a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p

    I suppose you could say "for presentation, allow stripping off of leading zero octets. And map current IPv4 addresses to 0.0.0.0.0.0.0.0.0.0.0.0.a.b.c.d

    Well, IPv6 does just that, but better - each address is broken down into 8 16 bit numbers, separated by a colon. Not only can these 16 bit numbers (represented in hex) have their leading zeros stripped, but groups of 16 bit numbers as zero can be replaced by "::"

    Still, if you want, you can still use IP4 notation, e.g. ffff:02::12.13.14.15

    You can use anything appropriate - remember, all it comes down to is a way to specify a 128 bit number, but just as IP4 can also be represented in different ways: (localhost: 127.0.0.1 or 127.1 or even just as a 32 bit decimal number: 2130706433), so can IP6, but you tend to use the form most appropriate.

    tl-dr: It's just a bit number. 128 bit instead of 32 bit. No other difference.

    Differences

    There are LOADS of useful enhancements with IPv6 - but they are optional.

    The only real "change" from IPv4 is that arp has been replaced by a more network efficient format that can also do other host discovery and duplicate address detection. - ICMPv6 is used for this.

    This makes it easier going forward - one protocol instead of mixtures of arp/icmp/ as with ipv4.

    This is only the real difference to IPv6, and it's a simple concept to understand.

    Backward Compatibility

    IPv6 still allows you to use protocols that are no longer necessary if you want, e.g. NAT and DHCP.

    You also have a large choice of transitional protocols to choose from: 6in4, 4in6, 4over6, 6over4, 6to4, nat64, dns64 -- none required, but there if you want.

    As for "plug in" compatibility, many commentators are like the special kid trying to hammer a square peg into a round hole.

    How are you going to fit an address longer than 32 bits into a 32 bit address?

    The stack HAS to change. Data structures will be different. The only ways of encapsulation ip4 into ip6 already exist.

    As for routing, IPv6 can already be encapsulated and routed over the existing IPv4 infrastructure, but guess what? It doesn't happen much because most of the wide are networking has already been upgraded, due to these systems constantly being improved. The issue with compatibility is not the networks or the routers, it's the endpoints. The users equipment. And no protocol with an expanded address range can magically make that transition invisible, though of course, with an ip4-ip6 conversion at the edge, ipv6 can still allow non-ipv6 hosts to connect to others as much as could be technically possible.

    It's almost as if a bunch of experts have slaved over this for years, and thought of - and mitigated against - many things most would never even consider.

    Still, what would they know? The real experts are el reg's very own mumsnet flatearthers commentards whose expert opinion is "I haven't looked at it, it's too hard", or "the addresses are too long"

    1. KSM-AZ

      Re: Welcome to MUMSnet

      Helpdesk how may I be of assistance?

      . . .

      OK, I need you to click the star button ,.... oh yes, the little wheel at the bittom left..... now type in cmd, .... now type in ipconfig and hit enter. You should see something that starts with ab:cd:02.... No not that one, ...

      IPv6 is for geeks. Of course the addressing is l-r, so what. Hard enough reading 3 decimal numbers, ... and frankly, if most all ipv6 is 3+3 hex with :: then why on earth would you make it 128 bits ling in the first place? People seem to forget what expotential means... just remember the pay me a penny day 1 and double my salary every day for 30 days story.

    2. John Sager

      Re: Welcome to MUMSnet

      It's worth also pointing out that the Gods of the Internet, i.e. the Regional Internet Registries, have developed a better plan for public address allocation than that which just growed up higgledy-piggledy with IPv4. That makes router routing tables a whole lot smaller, even with a much bigger address space.

    3. Anonymous Coward
      Anonymous Coward

      Re: Welcome to MUMSnet

      You're screaming into the void I'm afraid.

      A lot of the people here that have complaints about IPv6 still don't realise that an IPv4 address is not a string like the human readable form they are used to typing. Which is why they think you can just append a new section to it and have more addresses without replacing IPv4.

      Which is scary if you think about it. There are literally people here that are doing network administration as a profession that apparently don't have a grasp on very basic computer science concepts and those people are telling their bosses they need to stay on IPv4 with NAT because it's more secure and privacy friendly.

      Part of me is laughing at these people, another part of me is hoping I never have to work with or depend on these people.

      1. Anonymous Coward
        Anonymous Coward

        Re: Welcome to MUMSnet

        "Part of me is laughing at these people, another part of me is hoping I never have to work with or depend on these people."

        And part of me is scared shitless these people might be in charge of a network that matters.

      2. doublelayer Silver badge

        Re: Welcome to MUMSnet

        Be careful. The people who don't understand extending the length of addresses aren't always the people who "are telling their bosses they need to stay on IPv4 with NAT because it's more secure and privacy friendly." I have made that point here, but I made it clear when I did that I was referring to the default configuration for home users, where I fear that firewalls will be insufficient and lead to vulnerabilities. I.E. it's not IPV6's fault, and NAT on IPV6 would be equally fine, but either the defaults are going to have to improve the firewall rules or use NAT in order to prevent devices opening themselves up to the internet when they shouldn't. Those complaints are not the same.

      3. SImon Hobson Bronze badge
        Facepalm

        Re: Welcome to MUMSnet

        Part of me is laughing at these people, another part of me is hoping I never have to work with or depend on these people.

        With a previous work hat on, I did in fact work with this sort of "network professional".

        The sort of network professional that laid down a corporate standard that any routers would lie in the range of addresses .1 to .9, that servers would be in the range .30 to .49, and so on. Completely decimal thinking without any clue about what that means in terms of applying filters should that be needed.

        Not only that, but because of the size of my site, I decided to allocate a /23 out of our bit of the 172.16/12 block - the same "professional" network people simply couldn't understand that allocating a client to .1 in the upper half of the subnet didn't put it in the range reserved for routers.

        Oh yes, and I recall working with some Netgear routers in the past that simply could not cope with anything but a /24 subnet. Regardless of context, a.b.c.0 or a.b.c.255 were declared invalid by the GUI.

        So yes, "these people" really do exist - and yes, they do exist in worrying places.

        1. tip pc Silver badge

          Re: Welcome to MUMSnet

          “ Not only that, but because of the size of my site, I decided to allocate a /23 out of our bit of the 172.16/12 block - the same "professional" network people simply couldn't understand that allocating a client to .1 in the upper half of the subnet didn't put it in the range reserved for routers.”

          I bet your large site had just 1 subnet.

          So perhaps they’d had a standard that no subnet should be more than /24 and all routers would be from .1 to 9, and you suddenly broke that.

          Why didn’t you just do 2 x /24’s, private ip’s are free!!

          It’s good engineering to not use big subnets, modern switches can temper broadcasts but in older times having large broadcast domains would slow all your systems in that broadcast domain as everything would need to listen to the broadcasts.

          Many firewalls (checkpoint, asa etc) for decades have allowed ranges to be used in rules as well as subnets.

          >” So yes, "these people" really do exist - and yes, they do exist in worrying places.”

          Classic example of someone who knows a little & thinks they know best but truly has no clue.

          1. SImon Hobson Bronze badge

            Re: Welcome to MUMSnet

            I bet your large site had just 1 subnet.

            It did, but actually not that many devices. It was more a case of our use case didn't fit too well with their prescribed block assignments - and it left a dynamic range that was a bit too small to allow for both reasonable length leases (for stability) and a moderate amount of churn.

            Prior to joining this big WAN with the prescribed usage of IPs, I did use just a /24 for this network from the 192.168.0.0/16 allocation. It wasn't the number of devices, it was the restrictions imposed that made me choose a /23.

            So perhaps they’d had a standard that no subnet should be more than /24 and all routers would be from .1 to 9, and you suddenly broke that.

            Actually, it was more a case of the supposedly professional people doing the networking hadn't actually even thought about that. It was clear that they had never worked with anything but a /24.

            Why didn’t you just do 2 x /24’s, private ip’s are free!!

            And then you have the problem of routing those addresses together - and breaking the stuff that relies on broadcast or multicast.

            It’s good engineering to not use big subnets, modern switches can temper broadcasts but in older times having large broadcast domains would slow all your systems in that broadcast domain as everything would need to listen to the broadcasts.

            True. But as you don't know what was on our network, you aren't qualified to say whether your suggestion would be better or worse than what we did have. It did work just fine, and broadcast traffic was not a problem. Bear in mind that a significant proportion of traffic was keystrokes sent via Telnet and the corresponding screen updates - that should date it a bit for you, as should the fact that it was a mix of 100 and 10M, using hubs, and only (IIRC) one switch to give some traffic segregation between hubs (I tried to keep "groups of users", especially the art/design dept with their megabyte sized files, together on one hub). That was not far behind state of the art at one time you know ;-) As it was, it was a very major step up for us from the 230kbps Apple LocalTalk for the Macs, and no network at all for the PCs.

            Also, lets just say that budget was "not large" :-(

            Many firewalls (checkpoint, asa etc) for decades have allowed ranges to be used in rules as well as subnets.

            And many have not. And also there's the issue of diagnostics and stuff like that.

            Classic example of someone who knows a little & thinks they know best but truly has no clue.

            That's a rather wild accusation to throw at someone when the only evidence you have is that you think you have a better grasp on how the network should have been designed than the person who was actually there with access to the information needed in order to make those decisions.

            1. tip pc Silver badge

              Re: Welcome to MUMSnet

              So perhaps they’d had a standard that no subnet should be more than /24 and all routers would be from .1 to 9, and you suddenly broke that.

              Actually, it was more a case of the supposedly professional people doing the networking hadn't actually even thought about that. It was clear that they had never worked with anything but a /24.

              Why didn’t you just do 2 x /24’s, private ip’s are free!!

              And then you have the problem of routing those addresses together - and breaking the stuff that relies on broadcast or multicast.

              Why is routing a problem, especially on the same site? Router on a stick did just that before l3 switches where common.

              It’s good engineering to not use big subnets, modern switches can temper broadcasts but in older times having large broadcast domains would slow all your systems in that broadcast domain as everything would need to listen to the broadcasts.

              True. But as you don't know what was on our network, you aren't qualified to say whether your suggestion would be better or worse than what we did have. It did work just fine, and broadcast traffic was not a problem. Bear in mind that a significant proportion of traffic was keystrokes sent via Telnet and the corresponding screen updates - that should date it a bit for you, as should the fact that it was a mix of 100 and 10M, using hubs, and only (IIRC) one switch to give some traffic segregation between hubs (I tried to keep "groups of users", especially the art/design dept with their megabyte sized files, together on one hub). That was not far behind state of the art at one time you know ;-) As it was, it was a very major step up for us from the 230kbps Apple LocalTalk for the Macs, and no network at all for the PCs.

              Also, lets just say that budget was "not large" :-(

              Ummmmmmmm, hundreds of hosts broadcasting across 10 & 100mbs switched segments is a pain, across hubs too is just asking for trouble. I’m glad it worked ok for you.

              My first job, we had loads of sites with hubs on the edges, staff would come in, boot their machine, login and go for breakie and their machine would just about be useable ~40 mins later. Swapped all those hubs for 100mbs switches and logins dropped to less 3 mins.

              VLANing servers away from other systems improves responsiveness as the severs don’t see all the nonsense from the desktops.

              Many firewalls (checkpoint, asa etc) for decades have allowed ranges to be used in rules as well as subnets.

              And many have not. And also there's the issue of diagnostics and stuff like that.

              What’s the issue with diagnostics? You just check the ip against the subnet, it’s standard normal networking.

              That's a rather wild accusation to throw at someone when the only evidence you have is that you think you have a better grasp on how the network should have been designed than the person who was actually there with access to the information needed in order to make those decisions.

              Seen it before, not difficult to comprehend. Industry standard is to limit broadcast domains. All systems must listen to broadcasts, they are a huge pain in low bandwidth systems and hubs. It may have worked ok for you but could have been far far better.

              Classic example of someone who knows a little & thinks they know best but truly has no clue.

        2. Charles 9

          Re: Welcome to MUMSnet

          .0 and .255 are reserved in the standard. .0 describes the subnet and is crucial for bindings and listening rules (bind to 192.168.1.0, etc.). .255 is the broadcast address intended to send a packet to all members of the subnet.

          1. tip pc Silver badge

            Re: Welcome to MUMSnet

            Charles9

            Re: Welcome to MUMSnet

            .0 and .255 are reserved in the standard. .0 describes the subnet and is crucial for bindings and listening rules (bind to 192.168.1.0, etc.). .255 is the broadcast address intended to send a packet to all members of the subnet.

            That’s the network and subnet boundaries for a /24. Different CIDR’S will have different boundaries, e.g a /23 of that network will have the same broadcast address but the net address will be 192.168.0.0.

            Have a play here and see what happens when you choose /28 or /27

            https://www.subnet-calculator.com/subnet.php?net_class=C

            1. Charles 9

              Re: Welcome to MUMSnet

              It's considered nonstandard by the address class system set up with IPv4, which normally enforces the subnet split at the octet (class A at the first octet, class B at the second octet, and class C at the third). Resorting to nonstandard conventions points to there being a problem (or as I would put it, barrel-scraping).

              1. tip pc Silver badge

                Re: Welcome to MUMSnet

                It’s not non standard, it’s been a thing since 1993.

                Look at RFC 1518 and RFC 1519.

                Have you been in a time capsule since the 1980’s?

                https://en.m.wikipedia.org/wiki/Classless_Inter-Domain_Routing

                It’s positively dangerous when the I’ll informed spout nonsense as truth.

                1. Charles 9

                  Re: Welcome to MUMSnet

                  Thing is, RFC1918 still depends on the classful system, as the private allocations are explicitly classful: Class A (10.), Class B (172.16 thru 172.31), and Class C (192.168.). So any router doing NAT over an assumed Class C private network will assume the .0 and .255 (all 0s and all 1s on the host part, respectively) can't be used due to them being the network and broadcast identifiers, respectively.

                  1. tip pc Silver badge

                    Re: Welcome to MUMSnet

                    That’s not been true since before 1993.

                    If you have a subnet mask then your classless.

                    No mask and your classfull.

                    Everyone everywhere uses masks.

                    You’ve got a tiny fraction of a story and running with it, preaching falsehoods to all who will listen, yet the truth is stating you in the face.

                    1. Charles 9

                      Re: Welcome to MUMSnet

                      What truth? Class or no class, it's assuming a /24. Anything beyond that calls for more technical, more expensive equipment. If a router is assuming a /24, isn't it correct to reserve the .0 and .255 for the network and broadcast descriptors, yes or no?

                      1. tip pc Silver badge
                        Facepalm

                        Re: Welcome to MUMSnet

                        What truth? Class or no class, it's assuming a /24. Anything beyond that calls for more technical, more expensive equipment. If a router is assuming a /24, isn't it correct to reserve the .0 and .255 for the network and broadcast descriptors, yes or no?

                        a router built since 1993 will be compliant with the RFC's & will not assume classful networking & will be compliant with CIDR.

                        to be clear, no router will assume /24. All routers will require a CIDR.

                        the wiki pages for this are very clear and easy to understand

                        https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#Background

                        https://en.wikipedia.org/wiki/Classful_network

                        1. SImon Hobson Bronze badge

                          Re: Welcome to MUMSnet

                          a router built since 1993 will be compliant with the RFC's & will not assume classful networking & will be compliant with CIDR

                          I'd suggest "many routers built since 1993 will ..." It took a while for Netgear to understand that the whole internet isn't built with /24 subnets ! I recall working with one that was much more modern than 1993 that would not allow .0 or .255 to be used anywhere regardless - including on WAN facing settings.

    4. DevOpsTimothyC

      Re: Welcome to MUMSnet

      A couple of minor additions

      * IPv6 was designed with endpoint to endpoint connectivity in mind rejecting any form of translation in the middle (aka no NAT)

      * You can only have one :: shortening when writing network notation aka ::1, you cannot do ::1234::1 as it leads to an ambiguous value

      * When you split the host portion of network:host, the smallest you can go and still have a fully functioning IPv6 subnet is /64.

      Anything smaller than a /64 breaks RA's and you have to manually configure everything

    5. SImon Hobson Bronze badge

      Re: Welcome to MUMSnet

      ... but whenever the subject of IPv6 comes up, the comment section turns into something from Mumsnet or the Daily Mail - lots of loud uninformed opinions based on "research" that would embarass a flat-earther.

      And you missed off another feature of IPv6 discussions - all the downvotes against factually correct statements that don't fit with someone's idea of what reality should be in their world. And I note that none of those downvoting are brave enough to say what they think is wrong with the post they are downvoting.

  14. Paul 87

    By far the biggest headache with IPv6 is that they stop being easy for human's to read and comprehend

    An experienced network engineer can look at the issued IPv4 ranges on a PC and work out why they may be having issues accessing the internet / network resources / VPN etc.

    To do the same on IPv6 takes a lot more knowledge and understanding, if it's even possible at all

    Therefore, pain in the arse to switch over.

    1. Anonymous Coward
      Anonymous Coward

      A thing that most of the people using the internet is hard to do for people that should be able to learn a few rules or how to use DNS is hard..... so we should stick to a system that isn't fit for purpose anymore and add a bunch of awful hacks that break stuff for everyone.

      Sounds right. Hey guys. Stop that IPv6 deployment.

    2. DevOpsTimothyC

      That's just an familiarity / day to day use issue. An experienced network engineer spends alot of time working with IPv4 addresses (and probably has over the years). Generally they don't have the same amount of time spent managing IPv6 addresses and network

      1. jtaylor

        Yup, more confusing for normal humans, but network people should pick it up quickly.

        When you have to untangle network problems in IPv4, it's already binary. Masks are binary, option flags are binary, routes are binary. Router jockeys are as dain brammaged as people who code in assembly language.

    3. doublelayer Silver badge

      "By far the biggest headache with IPv6 is that they stop being easy for human's to read and comprehend"

      I don't think that's the problem. It's just unfamiliarity. Take this parallel. I do not live in the UK, and I do not understand UK postal codes. There's a space in the middle, somewhere, but sometimes it's left out and I don't know if that's a valid shortening technique or if someone wrote it wrong, and while the first half makes some geographic sense, the right half seems completely random. It contains letters and numbers, but not as a base 36 value, because some positions only contain one or the other. How do you verify that a string is a valid code? I don't know.

      This is not because the UK's postal codes are in fact confusing, it's just because I've spent all of ten minutes looking at them a year ago. I skimmed the top part of the Wikipedia article, got lost, grabbed something from elsewhere that solved the problem, and moved on. If I ever needed to understand them, perhaps if I moved there, I would spend some extra time and figure it out. I think all of us see IPV4 addresses more often than IPV6 ones. Even on local network equipment which supports IPV6 natively, the important addresses are often IPV4. For example, my home network supports IPV6 just fine, but the configuration address is still an IPV4 one (yes, it probably has an IPV6 address too, but I don't know it). If we just put in the time required to learn how the address structure is mapped out, it is something we can learn just as easily.

      1. Charles 9

        Some people just have a poor head for stuff like that, though. They have a hard time remembering a ten-digit telephone number, and the 12 (at most) digits of an IPv4 address is a real stretch. Now lengthen it and throw some letters into it and it all becomes alphabet soup in their heads.

        Now was that "correcthorsebatterystaple" or "donkeyenginepaperclipwrong"? That kind of confusion.

    4. SImon Hobson Bronze badge
      Facepalm

      An experienced network engineer can look at the issued IPv4 ranges on a PC and work out why they may be having issues accessing the internet / network resources / VPN etc.

      And with IPv6 it would be no harder - and in many ways a lot easier - for a given level of familiarisation.

      If I tell you that a client at a.b.c.237 is struggling to talk to a.b.c.243 with a subnet mask of 255.255.255.224 - how long does it take you to work out what the numbers mean ? OK, if you deal with it all day every day you carry the tables in your head to convert the decimal to binary - but with IPv6 you only have to remember at most 16 binary values from 0000 (0) to 1111 (f) and subnet calculations are a lot easier. And you only ever have to do one nibble of comparison as the split is explicit (as in writing a.b.c.237/27 - and in a well setup network you'll NEVER have to do any binary as the prefixes will all be on nibble boundaries.

      So ... IPv4 means learning "strange" tables of decimal-hex-binary-subnet length conversions, IPv6 means just comparing numbers are written and AT MOST doing on nibble of hex-binary conversion. So obviously, IPv6 is so much more complicated

      1. Alan Brown Silver badge

        Arbitrarily small LAN netmasks simply don't happen in IPv6 unless you're deliberately setting out to break things, so this is a straw man

  15. Disgusted Of Tunbridge Wells Silver badge

    IPv6 is hampering IPv6 adoption

  16. Anonymous Coward
    Anonymous Coward

    Another (posssibly uninformed) view........

    Dear Geoff Huston:

    Quote: "...The use of NATs forces the interactions into client-initiated transactions..."

    Well, well......I for one DO NOT WANT to see "server-initiated transactions".

    ....for the obvious reason that security here at Linux Mansions is ALREADY a worrying proposition.

    When we get a really secure hardware/software environment to run at MY END of the internet, then I'll start to take an interest in "openness".

    But perhaps your analysis also need to take account of the original design of TCP/IP......it was (with hindsight) designed as an open nightmare. Every networking advance has been predicated on limiting the nightmare. Perhaps that's why no one wants the IP6 free for all!

    Just saying!

    1. jtaylor

      Re: Another (posssibly uninformed) view........

      "I for one DO NOT WANT to see "server-initiated transactions".

      Your networking world is small. There are plenty of situations where data is pushed to the client. How would you connect a telephone call without notifying the recipient? How would you update real-time financial data to a trading terminal?

      1. Charles 9

        Re: Another (posssibly uninformed) view........

        Clients should keep a live link to central control, much like the telephone system depends on a live wire. This is especially important if the client keeps moving and jumping neyworks. Only it can keep the server informed of its current position.

        1. SImon Hobson Bronze badge

          Re: Another (posssibly uninformed) view........

          So you continue the situation the article mentions - "control" is vested with those who run the servers and there are disincentives for that to change.

          Agreed there are security issues, but for example I already run my own mail server at home (so SMTP and IMAP) and web service (so HTTP(S)). I can connect to those from my phone without having to have permission from someone like Google or Faecesborg to do so. Who knows what else people could come up with that might well be very useful if there weren't this technical hurdle that - contrary to what people will tell you - dealing with NAT is actually non-trivial (it's easy for some cases, impossible for some - there's a reason I hold a special place in my room 101 for Zyxel).

  17. JavaJester

    What's all the fuss about?

    At least for me, Comcast and T-Mobile both provide an IPv6 network address that passes all of these tests. Facebook and Google's DNS return IPv6 addresses that work fine. When big tech companies see a use case that benefits from IPv6 they will use it. Otherwise, there is little point in reworking a functional system just to be on IPv6.

    1. SImon Hobson Bronze badge

      Re: What's all the fuss about?

      The problem is that if you have enough large holdouts that stick to IPv4, then "rest of world" needs to continue supporting IPv4. As long as "rest of world" still does IPv4, then there's no incentive for anyone to move to IPv6.

      It's great that so many large outfits have gone to IPv4. But at the current rate, it's likely to be a long time before people see that propping up IPv4 with more gaffer tape (NAT is gaffer tape, CGNAT is more gaffer tape on top, methods to get through NAT are yet more gaffer tape) is pointless.

      Just think, if someone like Google declared that they were dropping IPv4 then there would be a significant push to get IPv6 working everywhere that people want to use Google services. Google isn't going to do that as ong as there's a significant amount of IPv4-only stuff about. Catch-22.

  18. ecofeco Silver badge

    Or maybe, just maybe

    Maybe we could try to trim the network traffic bloat first?

    Yeah, yeah, I know, optimization and not calling the mother ship every second with ceaseless data nattering is not what the cool kids are doing these day. Now get off my lawn.

  19. Anonymous Coward
    Anonymous Coward

    Fighting NAT and DHCP broke ipv6 adoption

    If, in the early days, they just accepted that NAT & DHCP from a central server where acceptable use cases then ipv6 adoption would have happened a long long time ago.

    Fighting NAT caused huge headaches requiring bespoke costly and time consuming strategies for something that was already cheap, easy and well understood.

    It could have been optional, as with ipv4, it would have been widely used on the domestic client side.

    The more tech savey would have tuned it to their use cases.

    Being smug and claiming it wasn’t needed just made moving to ipv6 harder.

    Yes NAT breaks the server client use case, but the early internet port scanners showed server client as the folly it truly is.

    Yes the huge client subnet makes it harder for the port scanners to find a device that will respond. https://datatracker.ietf.org/doc/html/rfc7707

    Yes a firewall will drop unsolicited inbound connections but that breaks the server client use case.

    A client frequently changing its client subnet address breaks the server client use case.

    The Server client use case is effectively broken, it’s safer for the client to open a long lived connection to the server.

    Client server confers far more protection to the client & is an easier thing to secure on the client side using NAT.

    In an enterprise, having a centralised dhcp solution makes address management far easier then checking every L3 for what it’s allocated via SLAAC.

    https://blogs.infoblox.com/ipv6-coe/the-odd-history-of-provisioning-an-ipv6-address-on-a-host/

    https://blog.apnic.net/2020/08/24/a-brief-history-of-recent-advances-in-ipv6-security-part-i-addressing/

    It’s virtually guaranteed that once ipv6 adoption gathers pace there will be more glaring issues found that would be mitigated by techniques used in ipv4 but where frowned upon for ipv6

    1. SImon Hobson Bronze badge

      Re: Fighting NAT and DHCP broke ipv6 adoption

      For DHCPv6 put the blame in Google's lap. There is no problem using DHCPv6 in general - it's just that Google for their own reasons refuse to allow it to be used on Android. This isn't just a case of not supporting it, they actively block the ability to install a DHCPv6 client.

      The reason, AIUI, is that DHCPv6 can be slow to renumber if the upstream network changes - such as in mobile networks. Therefore, because DHCPv6 is not good for this application, they refuse to allow it to be used anywhere.

      They also have this attitude that network operators should not be allowed to control or influence or monitor clients in any way - regardless of that being not just good practice, but legal requirement for many networks. And monitoring deices and spying on people is Google's job - not some pesky network operator between them and the client.

      GOOGLE IS TO BLAME for DHCPv6 being a problem

      1. tip pc Silver badge

        Re: Fighting NAT and DHCP broke ipv6 adoption

        “ The reason, AIUI, is that DHCPv6 can be slow to renumber if the upstream network changes - such as in mobile networks. Therefore, because DHCPv6 is not good for this application, they refuse to allow it to be used anywhere.”

        And do you know why the upstream network needs to change for the devices android works on!!

        Original intentions for ipv6 where for address stability and, if the provider changed, to aid identity by effectively using the MAC in the host part of the address, it’s now considered a privacy fail so now address instability is fashionable. I think Apple rotates the host address every 24hrs.

        Google don’t really care what the host address is and for domestic clients I guess they see slaac as having some advantage for the client.

        Enforcing slaac likely makes it harder for tracking clients across large Wi-Fi networks. Modern clients tend to randomise their MAC’S anyway, largely negating the use of dhcpv6 unless in a corporate.

        I’m not defending Google’s stance, just wanting to hi-light that there is likely some interesting underlying reason for this.

        1. SImon Hobson Bronze badge

          Re: Fighting NAT and DHCP broke ipv6 adoption

          I think you are getting confused with mobility services - where a client can keep a stable address - but only by using a mobility service in their home network. But this is completely unrelated to the long deprecated use of the MAC address in forming addresses.

          But yes, in many networks, especially mobile, the upstream prefix will change and so the device (and anything downstream of it) will need to renumber. Yes, people understand that, and yes, we can understand that DHCPv6 isn't necessarily the best option in those networks.

          But Google has declared that because DHCPv6 is not good for mobile devices, it won't allow it to be implemented on Android regardless of application. And when I say won't allow it to be implemented, AIUI they've done deals with hardware (chip) manufacturers to actively block the packets (at the chipset level) that would be needed to make DHCPv6 work. AIUI there is an implementation for Android - but because of this packet blocking, it doesn't work on many devices.

          So in this case, it really is a case of Google actively blocking it's implementation because they don't think people should be allowed to use their own devices as they want.

  20. Kevin McMurtrie Silver badge

    Sorry to change topic

    Doesn't APNIC have better things to do? They have multiple major countries in their jurisdiction that are part of global IP addressing but don't use APNIC. Japan has JPNIC, Korea pretends to use KRNIC, and China and Vietnam have been recycling the same dummy registration templates for maybe 15 years now.

  21. Blue Sky Pen

    What about security?

    The principal issue we don’t use IPV6 is security. You really can’t turn it off.

    1. Anonymous Coward
      Anonymous Coward

      Re: What about security?

      What do you mean you can't turn it off? What about your firewall?

  22. Medixstiff

    Good old APNIC flogging the IPv4 thing again.

    For the best part of 2 years they were sending out "IPv4 addresses are being bought up at an alarming rate" emails like a dodgy real estate agent trying to sucker you in to buy x amount of said dwindling addresses, on a weekly basis along with all the other useless drivel emails about electio0ns etc. that they were spamming us with so we re-directed them all to deleted items and had a calendar entry to check when our products were due for renewal.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like