Design Architecture Options for IPv6 Deployment in Broadband Access Networks

When we run our IPv6 deployment workshops, we get lots of great questions and comments. One of the most frequently asked questions recently is “What is the status of IPv6 deployment globally?”

Many ISPs have made progress in preparing their “IP core network” for IPv6 deployment, at least in testbed if not deployed as a commercial service offering for all operators in their region.

Two main deployment strategies that ISPs are using for their IP core network are:

• Dual-stack IPv4 and IPv6 Core
• MPLS (6PE/6VPE) Core

In dual-stack scenario both IPv6 and IPv4 are enabled on all routers.

Where as in MPLS scenario only the edge routers (PE/LER) need to be both IPv4 & IPv6 enabled. Based on the address family signalling with core routers (P/LSR), the approach is either 6PE or 6VPE.

I will not go into detail about the network design plan for “IP Core Network” but I will give you some information on what could be the IPv6 address planning option for a typical broadband “Access Network”.

Understanding IPv4 design for broadband Access Network

The following diagram provides an overview of current typical access network technology options to deliver broadband Internet access to the end users.

Let look at the first option of xDSL deployment case and IP address assignment plan.

In regular IPv4 network when a customer attempts to connect his/her DSL modem to the ISP, a point-to-point link needs to be established between the customers DSL modem and SP DSLAM. An authentication function runs on the BRAS to allow network access and enforce relevant subscription policy for this customer.

Then an IP address needs to be allocated to the link. Normally this IP address will be a public IP address with a /32 sub-net mask. This is the Wide Area Network (WAN) side of the connection.

Now, on the DSL modem, a LAN side of this connection needs to be establish so the customer can connect their devices (laptop, smart phone, Smart-TV etc.) to the Internet. This part of the connection we typically see as home Wi-Fi network.

The DSL modem uses a private/RFC1918 address for this purpose and performs a Network Address Translation (NAT) IPv4-private-to-IPv4-public function with the public IP address assigned to the WAN side. The number of available IP addresses for the LAN will depend on the DHCP address pool size configured on the DSL modem/router. It is normally a /24 private IP block and limited to 256 available IPv4 address. If the ISP has got enough IPv4 address left then they may choose to provide IPv4 public address for the LAN side too.

The advantage is of the later approach is the connection from the customer device to the Internet will be end-to-end Internet service and the ISP does not need to keep a extensive customer usage log to comply with Government/Law Enforcement Agency (LEA) regulations.

Deploying an IPv6 network option for broadband Access Network

Consider the similar procedure as the customer attempts to connect his/her DSL modem to the ISP, a point-to-point link will be established and an authentication function runs on the BRAS. In this case this point-to-point link may be dual-stack. So we need to assign IPv6 address for the WAN side, apart from IPv4.

Also for a home network we need to assign IPv6 global prefix to the LAN side, which was not a standard requirement (Public IPv4 address) for IPv4 case. In some cases this can be IPv6 only and needs some translation function (e.g. NAT64, DNS64 ), which is out of scope of this discussion.

In the case of IPv6, there is no private/public address translation and the customer’s LAN side needs to have a global IPv6 prefix which will be allocated by the ISP DHCP service. The following diagram helps explain this process:

 

As outlined above there could be two possible scenarios:

Case A – A single network link where all end user devices will be connected.

Case B – Multiple network links at end user segment.

Case A

IPv6 auto configuration RA (Router Advertisement) service can provide a /64 prefix to the p-to-p link. Based on RFC6164 this prefix can be even /127.

If we plan to assign any prefix length other then /64 for p-to-p link, we need to carefully check all CPE (Customer Premises Equipment) will be used will support the desired prefix length. Normally low scale CPE only support /64.

Now for the end user LAN side the DHCP service of the ISP need to allocate a minimum /64 prefix to the CPE. This is what we consider DHCP PD (Prefix Delegation) compared to a single IP address in IPv4 case. So a single /64 PD can cater as many number of end user devices connected to the same link as long as the link capacity can support the required bandwidth. In this case it is not restricted by the prefix length binary mathematics anymore.

Case B

A single /64 PD may not be enough because the end user LAN is further extended with several links and each link may need an individual /64. Considering the fact that majority of the end user CEP are hardware based and support finite states in their configuration option, they may not support wide range of IPv6 prefix length options (i.e. anything between /64 to /128). Further sub-net of /64 links may not be possible.

APNIC’s guidelines for IPv6 end side network:

• /64 where it is known that only one subnet is required.
• /56 for small sites where it is expected only a few subnets will be required. Subscribers can receive a /56 when connecting through on-demand or always-on connections such as small office and home office enterprises.
• /48 for larger sites, or if an end site is expected to grow into a large network and multihome.

A similar type of approach may be applicable for other access network technology options, which is outlined on Diagram 1.

On the above IPv6 design option, end-users device growth possibilities are decoupled from the ISPs infrastructure capacity. The Internet of things smart home ideas may demand a similar type of unrestricted growth prospect of the end-user network in the future.

I hope this blog will be useful especially for the ISP design architect and as always I’m happy to take any comments and questions.

Rate this article

---

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.