idnits 2.17.1 draft-ietf-dhc-topo-conf-05.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 (July 6, 2015) is 3210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: January 7, 2016 ISC 6 July 6, 2015 8 Customizing DHCP Configuration on the Basis of Network Topology 9 draft-ietf-dhc-topo-conf-05 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 January 7, 2016. 36 Copyright Notice 38 Copyright (c) 2015 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. Identifying Client's Location by DHCP Servers . . . . . . . . 3 56 3.1. DHCPv4 Specific Behavior . . . . . . . . . . . . . . . . 7 57 3.2. DHCPv6 Specific Behavior . . . . . . . . . . . . . . . . 7 58 4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 9 59 5. Relay agent running on a host . . . . . . . . . . . . . . . . 11 60 6. Cascade relays . . . . . . . . . . . . . . . . . . . . . . . 11 61 7. Regional Configuration Example . . . . . . . . . . . . . . . 12 62 8. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 14 63 9. Multiple subnets on the same link . . . . . . . . . . . . . . 15 64 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 65 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 66 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 69 13.2. Informative References . . . . . . . . . . . . . . . . . 16 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications 75 describe how addresses can be allocated to clients based on network 76 topology information provided by the DHCP relay infrastructure. 77 Address allocation decisions are integral to the allocation of 78 addresses and prefixes in DHCP. 80 The DHCP protocol also describes mechanisms for provisioning devices 81 with additional configuration information; for example, DNS [RFC1034] 82 server addresses, default DNS search domains, and similar 83 information. 85 Although it was the intent of the authors of these specifications 86 that DHCP servers would provision devices with configuration 87 information appropriate to each device's location on the network, 88 this practice was never documented, much less described in detail. 90 Existing DHCP server implementations do in fact provide such 91 capabilities; the goal of this document is to describe those 92 capabilities for the benefit both of operators and of protocol 93 designers who may wish to use DHCP as a means for configuring their 94 own services, but may not be aware of the capabilities provided by 95 most modern DHCP servers. 97 2. Terminology 99 o Routable IP address: an IP address with a scope of use wider than 100 the local link. 102 o PE router: provider edge router. The provider router closest to 103 the customer. 105 o CPE device: customer premise equipment device. Typically a router 106 belonging to the customer that connects directly to the provider 107 link. 109 o Shared subnet: a case where two or more subnets of the same 110 protocol family are available on the same link. 'Shared subnet' 111 terminology is typically used in Unix environments. It is 112 typically called 'multinet' in Windows environment. The 113 administrative configuration inside a Microsoft DHCP server is 114 called 'DHCP Superscope'. 116 3. Identifying Client's Location by DHCP Servers 118 Figure 1 illustrates a small hierarchy of network links with Link D 119 serving as a backbone to which the DHCP server is attached. 121 Figure 2 illustrates a more complex case. Although some of its 122 aspects are unlikely to be seen in an actual production networks, 123 they are beneficial for explaining finer aspects of the DHCP 124 protocols. Note that some nodes act as routers (which forward all 125 IPv6 traffic) and some are relay agents (i.e. run DHCPv6 specific 126 software that forwards only DHCPv6 traffic). 128 Link A Link B 129 |===+===========| |===========+======| 130 | | 131 | | 132 +---+---+ +---+---+ 133 | relay | | relay | 134 | A | | B | 135 +---+---+ +---+---+ 136 | | 137 | Link C | 138 |===+==========+=================+======| 139 | 140 | 141 +----+---+ +--------+ 142 | router | | DHCP | 143 | A | | Server | 144 +----+---+ +----+---+ 145 | | 146 | | 147 | Link D | 148 |==============+=================+======| 149 | 150 | 151 +----+---+ 152 | router | 153 | B | 154 +----+---+ 155 | 156 | 157 |===+==========+=================+======| 158 | Link E | 159 | | 160 +---+---+ +---+---+ 161 | relay | | relay | 162 | C | | D | 163 +---+---+ +---+---+ 164 | | 165 | | 166 |===+===========| |===========+======| 167 Link F Link G 169 Figure 1: A simple network with a small hierarchy of links 170 Link A Link B Link H 171 |===+==========| |=========+======| |======+======| 172 | | | 173 | | | 174 +---+---+ +---+---+ +---+---+ 175 | relay | | relay | | relay | 176 | A | | B | | G | 177 +---+---+ +---+---+ +---+---+ 178 | | | 179 | Link C | | Link J 180 |===+==========+==============+======| |======+======| 181 | | 182 | | 183 +----+---+ +--------+ +---+---+ 184 | router | | DHCP | | relay | 185 | A | | Server | | F | 186 +----+---+ +----+---+ +---+---+ 187 | | | 188 | | | 189 | Link D | | 190 |==============+=========+=======+=============+======| 191 | | 192 | | 193 +----+---+ +---+---+ 194 | router | | relay | 195 | B | | E | 196 +----+---+ +---+---+ 197 | | 198 | | 199 |===+==========+=========+=======+======| 200 | Link E | 201 | | 202 +---+---+ +---+---+ 203 | relay | | relay | 204 | C | | D | 205 +---+---+ +---+---+ 206 | | 207 | | 208 |===+===========| |===========+======| 209 Link F Link G 211 Figure 2: Complex network 213 Those diagrams allow us to represent a variety of different network 214 configurations and illustrate how existing DHCP servers can provide 215 configuration information customized to the particular location from 216 which a client is making its request. 218 It is important to understand the background of how DHCP works when 219 considering those diagrams. It is assumed that the DHCP clients may 220 not have routable IP addresses when they are attempting to obtain 221 configuration information. 223 The reason for making this assumption is that one of the functions of 224 DHCP is to bootstrap the DHCP client's IP address configuration; if 225 the client does not yet have an IP address configured, it cannot 226 route packets to an off-link DHCP server, therefore some kind of 227 relay mechanism is required. 229 The details of how packet delivery between clients and servers works 230 are different between DHCPv4 and DHCPv6, but the essence is the same: 231 whether or not the client actually has an IP configuration, it 232 generally communicates with the DHCP server by sending its requests 233 to a DHCP relay agent on the local link; this relay agent, which has 234 a routable IP address, then forwards the DHCP requests to the DHCP 235 server (directly or via other relays). In later stages of the 236 configuration when the client has aquired an address and certain 237 conditions are met, it is possible for the client to send packets 238 directly to the server, thus bypassing the relays. The conditions 239 for such behavior are different for DHCPv4 and DHCPv6 and are 240 discussed in sections Section 3.1 and Section 3.2. 242 The DHCP server uses an IP address from the client's message which is 243 on the same link as the client to perform address assignment 244 decisions or to select subnet-specific configuration for the client. 245 The address that the server uses is the DHCP client's routable IP 246 address or the client facing address of the relay agent. The server 247 is then able to determine the client's point of attachment and select 248 appropriate subnet- or link-specific configuration. 250 Sometimes it is useful for the relay agents to provide additional 251 about the topology. A number of extensions have been defined for 252 this purpose. The specifics are different, but the core principle 253 remains the same: the relay agent knows exactly where the original 254 request came from, so it provides an indentifier that will help the 255 server to choose appropriate address pool and configuration 256 parameters. Examples of such options are mentioned in the following 257 sections. 259 Finally, clients may be connected to the same link as the server, so 260 no relay agents are required. In such cases, the DHCPv4 server 261 typically uses the IPv4 address assigned to the network interface 262 over which the transmission was received to select appropriate 263 subnet. This is more complicated for DHCPv6, as the DHCPv6 server is 264 not required to have any globally unique addresses. In such cases, 265 an additional configuration information may be required. Some 266 servers allow indicating that a given subnet is directly reachable 267 over specific local network interface. 269 3.1. DHCPv4 Specific Behavior 271 In some cases in DHCPv4, when a DHCPv4 client has a routable IPv4 272 address, the message is unicast to the DHCPv4 server rather than 273 going through a relay agent. Examples of such transmissions are 274 renewal (DHCPREQUEST) and address release (DHCPRELEASE). 276 The relay agent that receives client's message sets GIADDR field to 277 the address of the network interface the message was received on. 278 The relay agent may insert a relay agent option [RFC3046]. 280 There are several options defined that are useful for subnet 281 selection in DHCPv4. [RFC3527] defines Link Selection sub-option 282 that is iserted by a relay agent. This option is particularly useful 283 when the relay agent needs to specify the subnet/link on which a DHCP 284 client resides, which is different from an IP address that can be 285 used to communicate with the relay agent. Virtual Subnet Selection 286 Option, specified in [RFC6607] is used for the same purpose (i.e. 287 relay agents insert that information), but it also covers additional 288 use cases in VPN environment. In certain cases it is useful for the 289 client itself to specify this option, e.g. when there are no relay 290 agents involved during VPN set up process. 292 Another option that may influence the subnet selection is IPv4 Subnet 293 Selection Option, defined in [RFC3011], which allows the client to 294 explicitly request allocation from a given subnet. 296 3.2. DHCPv6 Specific Behavior 298 In DHCPv6 unicast communication is possible in case where the server 299 is configured with a Server Unicast option (see Section 22.12 in 300 [RFC3315]) and clients are able to take advantage of it. In such 301 cases, once a client is assigned a, presumably global, address, it is 302 able to contact the server directly, bypassing any relays. It should 303 be noted that such a mode is completely controllable by 304 administrators in DHCPv6. (They may simply choose to not configure 305 server unicast option, thus forcing clients to send their messages 306 always via relay agents in every case). 308 In the DHCPv6 protocol, there are two core mechanisms defined in 309 [RFC3315] that allow server to distinguish which link the relay agent 310 is connected to. The first mechanism is a link-address field in the 311 Relay-forward and Relay-reply messages. Somewhat contrary to its 312 name, relay agents insert in the link-address field an address that 313 is typically global and can be used to uniquely identify the link on 314 which the client is located. In normal circumstances this is the 315 solution that is easiest to maintain, as existing address assignments 316 can be used and no additional administrative actions (like assigning 317 dedicated identifers for each relay agent, making sure they are 318 unique and maintaining a list of such identifiers) are needed. It 319 requires, however, for the relay agent to have an address with a 320 scope larger than link-local configured on its client-facing 321 interface. 323 If for whatever reason that is not feasible (e.g. because the relay 324 agent does not have a global address or ULA [RFC4193] configured on 325 the client-facing interface), the relay agent includes an Interface- 326 Id option (see Section 22.18 of [RFC3315]) that identifies the link 327 clients are connected to. If the interface-id is unique within an 328 administrative domain, the interface-id value may be used to select 329 the appropriate subnet. As there is no guarantee for the uniqueness 330 ([RFC3315] only mandates the interface-id to be unique within a 331 single relay agent context), it is up to the administrator to check 332 whether the relay agents deployed use unique interface-id values. If 333 they aren't, Interface-id cannot be used to determine client's point 334 of attachment. 336 It should be noted that Relay-forward and Relay-reply messages are 337 exchanged between relays and servers only. Clients are never exposed 338 to those messages. Also, servers never receive Relay-reply messages. 339 Relay agents must be able to process both Relay-forward (sending 340 already relayed message further towards the server, when there is 341 more than one relay agent in a chain) and Relay-reply (when sending 342 back the response towards the client, when there is more than one 343 relay agent in a chain). 345 For completeness, we also mention an uncommon, but valid case, where 346 relay agents set link-local address in the link-address field in 347 relayed Relay-forward messages. This may happen if the relay agent 348 doesn't have any address with a larger scope. Even though link local 349 addresses cannot be automatically used to associate relay agent with 350 a given link, with sufficient information provided the server is 351 still able to correctly select the proper link. That requires the 352 DHCP server software to be able to specify relay agent link-address 353 or a feature similar to 'shared subnets' (see Section 9). Network 354 administrator has to manually configure additional information that a 355 given subnet uses a relay agent with link-address X. Alternatively, 356 if the relay agent uses link address X and relays messages from a 357 subnet A, an administrator can configure that subnet A is a shared 358 subnet with a very small X/128 subnet. That is not a recommended 359 configuration, but in cases where it is impossible for relay agents 360 to get an address from the subnet they are relaying from, it may be a 361 viable solution. 363 DHCPv6 also has support for more finely grained link identification, 364 using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA). In this 365 case, the link-address field is set to Unspecified_address (::), but 366 the DHCPv6 server also receives an Interface-Id option from the relay 367 agent that can be used to more precisely identify the client's 368 location on the network. 370 What this means in practice is that the DHCP server in all cases has 371 sufficient information to pinpoint, at the very least, the layer 3 372 link to which the client is connected, and in some cases which layer 373 2 link the client is connected to, when the layer 3 link is 374 aggregated out of multiple layer 2 links. 376 In all cases, then, the DHCP server will have a link-identifying IP 377 address, and in some cases it may also have a link-specific 378 identifier (e.g. Interface-Id Option or Link Address Option defined 379 in Section 5 of [RFC6977]). It should be noted that there the link- 380 specific identifier is unique only within the scope of the link- 381 identifying IP address. For example, link-specific indentifier of 382 "eth0" for a relay agent with IPv4 address 192.0.2.1 means something 383 different than "eth0" for a relay agent with address 192.0.2.123. 385 It is also possible for link-specific identifiers to be nested, so 386 that the actual identifier that identifies the link is an aggregate 387 of two or more link-specific identifiers sent by a set of LDRAs in a 388 chain; in general this functions exactly as if a single identifier 389 were received from a single LDRA, so we do not treat it specially in 390 the discussion below, but sites that use chained LDRA configurations 391 will need to be aware of this when configuring their DHCP servers. 393 The Virtual Subnet Selection Options, present in DHCPv4, are also 394 defined for DHCPv6. The use case is the same as in DHCPv4: the relay 395 agent inserts VSS options that can help the server to select the 396 appropriate subnet with its address pool and associated configuration 397 options. See [RFC6607] for details. 399 4. Simple Subnetted Network 401 Consider Figure 1 in the context of a simple subnetted network. In 402 this network, there are four leaf subnets: links A, B, F and G, on 403 which DHCP clients will be configured. Relays A, B, C and D in this 404 example are represented in the diagram as IP routers with an embedded 405 relay function, because this is a very typical configuration, but the 406 relay function can also be provided in a separate node on each link. 408 In a simple network like this, there may be no need for link-specific 409 configuration in DHCPv6, since local routing information is delivered 410 through router advertisements. However, in IPv4, it is very typical 411 to configure the default route using DHCP; in this case, the default 412 route will be different on each link. In order to accomplish this, 413 the DHCP server will need link-specific configuration for the default 414 route. 416 To illustrate, we will use an example from a hypothetical DHCP server 417 that uses a simple JSON notation [RFC7159] for configuration. 418 Although we know of no DHCP server that uses this specific syntax, 419 most modern DHCP server provides similar functionality. 421 { 422 "prefixes": { 423 "192.0.2.0/26": { 424 "options": { 425 "routers": ["192.0.2.1"] 426 }, 427 "on-link": ["A"] 428 }, 429 "192.0.2.64/26": { 430 "options": { 431 "routers": ["192.0.2.65"] 432 }, 433 "on-link": ["B"] 434 }, 435 "192.0.2.128/26": { 436 "options": { 437 "routers": ["192.0.2.129"] 438 }, 439 "on-link": ["F"] 440 }, 441 "192.0.2.192/26": { 442 "options": { 443 "routers": ["192.0.2.193"] 444 }, 445 "on-link": ["G"] 446 } 447 } 448 } 450 Figure 3: Configuration example 452 In Figure 3, we see a configuration example for this scenario: a set 453 of prefixes, each of which has a set of options and a list of links 454 for which it is on-link. We have defined one option for each prefix: 455 a routers option. This option contains a list of values; each list 456 only has one value, and that value is the IP address of the router 457 specific to the prefix. 459 When the DHCP server receives a request, it searches the list of 460 prefixes for one that encloses the link-identifying IP address 461 provided by the client or relay agent. The DHCP server then examines 462 the options list associated with that prefix and returns those 463 options to the client. 465 So for example a client connected to link A in the example would have 466 a link-identifying IP address within the 192.0.2.0/26 prefix, so the 467 DHCP server would match it to that prefix. Based on the 468 configuration, the DHCP server would then return a routers option 469 containing a single IP address: 192.0.2.1. A client on link F would 470 have a link-identifying address in the 192.0.2.128/26 prefix, and 471 would receive a routers option containing the IP address 192.0.2.129. 473 5. Relay agent running on a host 475 A relay agent is a DHCP software that may be run on any IP node. 476 Although it is typically run on a router, this is by no means 477 required by the DHCP protocol. The relay agent is simply a service 478 that operates on a link, receiving link-local multicasts (IPv6) or 479 broadcasts (IPv4) and relaying them, using IP routing, to a DHCP 480 server. As long as the relay has an IP address on the link, and a 481 default route or more specific route through which it can reach a 482 DHCP server, it need not be a router, or even have multiple 483 interfaces. 485 A relay agent can be run on a host connected to two links. That case 486 is presented in Figure 2. There is router B that is connected to 487 links D and E. At the same time there is also a host that is 488 connected to the same links. The relay agent software is running on 489 that host. That is uncommon, but a valid configuration. 491 6. Cascade relays 493 Let's observe another case, shown in Figure 2. Note that in this 494 configuration, the clients connected to link G will send their 495 requests to relay D which will forward its packets directly to the 496 DHCP server. That is typical, but not the only possible 497 configuration. It is possible to configure relay agent D to forward 498 client messages to relay E which in turn will send it to the DHCP 499 server. This configuration is sometimes referred to as cascade relay 500 agents. 502 Note that the relaying mechanism works differently in DHCPv4 and in 503 DHCPv6. In DHCPv4 only the first relay is able to set the GIADDR 504 field in the DHCPv4 packet. Any following relays that receive that 505 packet will not change it as the server needs GIADDR information from 506 the first relay (i.e. the closest to the client). The server will 507 send the response back to the GIADDR address, which is the address of 508 the first relay agent that saw the client's message. That means that 509 the client messages travel on a different path than the server's 510 responses. A message from client connected to link G will travel via 511 relay D, relay E and to the server. A response message will be sent 512 from the server to relay D via router B, and relay D will send it to 513 the client on link G. 515 Relaying in DHCPv6 is more structured. Each relay agent encapsulates 516 a packet that is destined to the server and sends it towards the 517 server. Depending on the configuration, that can be a server's 518 unicast address, a multicast address or next relay agent address. 519 The next relay repeats the encapsulation process. Although the 520 resulting packet is more complex (may have up to 32 levels of 521 encapsulation if the packet traveled through 32 relays), every relay 522 may insert its own options and it is clear which relay agent inserted 523 which option. 525 7. Regional Configuration Example 527 In the Figure 2 example, link C is a regional backbone for an ISP. 528 Link E is also a regional backbone for that ISP. Relays A, B, C and 529 D are PE routers, and Links A, B, F and G are actually link 530 aggregators with individual layer 2 circuits to each customer--for 531 example, the relays might be DSLAMs or cable head-end systems. At 532 each customer site we assume there is a single CPE device attached to 533 the link. 535 We further assume that links A, B, F and G are each addressed by a 536 single prefix, although it would be equally valid for each CPE device 537 to be numbered on a separate prefix. 539 In a real-world deployment, there would likely be many more than two 540 PE routers connected to each regional backbone; we have kept the 541 number small for simplicity. 543 In the example presented in Figure 4, the goal is to configure all 544 the devices within a region with server addresses local to that 545 region, so that service traffic does not have to be routed between 546 regions unnecessarily. 548 { 549 "prefixes": { 550 "2001:db8:0:0::/40": { 551 "on-link": ["A"] 552 }, 553 "2001:db8:100:0::/40": { 554 "on-link": ["B"] 555 }, 556 "2001:db8:200:0::/40": { 557 "on-link": ["F"] 558 }, 559 "2001:db8:300:0::/40": { 560 "on-link": ["G"] 561 } 562 }, 563 "links": { 564 "A": {"region": "omashu"}, 565 "B": {"region": "omashu"}, 566 "F": {"region": "gaoling"}, 567 "G": {"region": "gaoling"} 568 }, 569 "regions": { 570 "omashu": { 571 "options": { 572 "sip-servers": ["sip.omashu.example.org"], 573 "dns-servers": ["dns1.omashu.example.org", 574 "dns2.omashu.example.org"] 575 } 576 }, 577 "gaoling": { 578 "options": { 579 "sip-servers": ["sip.gaoling.example.org"], 580 "dns-servers": ["dns1.gaoling.example.org", 581 "dns2.gaoling.example.org"] 582 } 583 } 584 } 585 } 587 Figure 4: An example regions configuration 589 In this example, when a request comes in to the DHCP server with a 590 link-identifying IP address in the 2001:DB8:0:0::/40 prefix, it is 591 identified as being on link A. The DHCP server then looks on the 592 list of links to see what region the client is in. Link A is 593 identified as being in omashu. The DHCP server then looks up omashu 594 in the set of regions, and discovers a list of region-specific 595 options. 597 The DHCP server then resolves the domain names listed in the options 598 and sends a sip-server option containing the IP addresses that the 599 resolver returned for sip.omashu.example.org, and a dns-server option 600 containing the IP addresses returned by the resolver for 601 dns1.omashu.example.org and dns2.omashu.example.org. Depending on 602 the server capability and configuration, it may cache resolved 603 responses for specific period of time, repeat queries every time or 604 even keep the response until reconfiguration or shutdown. 606 Similarly, if the DHCP server receives a request from a DHCP client 607 where the link-identifying IP address is contained by the prefix 608 2001:DB8:300:0::/40, then the DHCP server identifies the client as 609 being connected to link G. The DHCP server then identifies link G as 610 being in the gaoling region, and returns the sip-servers and dns- 611 servers options specific to that region. 613 As with the previous example, the exact configuration syntax and 614 structure shown above does not precisely match what existing DHCP 615 servers do, but the behavior illustrated in this example can be 616 accomplished with most existing modern DHCP servers. 618 8. Dynamic Lookup 620 In the Regional example, the configuration listed several domain 621 names as values for the sip-servers and dns-servers options. The 622 wire format of both of these options contains one or more IPv6 623 addresses--there is no way to return a domain name to the client. 625 This was understood to be an issue when the original DHCP protocol 626 was defined, and historical implementations even from the very early 627 days would accept domain names and resolve them. Some early DHCP 628 implementations, particularly those based on earlier BOOTP 629 implementations, had very limited capacity for reconfiguration. 631 However, most modern DHCP servers handle name resolution by querying 632 the resolver each time a DHCP packet comes in. This means that if 633 DHCP servers and DNS servers are managed by different administrative 634 entities, there is no need for the administrators of the DHCP servers 635 and DNS servers to communicate when changes are made. When changes 636 are made to the DNS server, these changes are promptly and 637 automatically adopted by the DHCP server, as long as the DNS server 638 is managed appropriately (see the next paragraph). Similarly, when 639 DHCP server configurations change, DNS server administrators need not 640 be aware of this. 642 It should be noted that even though the DHCP server may be configured 643 to query the DNS resolver every time it uses configured names, the 644 changes made in the DNS zone may not be visible to the server until 645 the DNS cache expires. In general, it is the responsibility of the 646 DNS zone's administrator to ensure that existing cache does not cause 647 a trouble when a change is made to the zone; it should be usually 648 reasonable for the DHCP server to rely on it. However, if this is 649 not desired or if the management of the DNS zone is not very 650 reliable, the DHCP server can be configured to query the 651 authoritative DNS server directly, bypassing any caching DNS servers. 653 It is worth noting that DNS is not the only way to resolve names, and 654 not all DHCP servers support other techniques (e.g., NIS+ or WINS). 655 However, since these protocols have all but vanished from common use, 656 this won't be an issue in new deployments. 658 9. Multiple subnets on the same link 660 There are scenarios where there is more than one subnet from the same 661 protocol family (i.e. two or more IPv4 subnets or two or more IPv6 662 subnets) configured on the same layer 3 link. One example is a slow 663 network renumbering where some services are migrated to the new 664 addressing scheme, but some aren't yet. Second example is a cable 665 network, where cable modems and the devices connected behind them are 666 connected to the same layer 2 link. However, operators want the 667 cable modems and user devices to get addresses from distinct address 668 spaces, so users couldn't easily access their modems management 669 interfaces. Such a configuration is often referred to as 'shared 670 subnets' in Unix environments or 'multinet' in Microsoft terminology. 672 To support such a configuration, additional differentiating 673 information is required. Many DHCP server implementations offer a 674 feature that is typically called client classification. The server 675 segregates incoming packets into one or more classes based on certain 676 packet characteristics, e.g. presence or value of certain options or 677 even a match between existing options. Servers require additional 678 information to handle such configuration, as they cannot use the 679 topographical property of the relay addresses alone to properly 680 choose a subnet. Exact details of such operation is not part of the 681 DHCPv4 or DHCPv6 protocols and is implementation dependent. 683 10. Acknowledgments 685 Thanks to Dave Thaler for suggesting that even though "everybody 686 knows" how DHCP servers are deployed in the real world, it might be 687 worthwhile to have an IETF document that explains what everybody 688 knows, because in reality not everybody is an expert in how DHCP 689 servers are administered. Thanks to Andre Kostur, Carsten Strotmann, 690 Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean- 691 Francois Tremblay, Marcin Siodelski and Bernie Volz for their 692 reviews, comments and feedback. 694 11. Security Considerations 696 This document explains existing practice with respect to the use of 697 Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host 698 Configuration Protocol Version 6 [RFC3315]. The security 699 considerations for these protocols are described in their 700 specifications and in related documents that extend these protocols. 701 This document introduces no new functionality, and hence no new 702 security considerations. 704 12. IANA Considerations 706 The IANA is hereby absolved of any requirement to take any action in 707 relation to this document. 709 13. References 711 13.1. Normative References 713 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 714 2131, March 1997. 716 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 717 and M. Carney, "Dynamic Host Configuration Protocol for 718 IPv6 (DHCPv6)", RFC 3315, July 2003. 720 13.2. Informative References 722 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 723 STD 13, RFC 1034, November 1987. 725 [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", 726 RFC 3011, November 2000. 728 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 729 3046, January 2001. 731 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 732 "Link Selection sub-option for the Relay Agent Information 733 Option for DHCPv4", RFC 3527, April 2003. 735 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 736 Addresses", RFC 4193, October 2005. 738 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 739 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May 740 2011. 742 [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet 743 Selection Options for DHCPv4 and DHCPv6", RFC 6607, April 744 2012. 746 [RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 747 Reconfiguration from Relay Agents", RFC 6977, July 2013. 749 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 750 Interchange Format", RFC 7159, March 2014. 752 Authors' Addresses 754 Ted Lemon 755 Nominum, Inc. 756 2000 Seaport Blvd 757 Redwood City, CA 94063 758 USA 760 Phone: +1-650-381-6000 761 Email: Ted.Lemon@nominum.com 763 Tomek Mrugalski 764 Internet Systems Consortium, Inc. 765 950 Charter Street 766 Redwood City, CA 94063 767 USA 769 Phone: +1 650 423 1345 770 Email: tomasz.mrugalski@gmail.com