🤶🏽 👐 👝 IPv6 - you are doing it wrong 🧑🏻‍🤝‍🧑🏻 🈳 🔟

There are a lot of misconceptions and myths around IPv6. Often, hosting providers misunderstand how to use it and think outdated approaches from the world of IPv4. For example, having octillions of IPv6 addresses, the hoster sells addresses to clients individually, instead of allocating a full-fledged network / 64, as follows from the recommendations.

It happens that hosters assign IPv6 addresses to different clients within the same / 64 network. At the same time, large services, such as Google, perceive all addresses within the / 64 range as one client. As a result, customers may suffer due to the activities of a bandmate.

The availability of IPv6 addresses allows you to assign full external addresses to internal resources, such as containers or VPN clients. To do this, the host must provide the client with a separate routed network. Unfortunately, almost no one can do this.

In this article, we will analyze the main errors in the use of IPv6 providers.

Storyline: RFC 3177

In 2001, the recommendations on the allocation of addresses recommended (sorry for the tautology, this is important) to highlight:

/ 48 in general
/ 64 if behind it one and only one subnet
/ 128 if one and only one device

The offensive document RFC 2119, which governs the application of various levels of compulsory compliance with instructions, defines “recommended” as follows:
The words “Should” or “Recommended” mean that there may be reasonable reasons in certain circumstances not to act in this way, however, the choice of a different line of behavior must be a balanced decision made with full understanding of the consequences.
Perhaps no one had a full understanding of the consequences at that time, maybe “certain circumstances” were not defined, but, one way or another, everyone followed the recommendations.

In general, at the time of writing the document, IPv6 traffic was extremely rare and was found, for the most part, in institutes and personal networks of curious enthusiasts. Some real problems began to accumulate and analyze, but it took a lot of time.
Rethinking began in 2005. Finally, these recommendations were deprecated in 2011.

Awareness of the problem: RFC 6177

The new addressing policy explicitly states that / 48 is just a wish, not a requirement. No indication of specific numbers is given, however, it is indicated that / 64 or shorter works under normal conditions.

The main logic in recommending the size of the issuance of the block / 48 to the final consumer pursued three goals.

First, the assigned address space should be sufficient for consumer purposes and easily extensible, without barbell squats. Yes, that's exactly what it says, only in the English version - jump through hoops. One of the important reasons for switching to IPv6 is to change the existing destination size from "single address" to "multiple subnets."

Secondly, the change of provider should have been held with a minimum of problems. If you can save the old subnet address scheme when moving to a new address space, then this will save a lot of work

. Thirdly, the allocation of block / 48 should cover the increase in the needs of the address space of a developing consumer.

Although all these conditions were fulfilled, it became apparent that recommendation / 48 was, to put it mildly, redundant.

Pin / 64 as units of issue

In addition to the distribution order, there were other points. It turned out that many features of IPv6 do not work if the network prefix is not / 64. Namely, they do not work:

Neighbor Discovery (ND)
Secure Neighborship Discovery (SEND)
some parts of Mobile IPv6
Site Multihoming by IPv6 Intermediation
many different little things

An additional factor was the fact that many of the technologies being designed relied precisely on such a network prefix.

Not only the threat to break the newfound standard was the reason for writing new recommendations. Two opinions of dubious validity were also very popular.
First, many devices implement IPv6 routing programmatically, with crutches and bicycles, and therefore are not ready for a full transition to it. A possible increase in the delay due to this can increase many times, if not an order of magnitude. The default definition of the / 64 subnet would greatly reduce these delays.

Second, switching to a new standard is always a pain for tech support and system administrators. A single / 64 prefix was supposed to reduce this pain to an acceptable value.

The situation on the fronts

As already happened earlier back in 2001, recommendation / 64 is perceived by many large Internet players as a standard. On the one hand it’s good, on the other hand, not so good.

For many rating systems, for example, for spam recognition, all addresses from one block will be considered as belonging to one spammer. In theory, this should make life easier for the user, in fact, just the opposite.

Often, providers do not bother with things like learning about common practices. Addresses can be issued according to any principle, at least even according to the horoscope.

There are several typical problems, and all of them stem from the violation of the recommendations by the provider on the one hand, and the strict adherence to them by some other organizations on the other.
Issuing addresses from one block to several users can lead to the fact that they will all be considered as one actual user, for example, machines in the organization’s network.

If several people from this block start looking for cats at the same time, Google may decide that this botnet will send requests for search scam or some other not very good things. From his point of view, this is all one user. The logical result is an increasingly complicated captcha.

This, as you know, is the most harmless answer to a hypothetical scam.
The reverse situation is the issuance to one user of addresses from different blocks. If users of these blocks fall into someone’s blacklist, then the addresses of an honest user will fall with them. Particularly interesting story: some of your addresses were banned by one ad network, some were banned by another.

In addition, other unpleasant surprises are possible. For example, you received the / 64 block for your use, but this is a dynamic block, as a dynamic address - today 2001: DA8: 1D01: FA13 :: / 64, tomorrow 2001: DA8: 1D01: FC15 :: / 64. New adventures every day!
There is a considerable chance to meet various combinations of these problems and other fancifully curved rakes in the appendage.

Issue IPv6 from our server

If we have a quintillion IP addresses, then why not give real IP addresses, for example, to VPN clients so that they go to the Internet without NAT and can accept incoming connections from the world. It sounds great, but in practice it’s not so easy. This will require a separate IPv6 network routed through the IP address assigned to the server interface.

Suppose a server is assigned an address 2a01:baba::c0fee:dead/64, then VPN clients will need a separate network, such 2a01:baba:fafa:0f0f::/64as routed through the address 2a01:baba::c0fee:dead/64.

Unfortunately, very few hosting providers have the tools to issue such networks to clients, which is why you have to use crutches like ND Proxy .

Conclusion

Reading IETF recommendations is not the most interesting activity, but it is extremely useful. Filling them with long winter evenings is clearly not worth it, but also neglecting to read sections that are important to you is also undesirable.

When choosing a provider, make sure that he shares this point of view.

You need to understand that the wrong approach to the allocation of addresses does not harm the provider in any way, and under most contracts it cannot even be the basis for receiving compensation for damage.
However, this may turn out to be a key factor for you, although you yourself do not suspect it yet.