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