DHCPv6 Dynamic Re-Configuration
draft-wing-behave-dhcpv6-reconfigure-01

Abstract

Some networks are expected to support IPv4-only, dual-stack, and IPV6-only hosts at the same time. This makes prioritizing the DNS servers for hosts tricky due to a heterogeneous mix of protocol stacks causing optimal behavior to occur only when the host stack re-initializes. The networks infrastructure is usually well equipped to be aware of single/dual-stack nature of hosts. This specification extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically influence the priority of DNS servers provided to the host, so that the host can use the optimal DNS server for resolution.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 03, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Mechanism
• 4. Protocol overview
• 4.1. Message
• 4.2. Relay Reconfigure option
• 5. DHCPv6 Relay Agent Behaviour
• 6. DHCPv6 Server Behaviour
• 7. Host Tracking
• 8. Security Considerations
• 9. IANA Considerations
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

The default address selection rules [RFC3484] prefers IPv6 over IPv4. If a dual-stack host is configured to use a DNS64 server, that DNS64 server will synthesize a AAAA response if there is an A record. Thus, the dual-stack host will always use IPv6 if a DNS lookup was involved, even if IPv4 could have been used more optimally. If NAT44 and NAT64 are deployed on the same network, , it is preferable to use NAT44 over NAT64 because of scale, performance and application incompatibility issues (e.g., FTP) [RFC6384]. At the same time, native IPv6 can still be preferred over IPv4. The DHCPv6 Relay Agent can observe host characteristics on a network to determine if the host is IPV4-only, dual-stack or IPV6-only and also determine transitions from single to dual-stack or vice-versa. In this document we propose a specification that allows the DHCPv6 Relay Agent to influence the DHCPv6 Server to send appropriately prioritized DNS Servers to the client as per host characteristics.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

'normal' DNS server : DNS server using an IPv4-mapped IPv6 address (that is, an IPv6 address starting with ::ffff:/96 IPv4-mapped prefix). Hosts can communicate with 'normal' DNS server only using IPv4 packets [RFC6052], section 4.2.

DNS64 server : DNS server using a normal IPv6 address and synthesizes AAAA records from A records [RFC6147]

3. Mechanism

This document describes a new DHCPv6 Message and Option that is to be used by the DHCPv6 Relay Agent to indicate to the DHCPv6 Server of the priority of DNS servers to be provided to the specified host. The DHCPv6 Server then sends a Reconfigure message to the host providing updated/re-ordered DNS server list as suggested by the Relay Agent. The idea is for the DHCPv6 Relay Agent to dynamically send the reconfigure message based on host characteristics.

1. IPv6-only transition to Dual-Stack In case a host is IPv6-only to start off, it is provided a DNS64 Server. When transitioning to dual-stack, a IPv4 DNS Server is assigned as a consequence of obtaining an IPv4 Address. The DHCPv6 Relay Agent can detect this and send RELAY-RECONFIG message Section 4.1 to the DHCPv6 Server indicating that the host needs to be needs to be provided with "normal" DNS Server followed by DNS64 server. In lieu of this mechanism, the host would continue to use the DNS64 server until the host stack Re-initializes.
2. Dual-Stack to IPv6-only In case a host is dual-stack, it is provided with "normal" DNS followed by DNS64 server. When transitioning to IPv6-only, the DHCPv6 Relay Agent can detect this and send a RELAY-RECONFIG message to the DHCPv6 Server indicating that the host needs to be assigned a DNS64 server only. Without this, the host will continue to use the "normal" DNS Server which is inaccessible and eventually time out to fail over to the DNS64 Server. This means that the host will take additional time to fully initialize causing delays in connection.
3. IPv4-only transition to Dual-Stack In case a host is IPv4-only to start off, it is provided IPv4 DNS Server. When transitioning to dual-Stack, DNS64 server is also provided as a consequence of obtaining IPv6 address(s). The DHCPv6 Relay Agent can detect this and send RELAY-RECONFIG message to the DHCPv6 Server indicating that the host needs to be provided with "normal" DNS Server followed by DNS64 server.
4. Dual-Stack to IPv4-only In case a host is dual-stack, it is provided with "normal" DNS followed by DNS64 server. When transitioning to IPv4-only, no change is required because the host continues to use "normal" server.

4. Protocol overview

To realize the mechanism described above, this document extends the DHCPv6 protocol allowing the DHCPv6 relay-agent to inform DHCPv6 server to initiate a reconfigure message with the client, resulting in the client to initiate Renew/Reply or information-request/Reply transaction with the server to receive updated/new configuration information.

DHCPv6 Client        DHCPv6 Relay Agent           DHCPv6 Server
      |                    |                              |
      |                    |----------------------------->|
      |                    |  DHCPv6 Relay-supplied       |
      |                    |   Reconfigure message        |
      |                    |                              |
      |                    |                              |
      |<--------------------------------------------------|
      |                    | DHCPv6 Reconfigure           |
      |                    |                              |
      |--------------------|----------------------------->|                         
      |           DHCPv6 Information-request              |
      |                    |                              |
      |<--------------------------------------------------|
      |              DHCPv6 Reply                         |
      |                    |                              |

4.1. Message

The RELAY-RECONFIG message uses the Client/Server message formats described in [RFC3315], section 6.

RELAY-RECONFIG - A Relay Agent sends a RELAY-RECONFIG message to DHCPv6 server so that server can update configuration information based on the details in the Relay Reconfigure option. DHCPv6 server will subsequently initiate Reconfigure message with the client to propagate the new configuration information.

4.2. Relay Reconfigure option

The Relay Reconfigure option is used only in a RELAY-RECONFIG message and identifies the query being performed. The option includes the reconf-type, client-key and option(s) to provide data needed for the DHCPv6 server to initiate Reconfigure message with the client.

The Relay Reconfigure option is defined below:

 0                   1                   2                     3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  OPTION_RELAY_RECONF          | option-len                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reconf-type   |  client-key   |        Reserved               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                  client-key-options                           .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Info-flags |              Reserved1                        |
-----------------------------------------------------------------

option-len:

Length of the option.

reconf-type:

5 for Renew message, 11 for Information-request message.

client-key:

8-bit unsigned integer. The client-key indicates the key to identify the client.

client-key-options:

8-bit unsigned integer. This option can contain either OPTION_IAADDR or OPTION_CLIENTID. The server identifies the client either using IPv6 address assigned to the client using OPTION_IAADDR option or using DHCP Unique Identifier (DUID) of the client in OPTION_CLIENTID option [RFC3315].

client-key values are defined below -

+------+--------------------------------
|Value | Name                          |
+------+--------------------------------
| 0x01 | IDENTIFY_CLIENT_BY_ADDRESS    |
| 0x02 | IDENTIFY_CLIENT_BY_CLIENTID   | 
+------+--------------------------------

Info-flag values are defined below -

+------+--------------------------------
|Value | Name                          |
+------+--------------------------------
| 0x01 | IPV6_DNS64_SERV_ONLY          |
| 0x02 | IPV6_HIG_PROI_NORM_SERV       | 
+------+--------------------------------

1 :

IPV6_DNS64_DNS_SERV_ONLY Provide only DNS64 address list to the client.

2 :

IPV6_HIG_PROI_NORM_SERV Provide DNS address list in this order to the client - first "normal" DNS servers, second DNS64 servers.

5. DHCPv6 Relay Agent Behaviour

Relay Agent and clients MUST discard any received RELAY-RECONFIG messages. DHCPv6 relay agents that implement this specification MUST be configurable for sending the RELAY-RECONFIG message. Relay agents SHOULD have separate configuration for client-key in OPTION_RELAY_RECONF option . The Relay Agent sets the "msg-type" field to RELAY-RECONFIG. The Relay Agent generates a transaction ID and inserts this value in the "transaction-id" field. The Relay Agent MUST include OPTION_RELAY_RECONF option and set the reconf-type, client-key, client-key-options accordingly. The Relay Agent detects host characteristics using mechanisms discussed in Section 7. For host transition from IPv6-only to dual-Stack or IPv4-only to dual-stack Relay Agent will set Info-flags with IPV6_HIG_PROI_NORM_SERV and for host transition from dual-stack to IPv6 only Relay-Agent will set Info-flags with IPV6_DNS64_SERV_ONLY. The Relay Reconfigure option is a general and extendable frame work such that in future based on changes to host/network characteristics, Relay agent can dynamically inform the DHCPv6 server to update the host with other configuration information.

6. DHCPv6 Server Behaviour

Servers MUST discard any received RELAY-RECONFIG messages that meet any of the following conditions :

• the message does not include OPTION_RELAY_RECONF option.
• DUID or IPv6 address in client-key-options does not match server binding to identify the client.

Client will have to indicate with a Reconfigure Accept option in the Solicit message that it will accept the Reconfigure message. Server can have administrative policy that it will only respond to a client willing to accept a Reconfigure message. If the client does not indicate that it will accept Reconfigure message in the Solicit message then the server will discard the Solicit Message.

Upon receiving RELAY-RECONFIG message containing the Relay Reconfigure Option, the DHCPv6 server processing is described below depending on the Info-flag values:

[RFC3315], section 19.1 to create and send Reconfigure message.

• IPV6_DNS64_SERV_ONLY The DHCPv6 server will select only IPv6 addresses list of DNS64 recursive name servers to be sent to the client. The DHCPv6 server would send Reconfigure message to inform the client that the server has updated configuration information and then the client would initiate Information-request/replay transaction with the server. The updated configuration will now be sent as part of Information-request reply by the DHCPv6 server.
• IPV6_HIG_PROI_NORM_SERV The DHCPv6 server will select DNS servers in this order, first is the normal DNS servers and the second is the DNS64 servers. The DHCPv6 server would send Reconfigure message to the client to inform the client that the server has updated configuration information and then the client would initiate Information-request/replay transaction with the server. The updated configuration will now be sent as part of Information-request reply by the DHCPv6 server. The order of DNS servers provided by option OPTION_DNS_SERVERS determines the preference for use by the DNS client resolver [RFC3646] thus ensuring higher priority for normal DNS server list followed by DNS64 servers.

DHCPv6 server will use mechanism described

7. Host Tracking

Relay Agents can actively keep track of all IPv4/IPv6 addresses and associated lease times assigned to hosts via the respective DHCP servers. This enables Relay Agents to detect transitions from single to dual-stack and vice-versa efficiently. In addition to this technique, which is to be primarily used, transitions can also be detected using snooping mechanisms. Network devices today use mechanisms such as ARP and NDP snooping to determine host characteristics such as IPv4/IPv6 - MAC bindings. IPv4/IPv6 and MAC counters are also used to determine host liveliness. These mechanisms help determine if a particular IP is inactive. Relay Agents can leverage these to potentially detect IP address inactivity to determine if a particular host has reverted to using a single stack even though it initially had dual-stack capabilities. Similarly, it can also detect active dual-stack usage after long periods of single-stack activity.

8. Security Considerations

The RELAY-RECONFIG is exchanged only between the DHCPv6 relay agent and DHCPv6 server, section 21.1 of [RFC3315] provides details on securing DHCPv6 messages sent between servers and relay agents. And section 23 of [RFC3315] provides general DHCPv6 security considerations.

9. IANA Considerations

IANA is requested to assign new DHCPv6 Message types to RELAY-RECONFIG from the msg-type space as defined in section "DHCP Message Types" of [RFC3315]. IANA is requested to assign new option codes to OPTION_RELAY_RECONF from the option-code space as defined in section "DHCPv6 Options" of [RFC3315].

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses