What do we need to do to make IPv6 a reality?

After the General Office of the CPC Central Committee and the General Office of the State Council issued the Action Plan for Promoting Large-Scale Deployment of Internet Protocol Version 6 (IPv6), the entire IPv6 industry chain began to become active. Although we are still a little far from the dream of having an address for every grain of sand in the world, the general trend of accelerated advancement should be an indisputable fact. However, while we look up at the stars, we also need to keep our feet on the ground. So what is the reality of IPv6 and what do we need to prepare for? This is what this article wants to express.

IPv6, a technology that was once used to solve the problem of address shortage, has existed for a long time, but for various reasons it has not been popularized worldwide, especially in China. Today's article is not an IPv6 popular science article, nor does it involve too much about how to transform the network and how to adapt the services. It is more about looking at the current situation from the perspective of users. In addition, from my personal perspective, mobile network IPv6 will be ahead of fixed network IPv6. Mobile network should be a dual-stack strategy, so the analysis of this article is based on mobile network as a premise, and fixed network is not involved for the time being.

Does the phone support dual stack?

IPv6 has not been popularized in the public network for quite a long time. One of the important reasons is the lack of motivation from all parties. Although the public has been promoting that IPv4 addresses are insufficient, the Internet has been able to survive for so many years with patchwork. If we put aside the lack of motivation, the popularization of IPv6 is actually a systematic project, which requires the coordinated support of the end, the pipe, and the cloud. So let's first look at the support of the lower end, that is, the mobile phone.

First, Apple iPhone. Apple has been pushing APPs to support IPv6 only for v6 for several years. If you do not pass this function review, you cannot put it on the App Store. But at that time, the most frustrating thing for APP developers was that it was difficult to find a commercial IPv6 Only environment for testing in China. Most of them used Mac hotspots or WiFi APPs to simulate the logic testing of the network library, and there was no way to test it under the mobile network. And such a problem is also faced during the current IPv6 transformation period, that is, Apple iPhones can only obtain v4 addresses under mobile networks in China, not v6 addresses. Why? Because the APN settings in the iPhone cannot be modified, and the field carried by the address request in the built-in APN is only the IPv4 type. In this way, even if the network supports dual stacks, the iPhone can only obtain a v4 address. The following figure is a signaling request of an Apple phone in a mobile network:

​​

The yellow area above shows that the PDN type is IPv4. If dual stack is used, the type here is IPv4IPv6. Under the joint promotion of national institutions and operators, Apple phones have enabled default dual stack support since iOS12.1.

Now let's talk about Android. Android is relatively open. Most mobile phones can support APN protocol editing, and some mobile phones have been set to support IPv4IPv6 dual stack protocols by default, as shown in the following screenshot:

​​

But there are still a few pitfalls to be aware of:

1. Not all Android phones can edit the APN protocol type.
2. Even though the APN protocol type can be edited, not all mobile phones will use IPv4/IPv6 as the default protocol.
3. Although some mobile phones support dual stack, the obtained IPv6 address cannot be seen from the system API. But if you turn on WiFi at the same time, a miracle happens and the v6 address appears again.

Fragmented Android brings about fragmented dual-stack support, which poses a great challenge for the client to judge the current network environment.

Do mobile operators support dual stacks now? What is the secret behind the address obtained by the mobile phone?

After talking about the end, the next step is to look at the pipe, that is, what is the current status of operators' support for v6 and what is their strategy? As mentioned at the beginning, leaving aside the fixed network, in the mobile network scenario, the three major operators have already opened dual-stack support for IPv4 and IPv6. However, it should be noted that the dual-stack support pipeline here specifically refers to the air interface to the mobile core network in the figure below. As for the dual-stack support of the backbone network and Alibaba network, it depends on the interconnection situation of each operator.

​​

Let's take a look at the address information obtained by the terminal under a certain operator's network:

​​

Generally, users will get IPv4v6 dual-stack addresses. DNS for v6 addresses is not necessary and may not be available in some provinces. However, in the case of dual-stack, as long as DNS can support resolution queries for AAAA records, it will be sufficient.

Now we are going to enter the important IPv6 address acquisition link, that is, how does the client obtain the v6 address starting with 2409 above? Is there any mystery about this address? There are two aspects of mobile phone and network communication in the mobile network. One is the control plane, which is commonly known as the signaling plane. The APP cannot perceive this level. The other is the user plane, that is, the normal business data flow of the APP goes here. In the IPv4 only scenario, the mobile phone address can be obtained simply through the signaling interaction of the control plane, but in the IPv4 IPv6 dual stack scenario, the process has changed. Let's look at the signaling plane first:

​​

Create Session Request is sent by the mobile phone to the core network, which carries several important information:

​​

The PDN Type field needs to be IPv4/IPv6, and PDN Address and Prefix(IPv6) is all zero.

Create Session Response is the core network's response to the mobile phone.

​​

It contains information like PDN AddressPrefix and DNS Server, but you may be surprised to find that this prefix is ​​not a real prefix, and it is also very different from the address format obtained by the mobile phone.

At this time, you need to look at the user-side message again:

​​

According to the IPv6 address allocation rules, the address starting with FE80 is a link unicast address, and FF02::1 is all hosts with IPv6 multicast enabled. Let's take a look at the Router Advertisement message:

​​

This message contains the important Prefix field, which is based on the implementation of IPv6 stateless Autonomous Address-Configuration (SLACC). From the subsequent data flow, we can see that after receiving this 64-bit prefix, the mobile phone adds the last 64 bits to form a complete 128-bit IPv6 address as the source address for normal business access. However, there is a little doubt about how the last 64 bits of the address are generated. From multiple tests, the last 64 bits are changed each time. Since root is required to construct packages on the mobile phone, the subsequent conditions will be met. Tests will be conducted by constructing different last 64 bits of data packets to see if the network only relies on the first 64 bits to identify users.

Then we face the last question, that is, is there any mystery in this address? On the one hand, the 128-bit address is difficult to remember, and on the other hand, it also makes address scanning extremely difficult. If these addresses are completely random, it will be a huge disaster for those back-end businesses that rely on address information. However, the operator has helped us solve this problem to a certain extent, but their starting point is for better supervision, that is, the sentence at the beginning of the article that every grain of sand in the world has an address should be followed by every grain of sand in the world that can be tracked.

According to the "YD/T 2682-2014 Technical Requirements for IPv6 Access Address Coding" issued by the Ministry of Industry and Information Technology in 2014, the guiding opinions on the structure of user equipment access addresses are:

​​

in:

• PB is the IPv6 access address block prefix, a bit string with a length of n.
• AI is an addressing identifier, a bit string of length s+t, including a province identifier of length s and an access type identifier of length t. The access types include fixed network dynamic access, fixed network static access, and mobile cellular access.
• CC is the district/county code, which is 8 digits long. The specific 8-digit codes of districts and counties across the country are specified in the appendix of the document of the Ministry of Industry and Information Technology.
• SSI is the subnet identifier, which is 56-nst in length.
• IID is the interface identifier, which is 64 bits long.

The three major domestic operators have made further refinements based on this technical requirement. The details will not be described here, but from the big address segment, China Mobile uses the 2409:8000::/20 IPv6 address, China Unicom uses the 2408:8000::/20 IPv6 address, and China Telecom has five address blocks: 240E::/24, 240E::/20, 2001:0C68 ::/32, 2001:07FA:0010::/48, and 2402:8800::/32.

However, it should be noted that dual stack is currently only enabled under 4G, which means that returning to 2G will become IPv4 only, which adds variables to the client's judgment of the current network environment; and because the current address has certain location attributes, it is not yet clear how to deal with address allocation in cross-district and county mobile scenarios.

Happy EyeBall Question

In the scenario where the mobile phone, network and server all support dual stacks, the first thing the mobile phone has to face is a selection problem, that is, a domain name will be resolved to A and AAAA records, which is simply two addresses. Two addresses are returned at the same time. How to choose? How to choose between a fast and a slow one? How to choose when one has a problem? Only when the address is selected can there be subsequent connection establishment and business can take place, so this selection strategy is very important. From the perspective of experience, whoever connects faster is the simplest logic, but in the current environment where the v4 network is better than v6, such logic will only make the popularization of v6 more difficult. Therefore, in response to this problem, IETF first named it Happy Eyeball, and then released two RFCs to describe the recommended processing logic. The latest one is RFC8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency. Those who are interested can read it. Here is only the most important paragraph:

The algorithm proceeds as follows: if a positive AAAA response (a response with at least one valid AAAA record) is received first, the first IPv6connection attempt is immediately started. "Resolution Delay". The recommended value for theResolution Delay is 50 milliseconds. If a positive AAAA response is received within the Resolution Delay period, the client immediately starts the IPv6connection attempt.

In simple terms, the RFC recommends that IPv6 be preferred and that a 50 millisecond tolerance period be allowed for the return of AAAA records.

Due to system limitations, the implementation of this selection logic is independent of the client network library. Based on network materials, the specific implementation of each system is as follows:

Apple iOS: In the case of v4 and v6 dual protocol stacks, starting from ios9, Apple will send DNS requests for A and AAAA records. If the AAAA record of DNS is received first, Apple will immediately send a v6 syn. If the A record is received first, there will be a 25ms timer. If it times out, it will send a v4 syn. If AAAA is received within this timer, it will send a v6 syn. This mechanism is basically the same as Happy Eyeball, but the waiting time is different. It is unknown whether Apple will modify it to the RFC recommended value.

Android: v6 is preferred, but the waiting time is unknown.

Theoretically, such a mechanism will result in a decline in business experience due to the waiting time.

Will there still be NAT, will there be PAT, will there still be firewalls?

In the scenario where the mobile network only has IPv4, an indispensable intermediate device in the entire link for mobile phone users to access the server is the operator's firewall. On the one hand, in order to cope with the problem of scarce v4 addresses, the device will translate the addresses of public and private networks, and in order to further reuse addresses, it will also do port translation. On the other hand, for security reasons, the device will make some security policies similar to ACL, usually only allowing outbound access. At the same time, in order to reduce the load on the device, some timeout settings will be made to disconnect those connections that have been idle for a long time. Such restrictions will have a certain impact on some applications on the server that are overly dependent on addresses, applications that are not friendly to port translation, and applications that need to be kept alive for a long time. So what about the IPv4v6 dual stack scenario? I did the following test: On a server with a public IPv6 address, I simply wrote a server with port 80 opened in python:

Server start at:2400:3200:1000:xx:::80

wait for connection...

Execute the busybox telnet 2400:3200:1000:xx::80 command on the phone

This is the log from the server.

Connected by('2409:8928:84e:995:xxxx:xxxx:xxxx:xxxx', 34102, 0, 0)

Among them, Connected by ('2409:8928:84e:995:xxxx:xxxx:xxxx:xxxx is the mobile phone address seen by the server, and 34102 is the corresponding port number. So is this address and port number the mobile phone's own? Check it on the mobile phone:

odin:/$ busyboxnetstat

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 10.84.66.147:43623 111.13.134.131:443 CLOSE_WAIT

tcp 0 0 10.84.66.147:46051 140.205.34.21:443 ESTABLISHED

tcp 0 0 ::ffff:10.84.66.147:49856 ::ffff:112.13.64.13:5333 ESTABLISHED

tcp 0 0 ::ffff:10.84.66.147:37201 ::ffff:39.106.239.196:443 ESTABLISHED

tcp 0 0 ::ffff:10.84.66.147:55440 ::ffff:118.194.55.183:5223 ESTABLISHED

tcp 0 0 2409:8928:84e:995:3b4a:38ce:8ead:1972:34102 2400:3200:1000:xxxx:::80ESTABLISHED

From the above output, we can see that the operator's intermediate equipment does not perform NAT or PAT. The server sees the original source address and source port sent by the mobile phone. Of course, there is still a firewall, and the mobile phone cannot be accessed from the server.

MTU Issues

From the perspective of the protocol header, there is an important difference between v4 and v6, that is, the Don't Fragment bit is always on, that is, because it is always on, there is no explicit field in the IPv6 header. If there is a fragment, a Fragemention Header will be added. Since the routers supporting v6 in the middle of the network will not fragment the IPv6 packets, if a packet is too large, the router will generate an ICMP6 Type2 data packet containing Packet Too Big (PTB) and MTU information and return it to the sender. This mechanism seems to be better, but since the intermediate equipment may filter out the PTB data packet, the sender will not receive such a notification, affecting normal transmission. Therefore, the sender is better not to send too large data packets at the beginning. The current recommended reference value MTU is 1280 bytes.

​​

Unfinished Conclusion

IPv6 has just begun, and this article is just a rough preliminary analysis to stimulate discussion. As time goes by, some of the examples in this article may change with network evolution or policy changes, so please forgive me if there are any mistakes. I hope that more practices and thoughts can be accumulated in the future to improve the service experience under IPv6.

[This article is an original article by 51CTO columnist "Alibaba Official Technology". Please contact the original author for reprinting.]

Click here to read more articles by this author