Solution Background

As various operators increasingly tighten public IPv4 addresses (Chengdu Telecom requires a package of 399 yuan or more plus a 100 yuan monthly service fee to have a public IPv4 address, and for old users who already have public IPv4 addresses, now even if they upgrade their packages, there is a high probability that their public IPv4 addresses will be gone, I have been sticking to my old package, and I don't know how long I can hold on), the popularization of IPv6 is only a matter of time (of course, in fact, many operators' IPv6 support on the backbone network is fine now, but it's hard to say at the local end, many on-site installation staff don't even know what IPv6 is, and my IPv6 address was only obtained after complaining and tossing around for a long time).

Due to the incompatibility between IPv4 and IPv6, direct communication is impossible. Therefore, before IPv6 dominates the world, IPv4 and IPv6 will coexist for a long time. To solve the mutual access problem between IPv4 and IPv6 during this coexistence period, many transition solutions have emerged:
Dual-Stack

Simultaneously providing public IPv4 and public IPv6 addresses, with DNS resolution resolving both A and AAAA records. This way, whether the visiting user has an IPv4 or IPv6 address, it works seamlessly. For general small and medium-sized enterprises, as long as they publish through a CDN, they can easily achieve dual-stack functionality (the CDN does all the necessary work for you, though you have to pay for it); whereas for some large enterprises with self-built data centers (such as local banks), they need to apply for a fixed public IPv6 address from broadband operators themselves and then configure it on their egress devices.
6to4

Used for IPv6 devices to communicate with remote IPv6 devices over an IPv4 network. Simply put, it builds a tunnel on the IPv4 network to carry IPv6 communication. The nodes at both ends of the tunnel must support both IPv6 and IPv4 addresses and be correctly configured for 6to4.
DNS64+NAT64 (Dynamic)

This solution requires support from DNS64 servers and NAT64 devices. Simply put, IPv6-only users send DNS queries to a DNS64 server. The DNS64 server first checks if the domain has a AAAA record. If not, it queries the corresponding A record to get the public IPv4 address, and then combines a specific 96-bit prefix (64:ff9b::/96 is used internally) with the 32-bit public IPv4 address to form a complete 128-bit IPv6 address, returning it as the resolution result to the IPv6-only user.

When the user's request to access the target address reaches the NAT64 device (which must support both IPv6 and IPv4), the NAT64 device extracts the real IPv4 address from the target address, converts the request into a normal IPv4 request (while performing NAT translation based on the configured IPv4 address pool), sends it to the IPv4 server, and records it in the session table. Upon receiving the 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 also a few free IPv6 addresses on the public network that provide DNS64 functionality (along with supporting NAT64). Although free, they are generally experimental in nature, and their speeds are unpredictable. You can look for them at the following links:https://nat64.xyz/, as follows:

Among the three solutions mentioned above, the second and third are carrier-grade (or large intranet-grade) solutions. The first one can indeed be used for home broadband, but if you actually have a public IPv4 address, you can just set up a dynamic DNS directly—why bother with IPv6? Chosen ones like me with IPv4+IPv6 dual-stack are, after all, a minority~.

Therefore, the truly valuable solution is aimed at the inbound requirements of IPv6-only home broadband users (outbound requirements can be met using either private IPv4 or public IPv6 addresses, depending on whether the DNS resolution of the target contains an AAAA record and the priority settings for IPv4 and IPv6 in the client operating system). This article is written with this as the major premise.

Note: The biggest problem with public IPv6 IPs is actually that they require the accessing client to also have an IPv6 address, which is quite challenging. Generally, enterprise business fiber, hotels, other business venues, or some other home broadbands may not have IPv6 enabled, so essentially, solving this problem still requires going through a CDN. If Cloudflare is used as the CDN, the free plan already has relatively strong security protection, and combined with a solution like Tunnel, the origin-pull traffic does not go through the public network either. It actually doesn't care whether you have a public IPv6 address or a private IPv4 address, it just works for everything, so there is no such need. However, if a domestic CDN is used (which requires ICP filing), it needs to go through the public network. This is actually what requires a security solution, which is why the title of the article is "Discussion on Inbound Access Solutions for Home Broadband Public IPv6 Addresses".

Choice of Egress Solution: Router-Centralized vs. Router-Marginalized

In traditional home broadband solutions with public IPv4 addresses, the broadband router performs NAT for outbound requests externally, and internally uses port mapping for the admission and delivery of inbound requests. This method is actually the one we are most accustomed to and the easiest for formulating security policies. However, in the IPv6 era, the broadband router essentially becomes a bridge for public IPv6 address distribution: it obtains the allocated 60-bit prefix from the upstream device, 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 IPv6 addresses to the internal network in a stateful or stateless manner. This is fundamentally different from traditional public IPv4 addresses terminating at the router's WAN port, which leads to two different implementation methods, each with its own advantages and disadvantages.

Method 1: Router-Centralized, Terminating Inbound IPv6 Traffic

This method still terminates the public IPv6 address used for publishing applications externally at the router's WAN port, which means using the public IPv6 address of the broadband router's WAN port. For example, the IPv6 of my iKuai is enabled on the adsl3 port, so there is an IPv6 address on the adsl3 port, as follows:

Therefore, if iKuai supported port forwarding from the IPv6 address of the adsl3 interface to the internal IPv4 address, it would perfectly replicate the same effect as IPv4 port mapping. However, the key issue now is that iKuai does not support port forwarding from IPv6 addresses to internal IPv4 addresses.

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

There are many online tutorials for OpenWrt installation, basic settings, and IPv6-related configurations, so I won't go into detail here. Moreover, OpenWrt is not the main character, but just the carrier of the main character; the real main character is Lucky. By deploying Lucky on OpenWrt, you can directly achieve dynamic domain name resolution based on the public IPv6 address of the OpenWrt WAN port (OpenWrt's built-in DDNS does not support common domestic domain name providers, so you still need to use the dynamic domain name resolution that comes with Lucky); achieve reverse proxying of web applications from the WAN port's public IPv6 address to multiple internal private IPv4 addresses, TCP and UDP port forwarding to internal private IPv4 addresses, etc. Therefore, at present, the combination of OpenWrt + Lucky seems to be the best choice for router-centric setups (socat should also work, but I haven't used it, so I don't have much say).

Note: Other routing systems that can achieve similar functions are actually fine, but I haven't researched them, so I don't know. Actually, I most look forward to iKuai implementing this feature.

However, the disadvantages and advantages of this method are both very obvious:
Disadvantages
Relying on OpenWrt as the main router is highly restrictive (for example, my main router is iKuai, which is used for multi-dialing and traffic splitting, and it is impossible to replace the main router with OpenWrt). Therefore, 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 overall population).
Advantages:
There is no need to worry about publishing the IPv6 addresses of internal network devices (you can even choose not to enable IPv6 and still only use private IPv4 addresses), making things much easier from an O&M perspective.

I look forward to mainstream commercial routers implementing similar features in the future, at which point there will be more options (unless you have other special requirements).

Method 2: Router-Marginalized, Terminating Inbound IPv6 Traffic with Dedicated Devices

This approach essentially lets the router focus solely on passing and distributing IPv6 addresses, leaving the tasks of publishing IPv6 addresses externally and terminating IPv6 traffic to a dedicated device. This dedicated device is quite flexible: it can be a virtual machine, an LXC (Linux container), or even a Docker container.

Taking my current dedicated device as an example, it is an LXC deployed with Nginx as a reverse proxy and Lucky for port forwarding, as shown in the red box in the figure below:

If your needs are relatively simple and it is only for yourself, family, and friends, you can directly use Lucky's port forwarding function to forward access requests targeting specific ports of the public IPv6 address to the ports of the intranet private IPv4 address (just like configuring broadband router port mapping in the past); if you need to use a reverse proxy but the requirements are not very high, you can directly use Lucky's built-in reverse proxy function (for Lucky's configuration, please refer to my other article:Docker Series: Using Docker to Build a Simplified Public IPv6 Inbound Access Gateway Based on Lucky)。

At this point, Lucky is actually treated as the core of the dedicated device. If the traffic is heavy, it is recommended to deploy it in a non-Docker way; if the traffic is light, the Docker method is also fine, but try to use the host network mode.

Note: This dedicated device also needs security considerations and hardening, as it exposes a public IPv6 address to the outside: do not use default ports for externally exposed ports (use high-numbered ports as much as possible), reasonably configure firewall port protection rules (configure access blacklists/whitelists if possible), reasonably configure default sites for the reverse proxy (using fake SSL certificates), and filter sensitive information in response content, etc.

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

It does not depend on the router brand and features, as long as normal IPv6 functions are supported, making it suitable for the vast majority of users.
Disadvantages

It requires a certain level of hands-on ability and an environment to build a suitable dedicated device and complete the relevant configurations.

Optional Security Policies (Although optional, highly recommended)

IPv6 Firewall

If the router supports the IPv6 firewall function (currently, both iKuai and ASUS AC86U that I use support IPv6 firewalls), it is recommended to enable it. You can choose different security policies based on the different egress schemes mentioned earlier in this article:
Router Centralization

In this approach, only the IPv6 address of the router's WAN port is exposed to the outside, so you can allow access only to specific ports of the WAN port's IPv6 address on the IPv6 firewall, while blocking all other access requests to the intranet public IPv6 addresses.
Router Marginalization

In this approach, only the IPv6 address of the dedicated device is exposed to the outside, so you can allow access only to specific ports of the dedicated device's IPv6 address on the IPv6 firewall, while blocking all other access requests to the intranet public IPv6 addresses.

Reverse proxy

If there are many HTTP-type applications that need to be published (such as a home data center acting as a CDN origin server), it is strongly recommended to use a reverse proxy instead of directly using port forwarding. There are many benefits to using a reverse proxy:
Only one port can be exposed to the outside

If port forwarding is used to access internal applications, each application needs to expose a port, and all access requests (regardless of whether they are legitimate or not) are directly forwarded to the internal application port, which is very insecure. By using a reverse proxy, only one port can be exposed, and then choices can be made based on whether the accessed domain name is valid: legitimate access is processed further, while illegitimate access directly returns 404 or 444. Therefore, the reasonable way is to use reverse proxy for publishing HTTP-type applications, and use port forwarding for publishing applications like TCP and UDP.
Access can be easily upgraded to HTTPS

By setting up an SSL certificate, HTTP can be easily upgraded to HTTPS.
More flexible deployment methods for applications

By setting the proxy_set_header parameter, HTTP header parameters passed to internal applications can be flexibly customized, making the deployment method of applications more flexible.

SSL Encryption

In the future, network regulation will only become more and more intense (see my other article:Home Data Center Series: Precautions for Building a Website with Home Broadband Having a Public IP), for self-protection, I think SSL encryption is already a must-have option (it would be perfect if domain name filing is also added).

Generally, SSL encrypted traffic is terminated at the reverse proxy. As for the choice of reverse proxy, there are many: the commonly used NGINX and NPM can easily perform SSL decryption (for details, see:Linux Panel Series: Configuring Reverse Proxy and Publishing Using Non-443 Ports、Docker Series: Building Your Own Reverse Proxy Based on NPM Using Docker), and even using Lucky to build a reverse proxy is the same (see the link above).

WAF Firewall

Although a reverse proxy can directly point to the internal network application port (for example, when only you, your family, or friends access the home application), pointing directly to the application is too dangerous when it needs to be published externally (such as acting as a CDN origin server). At this time, you can consider deploying a free WAF for security protection (Chaitin SafeLine is good; although the community free version only supports the reverse proxy deployment method, it fits perfectly with the upstream reverse proxy).

For a real case using this solution, please refer to:Home Data Center Series: Home Data Center v4/v6 Dual-Stack Network Architecture and Application Access Flow Optimization。

Afterword

The promotion of public IPv6 addresses still faces many problems, such as the poor support from home broadband central offices, and the lack of IPv6 support at the exits of public places like office buildings and hotels, as mentioned earlier in this article. These will affect the practicality of public IPv6 addresses (after all, most people will not file for record, and then happen to use CDN to solve the accessibility of IPv4-only clients).

Currently, the best support for IPv6 comes from the cellular networks of various operators. Therefore, if you only have a public IPv6 address at home and cannot use CDN to provide IPv4 access capabilities, using a mobile cellular network as a hotspot to allow other devices to access is also an option.

In fact, the greatest use of public IPv6 addresses is still for building websites (acting as a CDN origin server). Otherwise, if it is only for personal access, the most suitable way is to access via a fixed private IP provided by a virtual networking solution (such as Tailscale).