| Internet Engineering Task Force | M.R. 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
[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.
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 (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 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.
[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.
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.
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].
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 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.
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.)
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:
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].
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 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.
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.
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.
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.
Review and comments were provided by YOUR NAME HERE!
This memo was prepared using the xml2rfc tool.
draft-smith-v6ops-ce-dhcpv6-transparency-00, initial version, 2013-07-30
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [IANA-DHCPV6-OPTIONS] | Internet Assigned Numbers Authority, "DHCP Option Codes", 2013. |