Skip to main content

Recommendation for Encoding IP Address and Name in DHCP Options
draft-boucadair-dhc-address-name-encoding-00

The information below is for an old version of the document.
Document Type Active Internet-Draft (individual)
Authors Mohamed Boucadair , Roberta Maglione
Last updated 2012-09-05
Stream (None)
Formats plain text htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-boucadair-dhc-address-name-encoding-00
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]