IPv6 has no need for NAT, however, there is a need for a Globally Unique Addresses (GUAs). Therefore your SOHO (Small Office/Home Office) will require a block of GUAs to use. You can either obtain the Block of GUAs from your RIR (Regional Internet Registry, e.g. ARIN for North America and Hawaii), known as PI (Provider Independent).
Or you can use a block of GUAs from your ISP, known as PA (Provider Addresses).
I suspect for the foreseeable future, SOHO will obtain IPv6 addresses from their ISP (or PA Space). PA space is much easier for small organizations which do not have full time IT staff.
Although PI address space has its advantages, such as no address renumbering when changing ISPs, it requires a more sophisticated setup, usually including BGP (Border Gateway Protocol) peering with an ISP.
Prefix Delegation is a method where the ISP will “loan” you some PA Space to use inside your network. Prefix Delegation RFC 3633 standardized the allocation of a block addresses back in 2003. The standard has been updated by RFC 8415 in 2018.
In this article, we’ll pose the following questions, and hopefully provide some answers:
- What are the basics of Prefix Delegation?
- What if you have more than one router in your SOHO network?
- How is IPv6 Prefixes allocated within your network?
- Why use OpenWrt in your SOHO network?
- What if your ISP asks you to power cycle your main router? What happens to the other routers?
- Can deterministic PD address blocks be created with with OpenWrt?
- Can you create redundancy (or loops) in your network with PD?
Prefix Delegation Basics
Prefix Delegation is implemented as an option within the DHCPv6 spec in RFC 8415, as Option 25 (OPTION_IA_PD). Therefore, DHCPv6 must be used between the router and the upstream device (e.g. ISP router). Once the Delegated Prefix has been allocated by the ISP, the router will apply the Prefix to the internal LAN, hosts on this LAN segment will use the Delegated Prefix to create their own IPv6 GUA (Globally Unique Addresses) using SLAAC (Stateless Address Auto Config), or by making their own DHCPv6 request. Either way, the Hosts on the LAN will have a GUA and can get onto the IPv6 Internet.
Prefix Delegation in a more complex SOHO network
What if you have more than router in your SOHO netowrk? How is IPv6 PD allocated within your network?
Let’s take the following example network with four (4) routers and six (6) netowrks:
Fig 1: Example Network
Just like above, the WAN Router made a DHCPv6-PD Request to the ISP for a block of IPv6 addresses. The ISP will usually allocate a /56* which can be subdivided into 256 /64 networks. Should be plenty of room.
In the network above, the WAN router has multiple ports, which have been divided into three (3) Networks (Net A, Net B, Net C). These networks may have different purposes, and firewall access rules (such as Production, Printer/IoT, DMZ).
In turn each of the first tier routers (Router A, Router B, Router C) will make DHCPv6-PD request to the WAN Router, and each receive a smaller chunk of the original /56 allocated, to be used downstream (Net Aa, Net Bb, Net Cc).
As you can see Prefix Delegation continues to slice and dice the original /56 in smaller and smaller chunks supplying IPv6 GUA address space downstream.
Prefix Delegation implemented in OpenWrt
Why use OpenWrt in a SOHO environment?
- Supported on over 1000 home-class routers
- Inexpensive solution with excellent IPv6 support
- Includes a consistent web-based GUI for configuration
OpenWrt Prefix Delegation address allocation has its roots in HomeNet RFC 7368. Using the basic algorithm:
PD Address Space / Number of LAN Ports = block size per port.
Most home routers have 4 LAN ports, so that a /56 will be divided into /60s to be allocated to the first tier of routers (Router A, Router B, Router C). Each of the first tier routers will in-turn have 4 LAN ports, and allocate 4 x /64 out of each /60.
Fig 2: Example Network sliced and diced
Now let’s apply some addresses, assuming the ISP has delegated a /56 to our SOHO network.
Fig 3: Example Network sliced and diced with addresses
In Figure 3, the ISP Delegated Prefix is
2001:db8:aaaa:bb00::/56 which leaves the last two (2) nibbles (or hexidecimal characters) to be used inside the SOHO network. It is best practice to divide prefixes no smaller than nibble (4 bits). It will make things much easier for you going forward.
OpenWrt will create four (4) blocks of IPv6 addresses from the original /56 and allocate them to each network downstream. In our address example (Fig 3), the blocks would appear as:
2001:db8:aaaa:bb00::/60 2001:db8:aaaa:bb40::/60 2001:db8:aaaa:bb80::/60 2001:db8:aaaa:bbC0::/60
These blocks would in turn be sub-divided by each of the first tier routers (Routers A, Router B, Router C), so that Router A would create another 4 blocks:
2001:db8:aaaa:bb04::/64 2001:db8:aaaa:bb08::/64 2001:db8:aaaa:bb8C::/64 exhaused
And Router C PD blocks would be:
2001:db8:aaaa:bb84::/64 2001:db8:aaaa:b488::/64 2001:db8:aaaa:b88C::/64 exhaused
As you can see there is not enough address space in the /60 to create four (4) /64 address blocks since the Zeroth block (e.g. 2001:db8:aaaa:bb00::/64) has already been allocated.
As you can see Prefix Delegation within your SOHO using OpenWrt makes creating new networks a plug-and-play operation. However, it is not overly efficient with address space.
Prefix Delegation and Routing
What is not obvious, so far, is that not only does Prefix Delegation allocate address blocks down stream, but the router must also insert a route for each PD block allocated. With OpenWrt, this is done automagically for the user. Each tier 1 router will have a default router pointing upstream (toward the WAN Router) and a specific route for the PD block downstream. When the DHCPv6 lease is allowed to expire (e.g. the downstream router was removed), the downstream specific route will be removed.
Power Cycling your Main Router
But what if your ISP suggests you turn your router off and on again (a common refrain of the IT crowd). Since DHCPv6-PD is stateful, all memory of that state will be lost.
Should the WAN Router be power cycled, it will no longer know about the DHCPv6-PD arrangements previous made, and no longer have the PD specific downstream routes. In other words, this will be a bad thing. If you are running a network like Fig. 3, it is best to power cycle routers A, B, and C as well, so they will initiate a new DHCPv6-PD request from the WAN Router, and re-establish the PD address blocks, and specific downstream routes to the tier 1 routers.
Oh, and your address prefix delegations may change
You dutifully power cycled your WAN Router, and tier 1 routers, only to discover that your DNS queries (you are running DNS, right) are replied with the wrong addresses.
There is no guarantee that the LAN ports on the OpenWrt router will come up in the same order as they did before the power cycle, and your /60 may have moved from one port to another (e.g. Router C now has prefix
2001:db8:aaaa:bb40::/60 instead of
2001:db8:aaaa:bb80::/60. This is not only irritating, but can turn a simple action into a bad day
Leveraging PD but with more deterministic address blocks
Fortunately, the devs of OpenWrt create an easy solution to the non-deterministic PD blocks assigned to the downstream ports in the form of a ip6hint. On the WAN Router, enter the ip6hint via the web-based GUI, navigate to Network->Interface->Your interface->Edit->IP6hint
Save and Apply, and that interface (in Fig 3, connected to Router B) will always use
2001:db8:aaaa:bb40::/60 for prefix delegation. No change needs to be made on Router B itself, since it is receiving the PD from the WAN Router.
Of course, like any linux system, ip6hint can be configured in the
/etc/config/network file as well with lines like:
config interface 'DMZ' ... option ifname 'eth0.3' option ip6assign '60' option ip6hint '40' option mtu '1452'
Then restart the network to apply the change of the configuration file
Networks with loops/redundancy
What if you wanted redundancy in your network? What if Router B went down, or you wanted to upgrade it to the latest OpenWrt? You would want some resiliency or redundancy to your network.
For example by adding yet another router (Router D) to the network, both Network Aa and Bb would have an alternate path should Router A or Router B run into a problem.
Unfortunately, DHCPv6-PD will not help you here. You will need to run a routing protocol such as RIPng. There are better routing protocols, but none so simple to configure. Just turn it on, and forget it, perfect for the SOHO environment.
Fortunately, OpenWrt supports RIPng via the
bird routing daemon. To see how to configure it in OpenWrt please refer to RIPng the forgotten routing protocol
Summary: DHCPv6-PD is pretty much plug-and-play
As you can see Prefix Delegation is how each of your hosts in your SOHO network can use a GUA without the complications of NAT. DHCPv6-PD in its simplest form is plug-and-play. But your network may be a bit more complicated, as your business grows more complicated, and knowing how to stabilize PD address allocations will go a long way to keeping your network running smoothly while you concentrate on the more important parts of your business.
* ISPs can delegate blocks as large as a /48, and as small as a /64. /56 seems to be the most common allocation size.
* Originally posted on makiki.ca.