1. 19
  1. 8

    ntpd (the Mills implementation) configures a hardware reference clock as a “server” with an “address” of 127.127.x.y, where x is the driver ID and y is the unit ID for drivers supporting more than one device (akin to major/minor device numbers). This is likely to cause breakage. ntpd could be updated (and honestly, should have been, decades ago) to have a more sensible way of configuring these, but it would still leave many existing configs in need of an update.

    This is probably a minor concern compared to the zillion routers out there that are martian-filtering 127/8, but it’s still a thing.

    1. 8

      I don’t think ntpd will be the only thing, either.

      The authors clearly know of the ntp issue. (As you’d expect. They’re smart and very experienced.) Between the attack surface from services that have baked in the long standard “network 127 is always local” assumption in important ways, and the uselessness of these new ever-martian addresses, it seems at first blush like effort that is better spent leaning into selling adoption of IPv6.

      I’d love to see a little bit more about why they think this reallocation is worthwhile even though they clearly understand these problems better than most.

      1. 3

        it seems at first blush like effort that is better spent leaning into selling adoption of IPv6.

        I wonder. The IPv6 “migration” has been going on for 25 years, and we’re only ~35% of the way there – and you’d expect the first ~60% to be the “easy” part, with the rest being part of a very, very long tail. Personally, I almost never experience being on an IPv6-capable connection. I’m very doubtful that IPv6 will ever become widely available.

        Given that, maybe it makes sense to spend time and resources on workarounds for the IPv4 address shortage rather than to waste more time on the failed IPv6 project?

        I don’t personally think this RFC would help much, but the concept of spending time on improving the IPv4 situation does seem logical to me.

        1. 4

          The IPv6 “migration” has been going on for 25 years,

          I see your point even though I’d argue that it’s only been even receiving even half of an honest effort for a fraction of that. The RFC specifying IPv6 was ~1998, and at that point it was really just a weird (but standards track!) experiment primarily associated with Internet2. (I first wrote code to support IPv6 that year.) But by 2008 or 2009 the supporting standards and software were around such that we should have been able to deploy.

          I think a large part of the problem is that the workarounds have made life too comfortable as address space is exhausted. I’m not sure what I think the solution is.

          Curiously, I find that I’m on an IPv6 connection whenever I use my cheap cellular connection, but am not when I use my expensive fiber at home.

          1. 4

            The bad part is that we haven’t yet switched to ipv6 being the default-on option. Whatever tutorial / manual / guide you find to some internet service or server, it will list examples with ipv4 and maybe mention that IPv6 is also available if you really want it.

            We need AWS vpc and elb docs to use IPv6 in examples. We need dev services like GitHub to support it. Etc.

            I did a check some time ago and if AWS (console) and GitHub supported IPv6, I could turn off v4 today on my work machine.

            (I’m on the accelerationists side - let v4 burn. I hope it costs $1k per address soon. I hope the next unicorn starts v6 only. I hope people on v4 start asking their ISP why is their internet broken.)

      2. 6

        This sounds like a lot of pain for next to no gain. We’ve used of the almost 2^32 addresses that are available. Making 254*(2^16) more addresses available doesn’t seem like it would actually do anything about the actual problem of the IPv4 address shortage. The only value here seems to be the economic value of being able to sell more IP addresses at a premium.

        I may be wrong. Maybe making 0.38% of the already tiny IPv4 address space available will do something good. But I bet the space would just be bought up by Amazon and get locked up in AWS.

        1. 1

          They are making 2^24-2^16 addresses available, not 2^16. It’s a /8 with a /16 carved out of it, not a /16.

          1. 1

            2^24-2^16 = 16 711 680

            254*(2^16) = 16 646 144

            I’m not sure who of us is 100% right (I think you are?), but we’re talking about the same numbers essentially.

            1. 1

              I’m sorry, I thought you said 2^16, not 254*(2^16), I haven’t yet drank my tea today.

              The exact number of available addresses depends on how they choose to subnet the pie. More subnets means more addresses wasted on the network and broadcast address.

              Btw, IPv4 blocks sell for about $50/IP, even for a /16, so we’re talking about a huge monetary value here, even if the overall effect on the Internet would be small.

              1. 2

                Note that the authors will not profit from that RFC in any way because those addresses will be assigned to IANA and then distributed to RIRs in /8 blocks.

        2. 4

          The same authors also propose allowing use of 0/8 and 240/4.

          1. 15

            240/4 feels like the only one that could have legs here. I can’t see a world where 0/8 and 127/8 are anything but eternal martians, with anyone unlucky enough to get an IP in that space just doomed to have things never work.

            Can we just have IPv6 already? :/

            1. 4

              totally agree, we should have had IPv6 10 years ago - and yet here in Scotland my ISP cannot give me IPv6.

              1. 2

                Vote with your feet and change ISP.

                1. 4

                  Neither of the two broadband ISPs available where I live provide IPv6. Voting with my feet would have to be uncomfortably literal.

              2. 2

                Call me naive but I’m actually not sure if 0/8 would be such a big problem. I’ve surely never seen it actively special cased like 127/8. Which might just mean my experience with different makes of switches etc is not the best, but for 127/8 I don’t even need to think hard about 10 things that would break, wheres 0/8 is more like “I’d have to check all the stuff and it might work”

                1. 1

                  That’s weird, I thought I’ve seen an IP address like 0.3.something publicly routable. Not completely sure, but I vaguely remember seeing something along those lines and thinking it was weird.

                2. 7

                  Allocating 240/4 is the most realistic option because equipment that has hardcoded filters for it is either some really obscure legacy stuff that shouldn’t even be allowed access to the public Internet (like any unmaintained networked device) or, if maintained, should have never had it hardcoded and should be fixed.

                  Maybe it’s their secret plan: make two infeasible proposals to make the 240/4 proposal look completely sensible by comparison. ;)

                  1. 2

                    In all seriousness, I don’t think you have any concept of how much aging network kit there is out in the world which will never see a software upgrade ever again (either because the manufacturer don’t release them anymore, or because “it ain’t broke, why fix it?”).

                    1. 1

                      I know it quite well, but whose problem is it? Those people are already at a much greater risk than not being able to reach newly-allocated formerly reserved addresses.

                      1. 1

                        That may be the case but it’s ultimately everyone’s problem — there are network operators who will end up having to take on the support burden from users who can’t reach these services (whose hands may be tied for other reasons, e.g. organisational, budgetary etc), there are service operators who will end up having to take on the support burden from users who can’t reach their services (who can do basically nothing because it’s your network problem not ours), and there are users who will no doubt be unhappy when they can’t reach these services and don’t understand why (my friend or colleague says this URL works but for me it doesn’t).

                3. 3

                  I’d never want to run in 127.1/16-127.255/16; as the authors acknowledge,

                  Since deployed implementations’ willingness to accept 127/8 addresses as valid unicast addresses varies, a host to which an address from this range has been assigned may also have a varying ability to communicate with other hosts.