Customer Premise Equipment (CPE), namely routers, are beginning to see support for IPv6. However, it is far from complete.
In the past, I have written about OpenWrt: open-source software for home routers. The IPv6 features of OpenWrt are the basis of my IPv6 wish list for home routers.
In this post, I’d like to focus on efforts to bring greater IPv6 support to Small Office / Home Office (SOHO) routers, which differ from standard home routers as they need to accommodate broader functionality. My hope is that router manufacturers will incorporate these features to improve IPv6 support.
What support is currently available?
SOHO networks tend to grow organically, starting with a single ISP-connected router and adding additional routers as ports fill up, and/or to accommodate new technologies such as IPv6-only, Wireguard IPv6-enabled VPN, and separation of networks (that is, DMZ/VLAN) for IoT devices.
Many organizations have taken up the task of defining what IPv6 features a SOHO router should entail. There’s a wealth of information that has guided implementations over the years, including:
- Multiple RFCs published by the Internet Engineering Task Force (IETF).
- RIPE 772, formerly RIPE 554bis.
- Open-source implementations, such as OpenWrt, whose developers have often tried new ideas on the platform, resulting in excellent IPv6 support.
Let’s focus on the first and most extensive of these, IETF RFCs.
The IETF standards
The IETF has done a good job defining the minimum feature support of CPEs. Below are some notable RFCs that have done this:
RFC 7084: Basic Requirements for IPv6 Customer Edge Routers
This self-explanatory RFC provides details on the following basic requirements for IPv6 customer edge routers:
- General requirements that cover basic node, ICMPv6, and default route handling.
- WAN-side requirements that cover actions of the WAN interface, including supporting an IPv6 Host Mode (acquiring an address via SLAAC or DHCPv6), using a DHCP Unique Identifier (DUID), which is constant between reboots/resets, and supporting DHCPv6-PD (prefix delegation) to request a prefix for use on the LAN-side of the CPE.
- Link-layer requirements, supporting Ethernet, and PPP encapsulations, including support for dual-stack with IPCP and IPv6CP running over one PPP logical channel.
- Address assignment requirements, supporting SLAAC, DHCPv6 options (Identity Association for Non-temporary Address (IA_NA)), Reconfigure Accept [RFC 3315], and DNS_SERVERS [RFC 3646]. The IPv6 CE router SHOULD be able to support the DNS Search List (DNSSL) option as specified in RFC 3646 and Network Time Protocol (NTP).
- For PD requirements, CPE may provide a ‘hint’ in its PD request but must accept a PD of a different size CPE router to prevent forwarding loops when destination addresses are in the PD address block.
- LAN-side requirements, including:
- How Unique Local Addresses (ULA) should be supported and user-configurable.
- Supporting Neighbor Discovery Protocol (NDP).
- Ensuring Router Advertisements (RA) have the prefix information options A and L flags set to 1 by default, as well as sending Recursive DNS Server (RDNSS) and DNS Search Lists (DNSSL).
- Providing a DHCPv6 server for LAN Clients, including DHCPv6-PD to downstream routers.
- Transition technology support, specifically for 6rd and DS-Lite.
- Security requirements for firewalls. The IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in RFC6092, Section 4, ingress filtering for Ethernet, and tunnelled data.
RFC 7368: IPv6 Home Networking Architecture Principles
This architecture document describes a home network with several subnets and potentially more than one router. In this evolving environment, the RFC recommends:
- Multiple subnets and routers.
- Global addressability and elimination of NAT.
- Multi-addressing of devices.
- ULAs.
- Avoiding manual configuration of IP addresses.
- IPv6-only operation.
RFC 7788: Home Networking Control Protocol
While HomeNet has few implementations, it is worthwhile to view the RFC for basic IPv6 functionality in the SOHO environment. Specifically, for ease of deployment and autonomous operation (including addressing and DNS operation). The RFC describes:
- Autonomous address configuration.
- Prefix assignment algorithm parameters.
- Use of DHCPv6 prefix delegation.
- Local IPv4 and ULA prefixes.
- Multicast DNS (mDNS) proxy.
- Use of HomeNet Control Protocol (HNCP) to distribute the following:
- DNS A/AAAA records.
- Delegated prefix.
- DHCPv6 and DHCPv4 data.
- External connection information.
RFC 7597 and RFC 7599: Transitional Technologies of IPv4 over IPv6 using MAP-T and MAP-E, respectively
Mapping of Address and Port (MAP) is a standards-based approach of MAP-ing by encapsulation (MAP-E) or by translation of the IPv4 address into an IPv6 address (MAP-T). Fortunately, the most current release of OpenWrt (21.02.1) supports MAP-T and MAP-E.
RFC 8585: Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service
This is another transitional technology RFC specifically targeted at CPEs, with the thinking that at some point, IPv4 will be provided as a service over IPv6-only networks. The RFC extends the requirements of RFC 7084 and covers transitional technologies specifically supporting IPv4 as a service and NAT64 Prefix Discovery:
- 464XLAT.
- Dual-Stack Lite (DS-Lite).
- Lightweight 4over6 (lw4o6 RFC 7596).
- MAP-E and MAP-T.
In addition to the above transition technologies, the RFC requires support for:
- IPv4 multicast support for applications such as IPTV.
- UPnP; an AddPortMapping() or AddAnyPortMapping() action MUST be rejected with error code 729.
RFC 9099: Operational Security Considerations for IPv6 Networks, Sect 3.8 General Device Hardening
With almost all devices being IPv6 enabled by default and with many endpoints having IPv6 connectivity to the Internet, it is critical to also harden those devices against attacks over IPv6.
The same techniques used to protect devices against attacks over IPv4 should be used for IPv6 and should include but are not limited to:
- Restricting device access to authorized individuals.
- Monitoring and auditing access to the device.
- Turning off any unused services on the end node.
- Understanding which IPv6 addresses are being used to source traffic and changing defaults if necessary.
- Using cryptographically protected protocols for device management (Secure Copy Protocol (SCP), SNMPv3, SSH, TLS, and so forth).
- Using host firewall capabilities to control traffic that gets processed by upper-layer protocols.
- Promptly applying firmware, OS, and application patches/upgrades to devices.
- Using multi-factor credentials to authenticate to devices.
- Using virus scanners to detect malicious programs.
Additional IPv6 features
Further to the excellent RFC’s, I’d like to see the following also supported.
- A simple-to-use routing protocol that will allow the SOHO network to grow organically, and provide connectivity between multiple routers as they are added. A plug-and-play routing protocol such as RIPng (RFC 2080) or Babel (RFC 8966) use technologies that don’t require users needing a detailed understanding of routing protocols (OSPF type 3,5,7 and 10 LSAs) but rather work silently in the background with reasonable convergence times.
- Downstream DHCPv6-PD support. Not only should the SOHO router make requests on the WAN port and advertise the delegated prefix to the LAN clients, but it should also answer DHCPv6-PD requests from the LAN side, further delegating prefix address space.
- Downstream SLAAC support. There are some OSes that do not implement DHCPv6, most notably Android devices, including Android-based IoT devices. All of these devices will be able to communicate via SLAAC and IPv6.
- DNS auto-naming support for both SLAAC and DHCPv6 nodes on the SOHO network. As IPv6 is more readily used, the age of memorizing IP addresses is coming to an end. The DNS will be how SOHO users access devices on the network. A DNS auto naming system will map local node IPv6 addresses to names. mDNS service discovery will be helpful, however, with multiple subnets, support for mDNS Proxy, such as Avahi relay, will be required. Another excellent example of mapping SLAAC IPv6 addresses to names is the ip6neigh project for OpenWrt.
- Sane default firewall rules. NDP requires ICMPv6 to enter the SOHO router from all interfaces (WAN and LAN). The default firewall rules should permit the passage of ICMPv6 messages and optionally rate-limit them. OpenWrt provides an excellent example of this.
- Wireless mesh support. The SOHO router should enable 802.11s, including Hybrid Wireless Mesh Protocol (HWMP), an IEEEE standard for wireless mesh. In addition to 802.11s the SOHO router may support additional implementations of Wireless Mesh.
- Wi-Fi calling. Although there are no specific router requirements to support Wi-Fi calling, the SOHO router should include default firewall rules to permit it.
Leverage open-source
Many vendors’ products are based on open-source, primarily Linux, which means there is a wealth of solutions that already exist in the open-source world. SOHO routers should be no different.
One example I talked about at the start is OpenWrt, which is an open-source project that supports hundreds of commercial routers and has excellent IPv6 support.
Encouragingly, commercial vendors such as GL-iNET and Cudy already include OpenWrt as the base of their product.
SOHO routers must act as a stand-alone gateway to the IPv6 Internet or in concert with other IPv6-enabled routers. They must be ready to support IPv6-only, including IPv6-only management of devices, and transition technologies, such as NAT64 or MAP.
Lastly, the SOHO router must be ready to grow as the SOHO network itself becomes a complex network, with the concept that the person deploying the SOHO network is not a networking expert. Features such as auto-addressing, and auto name service (DNS) are key to the ‘deploy and go’ mindset.
This wish list is still in development. Please feel free to email me feedback and suggestions at cvmiller [at] gmail [dot] com.
Craig Miller is a consultant and IPv6 advocate at Makiki.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Very nice compilation, tks for it!