[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                 M. Smith
Internet-Draft                                                      IMOT
Updates: 6204 (if approved)                                July 30, 2013
Intended status: Standards Track
Expires: January 31, 2014


               IPv6 CE Device DHCPv6 Option Transparency
              draft-smith-v6ops-ce-dhcpv6-transparency-00

Abstract

   [RFC6204] defines basic requirements for IPv6 Customer Edge Routers,
   to suit residential or small office IPv6 deployments.  It describes a
   WAN interface DHCPv6 client and LAN interface DHCPv6 server
   implementation model.  This model constrains the set of DHCPv6
   options that can be conveyed between the upstream service provider
   and the hosts downstream of the CE device, to those supported by both
   the CE device's DHCPv6 client and server.  To support further current
   and future DHCPv6 options, this memo instead proposes a DHCPv6 option
   "transparent" implementation model for CE devices, primarily using
   DHCPv6 message relaying.

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 January 31, 2014.

Copyright Notice

   Copyright (c) 2013 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



Smith                   Expires January 31, 2014                [Page 1]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


   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
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Internet Transparency and Application Configuration . . . . .   4
   3.  LAN Interface(s) DHCPv6 Relay Agent . . . . . . . . . . . . .   5
   4.  LAN Interface(s) DHCPv6 Hybrid Server/Relay . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     5.1.  Client Information Disclosure . . . . . . . . . . . . . .   8
     5.2.  Additional State  . . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Change Log [RFC Editor please remove] . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [RFC6204] defines basic requirements for IPv6 Customer Edge Routers,
   to suit residential or small office IPv6 deployments.

   For these devices, the model of operation for DHCPv6 is to operate as
   a client on the CE device's WAN interface and as a server on the CE
   device's LAN interface(s).

   Operating as a client on the WAN interface, DHCPv6 is used for two
   purposes.  Firstly, the DHCPv6 client is used to acquire
   configuration parameters useful or necessary to the CE device itself.
   Examples of these parameters are an IPv6 address for the WAN
   interface, DNS server information, and Simple Network Time Server
   information.  Secondly, the DHCPv6 client is used to acquire
   configuration parameters that are either essential or useful for the
   operation of the downstream hosts, such as a delegated IPv6 prefix
   and DNS domain information.

   Operating as a server on the LAN interface(s), DHCPv6 is used for
   purposes such as stateful IPv6 address assignment (if supported by
   the CE device and requested by the hosts), providing hosts with DNS
   resolver and DNS domain information, and possibly being able to
   provide other DHCPv6 options such as SIP server addresses.



Smith                   Expires January 31, 2014                [Page 2]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


   This client and server model of operation of DHCPv6 on the CE device
   constrains the use of DHCPv6 options between the downstream host(s)
   and the upstream service provider.  The DHCPv6 options that a
   downstream host can request, and that an upstream service provider
   can supply, is limited to the set of options supported by both the CE
   device's WAN DHCPv6 client and LAN DHCPv6 server.  This set of
   supported DHCPv6 options is significantly limited compared to the
   current set of available DHCPv6 options [IANA-DHCPV6-OPTIONS].
   Additionally, it cannot accommodate DHCPv6 options that may be
   defined in the future.  This means the CE device is not DHCPv6 option
   "transparent".

   The main consequence of a lack of DHCPv6 option transparency is that
   users or operators of the hosts downstream of the CE device will have
   to resort to manual configuration of application and host parameters,
   for information that could be provided by the CE device's unsupported
   DHCPv6 options.  Manual configuration is time consuming, error prone,
   static, not scalable and most importantly, not user friendly.

   In markets where service provider customers can supply their own CE
   device, the CE device supported DHCPv6 options may vary significantly
   across the customers' devices.  This could create a perverse
   incentive for the service provider to not use DHCPv6 options at all,
   other than the minimum necessary, and instead have customers use
   manual configuration.  The motive to do so would be for the service
   provider to have a single and consistent method of configuration,
   simplifying customer fault troubleshooting, despite the other
   drawbacks of manual configuration described previously.  CE device
   DHCPv6 option transparency would avoid creating this incentive for
   manual configuration.

   A DHCPv6 Relay Agent [RFC3315] is DHCPv6 option transparent.  It does
   not constrain the set of options that can be used between a
   downstream DHCPv6 client and an upstream DHCPv6 server, as its
   operation does not depend on being able to interpret the options
   conveyed between the client and the server.  Consequently a DHCPv6
   relay agent inherently supports all current and future DHCPv6
   options.

   To overcome a CE device's lack of DHCPv6 option transparency, this
   memo proposes the use of a DHCPv6 relay agent for processing of
   stateless DHCPv6 requests, and a hybrid mode of operation for
   stateful DHCPv6 requests, where the IPv6 addressing related options
   are processed locally, and other options requested by hosts are
   acquired from a DHCPv6 server via a relayed, synthesised Information-
   request.





Smith                   Expires January 31, 2014                [Page 3]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


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 RFC 2119 [RFC2119].

2.  Internet Transparency and Application Configuration

   A variety of RFCs discuss Internet transparency, and its benefits
   [RFC1958] [RFC3724] [RFC4924].  Internet transparency essentially
   means that the Internet is transparent to the applications using it,
   such that deploying a new application only requires installing the
   application on the hosts which will be executing it.  The devices
   (routers) within the Internet remain "oblivious" to the new
   application's protocols, and consequently immediately facilitate its
   use.  The benefits of this model are significant; having to make
   fundamental changes or upgrades to one or more routers' operation to
   support a new application would likely be disruptive to the devices
   currently using the routers.  All routers that may potentially carry
   the new application's traffic would need to be upgraded.
   Furthermore, the software or firmware upgrades required to support
   the application may not currently or may never be available from the
   router vendor.  These network upgrades would significantly delay, or
   perhaps make impossible the deployment of new applications.
   Application awareness in the Internet limits its flexibility and
   generality.

   This Internet transparency model should also be followed by protocols
   and the deployment models used to provide application parameters.  If
   a device within the network is going to participate in an application
   configuration protocol, it should do so in a manner that is
   transparent to the application(s) configuration.

   The DHCPv6 protocol supports this transparency model.  DHCPv6 clients
   and servers, located on the hosts at the edge of the network, are
   option and application parameter aware.  A DHCPv6 relay, located
   within the network, does not need to understand the DHCPv6 options
   the clients and servers use to be able to relay them.  When a new
   DHCPv6 configured application is to be deployed, only the DHCPv6
   clients and servers involved in configuring the application need to
   be upgraded.  Widespread upgrades of DHCPv6 relays within the
   Internet are not required.

   The DHCPv6 deployment model described in [RFC6204] does not provide
   application configuration transparency, as it uses the combination of
   a DHCPv6 client and server, rather than a DHCPv6 relay, to convey
   service provider DHCPv6 options to hosts downstream of the CE device.
   The DHCPv6 options that can be conveyed "across" the CE device are



Smith                   Expires January 31, 2014                [Page 4]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


   limited to those understood by both the co-located DHCPv6 client and
   server on the CE device.  A DHCPv6 relay deployment model would be
   better for the types of CE devices described in [RFC6204], and
   devices located within the Internet in general.

   The addition of DNS related options to RAs [RFC6106] is also
   venturing down the path of violating network application
   configuration transparency.  Subsequent to these options being added
   to RAs, there has been at least one proposal to add a further
   application related option to RAs that is already present in DHCPv6.
   Following a model of using RAs to configure applications will result
   in network located constraints on application deployment, as
   described previously.  Proposals for further application
   configuration options in RAs should be resisted.  RA options should
   be limited to configuring network layer parameters, relevant to a
   single link or subnet, with DHCPv6 being used to configure higher
   layer transport and application layer parameters.  This will preserve
   application configuration transparency in the Internet.

3.  LAN Interface(s) DHCPv6 Relay Agent

   When SLAAC [RFC4862] is being used for LAN interface IPv6 address
   autoconfiguration, it is likely that stateless DHCPv6 [RFC3736] will
   be used by hosts to acquire other application-oriented configuration
   parameters.

   Instead of using a DHCPv6 server to answer hosts' DHCPv6 Information-
   request messages, a CE device uses DHCPv6 relay functionality
   [RFC3315] to relay the Information-request message out of its WAN
   interface, towards the service provider's DHCPv6 server
   infrastructure.  The service provider's DHCPv6 service infrastructure
   will either not respond, or provide values for some or all of the
   options requested by the DHCPv6 client.

   (I wonder if it would be useful to be able to supply one or more LAN
   interface relay agent target addresses during the DHCPv6-PD
   transaction on the WAN interface, via a currently undefined DHCPv6
   option.  This would allow the service provider to use different
   DHCPv6 server infrastructure to answer these LAN interface originated
   DHCPv6 Information-requests verses what they use for the CE device's
   WAN interface DHCPv6-PD transaction.  This could provide the benefit
   of both minimising the DHCPv6 configuration complexity on the SP
   router, and as relaying or answering of DHCPv6 is going to be a
   router control plane function, will reduce the router control plane
   load.)

4.  LAN Interface(s) DHCPv6 Hybrid Server/Relay




Smith                   Expires January 31, 2014                [Page 5]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


   To support stateful IPv6 address assignment on the LAN interface(s)
   (perhaps in addition to stateless IPv6 address assignment [RFC4862]),
   while also remaining DHCPv6 option transparent, a hybrid mode of
   DHCPv6 operation is necessary.  This hybrid mode involves locally
   processing the IPv6 address assignment related DHCPv6 options, while
   acquiring other option information from the upstream service
   provider's DHCPv6 infrastructure, using DHCPv6 relay functionality.
   To the LAN attached hosts, the DHCPv6 Hybrid Server/Relay appears to
   be a local stateful DHCPv6 server.  The hybrid operation is
   transparent to the DHCPv6 clients.

   In this section, the following terminology is used:

   o  DHCPv6 upstream server - the DHCPv6 server and related DHCPv6
      infrastructure located within the upstream service provider's
      network.

   o  DHCPv6 hybrid server - the DHCPv6 server that is available on the
      CE device's LAN interface(s).

   o  DHCPv6 hybrid transaction - the transaction where IPv6 addressing
      related DHCPv6 options are processed locally by the server, while
      other option information is acquired from a DHCPv6 upstream
      server.

   o  DHCPv6 client - an IPv6 host attached to the CE device's LAN
      interface, which uses the services of the DHCPv6 hybrid server.

   The DHCPv6 hybrid transaction occurs when the DHCPv6 hybrid server is
   preparing a Reply response to a client generated DHCPv6 Solicit (when
   Rapid Commit is in use), Request, Renew or Rebind message.  At this
   point in the transaction, if the message from the DHCPv6 client
   contains an Option Request Option, the DHCPv6 hybrid server
   synthesises a DHCPv6 Information-request message [RFC3736] on behalf
   of the DHCPv6 client.  The synthesised Information-request is
   constructed using the permitted subset of DHCPv6 options received
   from the DHCPv6 client.  Specifically, the IA options and other non-
   relevant options are excluded.  An Information Refresh option
   [RFC4242] code is added to the Option Request Option in the
   Information-request, to acquire option refresh time information
   [RFC4076].

   The synthesised Information-request is then relayed to the DHCPv6
   upstream server using standard DHCPv6 relay functionality [RFC3315].
   To detect lack of a response to the relayed Information-request, the
   DHCPv6 hybrid server also starts a count down to zero timer, with an
   initial value of INF_TIMEOUT [RFC3315].




Smith                   Expires January 31, 2014                [Page 6]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


   If the DHCPv6 hybrid server does not receive a Reply before the count
   down timer reaches zero, the DHCPv6 hybrid server abandons its
   knowledge of both the DHCPv6 client's original DHCPv6 message, and
   any state related to the synthesised Information-request.  Recovery
   from the lack of response from the DHCPv6 upstream server is left to
   the DHCPv6 client; it will eventually retransmit its Solicit,
   Request, Renew or Rebind message, restarting the DHCPv6 hybrid
   transaction, or will give up completely on the whole stateful DHCPv6
   transaction.

   While the synthesised Information-request is being relayed (i.e.,
   within INF_TIMEOUT from when the Information-request was sent), the
   DHCPv6 client may timeout its original message and therefore
   retransmit it.  These retransmissions are to be silently dropped.
   They can be recognised by the DHCPv6 client's reuse of the same
   DHCPv6 transaction ID.

   If the DHCPv6 hybrid server receives a Reply to the relayed
   Information-request, it uses the enclosed information to populate the
   set of options that will be sent to the DHCPv6 client.  The received
   options the DHCPv6 hybrid server provides to the DHCPv6 client are
   the options that fall within the set the DHCPv6 client originally
   requested using an Option Request Option.  Other options received in
   the relayed Reply are not sent to the DHCPv6 client.  They may be
   used by the DHCPv6 hybrid server for other purposes.

   If an Information Refresh option is received in the relayed Reply,
   the DHCPv6 hybrid server should use the supplied refresh time to
   cause the DHCPv6 client to refresh its option information at the
   appropriate time.  There are three possible ways this can be
   achieved, with the first being most preferred.

   Firstly, if the DHCPv6 client has indicated Reconfiguration support,
   the DHCPv6 hybrid server should send a Reconfigure message to the
   DHCPv6 client after the refresh time interval, as per the procedure
   in [RFC3315].  This should cause the DHCPv6 client to initiate a
   Renew/Reply transaction.  When responding to the Renew message, the
   DHCPv6 hybrid server performs the DHCPv6 hybrid transaction to
   acquire up-to-date option values.

   If the DHCPv6 client does not support Reconfiguration, one of two
   mechanisms can be used, depending on whether the IPv6 addresses
   provided to DHCPv6 clients are non-temporary or temporary addresses.

   For non-temporary addresses, supplied using IA_NA options, the T1
   time interval [RFC3315] should be set to the refresh time interval,
   if it is lower than the DHCPv6 hybrid server's normal T1 time
   interval.  This will cause the client to initiate a Renew/Reply



Smith                   Expires January 31, 2014                [Page 7]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


   transaction at time T1.  The DHCPv6 hybrid server then performs the
   DHCPv6 hybrid transaction when preparing the Reply.  The T2 value is
   derived from the T1 value, as per the advice in [RFC3315].

   For temporary addresses, supplied using IA_TA options, the refresh
   time interval is used to set the preferred lifetime values of all
   addresses supplied using the IA Address options.  This should cause
   the client to initiate a Renew/Reply transaction when any of the
   temporary addresses becomes deprecated, at which time the DHCPv6
   hybrid server performs the DHCPv6 hybrid transaction when preparing
   the Reply.

   If the DHCPv6 client does not support Reconfiguration, and the DHCPv6
   hybrid server supplies both temporary and non-temporary addresses,
   then the non-temporary address method for causing clients to refresh
   their option information should be used.

5.  Security Considerations

5.1.  Client Information Disclosure

   In the existing CE device DHCPv6 WAN client/LAN server model,
   messages sent by DHCPv6 clients to the LAN DHCPv6 server are
   processed locally.  This means that any client supplied options that
   provide client specific attributes, such as the Client Identification
   Option, the Vendor Class Option or the Vendor-specific Information
   Option, are not sent to the upstream provider.

   In the DHCPv6 relay models presented in this memo, client supplied
   information is now provided by the CE device to the upstream service
   provider.

   This is not a new risk to DHCPv6 clients.  Unless a DHCPv6 client
   uses DHCPv6 authentication, there is always a possibility that the
   client will be supplying information about itself to possibly an
   unknown and perhaps untrusted operator of an available DHCPv6 server.

   If a client wishes to avoid classification or unique identification,
   it should avoid supplying options which disclose client specific
   attributes.  A client may choose to supply these client specific
   attributes only when DHCPv6 authentication is being used and the
   DHCPv6 server is known and trusted.

   A client needs to consider the benefits and drawbacks of supplying
   client specific information.  If it supplies this information, it may
   receive client specific option values, resulting in useful service or
   application benefits.  If it does not supply this information, it is
   likely to receive a default and possibly a less beneficial service.



Smith                   Expires January 31, 2014                [Page 8]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


   A client must provide a Client Identifier Option within its DHCPv6
   messages, containing a DHCP Unique Identifier (DUID) [RFC3315].
   DUIDs formed using [RFC3315] methods contain client specific
   attributes.  To minimise this attribute disclosure, a DHCPv6 client
   should use the UUID-based form of DUID (DUID-UUID) [RFC6355], with a
   version 4 UUID [RFC4122] created using a truly random or pseudo-
   random number.  This should uniquely identify the client to the
   DHCPv6 server, while avoiding providing any other client attribute
   information.

5.2.  Additional State

   When performing the DHCPv6 Hybrid Server/Relay method, additional
   state is created while the CE device's DHCPv6 server is relaying the
   synthesised DHCPv6 Information-request.  The amount of additional
   state is proportional to the number of client DHCPv6 requests for
   which Information-requests are synthesised and relayed.  This state
   could be a target for a state capacity exhaustion attack (more
   generally, a resource exhaustion attack) from a malicious or
   misbehaving DHCPv6 client.  Existing methods used to protect a DHCPv6
   server from state capacity exhaustion attacks should also be used to
   protect this additional state.

6.  Acknowledgements

   Review and comments were provided by YOUR NAME HERE!

   This memo was prepared using the xml2rfc tool.

7.  Change Log [RFC Editor please remove]

   draft-smith-v6ops-ce-dhcpv6-transparency-00, initial version,
   2013-07-30

8.  References

8.1.  Normative References

   [IANA-DHCPV6-OPTIONS]
              Internet Assigned Numbers Authority, "DHCP Option Codes",
              2013, <http://www.iana.org/assignments/dhcpv6-parameters/
              dhcpv6-parameters.xhtml#dhcpv6-parameters-2>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References




Smith                   Expires January 31, 2014                [Page 9]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [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.

   [RFC3724]  Kempf, J., Austein, R., IAB, "The Rise of the Middle and
              the Future of End-to-End: Reflections on the Evolution of
              the Internet Architecture", RFC 3724, March 2004.

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC4076]  Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
              Requirements for Stateless Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122, July
              2005.

   [RFC4242]  Venaas, S., Chown, T., and B. Volz, "Information Refresh
              Time Option for Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 4242, November 2005.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4924]  Aboba, B. and E. Davies, "Reflections on Internet
              Transparency", RFC 4924, July 2007.

   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 6106, November 2010.

   [RFC6204]  Singh, H., Beebee, W., Donley, C., Stark, B., and O.
              Troan, "Basic Requirements for IPv6 Customer Edge
              Routers", RFC 6204, April 2011.

   [RFC6355]  Narten, T. and J. Johnson, "Definition of the UUID-Based
              DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August
              2011.

Author's Address






Smith                   Expires January 31, 2014               [Page 10]


Internet-Draft  IPv6 CE Device DHCPv6 Option Transparency      July 2013


   Mark Smith
   In My Own Time
   PO BOX 521
   HEIDELBERG, VIC  3084
   AU

   Email: markzzzsmith@yahoo.com.au












































Smith                   Expires January 31, 2014               [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/