DHC Working Group M. Boucadair Internet-Draft France Telecom Intended status: Standards Track R. Maglione Expires: March 9, 2013 Telecom Italia September 5, 2012 Recommendation for Encoding IP Address and Name in DHCP Options draft-boucadair-dhc-address-name-encoding-00 Abstract This document aims at providing a recommendation for the design of future DHCP options when both IP Address and Name encoding are needed to be supported. This design reconciles the flexibility requirement from service providers and the DHC WG recommendation to avoid defining 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 March 9, 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 the Trust Legal Provisions and are provided without warranty as Boucadair & Maglione Expires March 9, 2013 [Page 1] Internet-Draft Name DHCP Option September 2012 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. An FQDN can be Resolved into an IP Address by the Client . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. A Server Can Resolve the FQDN . . . . . . . . . . . . . . . 4 2.3. IP Address Option Can Not meet Some Operational Needs . . . 4 2.4. DNS-based Load Balancing . . . . . . . . . . . . . . . . . 5 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Boucadair & Maglione Expires March 9, 2013 [Page 2] Internet-Draft Name DHCP Option September 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 a FQDN in the option if it is configured to do so. o A DHCP server can be configured to resolve the FQDN and inject the resolved IP address as IP literals in the option if it is configured to do so. o A DHCP server can be configured to inject an IP address in the option if it is configured to do so. o DHCP clients are designed 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 Name 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: whether use an FQDN or an IP address is deployment-specific. In the past, no objection was made against defining two options (or sub-options) to convey an IP Address and a Domain Name for the same service. A non-exhaustive list of these options include: [RFC3361], Boucadair & Maglione Expires March 9, 2013 [Page 3] Internet-Draft Name DHCP Option September 2012 [RFC3319], [RFC5678] and [RFC4280]. But recently, there were objections (relying on [I-D.ietf-dhc-option-guidelines]) against progressing some specification documents; as such those specification documents were updated to select only one scheme (IP Address or a Domain Name option) to convey in a DHCP option. That decision was convenient for providers planning to use a Domain Name but was not appropriate for those planning to use an IP Address. Criteria to select whether an IP Address or a Domain Name is to be supported, may depend 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. For both IP Address and Name, it is likely a cache to be maintained by the client. Means to flush out this cache are needed for both modes. 2.1. An FQDN can be Resolved into an IP Address by the Client As an FQDN can be resolved into one or a list of IP addresses, this may be 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.2. 2.2. A Server Can Resolve the FQDN An argument which was advanced in favor of supporting an IP Address option instead of a Domain Name is to configure the server to resolve first the configured Name and then return that IP Address in a dedicated option. This design has the advantage of not requiring name resolution capabilities nor induce extra delay to access the service at the client side. Nevertheless, it is not compliant with some operational modes such as the one discussed in Section 2.3. 2.3. IP Address Option Can Not meet Some Operational Needs Returning a Name 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. Boucadair & Maglione Expires March 9, 2013 [Page 4] Internet-Draft Name DHCP Option September 2012 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 network operated by dedicated teams. This two-levels redirection can not be met by an IP Address option. 2.4. DNS-based Load Balancing Some deployed services (e.g., SIP-based service offerings) relies on DNS to distribute customers among available service access nodes based on load-related considerations. In some SIP-based deployments, SIP user agents are provisioned with a FQDN of an SBS/P-CSCF. The FQDN is then resolved into an IP address based on the load of available SBCs/P-CSCFs. This allows for deterministic distribution of customers among available SBCs/P-CSCFs. Of course, the mode described in Section 2.2 can be adapted to interface with a DNS-based load-balancing engine. Nevertheless, doing so would have 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 For contexts where both an IP Address and a Name 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. Boucadair & Maglione Expires March 9, 2013 [Page 5] Internet-Draft Name DHCP Option September 2012 o A Name may be structured as DNS qualified name or be composed of strings such as can be passed to getaddrinfo (Section 6.1 of [RFC3493]), including address literals (both IPv4 and IPv6), etc. o The Name is encoded as string. o When several Names are included, a space character is used as separator. o The host embedding the DHCP client is responsible for recognizing whether this option contains a hostname (e.g., "myserver"), a FQDN (e.g., "myservice.example.com" or "myserver.local" ) or IPv4/v6 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). 4. IANA Considerations This document does not require any action from IANA. 5. Security Considerations This document does not define any architecture not protocol extension. 6. Acknowledgements TBC. 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. Boucadair & Maglione Expires March 9, 2013 [Page 6] Internet-Draft Name DHCP Option September 2012 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 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. Boucadair & Maglione Expires March 9, 2013 [Page 7] Internet-Draft Name DHCP Option September 2012 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 March 9, 2013 [Page 8]