One of the main issues ISPs face when transitioning to IPv6-only is the replacement of, or firmware upgrades to, customer-premise equipment (CPE/CE). This is because some customers still have apps and devices on their local networks that require IPv4.
To accommodate this, ISPs need to use either ‘old-fashioned’ transition mechanisms using carrier-grade NAT (which breaks many things) or recent transition mechanisms supporting IPv4 ‘as-a-service’ on the IPv6-only network, which is popular among cellular networks.
The major issue is the lack of support provided by CE vendors for both older (DS-Lite, lw4o6), and newer (464XLAT, MAP T/E) transition mechanisms. Some vendors provide it ‘on-demand’ for big customers, but small and medium ISPs don’t have the same purchasing capability, creating a big issue for deployment.
I organized a panel session at APNIC 44, Taichung, to discuss these issues, which are related to two Internet Drafts I’ve authored (RFC7084-bis and RFC084-bis-transition). It included representatives from three well-known CE vendors, and aimed to understand the reasons behind the lack of support and find ways to improve the current situation.
I’d like to thank the panel participants, Hans Liu (Director of Strategic Technology, D-Link), Masanobu Kawashima (Assistant Manager, Product Planning, NEC Platforms) and Wen-Hsien Peng (Senior Programmer, Zyxel) for participating.
Vendors have been supporting IPv6 for over a decade
D-Link started supporting IPv6 work around 2002, initially to support the IPv6 Ready Logo in 2003. It began shipping products to the market in 2008, four years before IPv6 was enabled by default.
Early support was compliant with RFC6204 (Basic Requirements for IPv6 Customer Edge Routers), followed by RFC7084 (update of the previous one, which means including dual-stack, DS-Lite and 6RD) and later RFC7368 (IPv6 Home Networking Architecture Principles) for homenet. According to D-Link, the main issue with supporting transition mechanisms is that there are too many transition protocols to be supported, which makes the adoption decision more complex for ISPs.
NEC started supporting IPv6 in 2003. They’re providing support for RFC7084 as well as MAP-E and 464XLAT to ISPs.
Masanobu said that supporting all transition protocols on the same CE is hard, as it requires human resources for the additional software, testing and customer support. However, the ISPs need them and they require different technologies for the provisioning and configuration methods.
Vendors should provide easy or zero-configuration. Unfortunately, even if they support RFC8026 (Unified IPv4-in-IPv6 Softwire Customer Premises Equipment), some ISPs can’t/won’t use DHCPv6 options. This is something that the IETF may need to standardize — to make a simpler IPv6 CE configuration mechanism.
As the newest of the three vendors, Zyxel received their IPv6 Ready Logo in 2014. They are supporting dual-stack, 6RD, 6to4, and 6in4; therefore, partial support for RFC7084.
Vendor insights
Below is a summary of panellists’ views on each of the topics discussed during the session.
1. Developing products for customers
This question aimed to understand the vendors’ customers (retail, OEM, and service providers); if products differ (hardware/firmware) for different customers (markets, regions or countries); if a product evolution for a given customer gets integrated for others; what are the product’s base operating systems; and if they will implement the newer transition mechanism (if they don’t already support it) if there was an update or ‘companion’ document for RFC7084.
Overall, there is no difference between vendors’ products (both hardware and firmware) in different markets or regions and among retail and service providers or OEMs. Sometimes there are implementations specific to a given customer (tender projects), but these sometimes become part of the standard firmware release. Typically, the ‘code base’ is Linux.
The panellist clearly indicated their strong support for the need to update RFC7084 to RFC7084-bis to include new transition mechanisms that already have already been incorporated by several vendors for specific projects or customers. It has been five years since RFC7084 was implemented, therefore it’s time to update it and consider what we want and need for consumer routers.
2. New transition mechanisms are being supported
This question was trying to understand when lw4o6, MAP-E, MAP-T, and 464XLAT will become available in panellists organization’s products, as well as if there are new hardware (CPU, flash, RAM), and additional cost (development, testing, others) requirements, and if there is a minimum order for implementing them.
All panellists said their service providers’ products supported lw4o6, MAP-E/T, and 464XLAT, but because of the lack of support for these mechanisms in RFC7084, it is not standard in retail CE.
There are no new hardware requirements that will exclude vendors supporting all these transitions mechanisms — it is really a matter of very few kilobytes.
The panel agreed that minimum orders were not considered when implementing these mechanisms. For them, the fact is that IPv6 needs to be implemented, and there is a need to support new transition mechanisms and support service providers and retail users. Also, there is a need for products to pass some certification requirements (again the idea of RFC7084-bis is strongly supported by the panellists).
3. CE can be upgraded without the need for hardware support
I’m sure many of you have wondered why existing CE can’t be upgraded to support something new such as IPv6? Are there hardware or licensing reasons or is it a marketing or commercial decision?
The panel agreed that existing CE can be upgraded without the need for hardware support. The problem is about user experience. A firmware upgrade is dangerous (power outage in the middle of the flash process), so you only want to ask the users to do this if you’re 200% sure that it isn’t going to ‘brick’ the product.
A priority for vendors is to reduce calls to the support centre — a call may cost around USD 2, which could amount to the profit margin they’ve accounted for in their product.
In my opinion, there is a simple way to avoid this problem with firmware upgrades, but it may require more flash memory in CE (actually doubling it if the equipment has less than 8 or 16 MB). It consists of having two copies of the firmware. The boot code checks consistency before booting from the primary one. If it fails, it boots from the secondary copy — you never flash both copies at the same time, only one at a time. Note, you can keep two different versions in case of issues. A boot error flag, or a configuration in the GUI, will allow rebooting from the valid version.
This process is already being used in motherboards and many other systems as flash memory is becoming cheaper and it is easy to find products in the market that already have, by default, 32 or even 64 MB.
4. Homenet protocols are being considered for CE
Some CE on the market support IPv6, but they don’t support DHCPv6-PD correctly, or they don’t know how to use multiple /64s inside the customer LANs — they only allow a single /64 inside the customer network, so even they don’t offer support for a ‘guest’ SSID with IPv6.
There are products that do support DHCPv6-PD correctly and automatically support different levels of ‘cascaded’ routers running IPv6. However, they do not support dynamic routing protocols (again vendors want to reduce the risk of calls to the customer service centre to troubleshoot those issues). Overall there is no support for Home Networking Control Protocol (HNCP, RFC7788).
The panel believes that it is too early to implement homenet because there is still a lot to do in terms of deploying IPv6 first.
However, there is a big trend in implementing new WiFi technologies such as WiFi-mesh (self-organized WiFi), so this is a big opportunity to introduce homenet because we don’t want to have a bigger and bigger broadcast domain.
At the same time, the market for this kind of retail router is growing, and the price (and margin) for devices supporting IEEE 802.11ac, is going up from less than USD 70 to more than USD 200 for higher-end products. However, there is still an issue about device discovery, for example, printers, spanning across multiple routers within a homenet network.
5. IPv6-capable products have stateful firewalls enabled by default
Panellist confirmed that their IPv6-capable routers support RFC6092 (Recommended Simple Security Capabilities in IPv6 CE), with IPv6 firewall enabled by default.
Although this is pleasing, it worries me that many vendors have not sought to make improvements on these security measures to avoid the CE being part of a botnet DDoS.
6. Market demands for CE specs
There was a clear consensus among the three panellists: service providers are asking for support of new transitions mechanisms, while users are asking for faster WiFi.
7. Vendors have demands of the IETF too
Some of vendor’s demands of the IETF have already been mentioned above — device discovery, updates to RFC8026 to explicitly support 464XLAT, and alternatives to DHCPv6 options.
Personally, I think we are missing support for multiple access technologies (such as multiple ISPs or links) and the support of interfaces in CE to allow the direct attachment of IoT devices, instead of requiring external gateways.
Finally, there was a very interesting question from one attendee (Sunny Yeung, Senior Technology Specialist, Telstra), regarding what transition mechanisms should be used for hybrid CE that supports a wired link and a backup with LTE. After a short discussion, the panel agreed that the only logical mechanism was 464XLAT — I can confirm that I’ve tried this with OpenWRT/LEDE in a couple of customer trials.
Below is a recording of the session if you’d like to watch it for yourself:
If you have any feedback on this discussion or my Internet Drafts (RFC7084-bis-transition and RFC7084-bis) please leave your comments below.
Jordi Palet Martínez has been working with computers, networking and technology since he was eight years old. For the last 18 years, he has been CEO/CTO at “The IPv6 Company”, where he has devoted most of his time to IPv6 R&D, standardization, training and consultancy.
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.
Why is nobody considering libOSTree? It’s used by RedHat and gives you a linux upgrade process that’s atomic and consumes minimal flash for the extra copy.
I’m very surprised that the consensus is that any meshed network protocol will have fewer support issues then homenet. My experience has been the the mesh protocols are very weak for many usecases, although they’re great for battlefields. The primary issue is the challenge in identifying a network that’s decaying – typically due to moving furniture/walls/doors and fixing it.
I don’t think that was the point that mesh-WiFi will have fewer issues, but that it is a market opportunity to introduce both together in products.
Regarding libOSTree, I didn’t knew about that, anyway, my comment was just a suggestion
The mesh wifi market could well have one of the factors that seem to be common to consumer facing IoT offers: the manufacturers of Things’ profits are driven by moving product; the service providers, ISPs’ profit is seriously eroded by the costs of supporting features.
I suppose that in the context of internet access there is a degree of control with the ISPs.