This paper will discuss the basics of DHCPv6 and various implementation models to allow Service Providers to architect IPv6 access services using Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Classical access models have traditionally used PPP to provide IPv6 addressing services. In contrast, current Next Generation Networks (NGN) networks provide native IPv6 services without requiring PPP between the user and Service Provider. This paper extends the "IPv6 Access Services" whitepaper and highlights technology enhancements for deploying and provisioning PPP-less Service Provider access networks.
IPv6 has been developed with Internet Address assignment dynamics in mind. Being aware that IPv6 Internet addresses are 128 bits in length and written in hexadecimals makes automation of address-assignment an important aspect within network design. These attributes make it inconvenient for a user to manually assign IPv6 addresses as the format is not naturally intuitive to the human eye. To facilitate address assignment with little or no human intervention, several methods and technologies have been developed to automate the process of address and configuration parameter assignment to IPv6 hosts.
The various IPv6 address assignment methods are as follows:
1. Manual Assignment
An IPv6 address can be statically configured by a human operator. However, manual assignment is open to errors and operational overhead due to the 128 bit length and hexadecimal attributes of the addresses, although for router interfaces and static network elements and resources this can be an appropriate solution.
2. Stateless Address Autoconfiguration (RFC2462)
Stateless Address Autoconfiguration (SLAAC) is one of the most convenient methods to assign Internet addresses to IPv6 nodes. This method does not require any human intervention at all from an IPv6 user. If one wants to use IPv6 SLAAC on an IPv6 node then it is important that this IPv6 node is connected to a network with at least one IPv6 router connected. This router is configured by the network administrator and sends out Router Advertisement announcements onto the link. These announcements can allow the on-link connected IPv6 nodes to configure themselves with IPv6 address and routing parameters as specified in RFC2462, without further human intervention.
3. Stateful DHCPv6
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been standardized by the IETF through RFC3315. DHCPv6 enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or in addition to the stateless autoconfiguration to obtain configuration parameters.
4. DHCPv6-PD
DHCPv6 Prefix Delegation (DHCPv6-PD) is an extension to DHCPv6 and is specified in RFC3633. Classical DHCPv6 is typically focused upon parameter assignment from a DHCPv6 server to an IPv6 host running a DHCPv6 protocol stack. A practical example would be the stateful address assignment of "2001:db8::1" from a DHCPv6 server to a DHCPv6 client. DHCPv6-PD however is aimed at assigning complete subnets and other network and interface parameters from a DHCPv6-PD server to a DHCPv6-PD client. This means that instead of a single address assignment, DHCPv6-PD will assign a set of IPv6 "subnets". An example could be the assignment of "2001:db8::/60" from a DHCPv6-PD server to a DHCPv6-PD client. This will allow the DHCPv6-PD client (often a CPE device) to segment the received address IPv6 address space and assign it dynamically to its IPv6 enabled interfaces.
5. Stateless DHCPv6
Stateless DHCPv6 is a combination of "stateless Address Autoconfiguration" and "Dynamic Host Configuration Protocol for IPv6" and is specified by RFC3736. When using stateless-DHCPv6, a device will useStateless Address Auto-Configuration (SLAAC) to assign one or more IPv6 addresses to an interface, while it utilizes DHCPv6 to receive "additional parameters" which may not be available through SLAAC. For example, additional parameters could include information such as DNS or NTP server addresses and are provided in a stateless manner by DHCPv6. Using stateless DHCPv6 means that the DHCPv6 server does not need to keep track of any state of assigned IPv6 addresses, hence there is no need for state refreshment as result. On network media supporting a large number of hosts associated to a single DHCPv6 server, this could mean a significant reduction in DHCPv6 messages due to the reduced need for address state refreshments. From Cisco IOS Software Release 12.4(15)T onwards, the client can also receive timing information in addition to the "additional parameters" through DHCPv6. This timing information provides an indication to a host when it should refresh its DHCPv6 configuration data. This behavior (RFC4242) is particularly useful in unstable environments where changes are likely to occur.
Note that there is no requirement that a network use either stateless or stateful; in some cases both may be in use.
Introduction to DHCPv6
The basic DHCPv6 client-server concept is similar to DHCP for IPv4. If a client wishes to receive configuration parameters, it will send out a request on the attached local network. A DHCPv6 server which is connected to this local network may reply back with the requested configuration parameters as demonstrated below:
Figure 1. Basic DHCPv6 Principle
DHCPv6 technology was introduced in Cisco IOS Software since Release 12.3(4)T and feature support has been adapted by many additional Cisco IOS Software releases. The Dynamic Host Configuration Protocol for IPv6 enables managed distribution of configuration parameters between a DHCPv6 Server and its clients. DHCPv6 offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility (ie: DNS server, NTP server, etc.). DHCPv6 has been specified in RFC3315 and is the result of a clean new protocol architecture (for example DHCPv6 did not suffer from design restrictions mandated by legacy technology like BOOTP). As result DHCPv6 uses an architecture concept of "options" to carry additional parameters and information within DHCPv6 messages. These options are aligned in the Type-Length-Value (TLV) structure. Each Type and Length field has a length of 16 bits, with a variable length available for the Value field. Each option `should' appear only once in the option area of the DHCPv6 messages, although the protocol standard does not restrict this aspect. Each option is also scoped, which means that some options can contain other options, in which case the options contained in that option have meaning only for the option they are contained in.
DHCPv6 Components
DUID (DHCP Unique Identifier)
Each DHCPv6 component has a DHCPv6 Unique Identifier (DUID) which is used to identify the device when exchanging DHCPv6 messages. RFC3315 does not allow use of the DUID for any other purpose. The DUID is carried as an DHCPv6 option, because its length could be variable and its availability is not required in all DHCPv6 messages. The DUID is designed to be unique around all DHCPv6 servers and clients, and must be stable for any specific client or server (for example a device DUID should not change as the result of changing some hardware in a device). A DUID can not be longer than 128 octets. At the moment there are three types of DUID defined:
1. Link-Layer address plus Time (DUID-LLT)
2. Vendor-assigned unique ID based on Enterprise Number
3. Link-Layer address (DUID-LL)
Cisco uses a structure based on Link-Layer address plus Time (DUID-LLT). The device uses the MAC address from the lowest numbered interface to form the DUID. The DUID of a Cisco router can be checked by executing the command `show ipv6 dhcp` as shown below:
Router-1841-1#sho ipv6 dhcp
This device's DHCPv6 unique identifier(DUID): 00030001001A2F875602
Router-1841-1#
The DUID-LLT field is constructed as follows:
Figure 2.
The type of DUID-LLT consists of:
• Two octet type field containing the value 1
• Two octet hardware type code. The hardware type MUST be a valid hardware type assigned by the IANA as described in RFC 826. Ethernet uses hardware type 1 and 48-bit MAC address of the device as the link-layer address.
• Four octets containing a time value
• Link-layer address of any one network interface that is connected to the DHCP device at the time that the DUID is generated. The time value is the time that the DUID is generated represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32.
DHCPv6 Bindings
A DHCPv6 binding is based upon an Identity Association (IA) and is a construct through which a server and a client can identify, group, and manage a set of related IPv6 addresses.
A binding (or client binding) is a group of server data records containing the information the server has about the addresses in an IA or configuration information explicitly assigned to the client. A binding contains information about an IA and is indexed by the tuple <DUID, IA-type, IAID> (where IA-type is the type of address in the IA; for example, temporary, non-temporary or prefix delegation address; the IAID is a 32 bit number assigned by the DHCPv6 client). A binding contains configuration information for a client and is indexed by <DUID>. A single client can request multiple bindings (in single or multiple transactions), and each binding has one or more leases involved.
IPv6 Address Selection by an DHCPv6 Server
A server selects addresses to be assigned to an Identity Association (IA) according to the address assignment policies determined by the server administrator and the specific information the server determines about the client from some combination of the following sources:
• The link to which the client is attached; the client could be attached directly on-link or through a DHCPv6 relay
• The client's DUID
• Other information supplied by the client
• Other information supplied by a relay agent
DHCPv6 Client/Server Messages
DHCPv6 messages are exchanged over UDP port 546 and 547. Clients listen for DHCP messages on UDP port 546 while servers and relay agents listen for DHCP messages on UDP port 547. The basic message format is as follows:
To reduce the requirement for fixed fields, where potentially not all fields are always used, a flexible solution based upon DHCPv6 options is used to transport data, hence all data is transported through dynamic usage of selection options.
The following table shows a comparison between DHCPv6 and DHCPv4 message types.
Table 1. DHCPv6 vs DHCPv4 Message Types
DHCPv6 Message Type
DHCPv4 Message Type
Solicit (1)
DHCPDISCOVER
Advertise (2)
DHCPOFFER
Request (3), Renew (5), Rebind (6)
DHCPREQUEST
Reply (7)
DHCPACK / DHCPNAK
Release (8)
DHCPRELEASE
Information-Request (11)
DHCPINFORM
Decline (9)
DHCPDECLINE
Confirm (4)
none
Reconfigure (10)
DHCPFORCERENEW
Relay-Forw (12), Relay-Reply (13)
none
SOLICIT (1)
A DHCPv6 client sends a Solicit message to locate DHCPv6 servers.
ADVERTISE (2)
A server sends an Advertise message to indicate that it is available for DHCP service, in response to a Solicit message received from a client.
REQUEST (3)
A client sends a Request message to request configuration parameters, including IP addresses or delegated prefixes, from a specific server.
CONFIRM (4)
A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected. This could happen when the client detects either a link-layer connectivity change, or if it is powered on and one or more leases are still valid. The confirm message is used to confirm whether the client is still on the same link or whether it has been moved. The actual lease(s) are not validated; just the prefix portion of the addresses or delegated prefixes.
RENEW (5)
A client sends a Renew message to the server that originally provided the client's addresses and configuration parameters, to extend the lifetimes on the addresses assigned to the client and to update other configuration parameters.
REBIND (6)
A client sends a Rebind message to any available server to extend the lifetimes on the addresses assigned to the client and to update other configuration parameters; this message is sent after a client receives no response to a Renew message.
REPLY (7)
A server sends a Reply message containing assigned addresses and configuration parameters in response to a Solicit, Request, Renew, Rebind message received from a client. A server sends a Reply message containing configuration parameters in response to an Information-request message. A server sends a Reply message in response to a Confirm message confirming or denying that the addresses assigned to the client are appropriate to the link to which the client is connected. A server sends a Reply message to acknowledge receipt of a Release or Decline message.
RELEASE (8)
A client sends a Release message to the server that assigned addresses to the client to indicate that the client will no longer use one or more of the assigned addresses.
DECLINE (9)
A client sends a Decline message to a server to indicate that the client has determined that one or more addresses assigned by the server are already in use on the link to which the client is connected.
RECONFIGURE (10)
A server sends a Reconfigure message to a client to inform the client that the server has new or updated configuration parameters, and that the client is to initiate a Renew/Reply or Information-request/Reply transaction with the server in order to receive the updated information.
INFORMATION-REQUEST (11)
A client sends an Information-request message to a server to request configuration parameters without the assignment of any IP addresses to the client.
RELAY-FORW (12)
A relay agent sends a Relay-forward message to relay messages to servers, either directly or through another relay agent. The received message, either a client message or a Relay-forward message from another relay agent, is encapsulated in an option in the Relay-forward message.
RELAY-REPL (13)
A server sends a Relay-reply message to a relay agent containing a message that the relay agent delivers to a client. The Relay-reply message may be relayed by other relay agents for delivery to the destination relay agent. The server encapsulates the client message as an option in the Relay-reply message, which the relay agent extracts and relays to the client.
DHCPv6 Options
Within DHCPv6, options are used to exchange parameter information between a server and a client. If a client wishes to request a specific option or set of parameters it must do this through an Option Request Option (ORO). Cisco IOS Software only supports a limited set of options from the full list of options available at IANA (http://www.iana.org/assignments/dhcpv6-parameters). Options have a 16 bit option number and 16 bit option lengths. Some options will encapsulate other options for scoping purposes. A DHCPv6 relay will encapsulate client (or other relay) messages in a message option.
The following options are amongst others supported by Cisco IOS Software:
• Client Identifier option
The Client Identifier option is used to carry a DUID identifying a client between a client and a server
• Server Identifier option
The Server Identifier option is used to carry a DUID identifying a server between a client and a server
• Option Request option
The Option Request option is used to identify a list of options in a message between a client and a server.
• Preference option
The Preference option is sent by a server to a client to affect the selection of a server by the client
• Status Code Option
This option returns a status indication related to the DHCP message or option in which it appears
• Rapid Commit option
The Rapid Commit option is used to signal the use of the two message exchange for address assignment
• Identity Association for Prefix Delegation option (IA_PD option)
The IA_PD option is used to carry a prefix delegation identity association, the parameters associated with the IA_PD and the prefixes associated with it
• IA_PD Prefix option
The IA_PD Prefix option is used to specify IPv6 address prefixes associated with an IA_PD. The IA_PD Prefix option must be encapsulated in the IA_PD-options field of an IA_PD option.
• Domain Name Server option
The DNS Recursive Name Server option provides a list of one or more IPv6 addresses of DNS recursive name servers to which a client's DNS resolver MAY send DNS queries. The DNS servers are listed in the order of preference for use by the client resolver.
• Domain Search List option
The Domain Search List option specifies the domain search list the client is to use when resolving hostnames with DNS. This option does not apply to other name resolution mechanisms.
• Information Refresh Option
The Information Refresh Option is used for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration.
• Remote-id option
This option may be added by DHCPv6 relay agents that terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit.
Not all options have been or will be standardized by IETF. For these instances a special option (VENDOR_OPTS Option) has been created which allows vendor specific options to be implemented. The SNMP-Enterprise-ID is used to identify the vendor. The data available in these options are completely up to the definition of the related vendor, however there is preference for the 16 bit options format. For example CableLabs is a vendor which utilizes a vendor specific option for DOCSIS3.0. The CableLabs enterprise-ID is 4491.
Some DHCPv6 options may encapsulate other options
• Identity Association-Non-temporary Address (IA_NA) and Identity Association - Temporary Address (IA_TA) can encapsulate Identity Association Address (IAADDR)
• Identity Association-Prefix Delegation (IA_PD) can encapsulate Identity Association for prefixes (IAPREFIX)
• IAADDR and IAPREFIX could encapsulate address/prefix specific options (although none are presently specified by any IETF standard)
• Relay Message encapsulates relayed client or relayed messages; one message format is shared between Relay-Forward and Relay-Reply
Figure 5. Identity Association Address (IAADDR) Option
Figure 6. IAPREFIX Option (Identity Association for prefixes)
Figure 7. General Shared Relay Message Format
The entries within the shared Relay message format are defined as:
Relay-forward packet content
Relay-reply packet content
hop-count:
Number of relay agents that have relayed this message.
link-address:
A global or unique local address that will be used by the server to identify the link on which the client is located.
peer-address:
The address of the client or relay agent from which the message to be relayed was received.
Options:
MUST include a "Relay Message option" and may include other options added by the relay agent (ie: remote-id option).
hop-count:
Copied from the Relay-forward message
link-address:
Copied from the Relay-forward message
peer-address:
Copied from the Relay-forward message options
Options:
MUST include a "Relay Message option" and may include other options
DHCPv6 Basic Operation
Figure 8.
The traditional sequence of events is:
1. A router attached to a network will announce it as a router sending periodic Router Advertisements (RA's). If the router wishes that the attached clients have to use DHCPv6 for acquiring an IPv6 address, then it can signal that with setting the `O' and `M' bits in the Router Advertisement (RA). The two bits of importance within a Router Advertisement (RA) are:
a. M-bit: 1-bit "Managed address configuration" flag. When set, clients use DHCPv6 protocol for address configuration.
b. O-bit: 1-bit "Other stateful configuration" flag. When set, hosts use DHCPv6 to obtain `other' (non-address) information.
2. On a client enabled with the DHCPv6 stack, the DHCP procedure is typically initiated when either the client receives a notification from the attached router to run DHCPv6 (by the `O' and `M' bits in the Router Advertisement (RA)), or if the client detects no directly connected routers. However, there's nothing to prohibit DHCPv6 to run always; it is just that it SHOULD be run if M or O bits are set.
3. A directly connected DHCPv6 server or client will reply to the request from the DHCPv6 client
If however the client is a Cisco router trying to run DHCPv6-PD, then the parameters within the RA are not of critical importance to bootstrap the DHCPv6 process. In this case, the routers are manually configured to use DHCPv6. The DHCPv6-PD server can then decide to do Prefix Delegation with four messages, or it may proceed using only two messages if rapid-commit is supported.
DHCPv6 clients and servers use UDP (ports 546/547) to exchange messages. The client will make use of Link Local addressing to send and receive DHCPv6 messages. DHCPv6 servers make use of the reserved link-local "ff02::1:2" (All DHCPv6 relay agents and servers) and site-local "ff05::1:3" (All DHCPv6 Servers) multicast addresses. A DHCP client transmits most messages to the reserved link-local "ff02::1:2" multicast address, so that the client need not be configured with the address or addresses of DHCP servers. However, in many situations the DHCP server will not be connected to a segment where its clients are connected. In these situations, a DHCP Relay Agent is used. The DHCP Relay agent must be connected to the segment of the client and will relay the messages between the client and the server. The existence of a relay agent is transparent to the client. Cisco IOS routers can provide the function of DHCPv6 Relay Agent since Release 12.3(11)T. Once a client has identified the existence of a DHCPv6 server it may start sending messages using unicast instead of multicast. The DHCPv6 Client-Server exchange can be completed by either a 2 or 4 message exchange which is described in the following section.
The next two examples introduce the fundamentals of the DHCPv6 two and four phase client and server negotiation. For documentation purposes the IA_PD option is used in this example related to Prefix Delegation (for example a Customer Premises Equipment (CPE) router acquiring IPv6 prefixes from the Service Provider DHCPv6 server). The later case-study examples will also be visualized with IA_PD options for prefix delegation. The identical same DHCPv6 2 or 4 phase negotiation can be used for IA_NA prefix configuration (used for example when a host running a DHCPv6 client process wants to acquire IPv6 addresses and related information).
Client-Server Exchanges Involving Two Messages
When a DHCP client does not need to have a DHCP server assign it IP addresses, the client can obtain configuration information such as a list of available DNS or NTP servers through a single message and reply exchange with a DHCP server. To obtain configuration information the client first sends an Information-Request message to ff02::1:2 (All Relay Agents and Servers). The server will respond with a Reply message containing the configuration information for the client.
This message exchange assumes that the client requires only configuration information and does not require the assignment of any IPv6 addresses. When a server has IPv6 addresses and other configuration information committed to a client, the client and server may be able to complete the exchange using only two messages, instead of four messages. In this case, the client sends a Solicit message to the ff02::1:2 requesting the assignment of prefixes and other configuration information. This message includes the Rapid Commit Option as an indication that the client is willing to accept an immediate Reply message from the server. A server that is willing to commit the assignment of addresses to the client immediately responds with a Reply message. The configuration information and the addresses in the Reply message are then immediately available for use by the client. If a server is unwilling to allow the two message exchange, it responds as normal (as discussed later).
Each address assigned to the client has associated preferred and valid lifetimes specified by the server. To request an extension of the lifetimes assigned to an address, the client sends a Renew message to the server. The server sends a Reply message to the client with the new lifetimes, allowing the client to continue to use the address without interruption.
Figure 9. DHCPv6-PD Request Message Flows for Two Message Exchange
Client-Server Exchanges Involving Four Messages
To request the assignment of one or more IPv6 addresses
• A client first locates a DHCP server and then requests the assignment of addresses and other configuration information from the server. The client sends a Solicit message to the ff02::1:2 address to find available DHCP servers.
• Any server that can meet the client's requirements responds with an Advertise message.
• The client then chooses one of the servers and sends a Request message to the server asking for confirmed assignment of addresses and other configuration information.
• The server responds with a Reply message that contains the confirmed addresses and configuration.
In same manner as documented in previous section, the client sends a Renew message to the server to extend the lifetimes associated with its addresses, allowing the client to continue to use those addresses without interruption.
Figure 10. DHCPv6-PD Request Message Flows for Four Message Exchange
DHCPv6 Relay Messages
In many situations, the DHCPv6 server is not always directly connected to each and any potential client due to practical and network management reasons. It is however, required to have an on-link presence of the DHCP server entity because DHCPv6 basic operation between client and server will use link-local communication. This entity can either be a DHCPv6 Server, or if a server is not present it will be a DHCPv6 Relay Agent. A relay agent intercepts the link-local DHCPv6 messages and forwards these to a valid DHCPv6 server available within the networking infrastructure. When a relay agent "relays" messages it may be configured to with a list of destination addresses, which may include unicast addresses, the All_DHCP_Servers multicast address, or other addresses selected by the network administrator. If the relay agent relays messages to the All_DHCP_Servers multicast address or other multicast addresses, it sets the Hop Limit field to 32.
When a DHCPv6 server decides to respond to a relayed client message, it composes a reply with inclusion of information available within the relayed client message. In more detail, the server will copy some relay agent options (it will copy for example the Interface-Id option). The server will send the reply to the source address of the received packet on port 547 (relay port). This IPv6 source address is the address of the last relay agent within the potential chain of relay agents. The relay agent may now forward the packet onwards to either the next downstream relay-agent or directly to the actual DHCPv6 client if it is directly attached to the relay-agent. For the relay-agent to forward the reply it uses the `peer-address' field in the received relay-reply as destination address, while the link-address and/or Interface-ID option determine the interface on which to forward the relayed message. The forwarded message is sent to port 547 (if encapsulated message is Relay-forw) otherwise port 546 is used.
Figure 11. Initial Solicit and Resulting Relayed Solicit Message
There may be a series of relay agents concatenated behind one another. The impact this will have is that for each relay agent there is an additional set of information embedded in the relayed DHCPv6 packet while encapsulating the original packet. This additional encapsulation (message-type, hop-count, link-address and peer-address) by the additional relay is similar to the previous diagram. This is in contrast with the behavior of what "ip helper address" is bringing to DHCPv4, where "ip helper address" it can simply forward packets to a single IPv6 destination address.
The relay agent must be configured with a valid IPv6 address of the DHCPv6 server available within the network infrastructure (or the DHCPv6 server may be reachable via the site-local ff05::1:3 (All DHCPv6 Servers) multicast address). This can be done as demonstrated in the following example on a Cisco Router functioning as a DHCPv6 Relay:
Note: It is not required to configure this command on every router along the path between the client and server. It is ONLY required on the router functioning as the DHCPv6 relay agent.
When analyzing the packet exchange between the actual DHCPv6 client (in this example a DHCPv6-PD client is assumed), DHCPv6 relay agent, and DHCPv6 server the following packet flow can be seen (assuming Client-Server exchange involves four messages):
Figure 12. Message Exchanged for Relay Based Implementation
The packet trace content from the above visualized packet IA_PD exchange is shown in the following output:
Useful DHCPv6 deployment features and options
Remote-id Option
Service Provider DHCPv4 deployments make an extensive use of Option 82 to help identify the subscriber and assign addresses. Similar needs arise when including DHCPv6 in large scale deployments. When a relay-agent is forwarding DHCPv6 client messages, then it may insert additional parameters and options before relaying the message to a DHCPv6 server. A particular option of interest is the `remote-id' option. This option will help the DHCPv6 server to identify correct parameters to reply back to the DHCPv6 client. This option is the IPv6 counterpart of the IPv4 (DHCPv4) Relay Agent Option's Remote-ID sub-option as specified in RFC 3046. A full definition of the IPv6 remote-id option is found at RFC4649. This option is especially useful for an ISP, because it allows the ISP to allocate a client prefix based upon an administrative identification, instead of a DUID or other parameter values.
There is no direct show command on the router to show the assigned remote-id option added to a relayed DHCPv6 message. However, it can be found with "debug ipv6 dhcp relay" and "debug ipv6 dhcp detail", or it can be found on the DHCPv6 Server supporting remote-id option for IPv6.
Information Refresh Time Option
This option is a useful aid when deploying DHCPv6 based services, and is standardized by IETF in RFC4242. The refresh option can specify an upper boundary for the length of time a client should wait before refreshing information retrieved from DHCP for IPv6. This option is used with stateless DHCP for IPv6, because there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCP for IPv6 server to refresh its configuration and is supported from Cisco IOS Software Release 12.4(15)T.
Hierarchical DHCPv6
A home access router for an IPv6 enabled household can be both a DHCPv6 client and server. The client function will retrieve configuration parameters from the provider in stateful or stateless DHCPv6. In either case, the ISP side DHCPv6 server can provide configuration parameters such as DNS server addresses, domain names, NTP server, etc. to the DHCPv6 client on the IPv6 enabled household access router. These configuration parameters are traditionally specific to an ISP and may alter over time.
Figure 13.
In addition to being a DHCPv6 client (towards the ISP), the access router can act as a DHCPv6 server towards the home network. For example, Neighbor Discovery followed by stateless or stateful DHCPv6 can occur on the link between access router and the home devices. In some cases, the information to be provided to the home network is the same information obtained from the ISP side DHCPv6 server. Because this information can be dynamically changed, it makes sense to have the DHCPv6 server function on the access router inherit the received configuration parameters from the DHCPv6 server from the ISP. Therefore, the DHCP for IPv6 component on the CPE allows automatic importing of configuration parameters from the DHCP for IPv6 client to the DHCP for IPv6 server pool.
Deploying DHCPv6 Based Access Services
Introduction
Deploying DHCPv6 based access services can be achieved in a variety of manners. For the deployment models discussed in this paper, the assumed base requirement for a CPE is to receive an IPv6 address-range from its Service Provider while the local loop media used is Ethernet based. It is also assumed that the CPEs have support for DHCPv6-PD. This IPv6 address range can be used by the CPE to dynamically address the site and its interfaces.
When looking into the provisioning and deployment models of the DHCPv6-PD services, three main models can be identified:
• Deployment model 1: DHCPv6-PD Server at the Service Provider Edge Router
This is maybe the simplest model, but can have its limits due to operational maintenance and provisioning overhead. With this deployment model the Service Provider Edge router is directly delivering the DHCPv6-PD "server" service. This means that there is no need for an external DHCPv6 server beyond the Service Provider Edge router, however, each ISP network edge router may need a unique DHCPv6-PD configuration with a configuration in place to assign IPv6 address space to each of its customers.
Figure 14.
• Deployment mode 2: DHCPv6-PD Relay at the provider edge router
This provisioning model is based around a centralized DHCPv6-server. In contrast with the first model, each ISP edge router will serve as a DHCPv6-relay agent. The required DHCPv6 configuration for this function on each of the DHCPv6 relay-agents can be quite simple and similar. The bulk of the DHCPv6 configuration, provisioning and tracking is done on the DHCPv6 server. Cisco Network Registrar 7.0 (CNR7.0) has in-depth support of IPv6 technology. If this deployment model is used, then the ISP edge router will forward (known as Relaying) DHCPv6-PD messages between the DHCPv6-PD client and the DHCPv6-PD server.
Figure 15.
The principle of hierarchical DHCPv6 is powerful when hosts request additional information needed beyond IPv6 addresses. A Cisco IOS CPE can be both a DHCPv6 Server and Client, simultaneously. Through the DHCPv6 client the CPE can learn parameters as Domain name, DNS servers, SNTP servers, etc. from the central DHCPv6 server, and by acting as a DHCPv6 Server, it can announce these parameters to a set of locally connected hosts. These hosts may utilize DHCPv6 to learn their IPv6 addresses and in addition, use DHCPv6 to get information about the "other" parameters. This full process happens dynamically and without user intervention. In this case, the CPE DHCPv6 server functionality keeps track of the DHCPv6 client bindings and refreshes the bindings periodically. However, hosts may alternatively use Stateless Address Auto-configuration (SLAAC), and get an IPv6 Address based upon the received CPE RA's (Router Advertisements), while using DHCPv6 to get the "other" parameters. With this design, the CPE DHCPv6 server functionality does NOT need to keep track of the IPv6 to DHCPv6 client bindings, and hence, there is no need to refresh the binding periodically. This is especially useful in situations with potential for a large amount of client (wireless mobile phones connecting to the internet), or where bandwidth is an expensive resource.
• Deployment model 3: DHCPv6-PD Relay at the provider edge router and DHCPv6 remote-id option
This third deployment model is quite similar as the previous model because the configuration, provisioning and tracking is done on a centralized DHCPv6 server. The difference is in the methodology on how IPv6 prefixes are assigned to the DHCPv6-clients. In the 2nd model, the assigned DHCPv6-PD addresses are based around the DHCPv6 Unique ID (DUID) and the location where the DHCPv6 client is accessing the Service Provider network. If an end-user changes his CPE device due to an upgrade or due a break/fix, then the provisioned address and tracking could become complicated because some parameters have changed at the customer side, and the management system must accommodate that. In this last provisioning model, the assigned IPv6 address space is done based upon the remote-id options, which were injected by the DHCPv6-PD relay router. The remote-id gives the DHCPv6-server an indication to which Service Provider edge router any DHCPv6-client is connected to and can simply, based upon these values, assign an IPv6 address-space. This has as benefit that IPv6 provisioning is completely independent of the DUID used by the DHCPv6-client, while at the same time the assigned IPv6 address is independent of the CPE used by the end-customer.
The remote-id is a value assigned automatically by the Cisco DHCPv6 relay.
Figure 16.
DHCPv6-PD Client Configuration Consideration
The configuration for each of the DHCPv6-PD deployment models discussed is identical to each other. The configuration from the DHCPv6 client is fully independent and invisible from the DHCPv6-client perspective. During the DHCPv6 technology description, both the client-server message exchanged was discussed with 2 and 4 messages. The client can be instructed through configuration to run DHCPv6 in either `2' or `4' messages. During the examples documented for each deployment model, the default of `4' messages is used, as it covers all steps of the DHCPv6 communication procedure. However for generating less messages for DHCPv6-PD, a `2' message exchange can be a better choice for implementation. The CPE utilized for this paper is a Cisco1841 ISR. For each of the deployment models the following IOS configuration is used on the CPE router:
!
hostname router-1841-1
!
ipv6 unicast-routing
! Enable IPv6 Unicast Routing
ipv6 cef
! Enable IPv6 CEF switching
!
!
interface Loopback100
no ip address
ipv6 address PREFIX_1 ::1/64
! Configures the IPv6 address of the Loopback based upon the DHCPv6 received address
ipv6 enable
! enable IPv6 processing on this interface
!
interface FastEthernet0/0
description Link towards the Service Provider
ip address 11.11.11.1 255.255.255.252
speed 100
half-duplex
ipv6 address autoconfig default
! The IPv6 address is automatically learned and based upon the received Router Advertisement from its upstream Service Provider router. The `default' keyword means that the CPE will lear
