idnits 2.17.1 draft-ietf-dhc-topo-conf-01.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3696 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: Best Current Practice T. Mrugalski 5 Expires: August 18, 2014 Internet Systems Consortium, Inc. 6 February 14, 2014 8 Customizing DHCP Configuration on the Basis of Network Topology 9 draft-ietf-dhc-topo-conf-01 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 August 18, 2014. 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 . . . . . . . . . . . . . . . . . . 7 57 5. Relay agent running on a host . . . . . . . . . . . . . . . . 9 58 6. Cascade relays . . . . . . . . . . . . . . . . . . . . . . . 9 59 7. Regional Configuration Example . . . . . . . . . . . . . . . 9 60 8. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 11 61 9. Relay Agent Configurations . . . . . . . . . . . . . . . . . 12 62 10. Mutliple subnets on the same link . . . . . . . . . . . . . . 12 63 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 64 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 68 14.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 modern DHCP servers. 96 2. Terminology 98 an IP address with a scope of use wider than the local link. 100 provider edge router. The provider router closest to the customer. 102 customer premise equipment device. Typically a router belonging to 103 the customer that connects directly to the provider link. 105 3. Locality 107 Figure 1 illustrates a simple hierarchy of network links with Link D 108 serving as a backbone to which the DHCP server is attached. 110 Figure 2 illustrates a more complex case. Although some of its 111 aspects are unlikely to be seen in an actual production networks, 112 they are beneficial for explaining finer aspects of the DHCP 113 protocols. 115 Link A Link B 116 |===+===========| |===========+======| 117 | | 118 | | 119 +---+---+ +---+---+ 120 | relay | | relay | 121 | A | | B | 122 +---+---+ +---+---+ 123 | | 124 | Link C | 125 |===+==========+=================+======| 126 | 127 | 128 +----+---+ +--------+ 129 | router | | DHCP | 130 | A | | Server | 131 +----+---+ +----+---+ 132 | | 133 | | 134 | Link D | 135 |==============+=================+======| 136 | 137 | 138 +----+---+ 139 | router | 140 | B | 141 +----+---+ 142 | 143 | 144 |===+==========+=================+======| 145 | Link E | 146 | | 147 +---+---+ +---+---+ 148 | relay | | relay | 149 | C | | D | 150 +---+---+ +---+---+ 151 | | 152 | | 153 |===+===========| |===========+======| 154 Link F Link G 156 Figure 1: A simple network 158 Link A Link B Link H 159 |===+==========| |=========+======| |======+======| 160 | | | 161 | | | 162 +---+---+ +---+---+ +---+---+ 163 | relay | | relay | | relay | 164 | A | | B | | G | 165 +---+---+ +---+---+ +---+---+ 166 | | | 167 | Link C | | Link J 168 |===+==========+==============+======| |======+======| 169 | | 170 | | 171 +----+---+ +--------+ +---+---+ 172 | router | | DHCP | | relay | 173 | A | | Server | | F | 174 +----+---+ +----+---+ +---+---+ 175 | | | 176 | | | 177 | Link D | | 178 |==============+=========+=======+=============+======| 179 | | 180 | | 181 +----+---+ +---+---+ 182 | router | | relay | 183 | B | | E | 184 +----+---+ +---+---+ 185 | | 186 | | 187 |===+==========+=========+=======+======| 188 | Link E | 189 | | 190 +---+---+ +---+---+ 191 | relay | | relay | 192 | C | | D | 193 +---+---+ +---+---+ 194 | | 195 | | 196 |===+===========| |===========+======| 197 Link F Link G 199 Figure 2: Complex network 201 This diagram allows us to represent a variety of different network 202 configurations and illustrate how existing DHCP servers can provide 203 configuration information customized to the particular location from 204 which a client is making its request. 206 It's important to understand the background of how DHCP works when 207 considering this diagram. DHCP clients are assumed not to have 208 routable IP addresses when they are attempting to obtain 209 configuration information. 211 The reason for making this assumption is that one of the functions of 212 DHCP is to bootstrap the DHCP client's IP address configuration; if 213 the client does not yet have an IP address configuration, it cannot 214 route packets to an off-link DHCP server, and so some kind of relay 215 mechanism is required. 217 The details of how this works are different between DHCPv4 and 218 DHCPv6, but the essence is the same: whether or not the client 219 actually has an IP configuration, it generally communicates with the 220 DHCP server by sending its requests to a DHCP relay agent on the 221 local link; this relay agent, which has a routable IP address, then 222 forwards the DHCP requests to the DHCP server. In some cases in 223 DHCPv4, when a DHCP client has a routable IPv4 address, the message 224 is unicast to the DHCP server rather than going through a relay 225 agent. In DHCPv6 that is also possible in case where server is 226 configured with server unicast option and clients are able to take 227 advantage of it. In such case once the clients get their (presumably 228 global) addresses, they are able to contact server directly, 229 bypassing relays. It should be noted that such a mode is completely 230 controllable by administrators in DHCPv6. (They may simply choose to 231 not configure server unicast option, thus forcing clients to send 232 their messages always via relay agents). 234 In either case, the DHCP server is able to obtain an IP address that 235 it knows is on-link for the link to which the DHCP client is 236 connected: either the DHCPv4 client's routable IPv4 address, or the 237 relay agent's IP address on the link to which the client is 238 connected. 240 In DHCPv6 protocol, there are two mechanisms defined in [RFC3315] 241 that allow server to distinguish which link the relay agent is 242 connected to. The first mechanism is a link-address field in the 243 RELAY-FORW and RELAY-REPL messages. Somewhat contrary to its name, 244 relay agents insert an address that is typically global and can be 245 used to uniquely identify the link on which the client is located. 246 In normal circumstances this is the solution that is easiest to 247 maintain. It requires, however, for the relay agent to have an 248 address configured on its client-facing interface. If for whatever 249 reason that is not feasible (e.g. because the relay agent does not 250 have a global address), the relay agent includes an interface-id 251 option that identifies the link clients are connected to. It is up 252 to administrator to make sure that the interface-id is unique within 253 his administrative domain. 255 DHCPv6 also has support for more finely grained link identification, 256 using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA). In this 257 case, in addition to receiving an IPv6 address that is on-link for 258 the link to which the client is connected, the DHCPv6 server also 259 receives an Interface Identifier option from the relay agent that can 260 be used to more precisely identify the client's location on the 261 network. 263 What this means in practice is that the DHCP server in all cases has 264 sufficient information to pinpoint, at the very least, the layer 3 265 link to which the client is connected, and in some cases which layer 266 2 link the client is connected to, when the layer 3 link is 267 aggregated out of multiple layer 2 links. 269 In all cases, then, the DHCP server will have a link-identifying IP 270 address, and in some cases it may also have a link-specific 271 identifier. It should be noted that there is no guarantee that the 272 link-specific identifier will be unique outside the scope of the 273 link-identifying IP address. 275 It is also possible for link-specific identifiers to be nested, so 276 that the actual identifier that identifies the link is an aggregate 277 of two or more link-specific identifiers sent by a set of LDRAs in a 278 chain; in general this functions exactly as if a single identifier 279 were received from a single LDRA, so we do not treat it specially in 280 the discussion below, but sites that use chained LDRA configurations 281 will need to be aware of this when configuring their DHCP servers. 283 So let's examine the implications of this in terms of how a DHCP 284 server can deliver targeted supplemental configuration information to 285 DHCP clients. 287 4. Simple Subnetted Network 289 Consider Figure 1 in the context of a simple subnetted network. In 290 this network, there are four leaf subnets: links A, B, F and G, on 291 which DHCP clients will be configured. Relays A, B, C and D in this 292 example are represented in the diagram as IP routers with an embedded 293 relay function, because this is a very typical configuration, but the 294 relay function can also be provided in a separate server on each 295 link. 297 In a simple network like this, there may be no need for link-specific 298 configuration in DHCPv6, since local routing information is delivered 299 through router advertisements. However, in IPv4, it is very typical 300 to configure the default route using DHCP; in this case, the default 301 route will be different on each link. In order to accomplish this, 302 the DHCP server will need link-specific configuration for the default 303 route. 305 To illustrate, we will use an example from a hypothetical DHCP server 306 that uses a simple JSON notation for configuration. Although we know 307 of no DHCP server that uses this specific syntax, every commercial 308 DHCP server provides similar functionality. 310 {"prefixes": 311 {"10.0.0.0/24": {"options": {"routers": ["10.0.0.1"]} 312 "on-link": ["a"]}} 313 "10.0.1.0/24": {"options": {"routers": ["10.0.1.1"}} 314 "on-link": ["b"]} 315 "10.0.2.0/24": {"options": {"routers": ["10.0.2.1"}} 316 "on-link": ["f"]} 317 "10.0.3.0/24": {"options": {"routers": ["10.0.3.1"}} 318 "on-link": ["g"]}} 320 Figure 2 322 Figure 3 324 In Figure 3, we see a configuration example for this scenario: a set 325 of prefixes, each of which has a set of options and a list of links 326 for which it is on-link. We have defined one option for each prefix: 327 a routers option. This option contains a list of values; each list 328 only has one value, and that value is the IP address of the router 329 specific to the prefix. 331 When the DHCP server receives a request, it searches the list of 332 prefixes for one that encloses the link-identifying IP address 333 provided by the client or relay agent. The DHCP server then examines 334 the options list associated with that prefix and returns those 335 options to the client. 337 So for example a client connected to link A in the example would have 338 a link-identifying IP address within the 10.0.0.0/24 prefix, so the 339 DHCP server would match it to that prefix. Based on the 340 configuration, the DHCP server would then return a routers option 341 containing a single IP address: 10.0.0.1. A client on link F would 342 have a link-identifying address in the 10.0.2.0/24 prefix, and would 343 receive a routers option containing the IP address 10.0.2.1. 345 5. Relay agent running on a host 347 Relay agent is a DHCP software that may be run on any IP node. 348 Although it is typically run on a a router, it doesn't have to be 349 one. Relay agent can be run on a host connected to two links. That 350 case is presented in Figure 2. There is router B that is connected 351 to links D and E. At the same time there is also a host that is 352 connected to the same links. The relay agent software is running on 353 that host. That is uncommon, but legal configuration. 355 6. Cascade relays 357 Let's observe another case shown in Figure 2. Note that in typical 358 configuration, the clients connected to link G will send their 359 requests to relay D which will forward its packets directly to the 360 DHCP server. That is typical, but not the only possible 361 configuration. It is possible to configure relay agent D to forward 362 client messages to relay E which in turn will send it to the DHCP 363 server. This configuration is sometimes referred to as cascade relay 364 agents. 366 Note that the relaying mechanism works differently in DHCPv4 and in 367 DHCPv6. In DHCPv4 only the first relay is able to set the GIADDR 368 field in the DHCPv4 packet. Any following relays that receive that 369 packet will not change it as the server needs GIADDR information from 370 the first relay (i.e. the closest to the client). Server will send 371 the response back to the GIADDR address, which is the address of the 372 first relay agent that seen the client's message. That means that 373 the client messages travel on a different path than the server's 374 responses. A message from client connected to link G will travel via 375 relay D, relay E and to the server. A response message will be sent 376 from the server to relay D which will send it to the client on link 377 G. 379 Relaying in DHCPv6 is more structured. Each relay agent encapsulates 380 a packet that is destined to the server and sends it towards the 381 server. Depending on the configuration that can be server's unicast 382 address, a multicast address or next relay agent address. The next 383 relay repeats the encapsulation process. Although the resulting 384 packet is more complex (may have up to 32 levels of encapsulation if 385 traveled through 32 relays), every relay may insert its own options 386 and it is clear which relay agent inserted which option. 388 7. Regional Configuration Example 390 In this example, link C is a regional backbone for an ISP. Link E is 391 also a regional backbone for that ISP. Relays A, B, C and D are PE 392 routers, and Links A, B, F and G are actually link aggregators with 393 individual layer 2 circuits to each customer--for example, the relays 394 might be DSLAMs or cable head-end systems. At each customer site we 395 assume there is a single CPE device attached to the link. 397 We further assume that links A, B, F and G are each addressed by a 398 single prefix, although it would be equally valid for each CPE device 399 to be numbered on a separate prefix. 401 In a real-world deployment, there would likely be many more than two 402 PE routers connected to each regional backbone; we have kept the 403 number small for simplicity. 405 In this example, the goal is to configure all the devices within a 406 region with server addresses local to that region, so that service 407 traffic does not have to be routed between regions unnecessarily. 409 {"prefixes": 410 {"2001:DB8:0:0::/40": {"on-link": ["A"]}} 411 "2001:DB8:100:0::/40": {"on-link": ["B"]} 412 "2001:DB8:200:0::/40": {"on-link": ["F"]} 413 "2001:DB8:300:0::/40": {"on-link": ["G"]}} 415 {"links": 416 {"A": {"region": "omashu"}, 417 "B": {"region": "omashu"}, 418 "F": {"region": "gaoling"}, 419 "G": {"region": "gaoling"}}} 421 {"regions": 422 {"omashu": {"options": 423 {"sip-servers": ["sip.omashu.example.org"], 424 "dns-servers": ["dns1.omashu.example.org", 425 "dns2.omashu.example.org"]}}, 426 "gaoling": {"options": 427 {"sip-servers": ["sip.gaoling.example.org"], 428 "dns-servers": ["dns1.gaoling.example.org", 429 "dns2.gaoling.example.org"]}}}} 431 Figure 3 433 In this example, when a request comes in to the DHCP server with a 434 link-identifying IP address in the 2001:DB8:0:0::/40 prefix, it is 435 identified as being on link A. The DHCP server then looks on the 436 list of links to see what region the client is in. Link A is 437 identified as being in omashu. The DHCP server then looks up omashu 438 in the set of regions, and discovers a list of region-specific 439 options. 441 The DHCP server then resolves the domain names listed in the options 442 and sends a sip-server option containing the IP addresses that the 443 resolver returned for sip.omashu.example.org, and a dns-server option 444 containing the IP addresses returned by the resolver for 445 dns1.omashu.example.org and dns2.omashu.example.org. 447 Similarly, if the DHCP server receives a request from a DHCP client 448 where the link-identifying IP address is contained by the prefix 449 2001:DB8:300:0::/40, then the DHCP server identifies the client as 450 being connected to link G. The DHCP server then identifies link G as 451 being in the gaoling region, and returns the sip-servers and dns- 452 servers options specific to that region. 454 As with the previous example, the exact configuration syntax and 455 structure shown above does not precisely match what existing DHCP 456 servers do, but the behavior illustrated in this example can be 457 accomplished with all existing commercial DHCP servers. 459 8. Dynamic Lookup 461 In the Regional example, the configuration listed several domain 462 names as values for the sip-servers and dns-servers options. The 463 wire format of both of these options contains one or more IPv6 464 addresses--there is no way to return a domain name to the client. 466 This was understood to be an issue when the original DHCP protocol 467 was defined, and historical implementations even from the very early 468 days would accept domain names and resolve them. Some early DHCP 469 implementations, particularly those based on earlier BOOTP 470 implementations, had very limited capacity for reconfiguration. 472 However, all modern commercial DHCP servers handle name resolution by 473 querying the resolver each time a DHCP packet comes in. This means 474 that if DHCP servers and DNS servers are managed by different 475 administrative entities, there is no need for the administrators of 476 the DHCP servers and DNS servers to communicate when changes are 477 made. When changes are made to the DNS server, these changes are 478 immediately and automatically adopted by the DHCP server. Similarly, 479 when DHCP server configurations change, DNS server administrators 480 need not be aware of this. 482 It's worth noting that DNS is not the only way to resolve names, and 483 not all DHCP servers support other techniques (e.g., NIS+ or WINS). 484 However, since these protocols have all but vanished from common use, 485 this won't be an issue in new deployments. 487 9. Relay Agent Configurations 489 It's worth mentioning that although we talk about relay agents and 490 routers in this document mostly as if they are the same device, this 491 is by no means required by the DHCP protocol. The relay agent is 492 simply a service that operates on a link, receiving link-local 493 multicasts or broadcasts and relaying them, using IP routing, to a 494 DHCP server. As long as the relay has an IP address on the link, and 495 a default route or more specific route through which it can reach a 496 DHCP server, it need not be a router, or even have multiple 497 interfaces. 499 10. Mutliple subnets on the same link 501 There are scenarios where there is more than one subnet from the same 502 protocol family (i.e. two or more IPv4 subnets or two or more IPv6 503 subnets) configured on the same layer 3 link. One example is a slow 504 network renumbering where some services are migrated to the new 505 addressing scheme, but some aren't yet. Second example is a cable 506 network, where cable modems and the devices connected behind them are 507 connected to the same layer 2 link. However, operators want the 508 cable modems and user devices to get addresses from distinct address 509 spaces, so users couldn't easily access their modems management 510 interfaces. Such a configuration is often referred to as shared 511 subnets. 513 To support such an configuration, additional differentiating 514 information is required. Many DHCP server implementations offer a 515 feature that is typically called client classification. The server 516 segregates incoming packets into one or more classes based on certain 517 packet characteristics, e.g. presence or value of certains options or 518 even a match between existing options. Servers require additional 519 information to handle such configuration, as it can't use the 520 topographical property of the relay addresses alone to properly 521 choose a subnet. Such information is always implementation specific. 523 11. Acknowledgments 525 Thanks to Dave Thaler for suggesting that even though "everybody 526 knows" how DHCP servers are deployed in the real world, it might be 527 worthwhile to have an IETF document that explains what everybody 528 knows, because in reality not everybody is an expert in how DHCP 529 servers are administered. 531 12. Security Considerations 533 This document explains existing practice with respect to the use of 534 Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host 535 Configuration Protocol Version 6 [RFC3315]. The security 536 considerations for these protocols are described in their 537 specifications and in related documents that extend these protocols. 538 This document introduces no new functionality, and hence no new 539 security considerations. 541 13. IANA Considerations 543 The IANA is hereby absolved of any requirement to take any action in 544 relation to this document. 546 14. References 548 14.1. Normative References 550 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 551 2131, March 1997. 553 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 554 and M. Carney, "Dynamic Host Configuration Protocol for 555 IPv6 (DHCPv6)", RFC 3315, July 2003. 557 14.2. Informative References 559 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 560 STD 13, RFC 1034, November 1987. 562 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 563 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May 564 2011. 566 Authors' Addresses 568 Ted Lemon 569 Nominum, Inc. 570 2000 Seaport Blvd 571 Redwood City, CA 94063 572 USA 574 Phone: +1-650-381-6000 575 Email: Ted.Lemon@nominum.com 576 Tomek Mrugalski 577 Internet Systems Consortium, Inc. 578 950 Charter Street 579 Redwood City, CA 94063 580 USA 582 Phone: +1 650 423 1345 583 Email: tomasz.mrugalski@gmail.com