Internet DRAFT - draft-smith-v6ops-ce-dhcpv6-transparency
draft-smith-v6ops-ce-dhcpv6-transparency
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]
