There are many misconceptions and myths around IPv6. Often, hosting providers misunderstand how to use it and think of 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 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 the article, we will analyze the main errors in the use of IPv6 providers.

Storyline: RFC 3177

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

  /48 in general 

/64 if there is one and only one subnet behind it     

 /128 if one and only one device

The offensive document RFC 2119, which governs the application of various levels of compulsory compliance, defines “recommended” as follows:

The words “Should” or “Recommended” mean that there may be reasonable reasons in certain circumstances not to do so, but the choice of a different line of behavior should be a balanced decision made with a full understanding of the consequences.

Perhaps no one had a complete 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 says 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 must be sufficient for consumer purposes and easily extensible. One of the important reasons for switching to IPv6 is the change in 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, this will save a lot of work

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

Although all these conditions were met, it became apparent that recommendation / 48 was

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 on just 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 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, many major Internet players perceive recommendation / 64 as a standard. On the one hand it’s good, on the other hand, not so.

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 such things as studying 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 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 its 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.

IPv6 from our server

If we have 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.

Let’s say that the address 2a01: baba :: c0fee: dead / 64 is assigned to the server, then VPN clients will need a separate network like 2a01: baba: fafa: 0f0f :: / 64, routed through the address 2a01: baba :: c0fee: dead / 64.

Unfortunately, very few hosting providers have tools to issue such networks to customers, which is why something like ND Proxy have to be used.

Conclusion

Reading the 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 it shares this point of view.

You must understand that the wrong approach to the allocation of addresses does not harm the provider, and for most contracts it cannot even be the basis for compensation for damage.

However, this may turn out to be a key factor for you, although you yourself do not suspect it yet.