Project Background

As operators tighten their control over IPv4 public addresses (Chengdu Telecom requires packages above 399 yuan plus a monthly service fee of 100 yuan to get an IPv4 public address, and for old users with public IPv4 addresses, even if they upgrade their packages, the IPv4 public address will most likely be gone. I have been sticking to the old package, and I don’t know how long I can hold on), the popularization of IPv6 is a matter of time (of course, in fact, many operators now have no problem supporting IPv6 on the backbone network, but it is hard to say on the local side. Many people who come to install the equipment don’t even know what IPv6 is. I only got my IPv6 address after a long time of trouble after complaining).

Because IPv4 and IPv6 are incompatible, they cannot communicate directly. Therefore, before IPv6 becomes the dominant technology, IPv4 and IPv6 will coexist for a long time. In order to solve the problem of mutual access between IPv4 and IPv6 during the coexistence period, many transition solutions have emerged:
1. Dual stack

It provides both IPv4 and IPv6 public network addresses, and DNS resolves both A and AAAA records, so that no matter whether the accessing user has an IPv4 address or an IPv6 address, it can be used. For general small and medium-sized enterprises, as long as they publish through CDN, they can easily achieve the dual-stack function (CDN will do the necessary work for you, of course, you have to pay for it); and for some large enterprises with self-built data centers (such as local banks), they need to apply for a fixed IPv6 public network address from a broadband operator and then configure it on the export device themselves.
2. 6to4

It is used for IPv6 devices to communicate with remote IPv6 devices through IPv4 networks. In simple terms, it is to build a tunnel on the IPv4 network to carry IPv6 communication. The nodes at both ends of the tunnel need to support both IPv6 and IPv4 addresses and perform correct 6to4 configuration.
3. DNS64+NAT64 (dynamic)

This solution requires the support of DNS64 servers and NAT64 devices. In simple terms, IPv6-only users send DNS queries to DNS64 servers, which will first query whether the domain name has an AAAA record. If not, they will query the corresponding A record and obtain the IPv4 public address, and then use a specific 96-bit prefix (the intranet uses 64:ff9b::/96) and a 32-bit IPv4 public address to form a 128-bit complete IPv6 address and return it to the IPv6-only user as the resolution result.

The user's request to access the target address reaches the NAT64 device (which needs to support both IPv6 and IPv4). The NAT64 device extracts the real IPv4 address from the target address and converts the request into a normal IPv4 request (while performing NAT conversion based on the set IPv4 address pool), sends it to the IPv4 server and records it in the session table. After receiving a response, it converts the response into an IPv6 packet based on the session table and returns it to the IPv6 only user.
Note 1: There are a few free IPv6 addresses on the public Internet that can provide DNS64 functions (and also provide supporting NAT64). Although they are free, they are generally experimental in nature and the speed is not guaranteed. You can find them at the following link:https://nat64.xyz/,as follows:

Note 2: There is also a static method for NAT64, but this method is mainly used to solve the problem of IPv4 clients accessing IPv6. It is inconsistent with our topic and will not be discussed here.

Of the above three solutions, the second and third are both carrier (or large intranet) level solutions. The first one can be used for home broadband, but if you really have an IPv4 public network address, you can just make a dynamic domain name. Why bother with IPv6? After all, I am a minority of people who are born with IPv4+IPv6 dual stacks.

Therefore, the truly valuable solution is to target the inbound needs of IPv6-only home broadband users (outbound needs can use either IPv4 private network or IPv6 public network addresses, depending on whether the DNS resolution result of the access target contains AAAA records and the settings of the access client operating system for IPv4 and IPv6 priorities). This article is written based on this premise.

---

In addition: The biggest problem with IPv6 public IP is that it requires the access client to have an IPv6 address, which is very challenging. Generally, the business fiber of enterprises, hotels, other business places, or some other home broadband may not have IPv6 enabled, so in essence, it is still necessary to go through CDN to solve this problem. If CDN uses cloudflare, the free plan already has relatively strong security protection, and with the tunnel solution, the return traffic does not go through the public network. In fact, it does not matter whether you have an IPv6 public network address or an IPv4 private address, it will be directly blocked, so there is no such demand; if you use a domestic CDN (which needs to be registered), you need to go through the public network, which actually requires a security solution, so the title of this article is "Discussion on the Inbound Access Solution for Home Broadband IPv6 Public Network Address".

---

Choice of egress solution: router centralization vs. router edgeization

In the traditional home broadband solution with IPv4 public network addresses, the broadband router performs NAT for outbound requests and performs port mapping for inbound requests. This method is actually the most accustomed and the best way to formulate security policies. However, in the IPv6 era, the broadband router has essentially become a link between the distribution of IPv6 public network addresses: it obtains the assigned 60-bit prefix from the upstream device, and then selects one (usually the first one) from the 16 (note: 64-60=4, 2^4=16) available 64-bit prefix network segments, and finally distributes the IPv6 address to the intranet in a stateful or stateless manner. This is fundamentally different from the traditional IPv4 public network address that ends at the router's WAN port, so two different implementation methods will be derived, and different methods have their own advantages and disadvantages.

Method 1: Router centralization, terminating inbound IPv6 traffic

This method still terminates the IPv6 public network address of the externally published application at the WAN port of the router, that is, the IPv6 public network address of the WAN port of the broadband router is used. For example, the IPv6 of IaiKuai is enabled on the adsl3 port, so there is an IPv6 address on the adsl3 port, as follows:

So if iKuai supports port forwarding from the IPv6 address of the adsl3 interface to the intranet IPv4 address, it will perfectly reproduce the same effect as IPv4 port mapping. But the key problem now is that iKuai does not support port forwarding from the IPv6 address to the intranet IPv4 address.

Therefore, if you want to use a router-centric approach, the main router needs to be replaced with openwrt.

There are many online tutorials on the installation, basic settings and IPv6-related configuration of openwrt, so I won’t go into details here. Moreover, openwrt is not the protagonist, but only the carrier of the protagonist. The real protagonist is lucky. By deploying lucky on openwrt, you can directly implement dynamic domain name resolution based on the IPv6 public network address of the openwrt wan port (the ddns that comes with openwrt does not support commonly used domestic domain name providers, so you still have to use the dynamic domain name resolution that lucky brings); realize the reverse proxy of the web application from the wan port IPv6 public network address to multiple IPv4 private addresses in the intranet, and forward TCP and UDP ports to the IPv4 private addresses in the intranet, etc. Therefore, it seems that the combination of openwrt+lucky is the best choice for router centralization (socat should also work, but I have not used it, so I have no say).

In addition: Other routing systems that can achieve similar functions are fine, but I haven't studied them, so I don't know. In fact, I am most looking forward to AiKuai being able to achieve this function~.

However, this approach has both advantages and disadvantages:
1. Disadvantages
Relying on openwrt as the main router has strong limitations (for example, my main router is iQIYI, which is used for multi-dial and traffic diversion, and it is impossible to replace the main router with openwrt), so it is only suitable for people who already use openwrt as their main router or are willing to use openwrt as their main router (this group of people accounts for a small proportion of the total population).
2. Advantages:
There is no need to worry about publishing the IPv6 addresses of intranet devices (you can even not enable IPv6 and still only use private IPv4 addresses), which makes operation and maintenance much easier.

I hope that mainstream commercial routers will also have similar functions in the future, so that there will be more choices (unless you have other special needs).

Method 2: Router edge, using dedicated equipment to terminate inbound IPv6 traffic

This approach essentially lets the router only handle the delivery and distribution of IPv6 addresses, leaving the work of publishing IPv6 addresses and terminating IPv6 traffic to dedicated devices. This dedicated device is relatively flexible: it can be a virtual machine, an LXC (linxu container), or even a docker.

Taking my current dedicated device as an example, it is an LXC, which deploys nginx as a reverse proxy and lucky to implement port forwarding, as shown in the red box in the figure below:

If your needs are relatively simple and only for yourself, your family, or your friends, you can directly use lucky's port forwarding function to forward access requests to a specific port on the public IPv6 address to a port on the private IPv4 address on the intranet (just like configuring the port mapping on a broadband router before); if you need to use a reverse proxy and the requirements are not very high, you can directly use lucky's built-in reverse proxy function to achieve it (for the relevant configuration of lucky, see my other article:Docker series uses Docker to build a simple public network IPv6 access gateway based on lucky).

At this time, lucky is actually regarded as the core of a dedicated device. If the traffic is large, it is recommended to deploy it in a non-docker way. If the traffic is not large, the docker way is also OK, but try to use the host way for the network type.

In addition: This dedicated device also needs to consider security issues and perform security reinforcement. After all, it is an exposed IPv6 public network address: do not use the default port for the port that needs to be exposed (try to use a large port), reasonably configure the firewall port protection rules (if possible, configure the access black and white list), reasonably configure the default site of the reverse proxy (use a fake SSL certificate) and filter the sensitive information of the response content, etc.

The advantages and disadvantages of this approach are as follows:
1. Advantages

It is not dependent on the router brand and function, as long as it supports normal IPv6 function, it is suitable for most users.
2. Disadvantages

You need to have certain hands-on skills and environment to build your own special equipment and complete the relevant configuration.

Optional security policy (although optional, it is strongly recommended)

IPv6 Firewall

If the router supports IPv6 firewall function (the iQuick and ASUS AC86U I use currently both support IPv6 firewall), it is recommended to enable it. You can choose different security policies according to the different export solutions mentioned earlier in this article:
1. Router centralization

In this way, only the IPv6 address of the router's WAN port is exposed to the outside world, so only access to the specific port of the WAN port's IPv6 address can be allowed on the IPv6 firewall, and all other access requests to the intranet's IPv6 public address are blocked.
2. Router Edge

This method only exposes the IPv6 address of the dedicated device to the outside world, so only access to the specific port of the IPv6 address of the dedicated device can be allowed on the IPv6 firewall, while all other access requests to the intranet IPv6 public address are blocked.

Reverse Proxy

If you need to publish a lot of http applications (such as a home data center as the source station of a CDN), it is strongly recommended to use a reverse proxy instead of directly using port forwarding. There are many benefits to using a reverse proxy:
1. Only one port can be exposed to the outside

If port forwarding is used to access internal applications, an application needs to expose a port, and all access requests (regardless of whether they are legal or not) are directly forwarded to the internal application port, which is very unsafe. With reverse proxy, only one port can be exposed, and then a selection can be made based on whether the access domain name is valid: legal access is processed later, while illegal access directly returns 404 or 444. Therefore, the reasonable way is to use reverse proxy for http type application releases, and use port forwarding for tcp, udp and other application releases.
2. You can easily upgrade access to https

By setting up an SSL certificate, you can easily upgrade http to https.
3. More flexible deployment of applications

By setting the proxy_set_header parameter, you can flexibly customize the http header parameters passed to internal applications, making the application deployment method more flexible.

SSL Encryption

In the days ahead, Internet regulation will only intensify (see my other article:Home Data Center Series Home Broadband Site Building Considerations with Public IP), for self-protection, I think SSL encryption is a must (it would be perfect if domain name registration is added).

In general, SSL encrypted traffic ends at a reverse proxy. There are many options for reverse proxies: the commonly used NGINX and NPM can easily perform SSL decryption (for details, see:Linux panel series configure reverse proxy and use non-443 port for publishing,Docker series uses Docker to build its own reverse proxy based on NPM), and even using lucky to build a reverse proxy is the same (see the link above).

WAF Firewall

Although the reverse proxy can directly point to the application port of the intranet (for example, only yourself or family and friends access the application at home), when it needs to be published externally (for example, as a CDN source station), it is too dangerous to point directly to the application. At this time, you can consider deploying a free WAF for security protection (Changting Lei Chi is good. Although the free community version only supports the deployment of reverse proxy, it is a perfect match with the upper-level reverse proxy).

A real example of using this solution can be found in:Home Data Center Series Home Data Center v4v6 dual-stack network architecture and application access process optimization.

Afterword

The promotion of IPv6 public network addresses is still facing many problems, such as the poor support of home broadband local end, the non-support of IPv6 at the exits of public places such as office buildings and hotels, etc., which will affect the practicality of IPv6 public network addresses (after all, most people will not register them, and happen to use CDN to solve the accessibility of IPv4-only clients).

Currently, the best support for IPv6 is provided by the cellular networks of various operators. So if your home only has an IPv6 public address and cannot provide IPv4 access capabilities through CDN, one option is to use the mobile cellular network as a hotspot and then access it with other devices.

In fact, the biggest use of IPv6 public network addresses is to build websites (as CDN source sites). Otherwise, if you only want to access it yourself, the most appropriate way is to access it through a fixed private IP provided by a virtual networking solution (such as Tailscale).