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.
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.
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.
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.
Thanks for the article. I was looking for exactly similar explanation. Perfect.
But I am wondering why only /64, /56 and /48? Why not /62 or /60 etc.
Thanks for the comments Mark.
As explained to process instruction in ASIC vendor prefer finite state. It is easy to build ASIC instruction code then CPU base processing. Also cost effective and faster.
In this case only three state (/64, /56, /48) will make HW processing easy. But obviously if CPE support other prefix length then no issue of using /62 or /60 etc
How will DHCP default gateway issue resolve in IPv6? It should be describe in details.
Thanks Mirza for your comments.
I will write another detailed blog on IPv6 DHCP PD. Please stay tune till then.
Not clear what is DHCP PD? How this is different then regular DHCP server?
DHCP PD is IPv6 prefix delegation for a link by the DHCP server. All the device on that link will take this this prefix as global prefix and interface ID can be auto generated etc.
DHCP PD assign a prefix for a link vs regular DHCP server assign a host IP address.
Hi, thanks for the article. I’ve deployed IPv6 in my home network via a tunnel provider. I have a highly configurable router running open source router/firewall software.
What’s the IPv6 architecture that lets me plug in an IoT device and browse to its web-page based on it’s host name?
I can see an IPv4 DHCP table in my router that shows addresses and host names, and the host names get propagated to my local LAN DNS server also running on the router. Try as I might, I can only see IPv6 DUID and Mac address for the devices that even bother to request an IPv6 address.
Thanks for your comments.
IoT is still evolving but so far it is to connect little devices to the Internet and communicate P to P. Likely architecture will be DHCP PD from home gateway and auto configured interface ID.
Minimum IPv6 protocol will be embedded on to ASIC on those small devices to reduce power consumption.
That’s not really what I’m asking about.
I’m running SLACC and DHCPv6 and I can’t open the web interface of my network camera by hostname over IPv6.
I can’t ssh into my Raspberry PI 2 by hostname over IPv6.
I can’t open the web interface of my NAS server by hostname over IPv6.
See where I’m going? In IPv4, the DHCP protocol means that the DHCP server knows the host name if the host provides it, and this info can be propagated to local DNS servers, but in IPv6, the DHCPv6 server gets the DUID of the host, not the host name.
So how is the local DNS server supposed to build a list of local hostnameIPv6 address entries?
via Dynamic DNS?
if so, are there any *nix open source Dynamic DNS servers that I can run on my local network?
I see there are a few unanswered questions in your last post. Did you ever find the answers you needed?
These issues do fall under the IETF’s “homenet” working group: https://tools.ietf.org/wg/homenet/
But, standardisation and implementation are often far apart!