idnits 2.17.1 draft-ietf-dhc-topo-conf-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 22, 2014) is 3503 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nominum, Inc. 4 Intended status: Informational T. Mrugalski 5 Expires: March 26, 2015 Internet Systems Consortium, Inc. 6 September 22, 2014 8 Customizing DHCP Configuration on the Basis of Network Topology 9 draft-ietf-dhc-topo-conf-03 11 Abstract 13 DHCP servers have evolved over the years to provide significant 14 functionality beyond that which is described in the DHCP base 15 specifications. One aspect of this functionality is support for 16 context-specific configuration information. This memo describes some 17 such features and makes recommendations as to how they can be used. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 26, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Locality . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 8 57 5. Relay agent running on a host . . . . . . . . . . . . . . . . 10 58 6. Cascade relays . . . . . . . . . . . . . . . . . . . . . . . 10 59 7. Regional Configuration Example . . . . . . . . . . . . . . . 11 60 8. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 13 61 9. Multiple subnets on the same link . . . . . . . . . . . . . . 14 62 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 63 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 65 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 67 13.2. Informative References . . . . . . . . . . . . . . . . . 15 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 70 1. Introduction 72 The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications 73 describe how addresses can be allocated to clients based on network 74 topology information provided by the DHCP relay infrastructure. 75 Address allocation decisions are integral to the allocation of 76 addresses and prefixes in DHCP. 78 The DHCP protocol also describes mechanisms for provisioning devices 79 with additional configuration information; for example, DNS [RFC1034] 80 server addresses, default DNS search domains, and similar 81 information. 83 Although it was the intent of the authors of these specifications 84 that DHCP servers would provision devices with configuration 85 information appropriate to each device's location on the network, 86 this practice was never documented, much less described in detail. 88 Existing DHCP server implementations do in fact provide such 89 capabilities; the goal of this document is to describe those 90 capabilities for the benefit both of operators and of protocol 91 designers who may wish to use DHCP as a means for configuring their 92 own services, but may not be aware of the capabilities provided by 93 most modern DHCP servers. 95 2. Terminology 97 o Routable IP address: an IP address with a scope of use wider than 98 the local link. 100 o PE router: Provider Edge Router. The provider router closest to 101 the customer. 103 o CPE device: customer premise equipment device. Typically a router 104 belonging to the customer that connects directly to the provider 105 link. 107 o Shared subnet: a case where two or more subnets of the same 108 protocol family are available on the same link. 'Share subnet' 109 terminology is typically used in Unix environments. It is 110 typically called 'multinet' in Windows environment. The 111 administrative configuration inside a Microsoft DHCP server is 112 called 'DHCP Superscope'. 114 3. Locality 116 Figure 1 illustrates a simple hierarchy of network links with Link D 117 serving as a backbone to which the DHCP server is attached. 119 Figure 2 illustrates a more complex case. Although some of its 120 aspects are unlikely to be seen in an actual production networks, 121 they are beneficial for explaining finer aspects of the DHCP 122 protocols. Note that some nodes act as routers (which forward all 123 IPv6 traffic) and some are relay agents (i.e. run DHCPv6 specific 124 software that forwards only DHCPv6 traffic). 126 Link A Link B 127 |===+===========| |===========+======| 128 | | 129 | | 130 +---+---+ +---+---+ 131 | relay | | relay | 132 | A | | B | 133 +---+---+ +---+---+ 134 | | 135 | Link C | 136 |===+==========+=================+======| 137 | 138 | 139 +----+---+ +--------+ 140 | router | | DHCP | 141 | A | | Server | 142 +----+---+ +----+---+ 143 | | 144 | | 145 | Link D | 146 |==============+=================+======| 147 | 148 | 149 +----+---+ 150 | router | 151 | B | 152 +----+---+ 153 | 154 | 155 |===+==========+=================+======| 156 | Link E | 157 | | 158 +---+---+ +---+---+ 159 | relay | | relay | 160 | C | | D | 161 +---+---+ +---+---+ 162 | | 163 | | 164 |===+===========| |===========+======| 165 Link F Link G 167 Figure 1: A simple network 169 Link A Link B Link H 170 |===+==========| |=========+======| |======+======| 171 | | | 172 | | | 173 +---+---+ +---+---+ +---+---+ 174 | relay | | relay | | relay | 175 | A | | B | | G | 176 +---+---+ +---+---+ +---+---+ 177 | | | 178 | Link C | | Link J 179 |===+==========+==============+======| |======+======| 180 | | 181 | | 182 +----+---+ +--------+ +---+---+ 183 | router | | DHCP | | relay | 184 | A | | Server | | F | 185 +----+---+ +----+---+ +---+---+ 186 | | | 187 | | | 188 | Link D | | 189 |==============+=========+=======+=============+======| 190 | | 191 | | 192 +----+---+ +---+---+ 193 | router | | relay | 194 | B | | E | 195 +----+---+ +---+---+ 196 | | 197 | | 198 |===+==========+=========+=======+======| 199 | Link E | 200 | | 201 +---+---+ +---+---+ 202 | relay | | relay | 203 | C | | D | 204 +---+---+ +---+---+ 205 | | 206 | | 207 |===+===========| |===========+======| 208 Link F Link G 210 Figure 2: Complex network 212 This diagram allows us to represent a variety of different network 213 configurations and illustrate how existing DHCP servers can provide 214 configuration information customized to the particular location from 215 which a client is making its request. 217 It's important to understand the background of how DHCP works when 218 considering this diagram. DHCP clients are assumed not to have 219 routable IP addresses when they are attempting to obtain 220 configuration information. 222 The reason for making this assumption is that one of the functions of 223 DHCP is to bootstrap the DHCP client's IP address configuration; if 224 the client does not yet have an IP address configured, it cannot 225 route packets to an off-link DHCP server, therefore some kind of 226 relay mechanism is required. 228 The details of how packet delivery between clients and servers works 229 are different between DHCPv4 and DHCPv6, but the essence is the same: 230 whether or not the client actually has an IP configuration, it 231 generally communicates with the DHCP server by sending its requests 232 to a DHCP relay agent on the local link; this relay agent, which has 233 a routable IP address, then forwards the DHCP requests to the DHCP 234 server. In some cases in DHCPv4, when a DHCP client has a routable 235 IPv4 address, the message is unicast to the DHCP server rather than 236 going through a relay agent. In DHCPv6 that is also possible in case 237 where the server is configured with a Server Unicast option (see 238 Section 22.12 in [RFC3315]) and clients are able to take advantage of 239 it. In such case once the clients get their (presumably global) 240 addresses, they are able to contact server directly, bypassing 241 relays. It should be noted that such a mode is completely 242 controllable by administrators in DHCPv6. (They may simply choose to 243 not configure server unicast option, thus forcing clients to send 244 their messages always via relay agents). 246 In all cases, the DHCP server is able to obtain an IP address that it 247 knows is on-link for the link to which the DHCP client is connected: 248 either the DHCPv4 client's routable IPv4 address, or the relay 249 agent's IPv4 address on the link to which the client is connected. 250 So in every case the server is able to determine the client's point 251 of attachment and select appropriate subnet- or link-specific 252 configuration. 254 In the DHCPv6 protocol, there are two mechanisms defined in [RFC3315] 255 that allow server to distinguish which link the relay agent is 256 connected to. The first mechanism is a link-address field in the 257 RELAY-FORW and RELAY-REPL messages. Somewhat contrary to its name, 258 relay agents insert in the link-address field an address that is 259 typically global and can be used to uniquely identify the link on 260 which the client is located. In normal circumstances this is the 261 solution that is easiest to maintain. It requires, however, for the 262 relay agent to have an address with a scope larger than link-local 263 configured on its client-facing interface. If for whatever reason 264 that is not feasible (e.g. because the relay agent does not have a 265 global address configured on the client-facing interface), the relay 266 agent includes an Interface-Id option (see Section 22.18 of 267 [RFC3315]) that identifies the link clients are connected to. It is 268 up to administrator to make sure that the interface-id is unique 269 within his administrative domain. It should be noted that RELAY-FORW 270 and RELAY-REPL messages are exchanged between relays and servers 271 only. Clients are never exposed to those messages. Also, servers 272 never receive RELAY-REPL messages. Relay agents must be able to 273 process both RELAY-FORW (sending already relayed message further 274 towards the server, when there is more than one relay agent in a 275 chain) and RELAY-REPL (when sending back the response towards the 276 client, when there is more than one relay agent in a chain). 278 For completeless, we also mention an uncommon, but valid case, where 279 relay agents set link-local address in the link-address field in 280 relayed RELAY-FORW messages. This may happen if the relay agent 281 doesn't have any address with a larger scope. Even though link local 282 addresses can't be automatically used to associate relay agent with a 283 given link, with sufficient information provided the server is still 284 able to correctly select proper link. That requires the DHCP server 285 software to be able to specify relay agent link-address or a feature 286 similar to 'shared subnets' (see Section 9). Network administrator 287 has to manually configure additional information that a given subnet 288 uses a relay agent with link-address X. Alternatively, if the relay 289 agent uses link address X and relays messages from a subnet A, an 290 administrator can configure that subnet A is a shared subnet with a 291 very small X/128 subnet. That is not a recommended configuration, 292 but in cases where it is impossible for relay agents to get an 293 address from the subnet they are relaying from, it may be a viable 294 solution. 296 DHCPv6 also has support for more finely grained link identification, 297 using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA). In this 298 case, in addition to receiving an IPv6 address that is on-link for 299 the link to which the client is connected, the DHCPv6 server also 300 receives an Interface-Id option from the relay agent that can be used 301 to more precisely identify the client's location on the network. 303 What this means in practice is that the DHCP server in all cases has 304 sufficient information to pinpoint, at the very least, the layer 3 305 link to which the client is connected, and in some cases which layer 306 2 link the client is connected to, when the layer 3 link is 307 aggregated out of multiple layer 2 links. 309 In all cases, then, the DHCP server will have a link-identifying IP 310 address, and in some cases it may also have a link-specific 311 identifier (e.g. Interface-Id Option or Link Address Option defined 312 in Section 5 of [RFC6977]). It should be noted that there is no 313 guarantee that the link-specific identifier will be unique outside 314 the scope of the link-identifying IP address. 316 It is also possible for link-specific identifiers to be nested, so 317 that the actual identifier that identifies the link is an aggregate 318 of two or more link-specific identifiers sent by a set of LDRAs in a 319 chain; in general this functions exactly as if a single identifier 320 were received from a single LDRA, so we do not treat it specially in 321 the discussion below, but sites that use chained LDRA configurations 322 will need to be aware of this when configuring their DHCP servers. 324 So let's examine the implications of this in terms of how a DHCP 325 server can deliver targeted supplemental configuration information to 326 DHCP clients. 328 4. Simple Subnetted Network 330 Consider Figure 1 in the context of a simple subnetted network. In 331 this network, there are four leaf subnets: links A, B, F and G, on 332 which DHCP clients will be configured. Relays A, B, C and D in this 333 example are represented in the diagram as IP routers with an embedded 334 relay function, because this is a very typical configuration, but the 335 relay function can also be provided in a separate node on each link. 337 In a simple network like this, there may be no need for link-specific 338 configuration in DHCPv6, since local routing information is delivered 339 through router advertisements. However, in IPv4, it is very typical 340 to configure the default route using DHCP; in this case, the default 341 route will be different on each link. In order to accomplish this, 342 the DHCP server will need link-specific configuration for the default 343 route. 345 To illustrate, we will use an example from a hypothetical DHCP server 346 that uses a simple JSON notation for configuration. Although we know 347 of no DHCP server that uses this specific syntax, most modern DHCP 348 server provides similar functionality. 350 { 351 "prefixes": { 352 "192.0.2.0/26": { 353 "options": { 354 "routers": ["192.0.2.1"] 355 }, 356 "on-link": ["a"] 357 }, 358 "192.0.2.64/26": { 359 "options": { 360 "routers": ["192.0.2.65"] 361 }, 362 "on-link": ["b"] 363 }, 364 "192.0.2.128/26": { 365 "options": { 366 "routers": ["192.0.2.129"] 367 }, 368 "on-link": ["f"] 369 }, 370 "192.0.2.192/26": { 371 "options": { 372 "routers": ["192.0.2.193"] 373 }, 374 "on-link": ["g"] 375 } 376 } 377 } 379 Figure 3: Configuration example 381 In Figure 3, we see a configuration example for this scenario: a set 382 of prefixes, each of which has a set of options and a list of links 383 for which it is on-link. We have defined one option for each prefix: 384 a routers option. This option contains a list of values; each list 385 only has one value, and that value is the IP address of the router 386 specific to the prefix. 388 When the DHCP server receives a request, it searches the list of 389 prefixes for one that encloses the link-identifying IP address 390 provided by the client or relay agent. The DHCP server then examines 391 the options list associated with that prefix and returns those 392 options to the client. 394 So for example a client connected to link A in the example would have 395 a link-identifying IP address within the 192.0.2.0/26 prefix, so the 396 DHCP server would match it to that prefix. Based on the 397 configuration, the DHCP server would then return a routers option 398 containing a single IP address: 192.0.2.1. A client on link F would 399 have a link-identifying address in the 192.0.2.128/26 prefix, and 400 would receive a routers option containing the IP address 192.0.2.129. 402 5. Relay agent running on a host 404 Relay agent is a DHCP software that may be run on any IP node. 405 Although it is typically run on a router, this is by no means 406 required by the DHCP protocol. The relay agent is simply a service 407 that operates on a link, receiving link-local multicasts or 408 broadcasts and relaying them, using IP routing, to a DHCP server. As 409 long as the relay has an IP address on the link, and a default route 410 or more specific route through which it can reach a DHCP server, it 411 need not be a router, or even have multiple interfaces. 413 Relay agent can be run on a host connected to two links. That case 414 is presented in Figure 2. There is router B that is connected to 415 links D and E. At the same time there is also a host that is 416 connected to the same links. The relay agent software is running on 417 that host. That is uncommon, but legal configuration. 419 6. Cascade relays 421 Let's observe another case shown in Figure 2. Note that in typical 422 configuration, the clients connected to link G will send their 423 requests to relay D which will forward its packets directly to the 424 DHCP server. That is typical, but not the only possible 425 configuration. It is possible to configure relay agent D to forward 426 client messages to relay E which in turn will send it to the DHCP 427 server. This configuration is sometimes referred to as cascade relay 428 agents. 430 Note that the relaying mechanism works differently in DHCPv4 and in 431 DHCPv6. In DHCPv4 only the first relay is able to set the GIADDR 432 field in the DHCPv4 packet. Any following relays that receive that 433 packet will not change it as the server needs GIADDR information from 434 the first relay (i.e. the closest to the client). Server will send 435 the response back to the GIADDR address, which is the address of the 436 first relay agent that saw the client's message. That means that the 437 client messages travel on a different path than the server's 438 responses. A message from client connected to link G will travel via 439 relay D, relay E and to the server. A response message will be sent 440 from the server to relay D via router B, and relay D will send it to 441 the client on link G. 443 Relaying in DHCPv6 is more structured. Each relay agent encapsulates 444 a packet that is destined to the server and sends it towards the 445 server. Depending on the configuration that can be server's unicast 446 address, a multicast address or next relay agent address. The next 447 relay repeats the encapsulation process. Although the resulting 448 packet is more complex (may have up to 32 levels of encapsulation if 449 traveled through 32 relays), every relay may insert its own options 450 and it is clear which relay agent inserted which option. 452 7. Regional Configuration Example 454 In this example, link C is a regional backbone for an ISP. Link E is 455 also a regional backbone for that ISP. Relays A, B, C and D are PE 456 routers, and Links A, B, F and G are actually link aggregators with 457 individual layer 2 circuits to each customer--for example, the relays 458 might be DSLAMs or cable head-end systems. At each customer site we 459 assume there is a single CPE device attached to the link. 461 We further assume that links A, B, F and G are each addressed by a 462 single prefix, although it would be equally valid for each CPE device 463 to be numbered on a separate prefix. 465 In a real-world deployment, there would likely be many more than two 466 PE routers connected to each regional backbone; we have kept the 467 number small for simplicity. 469 In the example presented in Figure 4, the goal is to configure all 470 the devices within a region with server addresses local to that 471 region, so that service traffic does not have to be routed between 472 regions unnecessarily. 474 { 475 "prefixes": { 476 "2001:db8:0:0::/40": { 477 "on-link": ["A"] 478 }, 479 "2001:db8:100:0::/40": { 480 "on-link": ["B"] 481 }, 482 "2001:db8:200:0::/40": { 483 "on-link": ["F"] 484 }, 485 "2001:db8:300:0::/40": { 486 "on-link": ["G"] 487 } 488 }, 489 "links": { 490 "A": {"region": "omashu"}, 491 "B": {"region": "omashu"}, 492 "F": {"region": "gaoling"}, 493 "G": {"region": "gaoling"} 494 }, 495 "regions": { 496 "omashu": { 497 "options": { 498 "sip-servers": ["sip.omashu.example.org"], 499 "dns-servers": ["dns1.omashu.example.org", 500 "dns2.omashu.example.org"] 501 } 502 }, 503 "gaoling": { 504 "options": { 505 "sip-servers": ["sip.gaoling.example.org"], 506 "dns-servers": ["dns1.gaoling.example.org", 507 "dns2.gaoling.example.org"] 508 } 509 } 510 } 511 } 513 Figure 4: An example regions configuration 515 In this example, when a request comes in to the DHCP server with a 516 link-identifying IP address in the 2001:DB8:0:0::/40 prefix, it is 517 identified as being on link A. The DHCP server then looks on the 518 list of links to see what region the client is in. Link A is 519 identified as being in omashu. The DHCP server then looks up omashu 520 in the set of regions, and discovers a list of region-specific 521 options. 523 The DHCP server then resolves the domain names listed in the options 524 and sends a sip-server option containing the IP addresses that the 525 resolver returned for sip.omashu.example.org, and a dns-server option 526 containing the IP addresses returned by the resolver for 527 dns1.omashu.example.org and dns2.omashu.example.org. Depending on 528 the server capability and configuration, it may cache resolved 529 responses for specific period of time, repeat queries every time or 530 even keep the response until reconfiguration or shutdown. 532 Similarly, if the DHCP server receives a request from a DHCP client 533 where the link-identifying IP address is contained by the prefix 534 2001:DB8:300:0::/40, then the DHCP server identifies the client as 535 being connected to link G. The DHCP server then identifies link G as 536 being in the gaoling region, and returns the sip-servers and dns- 537 servers options specific to that region. 539 As with the previous example, the exact configuration syntax and 540 structure shown above does not precisely match what existing DHCP 541 servers do, but the behavior illustrated in this example can be 542 accomplished with most existing modern DHCP servers. 544 8. Dynamic Lookup 546 In the Regional example, the configuration listed several domain 547 names as values for the sip-servers and dns-servers options. The 548 wire format of both of these options contains one or more IPv6 549 addresses--there is no way to return a domain name to the client. 551 This was understood to be an issue when the original DHCP protocol 552 was defined, and historical implementations even from the very early 553 days would accept domain names and resolve them. Some early DHCP 554 implementations, particularly those based on earlier BOOTP 555 implementations, had very limited capacity for reconfiguration. 557 However, most modern DHCP servers handle name resolution by querying 558 the resolver each time a DHCP packet comes in. This means that if 559 DHCP servers and DNS servers are managed by different administrative 560 entities, there is no need for the administrators of the DHCP servers 561 and DNS servers to communicate when changes are made. When changes 562 are made to the DNS server, these changes are promptly and 563 automatically adopted by the DHCP server. Similarly, when DHCP 564 server configurations change, DNS server administrators need not be 565 aware of this. 567 However, it should be noted that even though the DHCP server may be 568 configured to query the DNS server every time it uses configured 569 names, the changes made in the DNS zone may not be visible to the 570 server until the DNS cache expires. If this is not desired, the DHCP 571 server can be configured to query the authoritative DNS server 572 directly, bypassing any caching DNS servers. 574 It's worth noting that DNS is not the only way to resolve names, and 575 not all DHCP servers support other techniques (e.g., NIS+ or WINS). 576 However, since these protocols have all but vanished from common use, 577 this won't be an issue in new deployments. 579 9. Multiple subnets on the same link 581 There are scenarios where there is more than one subnet from the same 582 protocol family (i.e. two or more IPv4 subnets or two or more IPv6 583 subnets) configured on the same layer 3 link. One example is a slow 584 network renumbering where some services are migrated to the new 585 addressing scheme, but some aren't yet. Second example is a cable 586 network, where cable modems and the devices connected behind them are 587 connected to the same layer 2 link. However, operators want the 588 cable modems and user devices to get addresses from distinct address 589 spaces, so users couldn't easily access their modems management 590 interfaces. Such a configuration is often referred to as 'shared 591 subnets' in Unix environments or 'multinet' in Microsoft terminology. 593 To support such an configuration, additional differentiating 594 information is required. Many DHCP server implementations offer a 595 feature that is typically called client classification. The server 596 segregates incoming packets into one or more classes based on certain 597 packet characteristics, e.g. presence or value of certains options or 598 even a match between existing options. Servers require additional 599 information to handle such configuration, as it can't use the 600 topographical property of the relay addresses alone to properly 601 choose a subnet. Such information is always implementation specific. 603 10. Acknowledgments 605 Thanks to Dave Thaler for suggesting that even though "everybody 606 knows" how DHCP servers are deployed in the real world, it might be 607 worthwhile to have an IETF document that explains what everybody 608 knows, because in reality not everybody is an expert in how DHCP 609 servers are administered. Thanks to Andre Kostur, Carsten Strotmann, 610 Simon Perreault, Jinmei Tatuya and Suresh Krishnan for their reviews, 611 comments and feedback. 613 11. Security Considerations 615 This document explains existing practice with respect to the use of 616 Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host 617 Configuration Protocol Version 6 [RFC3315]. The security 618 considerations for these protocols are described in their 619 specifications and in related documents that extend these protocols. 620 This document introduces no new functionality, and hence no new 621 security considerations. 623 12. IANA Considerations 625 The IANA is hereby absolved of any requirement to take any action in 626 relation to this document. 628 13. References 630 13.1. Normative References 632 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 633 2131, March 1997. 635 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 636 and M. Carney, "Dynamic Host Configuration Protocol for 637 IPv6 (DHCPv6)", RFC 3315, July 2003. 639 13.2. Informative References 641 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 642 STD 13, RFC 1034, November 1987. 644 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 645 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May 646 2011. 648 [RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 649 Reconfiguration from Relay Agents", RFC 6977, July 2013. 651 Authors' Addresses 653 Ted Lemon 654 Nominum, Inc. 655 2000 Seaport Blvd 656 Redwood City, CA 94063 657 USA 659 Phone: +1-650-381-6000 660 Email: Ted.Lemon@nominum.com 661 Tomek Mrugalski 662 Internet Systems Consortium, Inc. 663 950 Charter Street 664 Redwood City, CA 94063 665 USA 667 Phone: +1 650 423 1345 668 Email: tomasz.mrugalski@gmail.com