IPv6 as the "community default"

1

Hi there!
As this came up in a Github Issue
which pretty much ended in "we should discuss this", I wanted to get some more input about whether Rust should strictly default to IPv6 as the protocol used for talking about everything IP.

The idea is that, as a sizeable community with recent developer interest, Rust could make a meaningful impact towards better software support for IPv6 by both making it easy to use it (which pretty much already is the case, given as e.g. the standard library's functionality is entirely agnostic about IP protocols for everything), and more importantly examples and documentation should, in my opinion, default to IPv6 to increase visibility and help developers considering it the "default".

I consider the Rust community culture to be usually very proactive with encouraging good and discouraging bad habits with other things, e.g. making it very hard or impossible to disable verification in TLS libraries, or choosing the stricter parsing logic to get some rigor into the ecosystem, and I think that culture could make a meaningful impact on IPv6 transition too.

This is not entirely about documentation and examples then, but also about taking this issue into the usual modernization and security culture Rust (in my opinion) already has, and making the internet transition something people stay aware of.

Some in the github issue discussion already disagreed with this, and I fear there will be quite a lot of pushback here too given the general aversion to the topic (at least in my eyes, and I see a lot of it because I am quite passionate about v6), but I think it's worth discussing and hearing some points about.

2

I agree with the people opposing your proposed changes to the docs in the issue you linked. IPv6 is now almost 30 years old. Adoption won't suddenly increase due to some Rust docs using [::1] instead of 127.0.0.1. Plus, young developers who still learn networking with IPv4 at school / uni, probably, might get unnecessarily confused. It's not worth it IMO.

3

i don't think anyone expects the doc change to have a huge impact, but the fact that it isn't a big deal doesn't mean we shouldn't use the better default

that would be a problem with the course, not rust. if there is a networking course that doesn't teach ipv6, the curriculum should have gone in the trash 10 years ago.

no one is talking about removing ipv4 or even making it harder to use in any way.
having documentation for both certainly is fine.
but ipv6 must be the default if there has to be one

edit : i would add that having both side by side in some example might in fact be helpful to indicate the similarity to users which are only familiar with one

4

This is most of the reason why I even started this topic. I'm sometimes a bit baffled how every programming community, programming example, network equipment etc. does not at least to this.

Feels like after almost 30 years after coming up with the standard that could be the bare minimum.

I don't think anyone wants to make things harder for the sake of the transition, that's why we haven't completed it after all, but at least going v6 first should be "normal", and I don't think that's too much to ask for by anyone who cares about the topic.

And I don't want to argue that it makes a large difference, I just think it's the right default, and considering good defaults is something this community objectively cares about, I think this could be one of them

5

I feel like it would be better if the docs explained both IPv4 and IPv6 and told you that you're going to need support both for most software.

If there is no good default then it's best to not choose any default.

6

Note that there's a significant asymmetry here. If your software supports IPv4, that's all it supports. If your software supports IPv6, then in many cases[1], you get IPv4 support "for free" via IPv4-mapped IPv6 addresses.

Thus, unless you genuinely care about whether traffic is IPv4 or IPv6 (e.g. because you serialize addresses into a protocol), you're best off using IPv6 sockets, and supporting IPv4 by not disabling support for IPv4-mapped IPv6 addresses.

  1. If you set the IPV6_V6ONLY flag (e.g. via socket2's set_v6_only), then you only get IPv6 on an IPv6 socket, not IPv4 and IPv6. ↩︎

7

Of all network administrators and developers I know personally, less than a half knows how to use IPv6, and 127.0.0.1 is absolutelly well-known.

IMHO:
It wouldn't make any difference for people who know IPv6, because they already understand what IPv4 is, but not vice-versa.

8

It's been 30 years, at some point networking knowledge doesn't have to be backwards compatible

9

+1 vote on "against the grain" feeling of proposed change. imho the IPv6 default would be worse choice, due to overload of training materials, devices, examples etc. all over internet that view IPv4 as "the thing", and v6 as modern, more complicated extension...

10

It's been 30 years

Yep, but we still have so many IPv4 networks all over the world. Those, who do not speak IPv4, might have hard times trying to figure out how things work.

I am for IPv6: it has static size header, better multicast support, and of course NAT is a crime!
But I have a VPS on a small hosting provider, and they only gave me IPv4 and their (very limited) UI for DNS doesn't have "AAAA" record. And I am not alone here.

11

But what better way to encourage people to learn about it than gently pushing towards it as a community?

12

I agree that it was correct to close use IPV6 loopback and documentation address in documentation over V4 by default by 2ndDerivative · Pull Request #161879 · rust-lang/rust · GitHub

Even if I want to use IPv6, my ISP still doesn't support it.

If you want to add more IPv6 examples to things, great. But removing the IPv4 ones is needlessly antagonistic to people.

13

Others have said this in different ways by now, but to put it as directly as possible, the 30yrs of inadoption you keep mentioning, has been overwhelmingly bottlenecked by hardwares beyond developers' control.

For IPv6 to be adopted en masse, it has to be offered at no extra charge, because non-techies of the world, who have nothing to gain from it, will not pay a dime for it.

Meanwhile, the minority of people who stand to benefit from IPv6 doesn't have much leverage toward their ISPs, as those are even more dependent of having some internet right now.

There was a time when Minecraft was the next big thing, and I was secretly hoping it and gaming at large would drive IPv6 ahead. That didn't work; I suppose parents of the world did not understand how much pain NAT is.

14

For what it's worth, I don't disagree with your reasons for the lack of adoption either, they're true, but hardware isn't required for what i'm talking about here!

15

One problem is that attitudes toward IPv4 and IPv6 vary greatly from region to region:

There are regions where IPv6 has been the standard for many years and IPv4 is seen as an annoying relic of the past, and there are regions where people still view IPv6 as a technology of the future that will eventually become a reality.

16

It does mean that our choices are between documentation, examples, etc. that works for everyone vs. that works only for some people. If there's a good way to present both v4 and v6 without causing TL;DR, great, and by all means do it. But wherever we have to pick just one, we're likely to be choosing IPv4, because whenever different people have to do different things, there's a teaching/learning nightmare, as informations become exponentially more complicated to organize and we keep reading/pointing at the wrong thing. To some extent this is unavoidable when working close to the metal, but still, we'd like to keep as much stuff shared as possible.

17

Why? Because "it's the future of IP"?
If IPv6 was going to be universally or even broadly adopted, it would already have happened.

It seems like a worthy goal to understand the various reasons why it still hasn't been adopted. Off the top of my head, inconsistent support across networking stacks, ISPs that straight-up don't support it, as well as the way-too-long-too-remember ipv6 addresses (in their full form, 128 bit addresses turn out to be as weakness as well as a strength) come to mind.
The first issue is trickier than it sounds BTW, as routers for example don't always properly support ipv6 either (though perhaps that's gotten better with routers boasting more recent wifi versions, I don't know).

Part of it may also just be network effects, with reasoning (I don't espouse) like: "why use something where it remains to be seen that it works flawlessly for your use case when there is something that works, today?". Insofar it is that, trying to migrate people is doomed to fail (in a very similar way as how trying to create a competitor to Instagram or YouTube will fail), because of that line of reasoning.

And there's also a bit of a coordination issue: just because Alice is pushing for ipv6 doesn't mean Bob's use case places any import on it. In fact, Bob's use case might actively require ipv4 as that's the better supported protocol.

So what's the right solution? Nominally, IPv6. But in practice I have serious doubts ipv6 will ever become the default and fully replace ipv4, despite the issues with ipv4. The buy-in just doesn't seem to be there.

To anyone who reasons like this: all right, have fun, but be prepared for a 1-person network. The rest of the world certainly isn't going to go out of their way to support the purposely backwards-incompatible network that will likely result from such a philosophy, even if the tech provides benefits relative to what it's supposed to replace (and nobody mentioned such benefits being present).

Quite so. And it's very telling that that's still the dominant protocol despite the fact that collectively we've run out of IPv4 addresses: for a lot of relevant parties, IPv6 simply doesn't provide enough value to justify the disruption it causes. From that perspective, it's just churn (and thus imposes a real monetary cost) without getting any benefit from it.

Investing in IPv6 might lower the amount of churn needed, but it will never be able to fully eliminate it. Economics does the rest, as while IPv6 does provide benefits (the main one being 128 bit addresses that at least in principle allows users to dispense with hacks like NAT), the world collectively seems to be of the opinion that those benefits just aren't massive enough to justify wholehearted adoption.

Not for that, no. But it (among other things) definitely is required if IPv6 is ever going to be a practical option for devs and users alike.

18

My understanding is that 5G only natively supports ipv6, with ipv4 connections using 464XLAT instead. And for some countries that didn't get a large allocation of ipv4 addresses early on, ipv4 is not practical anymore even with CGNAT. CGNAT only allows this much extra devices per ipv4 address.

19

With my tin foil hat on I have always suspected that the adoption of IPV6 was slowed because it is counter to the business of many internet services and the huge corporations providing them.

For example, if I could get your IPV6 address and reach your machine without the NAT in between separating us then we could have peer-to-peer audio and video conferencing, we could be part of distributed messaging services without the need to go through the likes of middlemen like Facebook, Microsoft etc.

Far better for those mega corporations to keep us reliant on their services with IPV4.

20

there's also the fact that servers that relay massages to bypass NAT result in the connection being billed more times, if 2 peers connect directly to each other the connection between them is paid for twice,
if a server needs to relay messages to bypass NAT than that server's operator also pays, theoretically increasing the ISP's profit by 50%.