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:

  • Stateless address autoconfiguration and network renumbering and
  • an automatic mechanism for forming the host identifier

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

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:

Cable Modem IP Provisioning IPv4

Cable Modem IP Provisioning IPv4

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:

  • The hardware type (htype) MUST be set to 1;
  • The hardware length (hlen) MUST be set to 6;
  • The client hardware address (chaddr) MUST be set to the 48 bit MAC address associated with the RF interface of the CM;
  • The client identifier option MUST be included, using the format defined in [RFC 4361];
  • The parameter request list option MUST be included. The following option codes (defined in [RFC 2132] and [RFC 4361]) MUST be included in the list:
    • Option code 1 (Subnet Mask)
    • Option code 2 (Time Offset)
    • Option code 3 (Router Option)
    • Option code 4 (Time Server Option)
    • Option code 7 (Log Server Option)
    • Option code 125 (DHCPv4 Vendor-Identifying Vendor Specific Information Option)

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:

  • The CMTS DHCPv4 relay agent MUST support the DHCP Relay Agent Information Option (RAIO) [RFC3046].  Specifically, the CMTS DHCPv4 relay agent MUST add an RAIO to the DHCPDISCOVER message before relaying the message to a DHCP server. The RAIO MUST include the 48 bit MAC address of the RF-side interface of the CM generating or bridging the DHCPDISCOVER in the agent remote ID sub-option field [RFC 3046].
  • If the CMTS is a router, the CMTS DHCPv4 relay agent MUST use a giaddr field to differentiate between CM and CPE clients if they are to be provisioned in different IP subnets. The DHCPv4 relay agent in a bridging CMTS SHOULD provide this function.
  • DHCPv4 Relay Agent CMTS Capabilities option, containing the value “3.0” for the CMTS DOCSIS Version Number [CANN DHCP-Reg].

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.

IPv6 Provisioning Mode

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:

IPv6 Provisioning

IPv6 Provisioning

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:

  • Ensuring that the assigned IP address is not already in use, if so the CM must report this event to the local log and restart provisioning
  • The CM MUST perform router discovery as specified in [RFC 4861] so that it is aware of adjacent routers – if this fails, it must restart provisioning

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 Client Identifier option containing the DUID (DHCP Unique Identifier) for this CM as specified by [RFC3315]. The CM can choose any one of the rules to construct the DUID according to section 9.1 of [RFC 3315];
  • An IA_NA (Identity Association for Non-temporary Addresses) option to obtain its IPv6 management address;
  • A Vendor Class option containing 32-bit number 4491 (the Cable Television Laboratories, Inc. enterprise number) and the string “docsis 3.0”;
  • A Vendor-specific option containing:
    1. TLV5 option (reference [CANN DHCP-Reg] ) containing the encoded TLV5s describing the capabilities of CM information option in Annex C.1.3.1;.
    2. Device ID option containing the MAC address of the HFC interface of the CM;
    3. ORO option requesting the following vendor specific options:
    4. Time Protocol Servers
    5. Time Offset
    6. TFTP Server Addresses
    7. Configuration File Name
    8. SYSLOG Server Addresses

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):

  • IRT (Initial Retransmission Time) = SOL_TIMEOUT
  • MRT (Maximum Retransmission Time) = SOL_MAX_RT
  • MRC (Maximum Retransmission Count) =4
  • MRD (Maximum Retransmission Duration) =0

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:

  • The IA_NA option received from the CM, containing the IPv6 management address for the CM.
  • A Vendor-specific Information option containing the following sub-options (refer to [CANN DHCP-Reg]):
  • Time Protocol Servers option
  • Time Offset option
  • TFTP Server Addresses option
  • Configuration File Name option
  • Syslog Server Addresses option

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.

Alternate Provisioning Mode

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.

Dual-Stack Provisioning Mode

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.

Summary IPv6

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.

Upcoming events can be seen under Broadband Events. Previous events can be seen under the blog.

  • If you are watching this on youtube please hit the subscribe button!
  • Let us know what you think and remember to share!  
  • You can find slides at the bottom of the page and some on slideshare.  
  • Find out about events or articles by following us on Twitter, LinkedIn or Facebook too.

Also available on iTunes, Google Podcasts, Spotify, vurbl see podcasts “get your tech on”.

Spotify  Vurbl