Internet DRAFT - draft-boucadair-dhc-address-name-encoding
draft-boucadair-dhc-address-name-encoding
DHC Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Standards Track R. Maglione
Expires: June 3, 2013 Telecom Italia
November 30, 2012
Recommendation for Encoding IP Address and FQDN in DHCP Options
draft-boucadair-dhc-address-name-encoding-03
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 June 3, 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
Boucadair & Maglione Expires June 3, 2013 [Page 1]
Internet-Draft Name DHCP Option November 2012
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
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 . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Boucadair & Maglione Expires June 3, 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 June 3, 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 June 3, 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 June 3, 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.
New DHCP options SHOULD use either an IP-Address or FQDN encoding for
the data. If there is a strong requirement to support both an IP-
Address and FQDN encoding, the option specification MUST use the
encoding specified in this document and MUST provide the rationale to
motivate why either an IP-Address or FQDN encoding is insufficient.
This document defines 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.
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 DHCP client decoding an option in this format MUST validate
the contents of the option. If the contents are not valid, the
DHCP client MUST silently ignore the option. The DHCP client MUST
NOT attempt to process an invalid option of this type for reasons
of compatibility with non-conforming implementations, or for any
other reason. A Name is considered as valid if:
Boucadair & Maglione Expires June 3, 2013 [Page 6]
Internet-Draft Name DHCP Option November 2012
* It is a legal UTF-8 string which does not contain any spaces
nor nulls.
* It contains IPv4 address in dotted-decimal form (e.g.,
192.0.2.33), textual representation of an IPv6 address (e.g.,
2001:db8::1) [RFC4291] [RFC5952] or a domain name (e.g.,
"myservice.example.com")[RFC2181]. Note:
+ The trailing dot is optional when a domain name is conveyed
in the option.
+ IPv6 addresses MUST NOT be enclosed in brackets.
+ A domain name is structured as one or more labels
concatenated with dots. A label MUST NOT be no more than 63
characters.
o Each validated 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).
[[Discussion Note: Should we restrict this the proposed approach to
DHCPv6?]]
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, T. Mrugalski, T. Lemon, B. Voltz, B.
Millwood, S. Carlsen, D. Mayer and S. Jacob 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.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Boucadair & Maglione Expires June 3, 2013 [Page 7]
Internet-Draft Name DHCP Option November 2012
Specification", RFC 2181, July 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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[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
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,
Boucadair & Maglione Expires June 3, 2013 [Page 8]
Internet-Draft Name DHCP Option November 2012
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 June 3, 2013 [Page 9]
