idnits 2.17.00 (12 Aug 2021) /tmp/idnits13950/draft-boucadair-dhc-address-name-encoding-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 30, 2012) is 3452 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-dhc-option-guidelines has been published as RFC 7227 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track R. Maglione 5 Expires: June 3, 2013 Telecom Italia 6 November 30, 2012 8 Recommendation for Encoding IP Address and FQDN in DHCP Options 9 draft-boucadair-dhc-address-name-encoding-03 11 Abstract 13 This document aims at providing a recommendation for the design of 14 future DHCP options when both IP Address and FQDN encoding are needed 15 to be supported. This design reconciles the flexibility requirement 16 from service providers and the DHC WG recommendation to avoid 17 defining multiple options conveying similar set of configuration 18 data. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 3, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 56 2. Problem: IP Address or FQDN Dilemma . . . . . . . . . . . . . . 3 57 2.1. Arguments in Favor of IP Address Option . . . . . . . . . . 4 58 2.1.1. A Server Can Resolve the FQDN . . . . . . . . . . . . . 4 59 2.1.2. A Client May Not Embed a DNS Resolver . . . . . . . . . 4 60 2.2. Arguments in Favor of FQDN Option . . . . . . . . . . . . . 4 61 2.2.1. FQDN can be Resolved into an IP Address by the 62 Client . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.2. Some Operational Needs . . . . . . . . . . . . . . . . 5 64 2.2.3. DNS-based Load Balancing . . . . . . . . . . . . . . . 5 65 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Within this document DHCP is used to denote both DHCPv4 [RFC2131] and 77 DHCPv6 [RFC3315]. 79 This document sketches a recommendation which aims to reconcile both 80 what is discussed in Section 7 of [I-D.ietf-dhc-option-guidelines] 81 and also the requirements of operators in some specific contexts. 82 The proposed approach adopts a simple encoding which achieves the 83 following goals: 85 o A DHCP server can be configured to inject one or multiple FQDNs in 86 the option. 87 o A DHCP server can be configured to inject one or multiple IP 88 addresses in the option 89 o A DHCP server can be configured to resolve the FQDN and inject the 90 resolved IP address(es) as IP literals in the option. 91 o A DHCP server can convey in one single option both IPv4 and IPv6 92 address literals when serving dual-stack clients. 93 o A DHCP server can convey a hostname or any name which may be 94 passed to a name resolution library. 95 o DHCP clients are expected to pass the conveyed string to any 96 supported name resolution library (DNS is only a name resolution 97 service among others). 99 This document is mainly motivated by the discussions which have been 100 taken place during the production process of [RFC6334] and recently 101 within PCP working group. For more details, readers are invited to 102 check softwire and pcp mailing list archives. 104 Section 2 provides a reminder of the issue. A recommendation is 105 proposed in Section 3. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Problem: IP Address or FQDN Dilemma 115 The support of both IP Address and FQDN option allows for better 116 flexibility for service providers which are free to make their own 117 engineering choices and use the convenient option according to their 118 deployment context: Return an FQDN or an IP address in DHCP is 119 deployment-specific. 121 In the past, no objection was made against defining two options (or 122 sub-options) to convey an IP Address and a FQDN for the same service. 123 A non-exhaustive list of these options include: [RFC3361], [RFC3319], 124 [RFC5678] and [RFC4280]. But recently, there were objections 125 (relying on [I-D.ietf-dhc-option-guidelines]) against progressing 126 some specification documents (e.g., [RFC6334]); as such those 127 specification documents were updated to select only one scheme (IP 128 Address or a FQDN option) to convey in a DHCP option. That decision 129 was convenient for providers planning to use a FQDN but was not 130 appropriate for those planning to use an IP Address. 132 For both IP Address and FQDN, it is likely a cache to be maintained 133 by the client. Means to flush out this cache are needed for both 134 modes. 136 Criteria to support an IP Address or a FQDN depends on each 137 deployment context, operational considerations and also whether some 138 advanced features are supported by the DHCP server or by the host 139 embedding the client. More discussion is provided in the following 140 sub-sections. 142 2.1. Arguments in Favor of IP Address Option 144 2.1.1. A Server Can Resolve the FQDN 146 An argument which was advanced in favor of supporting an IP Address 147 option instead of a FQDN is the server can be configured to resolve 148 first the configured FQDN and then return the resolved IP Address in 149 a dedicated option. 151 This design has the advantage to not require name resolution 152 capabilities at the client side. Nevertheless, it is not compliant 153 with some operational modes such as the one discussed in 154 Section 2.2.2. 156 2.1.2. A Client May Not Embed a DNS Resolver 158 Returning an IP address does not require the client to embed a DNS 159 resolver. 161 This argument may be objected as implementing a DNS resolver is 162 claimed to be cheap and devices which don't embed DNS resolver are 163 uncommon. 165 2.2. Arguments in Favor of FQDN Option 166 2.2.1. FQDN can be Resolved into an IP Address by the Client 168 Because an FQDN can be resolved into one or a list of IP addresses, 169 this is presented as an argument to encourage defining exclusively a 170 FQDN option. 172 This alternative does require the host embedding the client to enable 173 name resolution capabilities. This argument might be objected as 174 discussed in Section 2.1.1. 176 2.2.2. Some Operational Needs 178 Returning a FQDN option is more convenient in some deployment 179 contexts. This is motivated by operational considerations such as a 180 Service Provider considering two levels of redirection: 182 (1) The first level is national-wise and undertaken by DHCP: a 183 regional-specific Name will be returned; 184 (2) The second level is done during the resolution of the regional- 185 specific Name to redirect the customer to a regional 186 server/service among a pool deployed regionally. 188 Distinct operational teams are responsible for each of the above 189 mentioned levels. A clear separation between the functional 190 perimeter of each team is a sensitive task for the maintenance of the 191 offered services. 193 Regional teams will require to introduce new resources to meet an 194 increase of customer base. Operations related to the introduction of 195 these new devices (e.g., addressing, redirection, etc.) are 196 implemented locally. Having this regional separation provides 197 flexibility to manage portions of a network operated by dedicated 198 teams. 200 This two-levels redirection can not be met by an IP Address option. 202 2.2.3. DNS-based Load Balancing 204 Some deployed services relies on DNS to distribute customers among 205 available service access nodes based on load-related considerations. 206 FQDN is provisioned to requesting clients. This FQDN is then 207 resolved into an IP address based on the load of available service 208 access nodes. This allows for deterministic distribution of 209 customers among available service access nodes. 211 The mode described in Section 2.1.1 can be adapted to interface with 212 a DNS-based load-balancing engine. Nevertheless, doing so would have 213 some impacts if the node selection is deployed at regional level 214 (e.g., a cluster of nodes is deployed in a regional PoP without 215 requiring a central entity to enforce node selection based on the 216 load of each regional cluster). For such deployment scenario, it 217 might be more simpler to enforce load-based node selection policies 218 at the regional level. 220 Requiring the DHCP server to interface with a DNS-based load 221 distributing engine may not be acceptable for operators separating 222 the delivery of (basic) network connectivity from service-related 223 provisioning. 225 3. Recommendation 227 Section 2 identifies the arguments which are advanced in favor of 228 defining options to convey an IP address while other arguments are 229 also advanced to motivate the need for defining options to convey 230 FQDN. These arguments are mainly deployment-specific. To 231 accommodate the requirements of both the proponents of defining an IP 232 Address option and FQDN option while considering the issues raised in 233 [I-D.ietf-dhc-option-guidelines], an encoding recommendation is 234 proposed in this section. 236 New DHCP options SHOULD use either an IP-Address or FQDN encoding for 237 the data. If there is a strong requirement to support both an IP- 238 Address and FQDN encoding, the option specification MUST use the 239 encoding specified in this document and MUST provide the rationale to 240 motivate why either an IP-Address or FQDN encoding is insufficient. 242 This document defines one single option which is characterized as 243 follows: 245 o The option is designed to convey a Name. 246 o The Name MUST be encoded as UTF-8 string [RFC3629]. 247 o The Name MUST be a string that can be passed to getaddrinfo 248 (Section 6.1 of [RFC3493]), such as a DNS name, address literals, 249 etc. 250 o The Name MUST NOT contain spaces or nulls. 251 o Multiple Names MAY be included in the same option. 252 o The Name is length-encoded. 253 o The DHCP client decoding an option in this format MUST validate 254 the contents of the option. If the contents are not valid, the 255 DHCP client MUST silently ignore the option. The DHCP client MUST 256 NOT attempt to process an invalid option of this type for reasons 257 of compatibility with non-conforming implementations, or for any 258 other reason. A Name is considered as valid if: 260 * It is a legal UTF-8 string which does not contain any spaces 261 nor nulls. 262 * It contains IPv4 address in dotted-decimal form (e.g., 263 192.0.2.33), textual representation of an IPv6 address (e.g., 264 2001:db8::1) [RFC4291] [RFC5952] or a domain name (e.g., 265 "myservice.example.com")[RFC2181]. Note: 266 + The trailing dot is optional when a domain name is conveyed 267 in the option. 268 + IPv6 addresses MUST NOT be enclosed in brackets. 269 + A domain name is structured as one or more labels 270 concatenated with dots. A label MUST NOT be no more than 63 271 characters. 272 o Each validated Name is passed to the name resolution library 273 (e.g., Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the 274 corresponding IP address(es) (IPv4, IPv6 or both). 276 [[Discussion Note: Should we restrict this the proposed approach to 277 DHCPv6?]] 279 4. IANA Considerations 281 This document does not require any action from IANA. 283 5. Security Considerations 285 This document does not define any architecture nor protocol 286 extension. 288 6. Acknowledgements 290 Many thanks to T. Tsou, Y. Lee, T. Mrugalski, T. Lemon, B. Voltz, B. 291 Millwood, S. Carlsen, D. Mayer and S. Jacob for their comments. 293 7. References 295 7.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 301 RFC 2131, March 1997. 303 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 304 Specification", RFC 2181, July 1997. 306 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 307 and M. Carney, "Dynamic Host Configuration Protocol for 308 IPv6 (DHCPv6)", RFC 3315, July 2003. 310 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 311 10646", STD 63, RFC 3629, November 2003. 313 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 314 Architecture", RFC 4291, February 2006. 316 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 317 Address Text Representation", RFC 5952, August 2010. 319 7.2. Informative References 321 [I-D.ietf-dhc-option-guidelines] 322 Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 323 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 324 draft-ietf-dhc-option-guidelines-08 (work in progress), 325 June 2012. 327 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 328 and Support", STD 3, RFC 1123, October 1989. 330 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 331 Protocol (DHCPv6) Options for Session Initiation Protocol 332 (SIP) Servers", RFC 3319, July 2003. 334 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 335 (DHCP-for-IPv4) Option for Session Initiation Protocol 336 (SIP) Servers", RFC 3361, August 2002. 338 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 339 Stevens, "Basic Socket Interface Extensions for IPv6", 340 RFC 3493, February 2003. 342 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host 343 Configuration Protocol (DHCP) Options for Broadcast and 344 Multicast Control Servers", RFC 4280, November 2005. 346 [RFC5678] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol 347 (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility 348 Services (MoS) Discovery", RFC 5678, December 2009. 350 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 351 Encodings for Internationalized Domain Names", RFC 6055, 352 February 2011. 354 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 355 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 356 RFC 6334, August 2011. 358 Authors' Addresses 360 Mohamed Boucadair 361 France Telecom 362 Rennes, 35000 363 France 365 Email: mohamed.boucadair@orange.com 367 Roberta Maglione 368 Telecom Italia 369 Via Reiss Romoli 274 370 Torino, 10148 371 Italy 373 Email: roberta.maglione@telecomitalia.it