DHC Working Group D. Wing Internet-Draft T. Reddy Intended status: Standards Track P. Patil Expires: October 07, 2013 Cisco M. Boucadair France Telecom April 05, 2013 DHCPv6 Dynamic DNS Reconfiguration draft-wing-dhc-dns-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 October 07, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Wing, et al. Expires October 07, 2013 [Page 1] Internet-Draft dynamic_dhc_dns_reconfig April 2013 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. DNS_RECONFIG option . . . . . . . . . . . . . . . . . . . . . 4 5. DHCPv6 Relay Agent Behaviour . . . . . . . . . . . . . . . . 4 6. DHCPv6 Server Behaviour . . . . . . . . . . . . . . . . . . . 5 7. Host Tracking . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The default address selection rules [RFC6724] prefers IPv6 over IPv4. If a dual-stack host is configured to use a DNS64 server [RFC6147], 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 [RFC6146] are deployed on the same network, it is preferable to use NAT44 over NAT64 for various reasons such as application incompatibility issues (e.g., FTP) [RFC6384] or for NAT dimensioning considerations. 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. The DHCPv6 Relay Agent can also be controlled by an external entity (e.g., RADIUS server) about the connectivity type of a given connected host. This document proposes 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. Wing, et al. Expires October 07, 2013 [Page 2] Internet-Draft dynamic_dhc_dns_reconfig April 2013 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]. DNS64 server denotes a DNS server using an IPv6 address and synthesizes AAAA records from A records [RFC6147] 3. Mechanism This document describes a new DHCPv6 Option that can be used along with the DHCPv6 RECONFIGURE_REQUEST [I-D.ietf-dhc-triggered-reconfigure] by the DHCPv6 Relay Agent to indicate to the DHCPv6 Server 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 with a DNS64 Server. When transitioning to dual-stack, an IPv4 DNS Server is assigned as a consequence of obtaining an IPv4 Address. The DHCPv6 Relay Agent can detect this and send a RECONFIGURE_REQUEST message to the DHCPv6 Server indicating that the host needs to be provided with a regular 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 a regular DNS server followed by DNS64 server. When transitioning to IPv6-only, the DHCPv6 Relay Agent can detect this and send a RECONFIGURE_REQUEST 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 regular 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. Dual-stack to IPv4-only: In case a host is dual-stack, it is provided with a regular DNS server followed by DNS64 server. When transitioning to IPv4-only, no change is required because the host continues to use regular DNS server. Wing, et al. Expires October 07, 2013 [Page 3] Internet-Draft dynamic_dhc_dns_reconfig April 2013 4. DNS_RECONFIG option The DNS_RECONFIG option is to be used only in a RECONFIGURE_REQUEST message and identifies the query being performed. The option includes a flag that determines the DNS server list to be provided by the DHCPv6 server to the respective client. The 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_DNS_RECONFIG | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Info-flags | Reserved1 | ----------------------------------------------------------------- Figure 1: DNS Reconfigure option message format Info-flag values are defined below - +------+-------------------------------- |Value | Name | +------+-------------------------------- | 0x01 | IPV6_DNS64_SERV_ONLY | | 0x02 | IPV6_HIG_PROI_NORM_SERV | +------+-------------------------------- Figure 2: Info-flag values IPV6_DNS64_SERV_ONLY: Provide only DNS64 address list to the client. IPV6_DNS64_SERV_ONLY: Provide DNS address list in this order to the client - first regular DNS servers, second DNS64 servers. 5. DHCPv6 Relay Agent Behaviour DHCPv6 relay agents that implement this specification MUST be configurable for sending the RECONFIGURE_REQUEST message. The Relay Agent MUST set the "msg-type" field to RECONFIGURE_REQUEST. 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 content of OPTION_DNS_RECONFIG MAY also be tweaked by an external entity. Wing, et al. Expires October 07, 2013 [Page 4] Internet-Draft dynamic_dhc_dns_reconfig April 2013 6. DHCPv6 Server Behaviour Upon receiving RECONFIGURE_REQUEST message containing the DNS_RECONFIG 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 regular 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 regular DNS server list followed by DNS64 servers. DHCPv6 server will follow the mechanism described [I-D.ietf-dhc-triggered-reconfigure] to create and send Reconfigure message. 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. Wing, et al. Expires October 07, 2013 [Page 5] Internet-Draft dynamic_dhc_dns_reconfig April 2013 8. Security Considerations Security considerations described in [I-D.ietf-dhc-triggered-reconfigure]are applicable to this mechanism. 9. IANA Considerations IANA is requested to assign new option codes for OPTION_DNS_RECONFIG from the option-code space as defined in section "DHCPv6 Options" of [RFC3315]. 10. References 10.1. Normative References [I-D.ietf-dhc-triggered-reconfigure] Boucadair, M. and X. Pougnard, "Reconfigure Triggered by DHCPv6 Relay Agents", draft-ietf-dhc-triggered- reconfigure-05 (work in progress), March 2013. [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. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [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. [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011. Wing, et al. Expires October 07, 2013 [Page 6] Internet-Draft dynamic_dhc_dns_reconfig April 2013 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. 10.2. Informative References [I-D.wing-behave-dns64-config] Wing, D., "IPv6-only and Dual Stack Hosts on the Same Network with DNS64", draft-wing-behave-dns64-config-03 (work in progress), February 2011. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007. 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. Bangalore India Email: praspati@cisco.com Wing, et al. Expires October 07, 2013 [Page 7] Internet-Draft dynamic_dhc_dns_reconfig April 2013 Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Wing, et al. Expires October 07, 2013 [Page 8]