bigstrat2003 6 days ago

That might've been better, actually. The author makes the mistake of "more time would've made this better", but we've had plenty of time to transition to IPv6. People simply don't because they are lazy and IPv4 works for them. More time wouldn't help that, any more than a procrastinating student benefits when the deadline for a paper gets extended.

But on the other hand, if we had run out sooner, perhaps IPv4 wouldn't be as entrenched and people would've been more willing to switch. Maybe not, of course, but it's at least a possibility.

▲ SchemaLoad 6 days ago | parent | next [-]

The internet also fundamentally changed in the middle of the rollout. End user devices stopped being directly accessible because this was a security issue, they stopped being always online because they mostly run on battery now, and IP addresses costing money became a kind of barrier to spam and abuse.

Even if we could directly address every device on the internet, you'd still mostly want to run through a middle server anyway so you can send files and messages while the receiver device is sleeping, or to sync between multiple devices.

Pretty much the only loss was people self hosting servers, but as long as you aren't behind CGNAT you can just set up DDNS and be fine. Every ISP I've been with lets you opt out of CGNAT as well as pay for a static IP.

▲ dmitrygr 6 days ago | parent | prev [-]

> simply don't because they are lazy and IPv4 works for them

Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.

▲ zamadatix 6 days ago | parent | next [-]

Most of the "unwanted" things in IPv6 aren't actually required by IPv6. Temporary addresses, most of the feature complexity in NDP, SLAAC, link-local addresses for anything but the underlying stuff that happens automatically, "no NAT, you must use PD", probably more I'm forgetting. Another large portion is things related to trying to be dual stack like concurrent resolutions/requests, various forms of tunneling, NAT64, and others.

They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.

▲ yjftsjthsd-h 6 days ago | parent | next [-]

I'm not convinced that's true in practice. I would like to have an IPv6 network that I can connect Android devices to and on which I can connect to the devices by their host name. Android refuses to support DHCPv6, telling the local DNS server about SLAAC addresses involves awful and unreliable hacks, mDNS requires extra daemons and resolver configuration. I looked at just copying my v4 stack to v6; it doesn't appear possible.

▲

zamadatix 6 days ago | parent [-]

Android was nearly my real life example a la "IPv6 doesn't mandate anything be different, some guy at Android just likes doing things that way more". I.e. nothing needs to be changed in the IPv6 standard, there's just some guy on the Android team who really likes SLAAC and thinks DHCPv6 is an abomination.

▲

yjftsjthsd-h 6 days ago | parent [-]

Okay, but that's not useful. In practice in the real world you cannot run a v6 network the way you would a v4 network even if you want to. That you theoretically could go implement changes to bring them into line doesn't really affect that.

▲

zamadatix 6 days ago | parent | next [-]

I think we're saying the same thing except I'm splitting the blame from IPv6 (which was very much about adding more bits) and placing it on the unrelated hobby horses people like whats-his-name on Android ride in on. Intentionally not supporting DHCP in the new protocol had nothing to do with the design of IPv6, it's just something they prefer.

To put it from another perspective: If the situation was reversed would you be blaming IPv4 and saying IPv4 should have been designed differently or would you just be asking why this guy from Android doesn't want to add DHCPv4 when DHCPv6 is supported? In both situations it's not IPv4/IPv6 to blame for the inconvenience, it's the guy taking advantage of the transition between protocols to do something stupid at the same time. No amount of changing the definition of IP is going to make them like DHCP, they'll always push some SLAAC-like address assignment onto users. The only reason they didn't for IPv4 was they came in after it was already the way instead of before networks were deployed and they could force it.

It's often very difficult to use IPv6 in practice, but not because IPv6 made it that way.

	▲	yjftsjthsd-h 6 days ago \| parent [-]
		Oh, yes, we do (mostly) agree then. Thanks for clarifying:)

▲

6 days ago | parent | prev [-]

[deleted]

▲ JoshTriplett 6 days ago | parent | prev [-]

> They're almost always deployed though because people end up liking the ideas.

Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.

Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.

▲ zamadatix 6 days ago | parent [-]

Side note: I'm not sure why folks downvoted you. Even if they disagree it seems like an honest question.

> For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.

On IPv4 I assume you're doing something which boils down to (from whatever network configuration tool you use):

  ip addr add 192.168.1.100/24 dev eth0
  ip route add default via 192.168.1.1 dev eth0

Which maps directly to:

  ip -6 addr add 2001:db8:abcd:0012::1/64 dev eth0
  ip -6 route add default via 2001:db8:abcd:0012::1 dev eth0

If you're also doing a static ARP to be "fully" static then you'll also have an additional config which boils down to something akin to:

  ip neigh add 192.168.1.50 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent

Which maps to this config to statically set the MAC instead of using ND:

  ip -6 neigh add 2001:db8:abcd:0012::2 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent

In both cases you either need to still locally respond to dynamic ARP/ND request or also statically configure the rest of the devices in the subnet (including the router) in a similar fashion, but there's not really much difference beyond the extra bits in the address.

> Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.

I have a strong aversion to AWS... but if there is anything more difficult about this for IPv6 than IPv4 then that's entirely on what AWS likes to do rather than what IPv6 requires. E.g. if they only give you a dynamic link local gateway it's because they just don't want you to use a public address as the static gateway, not because IPv6 said it had to be so by not supporting unicast gateways or something.

There's also nothing about IPv6 ND that would make it take longer to discover the gateway from a statically configured unicast address than IPv4 ARP would take, but AWS may be doing a lot of optional stuff beyond just being a dumb gateway in their IPv6 implementation - again, not because IPv6 itself said it should be so but because they want to do whatever they are doing.

▲

JoshTriplett 5 days ago | parent [-]

That's really helpful, thank you; I'll give that a try the next time I'm attempting to make this work.

(I'm doing this using direct netlink calls from my init; this is all about booting as fast as possible. The IPv6 address information is coming from instance metadata.)

▲

Dagger2 5 days ago | parent [-]

You probably want to add the "optimistic" or "nodad" flags when adding the address, or you'll need to wait for DAD to finish.

	▲	JoshTriplett 5 days ago \| parent [-]
		I'd figured that specific detail out already, though it was hard-won knowledge. But there's a lot more where that came from before getting to the point of bringing up IPv6 and sending packets without dealing with slow RA and various other slow processes of waiting for data from the network, for instance.

▲ codebje 6 days ago | parent | prev | next [-]

If you "simply" added more bits to IPv4, you'd have a transition every bit (ahaha, ahem, sorry) as complex as the transition to IPv6 anyway, because IPv4+ would be a new protocol in exactly the same way as IPv6. A new DNS response record. Updates to routing protocols. New hardware. New software.

And no interoperability between the two without stateful network address translation.

▲

pavpanchekha 6 days ago | parent [-]

Author here. The point is that with 9-bit bytes we'd have designed IPv4 to have 36-bit addresses from the beginning. There wouldn't have been a transition.

▲

codebje 6 days ago | parent [-]

The post I replied to was speculating on IPv4's life being extended by "simply making the numbers bigger" rather than having more bits per byte, but nevertheless... there still would've been a transition, delayed by at most a few years.

Exhaustion was raised for 32-bit IPv4 in the very early 90s, when we had a few million active Internet users. Allocations were very sparsely used and growth in Internet usage was exponential. It didn't take much of an imagination to foresee a problem.

A 36-bit Internet would be little better. By the middle of the 90s we had ~45 million active Internet users, ending our 16x space advantage, even assuming we didn't just squander that with 8x as wasteful Class A allocations and bigger spaces reserved for uses that will never arise.

Today, we have ~70 billion connected devices: 5-6 billion home subscribers each with multiple devices in the home, 7.5 billion smartphones, 20 billion IoT devices, and all growing rapidly.

We'd need NAT. But NAT was a response to exhaustion concerns, as a stop-gap measure to provide time to design and transition to a proper solution. If we didn't have exhaustion concerns, there'd be no NAT. If we did have exhaustion concerns, brought on perhaps by the lack of NAT, we'd still have invented IPv6, because we'd still have been able to forecast that the Internet would rapidly outgrow 36 bits of address space.

edit: disclaimer, I work in this space, but my comments reflect my own opinion and are not necessarily those of my employer.

▲

pavpanchekha 5 days ago | parent [-]

Great reply, much appreciated. I searched a bit for a number like ~70B and didn't find one. Perhaps 36 bits wouldn't have actually worked. I do think we'd have wasted more Class As, but that's where the "minor market mechanisms" would have happened—most of the class As did get sold and would in this universe too. Again, if total internet-connected devices is now 70B that wouldn't help, you'd still need NATs.

	▲	codebje 5 days ago \| parent [-]
		It's extremely hard to get an accurate count of connected devices, so we're all just estimating. There's lots of sources giving rough values for things like smartphones or IoT devices, there's a reasonably common estimate of 5.6 billion connected Internet users, but it's largely guesswork for connected devices per user. It's improbable that I'm off by an order of magnitude: 7 billion is far too low (we have 7.5 billion smartphones in the world!) and 700 billion is far too high; how low an estimate could we make without being unreasonably optimistic? 40b seems quite low to me - 7.5b smartphones, 5.6b connected users, 20b IoT devices, and commercial use of IPs - but if we took that value we'd be sitting at saturation for 36 bits of address space (60% utilisation is pretty darn good!) and the next decade would kind of suck.

▲ bigstrat2003 6 days ago | parent | prev | next [-]

I've run IPv6 on both corporate and home networks. Whether or not the additions were merited, they are not a formidable challenge for any reasonably-skilled admin. So no, I don't think that the reason you gave suffices as an excuse for why so many still refuse to deploy IPv6.

▲

icedchai 6 days ago | parent | next [-]

It's definitely more of an education issue. I still run into "IT" people that instinctively disable IPv6 no matter what. How do we fix this? The sad thing is IPv6 is actually easier in many respects: subnetting is simpler, no NAT hackery, SLAAC...

	▲	raron 5 days ago \| parent [-]
		> I still run into "IT" people that instinctively disable IPv6 no matter what. How do we fix this? - force ISPs to follow RIPE guidance on addressing (static prefix, at least /56 for every site, DHCPv6-PD) - force the manufacturers of low-end routers (e.g. provided by ISPs) to have good IPv6 support (good firewalling, DHCPv6-PD, mDNS, PCP/UPNP, advertise static ULA prefix to have working local network even if internet connection is cut) - force Android team to support DHCPv6 - force browsers to support full IPv6 addresses in URLs / URIs (link local addresses, scope id) - force avahi / mDNS to support IPv6 scope id - make operating system manufacturers to have a better unified socket API which can resolve any type of address (IPv4, IPv6, DNS, mDNS, etc. maybe even URLs directly) and deprecate all other API - make software developers to use this new API and don't try to parse IP addresses or URLs themselves - have a good solution for multi-homing / WAN failover (without BGP and PI address space) - have a good solution for mobile / roaming devices (phones, notebooks) and maybe we could make IPv6 stable and universally working (Waste a /40 for every company, get low on available prefixes and start over designing IPv8 to have 256 bit addresses with 184 bit host part...)

▲

dmitrygr 6 days ago | parent | prev [-]

I'll assume you are speaking in good faith, so i'll reply so as well:

I do not want to be a "reasonably-skilled admin". Not my job nor desire. I want DHCP to work and NAT to exist which acts as a de-facto firewall and hides my internal network config from the outside world. All with zero or fewer clicks in my home router's config. With IPv4 this works. With IPv6 it does not. Simple choice for me then: find the IPv6 checkbox and turn it off, as usual.

▲

miyuru 6 days ago | parent | next [-]

> I do not want to be a "reasonably-skilled admin" > NAT to exist which acts as a de-facto firewall

My option is you should not handle router config at all and leave it to the ISP.

▲

Dylan16807 6 days ago | parent | prev [-]

That's the fault of whoever designed the router, not IPv6.

▲

dmitrygr 6 days ago | parent [-]

As a consumer, I don’t care if it’s Santa Claus’s fault. IPv4: works, IPv6: doesn’t. I don’t even need to know what IPv6 means. I just need to know: Turn it off to make things work.

As a technologist, growing up involves learning not to blame the consumer. They are not holding it wrong, you just designed it in a dumb way.

▲

Dylan16807 6 days ago | parent [-]

And I'm not blaming the consumer.

If you want to come into a topic and say the problem is that IPv6 did too much, you can't fall back on "it doesn't matter who's at fault". Yes it does matter, that's what this thread is about, that and looking at how technological changes would have affected deployment.

▲

dmitrygr 6 days ago | parent [-]

It is forever tainted and I will put down money on a bet that when IPv4 is replaced (in the 2040s), it will be by something that will not be IPv6.

	▲	zveyaeyv3sfye 5 days ago \| parent [-]
		My main man, It is already IPv6 !

▲ hinkley 6 days ago | parent | prev [-]

If it had been more urgent to move off of IPv4 a lot of those riders would have either been eliminated or not thought of yet. We’d be looking at 54 bit addressing and planning IPv7 to have 108.