idnits 2.17.1 draft-smith-v6ops-ce-dhcpv6-transparency-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC6204]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC6204, but the abstract doesn't seem to directly say this. It does mention RFC6204 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 30, 2013) is 3916 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-DHCPV6-OPTIONS' -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4242 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft IMOT 4 Updates: 6204 (if approved) July 30, 2013 5 Intended status: Standards Track 6 Expires: January 31, 2014 8 IPv6 CE Device DHCPv6 Option Transparency 9 draft-smith-v6ops-ce-dhcpv6-transparency-00 11 Abstract 13 [RFC6204] defines basic requirements for IPv6 Customer Edge Routers, 14 to suit residential or small office IPv6 deployments. It describes a 15 WAN interface DHCPv6 client and LAN interface DHCPv6 server 16 implementation model. This model constrains the set of DHCPv6 17 options that can be conveyed between the upstream service provider 18 and the hosts downstream of the CE device, to those supported by both 19 the CE device's DHCPv6 client and server. To support further current 20 and future DHCPv6 options, this memo instead proposes a DHCPv6 option 21 "transparent" implementation model for CE devices, primarily using 22 DHCPv6 message relaying. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 31, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Internet Transparency and Application Configuration . . . . . 4 61 3. LAN Interface(s) DHCPv6 Relay Agent . . . . . . . . . . . . . 5 62 4. LAN Interface(s) DHCPv6 Hybrid Server/Relay . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 5.1. Client Information Disclosure . . . . . . . . . . . . . . 8 65 5.2. Additional State . . . . . . . . . . . . . . . . . . . . 9 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 7. Change Log [RFC Editor please remove] . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 [RFC6204] defines basic requirements for IPv6 Customer Edge Routers, 76 to suit residential or small office IPv6 deployments. 78 For these devices, the model of operation for DHCPv6 is to operate as 79 a client on the CE device's WAN interface and as a server on the CE 80 device's LAN interface(s). 82 Operating as a client on the WAN interface, DHCPv6 is used for two 83 purposes. Firstly, the DHCPv6 client is used to acquire 84 configuration parameters useful or necessary to the CE device itself. 85 Examples of these parameters are an IPv6 address for the WAN 86 interface, DNS server information, and Simple Network Time Server 87 information. Secondly, the DHCPv6 client is used to acquire 88 configuration parameters that are either essential or useful for the 89 operation of the downstream hosts, such as a delegated IPv6 prefix 90 and DNS domain information. 92 Operating as a server on the LAN interface(s), DHCPv6 is used for 93 purposes such as stateful IPv6 address assignment (if supported by 94 the CE device and requested by the hosts), providing hosts with DNS 95 resolver and DNS domain information, and possibly being able to 96 provide other DHCPv6 options such as SIP server addresses. 98 This client and server model of operation of DHCPv6 on the CE device 99 constrains the use of DHCPv6 options between the downstream host(s) 100 and the upstream service provider. The DHCPv6 options that a 101 downstream host can request, and that an upstream service provider 102 can supply, is limited to the set of options supported by both the CE 103 device's WAN DHCPv6 client and LAN DHCPv6 server. This set of 104 supported DHCPv6 options is significantly limited compared to the 105 current set of available DHCPv6 options [IANA-DHCPV6-OPTIONS]. 106 Additionally, it cannot accommodate DHCPv6 options that may be 107 defined in the future. This means the CE device is not DHCPv6 option 108 "transparent". 110 The main consequence of a lack of DHCPv6 option transparency is that 111 users or operators of the hosts downstream of the CE device will have 112 to resort to manual configuration of application and host parameters, 113 for information that could be provided by the CE device's unsupported 114 DHCPv6 options. Manual configuration is time consuming, error prone, 115 static, not scalable and most importantly, not user friendly. 117 In markets where service provider customers can supply their own CE 118 device, the CE device supported DHCPv6 options may vary significantly 119 across the customers' devices. This could create a perverse 120 incentive for the service provider to not use DHCPv6 options at all, 121 other than the minimum necessary, and instead have customers use 122 manual configuration. The motive to do so would be for the service 123 provider to have a single and consistent method of configuration, 124 simplifying customer fault troubleshooting, despite the other 125 drawbacks of manual configuration described previously. CE device 126 DHCPv6 option transparency would avoid creating this incentive for 127 manual configuration. 129 A DHCPv6 Relay Agent [RFC3315] is DHCPv6 option transparent. It does 130 not constrain the set of options that can be used between a 131 downstream DHCPv6 client and an upstream DHCPv6 server, as its 132 operation does not depend on being able to interpret the options 133 conveyed between the client and the server. Consequently a DHCPv6 134 relay agent inherently supports all current and future DHCPv6 135 options. 137 To overcome a CE device's lack of DHCPv6 option transparency, this 138 memo proposes the use of a DHCPv6 relay agent for processing of 139 stateless DHCPv6 requests, and a hybrid mode of operation for 140 stateful DHCPv6 requests, where the IPv6 addressing related options 141 are processed locally, and other options requested by hosts are 142 acquired from a DHCPv6 server via a relayed, synthesised Information- 143 request. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 2. Internet Transparency and Application Configuration 153 A variety of RFCs discuss Internet transparency, and its benefits 154 [RFC1958] [RFC3724] [RFC4924]. Internet transparency essentially 155 means that the Internet is transparent to the applications using it, 156 such that deploying a new application only requires installing the 157 application on the hosts which will be executing it. The devices 158 (routers) within the Internet remain "oblivious" to the new 159 application's protocols, and consequently immediately facilitate its 160 use. The benefits of this model are significant; having to make 161 fundamental changes or upgrades to one or more routers' operation to 162 support a new application would likely be disruptive to the devices 163 currently using the routers. All routers that may potentially carry 164 the new application's traffic would need to be upgraded. 165 Furthermore, the software or firmware upgrades required to support 166 the application may not currently or may never be available from the 167 router vendor. These network upgrades would significantly delay, or 168 perhaps make impossible the deployment of new applications. 169 Application awareness in the Internet limits its flexibility and 170 generality. 172 This Internet transparency model should also be followed by protocols 173 and the deployment models used to provide application parameters. If 174 a device within the network is going to participate in an application 175 configuration protocol, it should do so in a manner that is 176 transparent to the application(s) configuration. 178 The DHCPv6 protocol supports this transparency model. DHCPv6 clients 179 and servers, located on the hosts at the edge of the network, are 180 option and application parameter aware. A DHCPv6 relay, located 181 within the network, does not need to understand the DHCPv6 options 182 the clients and servers use to be able to relay them. When a new 183 DHCPv6 configured application is to be deployed, only the DHCPv6 184 clients and servers involved in configuring the application need to 185 be upgraded. Widespread upgrades of DHCPv6 relays within the 186 Internet are not required. 188 The DHCPv6 deployment model described in [RFC6204] does not provide 189 application configuration transparency, as it uses the combination of 190 a DHCPv6 client and server, rather than a DHCPv6 relay, to convey 191 service provider DHCPv6 options to hosts downstream of the CE device. 192 The DHCPv6 options that can be conveyed "across" the CE device are 193 limited to those understood by both the co-located DHCPv6 client and 194 server on the CE device. A DHCPv6 relay deployment model would be 195 better for the types of CE devices described in [RFC6204], and 196 devices located within the Internet in general. 198 The addition of DNS related options to RAs [RFC6106] is also 199 venturing down the path of violating network application 200 configuration transparency. Subsequent to these options being added 201 to RAs, there has been at least one proposal to add a further 202 application related option to RAs that is already present in DHCPv6. 203 Following a model of using RAs to configure applications will result 204 in network located constraints on application deployment, as 205 described previously. Proposals for further application 206 configuration options in RAs should be resisted. RA options should 207 be limited to configuring network layer parameters, relevant to a 208 single link or subnet, with DHCPv6 being used to configure higher 209 layer transport and application layer parameters. This will preserve 210 application configuration transparency in the Internet. 212 3. LAN Interface(s) DHCPv6 Relay Agent 214 When SLAAC [RFC4862] is being used for LAN interface IPv6 address 215 autoconfiguration, it is likely that stateless DHCPv6 [RFC3736] will 216 be used by hosts to acquire other application-oriented configuration 217 parameters. 219 Instead of using a DHCPv6 server to answer hosts' DHCPv6 Information- 220 request messages, a CE device uses DHCPv6 relay functionality 221 [RFC3315] to relay the Information-request message out of its WAN 222 interface, towards the service provider's DHCPv6 server 223 infrastructure. The service provider's DHCPv6 service infrastructure 224 will either not respond, or provide values for some or all of the 225 options requested by the DHCPv6 client. 227 (I wonder if it would be useful to be able to supply one or more LAN 228 interface relay agent target addresses during the DHCPv6-PD 229 transaction on the WAN interface, via a currently undefined DHCPv6 230 option. This would allow the service provider to use different 231 DHCPv6 server infrastructure to answer these LAN interface originated 232 DHCPv6 Information-requests verses what they use for the CE device's 233 WAN interface DHCPv6-PD transaction. This could provide the benefit 234 of both minimising the DHCPv6 configuration complexity on the SP 235 router, and as relaying or answering of DHCPv6 is going to be a 236 router control plane function, will reduce the router control plane 237 load.) 239 4. LAN Interface(s) DHCPv6 Hybrid Server/Relay 240 To support stateful IPv6 address assignment on the LAN interface(s) 241 (perhaps in addition to stateless IPv6 address assignment [RFC4862]), 242 while also remaining DHCPv6 option transparent, a hybrid mode of 243 DHCPv6 operation is necessary. This hybrid mode involves locally 244 processing the IPv6 address assignment related DHCPv6 options, while 245 acquiring other option information from the upstream service 246 provider's DHCPv6 infrastructure, using DHCPv6 relay functionality. 247 To the LAN attached hosts, the DHCPv6 Hybrid Server/Relay appears to 248 be a local stateful DHCPv6 server. The hybrid operation is 249 transparent to the DHCPv6 clients. 251 In this section, the following terminology is used: 253 o DHCPv6 upstream server - the DHCPv6 server and related DHCPv6 254 infrastructure located within the upstream service provider's 255 network. 257 o DHCPv6 hybrid server - the DHCPv6 server that is available on the 258 CE device's LAN interface(s). 260 o DHCPv6 hybrid transaction - the transaction where IPv6 addressing 261 related DHCPv6 options are processed locally by the server, while 262 other option information is acquired from a DHCPv6 upstream 263 server. 265 o DHCPv6 client - an IPv6 host attached to the CE device's LAN 266 interface, which uses the services of the DHCPv6 hybrid server. 268 The DHCPv6 hybrid transaction occurs when the DHCPv6 hybrid server is 269 preparing a Reply response to a client generated DHCPv6 Solicit (when 270 Rapid Commit is in use), Request, Renew or Rebind message. At this 271 point in the transaction, if the message from the DHCPv6 client 272 contains an Option Request Option, the DHCPv6 hybrid server 273 synthesises a DHCPv6 Information-request message [RFC3736] on behalf 274 of the DHCPv6 client. The synthesised Information-request is 275 constructed using the permitted subset of DHCPv6 options received 276 from the DHCPv6 client. Specifically, the IA options and other non- 277 relevant options are excluded. An Information Refresh option 278 [RFC4242] code is added to the Option Request Option in the 279 Information-request, to acquire option refresh time information 280 [RFC4076]. 282 The synthesised Information-request is then relayed to the DHCPv6 283 upstream server using standard DHCPv6 relay functionality [RFC3315]. 284 To detect lack of a response to the relayed Information-request, the 285 DHCPv6 hybrid server also starts a count down to zero timer, with an 286 initial value of INF_TIMEOUT [RFC3315]. 288 If the DHCPv6 hybrid server does not receive a Reply before the count 289 down timer reaches zero, the DHCPv6 hybrid server abandons its 290 knowledge of both the DHCPv6 client's original DHCPv6 message, and 291 any state related to the synthesised Information-request. Recovery 292 from the lack of response from the DHCPv6 upstream server is left to 293 the DHCPv6 client; it will eventually retransmit its Solicit, 294 Request, Renew or Rebind message, restarting the DHCPv6 hybrid 295 transaction, or will give up completely on the whole stateful DHCPv6 296 transaction. 298 While the synthesised Information-request is being relayed (i.e., 299 within INF_TIMEOUT from when the Information-request was sent), the 300 DHCPv6 client may timeout its original message and therefore 301 retransmit it. These retransmissions are to be silently dropped. 302 They can be recognised by the DHCPv6 client's reuse of the same 303 DHCPv6 transaction ID. 305 If the DHCPv6 hybrid server receives a Reply to the relayed 306 Information-request, it uses the enclosed information to populate the 307 set of options that will be sent to the DHCPv6 client. The received 308 options the DHCPv6 hybrid server provides to the DHCPv6 client are 309 the options that fall within the set the DHCPv6 client originally 310 requested using an Option Request Option. Other options received in 311 the relayed Reply are not sent to the DHCPv6 client. They may be 312 used by the DHCPv6 hybrid server for other purposes. 314 If an Information Refresh option is received in the relayed Reply, 315 the DHCPv6 hybrid server should use the supplied refresh time to 316 cause the DHCPv6 client to refresh its option information at the 317 appropriate time. There are three possible ways this can be 318 achieved, with the first being most preferred. 320 Firstly, if the DHCPv6 client has indicated Reconfiguration support, 321 the DHCPv6 hybrid server should send a Reconfigure message to the 322 DHCPv6 client after the refresh time interval, as per the procedure 323 in [RFC3315]. This should cause the DHCPv6 client to initiate a 324 Renew/Reply transaction. When responding to the Renew message, the 325 DHCPv6 hybrid server performs the DHCPv6 hybrid transaction to 326 acquire up-to-date option values. 328 If the DHCPv6 client does not support Reconfiguration, one of two 329 mechanisms can be used, depending on whether the IPv6 addresses 330 provided to DHCPv6 clients are non-temporary or temporary addresses. 332 For non-temporary addresses, supplied using IA_NA options, the T1 333 time interval [RFC3315] should be set to the refresh time interval, 334 if it is lower than the DHCPv6 hybrid server's normal T1 time 335 interval. This will cause the client to initiate a Renew/Reply 336 transaction at time T1. The DHCPv6 hybrid server then performs the 337 DHCPv6 hybrid transaction when preparing the Reply. The T2 value is 338 derived from the T1 value, as per the advice in [RFC3315]. 340 For temporary addresses, supplied using IA_TA options, the refresh 341 time interval is used to set the preferred lifetime values of all 342 addresses supplied using the IA Address options. This should cause 343 the client to initiate a Renew/Reply transaction when any of the 344 temporary addresses becomes deprecated, at which time the DHCPv6 345 hybrid server performs the DHCPv6 hybrid transaction when preparing 346 the Reply. 348 If the DHCPv6 client does not support Reconfiguration, and the DHCPv6 349 hybrid server supplies both temporary and non-temporary addresses, 350 then the non-temporary address method for causing clients to refresh 351 their option information should be used. 353 5. Security Considerations 355 5.1. Client Information Disclosure 357 In the existing CE device DHCPv6 WAN client/LAN server model, 358 messages sent by DHCPv6 clients to the LAN DHCPv6 server are 359 processed locally. This means that any client supplied options that 360 provide client specific attributes, such as the Client Identification 361 Option, the Vendor Class Option or the Vendor-specific Information 362 Option, are not sent to the upstream provider. 364 In the DHCPv6 relay models presented in this memo, client supplied 365 information is now provided by the CE device to the upstream service 366 provider. 368 This is not a new risk to DHCPv6 clients. Unless a DHCPv6 client 369 uses DHCPv6 authentication, there is always a possibility that the 370 client will be supplying information about itself to possibly an 371 unknown and perhaps untrusted operator of an available DHCPv6 server. 373 If a client wishes to avoid classification or unique identification, 374 it should avoid supplying options which disclose client specific 375 attributes. A client may choose to supply these client specific 376 attributes only when DHCPv6 authentication is being used and the 377 DHCPv6 server is known and trusted. 379 A client needs to consider the benefits and drawbacks of supplying 380 client specific information. If it supplies this information, it may 381 receive client specific option values, resulting in useful service or 382 application benefits. If it does not supply this information, it is 383 likely to receive a default and possibly a less beneficial service. 385 A client must provide a Client Identifier Option within its DHCPv6 386 messages, containing a DHCP Unique Identifier (DUID) [RFC3315]. 387 DUIDs formed using [RFC3315] methods contain client specific 388 attributes. To minimise this attribute disclosure, a DHCPv6 client 389 should use the UUID-based form of DUID (DUID-UUID) [RFC6355], with a 390 version 4 UUID [RFC4122] created using a truly random or pseudo- 391 random number. This should uniquely identify the client to the 392 DHCPv6 server, while avoiding providing any other client attribute 393 information. 395 5.2. Additional State 397 When performing the DHCPv6 Hybrid Server/Relay method, additional 398 state is created while the CE device's DHCPv6 server is relaying the 399 synthesised DHCPv6 Information-request. The amount of additional 400 state is proportional to the number of client DHCPv6 requests for 401 which Information-requests are synthesised and relayed. This state 402 could be a target for a state capacity exhaustion attack (more 403 generally, a resource exhaustion attack) from a malicious or 404 misbehaving DHCPv6 client. Existing methods used to protect a DHCPv6 405 server from state capacity exhaustion attacks should also be used to 406 protect this additional state. 408 6. Acknowledgements 410 Review and comments were provided by YOUR NAME HERE! 412 This memo was prepared using the xml2rfc tool. 414 7. Change Log [RFC Editor please remove] 416 draft-smith-v6ops-ce-dhcpv6-transparency-00, initial version, 417 2013-07-30 419 8. References 421 8.1. Normative References 423 [IANA-DHCPV6-OPTIONS] 424 Internet Assigned Numbers Authority, "DHCP Option Codes", 425 2013, . 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 8.2. Informative References 433 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 434 RFC 1958, June 1996. 436 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 437 and M. Carney, "Dynamic Host Configuration Protocol for 438 IPv6 (DHCPv6)", RFC 3315, July 2003. 440 [RFC3724] Kempf, J., Austein, R., IAB, "The Rise of the Middle and 441 the Future of End-to-End: Reflections on the Evolution of 442 the Internet Architecture", RFC 3724, March 2004. 444 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 445 (DHCP) Service for IPv6", RFC 3736, April 2004. 447 [RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering 448 Requirements for Stateless Dynamic Host Configuration 449 Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005. 451 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 452 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 453 2005. 455 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 456 Time Option for Dynamic Host Configuration Protocol for 457 IPv6 (DHCPv6)", RFC 4242, November 2005. 459 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 460 Address Autoconfiguration", RFC 4862, September 2007. 462 [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet 463 Transparency", RFC 4924, July 2007. 465 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 466 "IPv6 Router Advertisement Options for DNS Configuration", 467 RFC 6106, November 2010. 469 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 470 Troan, "Basic Requirements for IPv6 Customer Edge 471 Routers", RFC 6204, April 2011. 473 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 474 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 475 2011. 477 Author's Address 478 Mark Smith 479 In My Own Time 480 PO BOX 521 481 HEIDELBERG, VIC 3084 482 AU 484 Email: markzzzsmith@yahoo.com.au