DHC Working Group M. Boucadair Internet-Draft France Telecom Intended status: Standards Track R. Maglione Expires: May 17, 2013 Telecom Italia November 13, 2012 Recommendation for Encoding IP Address and FQDN in DHCP Options draft-boucadair-dhc-address-name-encoding-02 Abstract This document aims at providing a recommendation for the design of future DHCP options when both IP Address and FQDN encoding are needed to be supported. This design reconciles the flexibility requirement from service providers and the DHC WG recommendation to avoid defining multiple options conveying similar set of configuration data. 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 17, 2013. Copyright Notice Copyright (c) 2012 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 Boucadair & Maglione Expires May 17, 2013 [Page 1] Internet-Draft Name DHCP Option November 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Problem: IP Address or FQDN Dilemma . . . . . . . . . . . . . . 3 2.1. Arguments in Favor of IP Address Option . . . . . . . . . . 4 2.1.1. A Server Can Resolve the FQDN . . . . . . . . . . . . . 4 2.1.2. A Client May Not Embed a DNS Resolver . . . . . . . . . 4 2.2. Arguments in Favor of FQDN Option . . . . . . . . . . . . . 4 2.2.1. FQDN can be Resolved into an IP Address by the Client . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Some Operational Needs . . . . . . . . . . . . . . . . 5 2.2.3. DNS-based Load Balancing . . . . . . . . . . . . . . . 5 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Boucadair & Maglione Expires May 17, 2013 [Page 2] Internet-Draft Name DHCP Option November 2012 1. Introduction Within this document DHCP is used to denote both DHCPv4 [RFC2131] and DHCPv6 [RFC3315]. This document sketches a recommendation which aims to reconcile both what is discussed in Section 7 of [I-D.ietf-dhc-option-guidelines] and also the requirements of operators in some specific contexts. The proposed approach adopts a simple encoding which achieves the following goals: o A DHCP server can be configured to inject one or multiple FQDNs in the option. o A DHCP server can be configured to inject one or multiple IP addresses in the option o A DHCP server can be configured to resolve the FQDN and inject the resolved IP address(es) as IP literals in the option. o A DHCP server can convey in one single option both IPv4 and IPv6 address literals when serving dual-stack clients. o A DHCP server can convey a hostname or any name which may be passed to a name resolution library. o DHCP clients are expected to pass the conveyed string to any supported name resolution library (DNS is only a name resolution service among others). This document is mainly motivated by the discussions which have been taken place during the production process of [RFC6334] and recently within PCP working group. For more details, readers are invited to check softwire and pcp mailing list archives. Section 2 provides a reminder of the issue. A recommendation is proposed in Section 3. 1.1. Requirements Language 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]. 2. Problem: IP Address or FQDN Dilemma The support of both IP Address and FQDN option allows for better flexibility for service providers which are free to make their own engineering choices and use the convenient option according to their deployment context: Return an FQDN or an IP address in DHCP is deployment-specific. Boucadair & Maglione Expires May 17, 2013 [Page 3] Internet-Draft Name DHCP Option November 2012 In the past, no objection was made against defining two options (or sub-options) to convey an IP Address and a FQDN for the same service. A non-exhaustive list of these options include: [RFC3361], [RFC3319], [RFC5678] and [RFC4280]. But recently, there were objections (relying on [I-D.ietf-dhc-option-guidelines]) against progressing some specification documents (e.g., [RFC6334]); as such those specification documents were updated to select only one scheme (IP Address or a FQDN option) to convey in a DHCP option. That decision was convenient for providers planning to use a FQDN but was not appropriate for those planning to use an IP Address. For both IP Address and FQDN, it is likely a cache to be maintained by the client. Means to flush out this cache are needed for both modes. Criteria to support an IP Address or a FQDN depends on each deployment context, operational considerations and also whether some advanced features are supported by the DHCP server or by the host embedding the client. More discussion is provided in the following sub-sections. 2.1. Arguments in Favor of IP Address Option 2.1.1. A Server Can Resolve the FQDN An argument which was advanced in favor of supporting an IP Address option instead of a FQDN is the server can be configured to resolve first the configured FQDN and then return the resolved IP Address in a dedicated option. This design has the advantage to not require name resolution capabilities at the client side. Nevertheless, it is not compliant with some operational modes such as the one discussed in Section 2.2.2. 2.1.2. A Client May Not Embed a DNS Resolver Returning an IP address does not require the client to embed a DNS resolver. This argument may be objected as implementing a DNS resolver is claimed to be cheap and devices which don't embed DNS resolver are uncommon. 2.2. Arguments in Favor of FQDN Option Boucadair & Maglione Expires May 17, 2013 [Page 4] Internet-Draft Name DHCP Option November 2012 2.2.1. FQDN can be Resolved into an IP Address by the Client Because an FQDN can be resolved into one or a list of IP addresses, this is presented as an argument to encourage defining exclusively a FQDN option. This alternative does require the host embedding the client to enable name resolution capabilities. This argument might be objected as discussed in Section 2.1.1. 2.2.2. Some Operational Needs Returning a FQDN option is more convenient in some deployment contexts. This is motivated by operational considerations such as a Service Provider considering two levels of redirection: (1) The first level is national-wise and undertaken by DHCP: a regional-specific Name will be returned; (2) The second level is done during the resolution of the regional- specific Name to redirect the customer to a regional server/service among a pool deployed regionally. Distinct operational teams are responsible for each of the above mentioned levels. A clear separation between the functional perimeter of each team is a sensitive task for the maintenance of the offered services. Regional teams will require to introduce new resources to meet an increase of customer base. Operations related to the introduction of these new devices (e.g., addressing, redirection, etc.) are implemented locally. Having this regional separation provides flexibility to manage portions of a network operated by dedicated teams. This two-levels redirection can not be met by an IP Address option. 2.2.3. DNS-based Load Balancing Some deployed services relies on DNS to distribute customers among available service access nodes based on load-related considerations. FQDN is provisioned to requesting clients. This FQDN is then resolved into an IP address based on the load of available service access nodes. This allows for deterministic distribution of customers among available service access nodes. The mode described in Section 2.1.1 can be adapted to interface with a DNS-based load-balancing engine. Nevertheless, doing so would have Boucadair & Maglione Expires May 17, 2013 [Page 5] Internet-Draft Name DHCP Option November 2012 some impacts if the node selection is deployed at regional level (e.g., a cluster of nodes is deployed in a regional PoP without requiring a central entity to enforce node selection based on the load of each regional cluster). For such deployment scenario, it might be more simpler to enforce load-based node selection policies at the regional level. Requiring the DHCP server to interface with a DNS-based load distributing engine may not be acceptable for operators separating the delivery of (basic) network connectivity from service-related provisioning. 3. Recommendation Section 2 identifies the arguments which are advanced in favor of defining options to convey an IP address while other arguments are also advanced to motivate the need for defining options to convey FQDN. These arguments are mainly deployment-specific. To accommodate the requirements of both the proponents of defining an IP Address option and FQDN option while considering the issues raised in [I-D.ietf-dhc-option-guidelines], an encoding recommendation is proposed in this section. For contexts where both an IP Address and a FQDN should be supported in DHCP, it is RECOMMENDED to define one single option which is characterized as follows: o The option is designed to convey a Name. o The Name MUST be encoded as UTF-8 string [RFC3629]. o The Name MUST be a string that can be passed to getaddrinfo (Section 6.1 of [RFC3493]), such as a DNS name, address literals, etc. A name may be a fully qualified domain name (e.g., "myservice.example.com."), IPv4 address in dotted-decimal form (e.g., 192.0.2.33) or textual representation of an IPv6 address (e.g., 2001:db8::1) [RFC5952]. o The Name MUST NOT contain spaces or nulls. o Multiple Names MAY be included in the same option. o The Name is length-encoded. o The host embedding the DHCP client is responsible for recognizing whether this option contains a hostname (e.g., "myserver"), a domain name (e.g., "myservice.example.com" or "myserver.local" ) or IPv4/IPv6 address literals. o Each configured Name is passed to the name resolution library (e.g., Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the corresponding IP address(es) (IPv4, IPv6 or both). Boucadair & Maglione Expires May 17, 2013 [Page 6] Internet-Draft Name DHCP Option November 2012 4. IANA Considerations This document does not require any action from IANA. 5. Security Considerations This document does not define any architecture nor protocol extension. 6. Acknowledgements Many thanks to T. Tsou, Y. Lee and T. Mrugalski for their comments. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 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. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. 7.2. Informative References [I-D.ietf-dhc-option-guidelines] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", draft-ietf-dhc-option-guidelines-08 (work in progress), June 2012. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Boucadair & Maglione Expires May 17, 2013 [Page 7] Internet-Draft Name DHCP Option November 2012 Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003. [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers", RFC 4280, November 2005. [RFC5678] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery", RFC 5678, December 2009. [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011. [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011. Authors' Addresses Mohamed Boucadair France Telecom Rennes, 35000 France Email: mohamed.boucadair@orange.com Roberta Maglione Telecom Italia Via Reiss Romoli 274 Torino, 10148 Italy Email: roberta.maglione@telecomitalia.it Boucadair & Maglione Expires May 17, 2013 [Page 8]