BEHAVE Working Group D. Wing
Internet-Draft T. Reddy
Intended status: Standards Track P. Patil
Expires: April 18, 2012 Cisco
October 16, 2011
DHCPv6 Dynamic Re-Configuration
draft-wing-behave-dhcpv6-reconfigure-00
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 April 18, 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
Wing, et al. Expires April 18, 2012 [Page 1]
Internet-Draft dhcpv6_dynamic_reconfig October 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Message . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Relay Reconfigure option . . . . . . . . . . . . . . . . . 5
5. DHCPv6 Relay Agent Behaviour . . . . . . . . . . . . . . . . . 7
6. DHCPv6 Server Behaviour . . . . . . . . . . . . . . . . . . . 7
7. Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Wing, et al. Expires April 18, 2012 [Page 2]
Internet-Draft dhcpv6_dynamic_reconfig October 2011
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, roughly the same
inefficiency occurs (i.e., NAT state is created). However, it is
generally considered better to perform NAT44 than NAT64, because
NAT64 breaks at least one application when translated between IP
address families unless special measures are taken
[I-D.ietf-behave-ftp64]. To avoid this, the priority of "normal" DNS
server should be set above DNS64 server so that IPv4 is preferred
over the IPv6/IPv4 translator prefix. At the same time, native IPv6
can still be preferred over IPv4. The DHCPv6 Relay Agent can observe
host characteristics on a network using well known snooping
mechanisms Section 7 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
Wing, et al. Expires April 18, 2012 [Page 3]
Internet-Draft dhcpv6_dynamic_reconfig October 2011
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. Without this,
nothing automatically causes the host to start querying the
"normal" DNS server. Thus, a host that transitions from IPv6-
only to dual-stack will always use IPv6 until the host's 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.
Wing, et al. Expires April 18, 2012 [Page 4]
Internet-Draft dhcpv6_dynamic_reconfig October 2011
DHCPv6 Client DHCPv6 Relay Agent DHCPv6 Server
| | |
| |----------------------------->|
| | DHCPv6 Relay-supplied |
| | Reconfigure message |
| | |
| | |
|<--------------------------------------------------|
| | DHCPv6 Reconfigure |
| | |
|--------------------|----------------------------->|
| DHCPv6 Information-request |
| | |
|<--------------------------------------------------|
| DHCPv6 Reply |
| | |
Figure 1: Message Flow
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:
Wing, et al. Expires April 18, 2012 [Page 5]
Internet-Draft dhcpv6_dynamic_reconfig October 2011
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 |
-----------------------------------------------------------------
Figure 2: Relay Reconfigure option message format
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 |
+------+--------------------------------
Figure 3: client-key values
Info-flag values are defined below -
Wing, et al. Expires April 18, 2012 [Page 6]
Internet-Draft dhcpv6_dynamic_reconfig October 2011
+------+--------------------------------
|Value | Name |
+------+--------------------------------
| 0x01 | IPV6_DNS64_SERV_ONLY |
| 0x02 | IPV6_HIG_PROI_NORM_SERV |
+------+--------------------------------
Figure 4: Info-flag values
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 change using snooping mechanisms
Section 7. For host transition from IPv6-only to Dual-Stack/
IPv4-only to Dual 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 :
o the message does not include OPTION_RELAY_RECONF option.
o DUID or IPv6 address in client-key-options does not match server
binding to identify the client.
Wing, et al. Expires April 18, 2012 [Page 7]
Internet-Draft dhcpv6_dynamic_reconfig October 2011
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:
o *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.
o *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 [RFC3315], section 19.1 to
create and send Reconfigure message.
7. Snooping
Network devices today use mechanisms such as snooping to determine
host characteristics such as IPv4/IPv6 - MAC bindings. ARP and NDP
snooping mechanisms are used for these purposes. IPv4/IPv6 and MAC
counters are also used to determine host liveliness. In addition to
DHCPv4/DHCPv6 bindings that are available to Relay Agents, Relay
Agents on network devices can use information gleaned from these
mechanisms to determine if there are transitions from single to dual-
stack and vice versa.
Wing, et al. Expires April 18, 2012 [Page 8]
Internet-Draft dhcpv6_dynamic_reconfig October 2011
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
[I-D.ietf-6man-addr-select-opt]
Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
"Distributing Address Selection Policy using DHCPv6",
draft-ietf-6man-addr-select-opt-01 (work in progress),
June 2011.
[I-D.ietf-behave-ftp64]
Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation",
draft-ietf-behave-ftp64-12 (work in progress), July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007.
Wing, et al. Expires April 18, 2012 [Page 9]
Internet-Draft dhcpv6_dynamic_reconfig October 2011
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.
10.2. Informative References
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Authors' Addresses
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Prashanth Patil
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marthalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: praspati@cisco.com
Wing, et al. Expires April 18, 2012 [Page 10]