In this post I want to show the different alternatives Internet Service Provider (ISP) can use to numbering their IPv4 and IPv6 point-to-point WAN link for their customers.


IPv4

In most cases small Offices will get a /29 subnet (IPv4 address pool) which leaves less the network, broadcast and gateway address, 5 public IPs for free use for the customers and their Customer Premises Equipment (CPE) router.

In this case the ISP configures the gateway IP from the /29 subnet on its side of the WAN link and its own Provider Edge Router (PE). This gateway IP must then be configured as upstream gateway from the customer on their Customer Premises Equipment (CPE) router to route traffic outbound for the WAN.

Usually the gateway IP is the first IP after the network address from this subnet (address pool). The customers can then configure the rest 5 IPs on their router (CPE) and its WAN interface by using the /29 subnet mask.

For companies they need more public IPs as the 5 IPs from a /29 subnet as mentioned above for most small offices, they can request a larger address pool (subnet), either also from their ISP which are so called provider-aggregatable address space (PA) IP addresses, or in case of real large enterprises, they can resp. could in past, for IPv4 request provider-independent address space (PI) IP addresses, which are directly assigned by a regional Internet registry (RIR) to a customer.

Customers they request these provider independent address space from a regional Internet registry (RIR) are so called local Internet registry (LIR).

A local Internet registry (LIR) is an organization that has been allocated a block of IP addresses by a RIR, and that assigns most parts of this block to its own customers. Most LIRs are Internet service providers, enterprises, or academic institutions. Membership in a regional Internet registry is required to become a LIR.

Source: https://en.wikipedia.org/wiki/Regional_Internet_registry#Local_Internet_registry


These local Internet registry (LIR) are responsible for the routing within their own allocated block of IP addresses aka autonomous system (AS).

One of the RIRs is RIPE NCC. The RIPE NCC can no longer assign IPv4 Provider Independent (PI) address space as it is now using the last /8 of IPv4 address space that it holds.

Source: https://en.wikipedia.org/wiki/Provider-independent_address_space#IPv4_assignments



If requesting a larger pool of IPv4 addresses from the provider, like a /24 or even larger subnet, the most common scenario is to use a dedicated small pool of IPv4 addresses to number the WAN link. Then the larger subnet will be routed through this dedicated smaller subnet and one of its IPs as next hop for the ISP and assigned on the customers router (CPE) and its WAN interface.

From then the routing for this larger address pool must be configured on the customers site and on their customers router (CPE).

Alternatively the ISP could also configure this larger subnet directly on the WAN link by assigning a gateway IP as done for the /29 subnet by default.

In IPv6 for large prefixes like a /48 prefix, also a common scenario is to use the first /64 prefix within the /48 prefix, to number the WAN link and then route the whole /48 prefix through this /64 prefix. More in the next section about numbering the WAN link for IPv6.


This could be done technically also for IPv4, to divide the large IPv4 subnet into smaller subnets and then route the whole large subnet through the first small subnet, but this is not a common scenario and would waste public IPv4 addresses as they anyway be rare to get assigned.

Technically by using this scenario, the large subnet, for example a /24 subnet is divided into smaller 8 x /27 subnets. Then the first /27 subnet will be used for the WAN link.

To show this exemplary, I will use a private address range, let’s assume the whole large /24 subnet is the 192.168.1.0/24 network.

Network: 192.168.1.0/24
Broadcast: 192.168.1.255
HostMin: 192.168.1.1
HostMax: 192.168.1.254
Hosts/Net: 254


In that case if we divide (subnetting) this into 8 x smaller /27 subnets, the first /27 subnet will be assigned to the WAN link.

Network: 192.168.1.0/27
Broadcast: 192.168.1.31
HostMin: 192.168.1.1
MostMax: 192.168.1.30
Hosts/Net: 30


In general the first IP from this first /27 subnet, therefore the IP 192.168.1.1 will be assigned on the ISPs Provider Edge Router (PE) and the second IP 192.168.1.2 on the customer site and their Customer Premises Equipment (CPE) router.

Both routers, ISP and customer have to configure a /27 subnet mask on its interfaces for this WAN link and the IP addresses ( 192.168.1.1 & 192.168.1.2).


In case they would configure the origin /24 subnet mask for the IP address on the WAN link, they would run into the following error as both have configured to route the whole /24 subnet to a next hop IP address and then would overlap the address space.


Now as the WAN link is configured on both sites, the ISP will route the whole 192.168.1.0/24 address pool (subnet) to the next hop IP 192.168.1.2 configured on the WAN interface from the customers router.

192.168.1.0/24 -> 192.168.1.2


From here the customer needs to configure the routing for the rest 7 x /27 subnets on his own site.




IPv6

In IPv6 there are also different alternatives the Internet Service Provider (ISP) can use to numbering their IPv6 point-to-point WAN link for their customers.

There are three options for addresses on the link between the operator network and the “end-user” CPE WAN port.


The most common scenario and currently the best practice is to use a /64 prefix from a dedicated pool of IPv6 prefixes as also done for large IPv4 address pools in IPv4 as mentioned above.

/64 prefix from a dedicated pool of IPv6 prefixes
Using a /64 prefix from a dedicated pool of IPv6 prefixes is the most common scenario and currently the best practice. A separate block of IPv6 space is allocated for the WAN links to the end customer CPEs, so that when CPE connects to the network and performs router discovery, a /64 prefix is used to number both ends of the connection.

Source: https://www.ripe.net/publications/docs/ripe-690#4-1-1—64-prefix-from-a-dedicated-pool-of-ipv6-prefixes


Also a common practice and used by Deutsche Telekom is to use the first /64 prefix out of the IPv6 prefix assigned to the customer.

/64 prefix out of the IPv6 prefix assigned to the end-user
Some operators use the first or last /64 prefix to number the CPE WAN link, from the larger IPv6 prefix assigned to the end customer. This has been described by an expired IETF Internet Draft (https://tools.ietf.org/html/draft-palet-v6ops-point2point-01).

This is sometimes a good idea, but may fail in some cases as some CPEs or scripts may try to use it for loopback and assign the next /64 to the LAN ports. Responsibility for the prefix is delegated to a CPE, but then one /64 is used for the WAN connection. Whilst there is a DHCPv6 option to let the CPE know if one of its prefixes have been “stolen” (RFC 6603). Even if RFC 7084 asks for it, not all CPEs support this and some issues will be encountered.

This is an option that simplifies routing and general provisioning provided you’re sure that the CPEs in your network don’t have the aforementioned issues.


Another alternative is to use only link-local addresses for the WAN link and not Global Unicast Addresses (GUAs).

Some operators decide to leave the WAN link to the end-user CPE unnumbered which means no GUA, so only link-local addresses are used at both ends of the link. While this might work for routers, it does not work for devices that cannot request a prefix delegation over DHCPv6 and are therefore left without any usable GUA to allow traffic in and out.

In the case of a router on the end customer side, the route for the assigned prefix is pointed towards the link-local address on the CPE/router WAN port and the default route on the CPE/router is pointed towards the link-local address on the upstream network equipment port. This method may be seen as easier to implement, but it also brings some drawbacks such as difficulties with troubleshooting and monitoring that need to be considered. For example, link local addresses do not appear in traceroute, the most common troubleshooting tool used, so you will not be able to easily locate the exact point of failure.

It is most useful in scenarios where it is known that only CPEs will be attached to the WAN link, and where a “pingable” address of the CPE is known (e.g. because the ISP-provided CPEs are always “pingable” on the first delegated address). It is less suitable in situations where unknown CPEs and/or non-CPE devices are attached to the WAN link.

In addition, non-routers (e.g. an older Windows or Linux PC or any other end-user host) connecting to a network that have no ability to ask for prefix delegation over DHCPv6 might experience problems and will stay unnumbered upon connection if a /64 prefix is not used to number the CPE WAN link. This may be also the case for many CPEs, which will not be able to complete the DHCPv6-PD if they got an unnumbered link.

Source: https://www.ripe.net/publications/docs/ripe-690#4-1-2–unnumbered


Some operators use ULAs for numbering the WAN link to the end-user CPE. This approach may cause numerous problems and is therefore strongly discouraged. For example, if the CPE needs to send an ICMPv6 message to a host outside an operator’s network (to the Internet), the packet with ULA source address will not get very far and PMTUD will break, which in turn will completely break that IPv6 connection when MTU is not the same for all the path.

Source: https://www.ripe.net/publications/docs/ripe-690#4-1-3–ula

Link-local address
https://en.wikipedia.org/wiki/Link-local_address

unique local address (ULA)
https://en.wikipedia.org/wiki/Unique_local_address

Global unicast addresses (GUAs)
https://www.ciscopress.com/articles/article.asp?p=2803866&seqNum=4#:~:text=Global%20unicast%20addresses%20(GUAs)%2C



When choosing which /64 to use, the recommended option is to dedicate a separate pool of prefixes for the WAN links.

While the addressing plan and administration might be easier when selecting the /64 from the prefix delegated to the customer, this is technically stealing because the customer’s CPE has been informed that whole prefix will be delegated to it, so it should not also be used on the WAN link unless it is known that all CPEs will support RFC 6603 to negotiate this.

Source: https://www.ripe.net/publications/docs/ripe-690#4-1-5–summary


Read also

Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans
https://datatracker.ietf.org/doc/html/draft-palet-v6ops-point2point-01

Routing Aggregation of the Point-to-Point Links
https://datatracker.ietf.org/doc/html/draft-palet-v6ops-point2point-01#section-4

Longest-Prefix-Match
https://www.juniper.net/documentation/us/en/software/junos/static-routing/topics/ref/statement/longest-match-next-hop-edit-static-routing-options.html
https://datatracker.ietf.org/doc/html/draft-palet-v6ops-point2point-01#section-4
https://www.geeksforgeeks.org/longest-prefix-matching-in-routers/

IPv6 CPE Router Recommendations
https://datatracker.ietf.org/doc/html/draft-wbeebee-ipv6-cpe-router

A /48 For Every Site and For Every Site a /48
https://blogs.infoblox.com/ipv6-coe/a-48-for-every-site-and-for-every-site-a-48/

IPv6 Nibble Boundary

What is a nibble boundary?
A nibble is 4 bits. A nibble boundary is a network mask that aligns with a boundary of 4 bits. The size of the IPv6 prefix to be delegated should match a nibble-aligned boundary to keep addressing plans easily readable and understandable. Moreover, since DNS reverse delegations for IPv6 are based on the closest 4-bit boundaries, the use of nibble boundaries simplifies the management of DNS reverse delegations. In an IPv6 prefix, each hexadecimal character represents one nibble, which is 4 bits. Therefore, the prefix length of a delegated prefix should always be a multiple of 4.
Source: https://afrinic.net/support/ipv6/nibble

https://blog.apnic.net/2018/08/10/how-to-calculating-ipv6-subnets-outside-the-nibble-boundary/



Set up a Perimeter Network with public IPv4 Addresses and pfSense


Set up an internal LAN and Perimeter Network with public IPv6 Addresses and pfSense



Links

Why is a /48 the recommended minimum prefix size for routing?
https://blog.apnic.net/2020/06/01/why-is-a-48-the-recommended-minimum-prefix-size-for-routing/

A /48 For Every Site and For Every Site a /48
https://blogs.infoblox.com/ipv6-coe/a-48-for-every-site-and-for-every-site-a-48/
To add to this significance, a /48 is the smallest Internet routable IPv6 prefix

IPv6 Subnetting
https://docs.netgate.com/pfsense/en/latest/network/ipv6/subnets.html

IPv6 Global Unicast Address Assignments
https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml