Everyone is familiar with Internet Protocol version 4 (IPv4) addresses. You probably even set them up in your home network, such as 192.168.1.1 IPv4 is described in IETF publication RFC 791 (September 1981), which replaced the previous version RFC 760, dating back to January 1980. So its safe to say that IPv4 has been around for some time and serving us quite well. New in DOCSIS 3.0 is the support for IPv6. Why do we need this new version? IPv6 has a vastly larger address space than IPv4. This results from the use of a 128-bit address, whereas IPv4 uses only 32 bits. Believe it or not, major cable operators are running out IP addresses. This is due to more customers, not just for cable modems, but also for set top boxes and VoIP eMTAs. Further, deployed in cable networks are IP devices such as power supplies with embedded cable modems for monitoring voltage, temperature, current and more. All networks are getting more IP devices requiring more and more IP addresses, so the 232 addresses allocated in IPv4 are no longer sufficient and we turn to the 2128 addresses provided in IPv6.
IPv6 isn't just your basic IP addressing scheme. It has some additional intelligence built into it that, once enabled, will make networks (including DOCSIS networks) operate a little more efficiently such as:
The bullets above can be quite powerfull because a host server can change the prefix of an IPv6 IP address scheme and renumber a complete subnet in order to operate with adjacent routers. This is something that would normally be a significant effort in an IPv4 network. IPsec is also mandated as part of IPv6, which adds a layer of security through encryption. IPsec can be added in IPv4 too, but it is something that the end user must put in as an afterthought. Having it as a requirement in IPv6 is a step in the right direction to improving network security in the future.
So now the question comes up, how does a DOCSIS 3.0 cable modem know when to use IPv4 and when to use IPv6? Well, the DOCSIS spec. defines it as follows: The CM performs IP provisioning in one of four modes: IPv4 Only, IPv6 Only, Alternate Provisioning Mode (APM), and Dual-stack Provisioning Mode (DPM). So the cable modem has four (4) options to pick from during registration with a DHCP server. So let's break each one down.
IPv4 Provisioning mode was discussed in detail in my blog on DOCSIS and Cable Modems – How it works :: Cable Modem Registration. The following diagram is also a quick reminder of the DHCP Discover, Offer process between a cable modem and a DHCP server:
Oh, and here are some handy fields that you probably are always looking up when setting up config files - these are the required stuff for provisioning an IPv4 DOCSIS cable modem pulled directly from the DOCSIS 3.0 specifcation:
The following fields MUST be present in the DHCPDISCOVER and DHCPREQUEST messages from the CM:
Now I want to include the following information, which I have never covered in the past, because a collegue of mine recently was inquiring about it. This deals with how a CPE (Customer Premise Equipment) or any IP device connected to a cable modem gets an IP address. While the DOCSIS specification I am about to quote is quite clear I want to warn you that the implementation by vendors can vary greatly. First let me show you what the spec. says as follows and then I'll explain.
In order to assist the DHCP server in differentiating between a DHCPDISCOVER sent from a CM and a DHCPDISCOVER sent from a CPE:
Okay, so what the above bullets basically say is that if your CMTS is a router (which it had better be if you want security - see my Hacking DOCSIS Cable Modems blog), then when a CPE registers it's IP, the cable modem is going to append it's own MAC address along with a "giaddr" What's a giaddr? That is a gateway address that is configured in the CMTS running config. It tells the CMTS how to route IP traffic for a particular IP subnet of cable modems - this is important because each CMTS can have many IP subnets for cable modems, each on a different line card. The giaddr helps the CMTS keep each block of cable modems straight especially when routing traffic out to a main gateway port. So this is the ideal scenario, but in my experience I have found that some vendors do make mistakes in this implementation and can accidentally just pass on the CPE MAC address. Since this is a Layer 3 IP network it usually does not cause any problems unless you trying to troubleshoot the root cause of an issue and looking for the source cable modem MAC address. If the cable modem MAC address is not attached to the DHCP Discover, realize this could be a vendor issue and you will need to dig further.
For IPv6 provisioning mode to even occur, it must be communicated by the MAC Domain Descriptor (MDD) message. Whoa, back up - this is new and I have never covered before, but it is new to DOCSIS 3.0 also. The MDD is a message transmitted by the CMTS to all cable modems on the downstream on a periodic basis, much like the UCD, but it contains more information relevant to registration. Some of this useful information is the number of bonded downstream and upstream channels, channel profile, early authentication (security), symbol clock locking, and the IP Provisioning mode [0 = IPv4 Only, 1 = IPv6, only, 2 = Alternate (APM), 3 = Dual-stack (DPM)]. So if a "1" is included in the IP Provisioning Mode of the MDD, then we have a "Go" for IPv6 provisioning. In which case the flow is a little different from IPv4 and is a follows:
So just by looking at the flow chart above, it should me immediately apparent that IPv6 provisioning is radically different that IPv4. A lot of items that were once the burden of a DHCP server are now the burden of the cable modem or IP device. Some of these include:
Oh, and here are the list of goodies that are required for a valid DHCP IPv6 provisioning message per the DOCSIS specification:
The CM sends a DHCPv6 Solicit message as described in [RFC 3315]. The Solicit message MUST include:
A Rapid Commit option indicating that the CM is willing to perform a 2-message DHCPv6 message exchange with the server.
The CM MUST use the following values for retransmission of the Solicit message (see [RFC 3315] for details):
The CM MUST use the values for retransmission of the Request message defined in [RFC 3315].
If the number of retransmissions is exhausted before the CM receives an Advertise or Reply message from a DHCP server, the CM MUST consider IPv6 address acquisition to have failed.
The CM MUST support the Reconfigure Key Authentication Protocol as described in [RFC 3315].
The DHCPv6 server may be configured to use a 2 message Rapid Commit sequence. The DHCP server and CM follow [RFC 3315] in the optional use of the Rapid Commit message exchange.
The DHCPv6 server responds to Solicit and Request messages with Advertise and Reply messages (depending on the use of Rapid Commit). The Advertise and Reply messages may include other configuration parameters, as requested by the CM or as configured by the administrator to be sent to the CM. If any of the following options is
absent from the Advertise message, the CM MUST discard the message and wait for other Advertise messages. If any of the following options is absent from the Reply message, the CM MUST consider IPv6 address acquisition to have failed:
Okay, that was brutally painful. But I wanted to illustrate that while IPv6 has tremendous value over IPv4, the transition from IPv4 to IPv6 is not going to be as easy as clicking a button in a DHCP server - at least not yet in today's DHCP servers. In fact as you make the transition, it is highly likely that there will be growing pains and possible system outages as devices get stuck in an IPv6 provisioning loop. This is one reason that the Alternate Provisioning Mode (APM) has been provided.
So as I just discussed, problems will arise during the transition to IPv6. So smart people have developed the Alternate Provisioning Mode (APM) to help us through this. In the MDD, mode 2 would be identified indicating to the cable modem to use APM. In this case, the CM will first attempt to provision with IPv6. In the event that IPv6 provisioning fails, for a multitude of reasons, the cable modem will fall back and attempt provisioning using IPv4. This gives operators a great opportunity to start trying out IPv6 without risking having subscribers lose service. There will be a slight delay since there is a time in which two provisioning modes are happening each time a modem boots, first IPv6 and then IPv4 if IPv6 fails. This can create serious problems if there is a system-wide outage, in which case it would significantly increase the load on a DHCP server and also the time for the network to be restored, assuming your IPv6 provisioning system is not working properly.
To build upon the potential time and outage issues with APM above, Dual-Stack Provisioning Mode (DPM) is an available option and potentially the best of both worlds. In DPM, the cable modem attempts simultaneous IPv6 and IPv4 provisioning. If both IPv6 and IPv4 are successful, the CM can have dual IP addresses and maintain them in a parallel mode. If one fails, it will still have a successful registration with the other. There can even be cases where portions of one provision fails, but the overall provisioning is successful because the CM obtains everything it needs as a hybrid provisioned device. Finally, since both IPv6 and IPv4 occur nearly simultaneously, if there is system outage, there will be less overall impact to network restore time since provisioning is back to a near parallel process for IPv6 and IPv4 instead of a serial process as in APM.
IPv6 is in high demand in DOCSIS and IP networks and is now available through DOCSIS 3.0. Migration to IPv6 will not be seamless, but there are some features in the DOCSIS 3.0 specification to really enable operators to make the transition much easier provided they are aware of the features and put them to use. There is no time like the present to adopt the features and opportunities available in IPv6. Do your homework and make the leap.