I was reading RFC 8475 this week, which describes some IPv6 multihoming ‘net connection’ solutions. This got me thinking about when you should use IPv6 Provider Assigned (PA) space.
To begin, it’s useful to review the concept of IPv6 Provider Independent (PI) and PA space.
PI space is assigned by a Regional Internet Registry to network operators who can show they need address space that is not tied to a service provider. These requirements generally involve having a specific number of hosts, showing growth in the number of IPv6 addresses used over time, and other factors that depend on the registry providing the address space.
PA IPv6 addresses can be assigned by a provider from their PI pool to an operator to which they are providing connectivity service.
There are two main differences between these two kinds of addresses. PI space is portable, which means the operator can take the address space with them when they change providers. PI space is also fixed; it is (generally) safe to use PI space as you might private or other IP address space. You can assign them to individual subnets, hosts, and so forth, and count on them remaining the same over time. If everyone obtained PI space, however, the IPv6 routing table in the default free zone (DFZ) could explode. PI space cannot be aggregated by the operator’s upstream provider because it is portable in just this way.
PA space, on the other hand, can be aggregated by your upstream provider because it is assigned by the provider. This means the provider can change the address block assigned to its customer at any time. The general idea is the renumbering capabilities built into IPv6 make it possible to ‘not care’ about the addresses assigned to individual hosts on your network.
How does this work out in real life? Consider the following network:
Figure 1 — Source Address selection example.
Assume AS65000 assigns 2001:db8:1:1::/64 to the operator, and AS65001 assigns 2001:db8:2:2::/64. IPv6 provides mechanisms for A, B, and D to obtain addresses from within these two ranges, so each device has two IP addresses.
Now, assume A wants to send a packet to some site connected to the public Internet. If it sources the packet from its address in the 1:1::/64 range, A should send the packet to E. If it sources the packet from its address in the 2:2::/64 range, it should send the packet to F. This behaviour is described in RFC 6724, rule 5.5:
“Prefer addresses in a prefix advertised by the next-hop. If SA or SA’s prefix is assigned by the selected next-hop that will be used to send to D and SB or SB’s prefix is assigned by a different next-hop, then prefer SA. Similarly, if SB or SB’s prefix is assigned by the next-hop that will be used to send to D and SA or SA’s prefix is assigned by a different next-hop, then prefer SB.”
If the host uses this solution, it needs to remember which sources it has used in the past for which destinations — at least for the length of a single session, at any rate. RFC 6724, however, notes supporting rule 5.5 is a SHOULD, rather than a MUST, which means some hosts may not have this capability. What should the network operator do in this case?
RFC 8475 suggests using a set of policy-based routing or filter-based forwarding policies at the routers in the network to compensate. If E, for instance, receives a packet with a source in the range 2:2::/64 range, it should route the packet to F for forwarding. This will generally mean forwarding the packet out of the interface on which E received the packet. Likewise, F should have a local policy that forwards packets it receives with a source address in the 1:1::/64 range to E. RFC 8475 provides several examples of policies that would work for a number of different situations (for active/standby, active/active, one border router or two).
There are, however, two failure modes here. For the first one, assume AS65000 decides to assign the operator another IPv6 address range. IPv6’s renumbering capabilities will take care of getting the correct addresses onto A, B, and D — but the policies at E and F must be manually updated for the new address space to work correctly. It should be possible to automate the management of these filters in some way, of course, but the complexity injected into the network is larger than you might initially think.
The second failure relates to a deeper problem. What if B is not allowed, by policy, to talk to D? If the addressing in the network was consistent, the operator could set up a filter at C to prevent traffic from flowing between these two devices. When the network is renumbered, any such filters must be reconfigured, of course. In the second instance of this same kind of failure, what if D is the internal DNS server for the network? While the DNS server’s address can be pushed out through the IPv6 renumbering capabilities (through NA, specifically), some manual or automated configuration must be adjusted to get the new address into the IPv6 advertisements so it can be distributed.
The short answer to the question above — when should you use PA space for a network? — comes down to this: when you have a very small, simple network behind a set of routers connecting to the ‘net’; where the hosts attached to the network support RFC 6724 rule 5.5; and when intra-site communication is very simple (or there are no intra-site communications at all).
Essentially, renumbering is not the only problem to solve when renumbering a network.
Adapted from original post, which appeared on Rule 11.
Russ White is a Network Architect at LinkedIn.
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.
The number of customers with networks that shouldn’t use a PA but instead a PI represent a large portion of internet users. If they all apply to a PI -as we are suggesting in all conventions- and assuming all ISPs would accept it, then DFZ would be madness.