idnits 2.17.1 draft-ietf-dhc-topo-conf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (October 22, 2013) is 3838 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: April 25, 2014 Internet Systems Consortium, Inc. 6 October 22, 2013 8 Customizing DHCP Configuration on the Basis of Network Topology 9 draft-ietf-dhc-topo-conf-00 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 April 25, 2014. 36 Copyright Notice 38 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . 5 57 5. Regional Configuration Example . . . . . . . . . . . . . . . 7 58 6. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 8 59 7. Relay Agent Configurations . . . . . . . . . . . . . . . . . 9 60 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 65 11.2. Informative References . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications 71 describe how addresses can be allocated to clients based on network 72 topology information provided by the DHCP relay infrastructure. 73 Address allocation decisions are integral to the allocation of 74 addresses and prefixes in DHCP. 76 The DHCP protocol also describes mechanisms for provisioning devices 77 with additional configuration information; for example, DNS [RFC1034] 78 server addresses, default DNS search domains, and similar 79 information. 81 Although it was the intent of the authors of these specifications 82 that DHCP servers would provision devices with configuration 83 information appropriate to each device's location on the network, 84 this practice was never documented, much less described in detail. 86 Existing DHCP server implementations do in fact provide such 87 capabilities; the goal of this document is to describe those 88 capabilities for the benefit both of operators and of protocol 89 designers who may wish to use DHCP as a means for configuring their 90 own servies, but may not be aware of the capabilities provided by 91 modern DHCP servers. 93 2. Terminology 95 an IP address with a scope of use wider than the local link. 97 provider edge router. The provider router closest to the customer. 99 customer premise equipment device. Typically a router belonging to 100 the customer that connects directly to the provider link. 102 3. Locality 104 Figure 1 illustrates a simple hierarchy of network links with Link D 105 serving as a backbone to which the DHCP server is attached. 107 Link A Link B 108 |===+===========| |===========+======| 109 | | 110 | | 111 +---+---+ +---+---+ 112 | relay | | relay | 113 | A | | B | 114 +---+---+ +---+---+ 115 | | 116 | Link C | 117 |===+==========+=================+======| 118 | 119 | 120 +----+---+ +--------+ 121 | router | | DHCP | 122 | A | | Server | 123 +----+---+ +----+---+ 124 | | 125 | | 126 | Link D | 127 |==============+=================+======| 128 | 129 | 130 +----+---+ 131 | router | 132 | B | 133 +----+---+ 134 | 135 | 136 |===+==========+=================+======| 137 | Link E | 138 | | 139 +---+---+ +---+---+ 140 | relay | | relay | 141 | C | | D | 142 +---+---+ +---+---+ 143 | | 144 | | 145 |===+===========| |===========+======| 146 Link F Link G 148 Figure 1 150 This diagram allows us to represent a variety of different network 151 configurations and illustrate how existing DHCP servers can provide 152 configuration information customized to the particular location from 153 which a client is making its request. 155 It's important to understand the background of how DHCP works when 156 considering this diagram. DHCP clients are assumed not to have 157 routable IP addresses when they are attempting to obtain 158 configuration information. 160 The reason for making this assumption is that one of the functions of 161 DHCP is to bootstrap the DHCP client's IP address configuration; if 162 the client does not yet have an IP address configuration, it cannot 163 route packets to an off-link DHCP server, and so some kind of relay 164 mechanism is required. 166 The details of how this works are different between DHCPv4 and 167 DHCPv6, but the essence is the same: whether or not the client 168 actually has an IP configuration, it generally communicates with the 169 DHCP server by sending its requests to a DHCP relay agent on the 170 local link; this relay agent, which has a routable IP address, then 171 forwards the DHCP requests to the DHCP server. In some cases in 172 DHCPv4, when a DHCP client has a routable IPv4 address, the message 173 is unicast to the DHCP server rather than going through a relay 174 agent. 176 In either case, the DHCP server is able to obtain an IP address that 177 it knows is on-link for the link to which the DHCP client is 178 connected: either the DHCPv4 client's routable IPv4 address, or the 179 relay agent's IP address on the link to which the client is 180 connected. 182 DHCPv6 also has support for more finely grained link identification, 183 using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA). In this 184 case, in addition to receiving an IPv6 address that is on-link for 185 the link to which the client is connected, the DHCPv6 server also 186 receives an Interface Identifier option from the relay agent that can 187 be used to more precisely identify the client's location on the 188 network. 190 What this means in practice is that the DHCP server in all cases has 191 sufficient information to pinpoint, at the very least, the layer 3 192 link to which the client is connected, and in some cases which layer 193 2 link the client is connected to, when the layer 3 link is 194 aggregated out of multiple layer 2 links. 196 In all cases, then, the DHCP server will have a link-identifying IP 197 address, and in some cases it may also have a link-specific 198 identifier. It should be noted that there is no guarantee that the 199 link-specific identifier will be unique outside the scope of the 200 link-identifying IP address. 202 It is also possible for link-specific identifiers to be nested, so 203 that the actual identifier that identifies the link is an aggregate 204 of two or more link-specific identifiers sent by a set of LDRAs in a 205 chain; in general this functions exactly as if a single identifier 206 were received from a single LDRA, so we do not treat it specially in 207 the discussion below, but sites that use chained LDRA configurations 208 will need to be aware of this when configuring their DHCP servers. 210 So let's examine the implications of this in terms of how a DHCP 211 server can deliver targeted supplemental configuration information to 212 DHCP clients. 214 4. Simple Subnetted Network 216 Consider Figure 1 in the context of a simple subnetted network. In 217 this network, there are four leaf subnets: links A, B, F and G, on 218 which DHCP clients will be configured. Relays A, B, C and D in this 219 example are represented in the diagram as IP routers with an embedded 220 relay function, because this is a very typical configuration, but the 221 relay function can also be provided in a separate server on each 222 link. 224 In a simple network like this, there may be no need for link-specific 225 configuration in DHCPv6, since local routing information is delivered 226 through router advertisements. However, in IPv4, it is very typical 227 to configure the default route using DHCP; in this case, the default 228 route will be different on each link. In order to accomplish this, 229 the DHCP server will need link-specific configuration for the default 230 route. 232 To illustrate, we will use an example from a hypothetical DHCP server 233 that uses a simple JSON notation for configuration. Although we know 234 of no DHCP server that uses this specific syntax, every commercial 235 DHCP server provides similar functionality. 237 {"prefixes": 238 {"10.0.0.0/24": {"options": {"routers": ["10.0.0.1"]} 239 "on-link": ["a"]}} 240 "10.0.1.0/24": {"options": {"routers": ["10.0.1.1"}} 241 "on-link": ["b"]} 242 "10.0.2.0/24": {"options": {"routers": ["10.0.2.1"}} 243 "on-link": ["f"]} 244 "10.0.3.0/24": {"options": {"routers": ["10.0.3.1"}} 245 "on-link": ["g"]}} 247 Figure 2 249 In figure 2, we see a configuration example for this scenario: a set 250 of prefixes, each of which has a set of options and a list of links 251 for which it is on-link. We have defined one option for each prefix: 252 a routers option. This option contains a list of values; each list 253 only has one value, and that value is the IP address of the router 254 specific to the prefix. 256 When the DHCP server receives a request, it searches the list of 257 prefixes for one that encloses the link-identifying IP address 258 provided by the client or relay agent. The DHCP server then examines 259 the options list associated with that prefix and returns those 260 options to the client. 262 So for example a client connected to link A in the example would have 263 a link-identifying IP address within the 10.0.0.0/24 prefix, so the 264 DHCP server would match it to that prefix. Based on the 265 configuration, the DHCP server would then return a routers option 266 containing a single IP address: 10.0.0.1. A client on link F would 267 have a link-identifying address in the 10.0.2.0/24 prefix, and would 268 receive a routers option containing the IP address 10.0.2.1. 270 5. Regional Configuration Example 272 In this example, link C is a regional backbone for an ISP. Link E is 273 also a regional backbone for that ISP. Relays A, B, C and D are PE 274 routers, and Links A, B, F and G are actually link aggregators with 275 individual layer 2 circuits to each customer-\u002Dfor example, the 276 relays might be DSLAMs or cable head-end systems. At each customer 277 site we assume there is a single CPE device attached to the link. 279 We further assume that links A, B, F and G are each addressed by a 280 single prefix, although it would be equally valid for each CPE device 281 to be numbered on a separate prefix. 283 In a real-world deployment, there would likely be many more than two 284 PE routers connected to each regional backbone; we have kept the 285 number small for simplicity. 287 In this example, the goal is to configure all the devices within a 288 region with server addresses local to that region, so that service 289 traffic does not have to be routed between regions unnecessarily. 291 {"prefixes": 292 {"2001:DB8:0:0::/40": {"on-link": ["A"]}} 293 "2001:DB8:100:0::/40": {"on-link": ["B"]} 294 "2001:DB8:200:0::/40": {"on-link": ["F"]} 295 "2001:DB8:300:0::/40": {"on-link": ["G"]}} 297 {"links": 298 {"A": {"region": "omashu"}, 299 "B": {"region": "omashu"}, 300 "F": {"region": "gaoling"}, 301 "G": {"region": "gaoling"}}} 303 {"regions": 304 {"omashu": {"options": 305 {"sip-servers": ["sip.omashu.example.org"], 306 "dns-servers": ["dns1.omashu.example.org", 307 "dns2.omashu.example.org"]}}, 308 "gaoling": {"options": 309 {"sip-servers": ["sip.gaoling.example.org"], 310 "dns-servers": ["dns1.gaoling.example.org", 311 "dns2.gaoling.example.org"]}}}} 313 Figure 3 314 In this example, when a request comes in to the DHCP server with a 315 link-identifying IP address in the 2001:DB8:0:0::/40 prefix, it is 316 identified as being on link A. The DHCP server then looks on the 317 list of links to see what region the client is in. Link A is 318 identified as being in omashu. The DHCP server then looks up omashu 319 in the set of regions, and discovers a list of region-specific 320 options. 322 The DHCP server then resolves the domain names listed in the options 323 and sends a sip-server option containing the IP addresses that the 324 resolver returned for sip.omashu.example.org, and a dns-server option 325 containing the IP addresses returned by the resolver for 326 dns1.omashu.example.org and dns2.omashu.example.org. 328 Similarly, if the DHCP server receives a request from a DHCP client 329 where the link-identifying IP address is contained by the prefix 330 2001:DB8:300:0::/40, then the DHCP server identifies the client as 331 being connected to link G. The DHCP server then identifies link G as 332 being in the gaoling region, and returns the sip-servers and dns- 333 servers options specific to that region. 335 As with the previous example, the exact configuration syntax and 336 structure shown above does not precisely match what existing DHCP 337 servers do, but the behavior illustrated in this example can be 338 accomplished with all existing commercial DHCP servers. 340 6. Dynamic Lookup 342 In the Regional example, the configuration listed several domain 343 names as values for the sip-servers and dns-servers options. The 344 wire format of both of these options contains one or more IPv6 345 addresses-\u002Dthere is no way to return a domain name to the 346 client. 348 This was understood to be an issue when the original DHCP protocol 349 was defined, and historical implementations even from the very early 350 days would accept domain names and resolve them. Some early DHCP 351 implementations, particularly those based on earlier BOOTP 352 implementations, had very limited capacity for reconfiguration. 354 However, all modern commercial DHCP servers handle name resolution by 355 querying the resolver each time a DHCP packet comes in. This means 356 that if DHCP servers and DNS servers are managed by different 357 administrative entities, there is no need for the administrators of 358 the DHCP servers and DNS servers to communicate when changes are 359 made. When changes are made to the DNS server, these changes are 360 immediately and automatically adopted by the DHCP server. Similarly, 361 when DHCP server configurations change, DNS server administrators 362 need not be aware of this. 364 It's worth noting that DNS is not the only way to resolve names, and 365 not all DHCP servers support other techniques (e.g., NIS+ or WINS). 366 However, since these protocols have all but vanished from common use, 367 this won't be an issue in new deployments. 369 7. Relay Agent Configurations 371 It's worth mentioning that although we talk about relay agents and 372 routers in this document mostly as if they are the same device, this 373 is by no means required by the DHCP protocol. The relay agent is 374 simply a service that operates on a link, receiving link-local 375 multicasts or broadcasts and relaying them, using IP routing, to a 376 DHCP server. As long as the relay has an IP address on the link, and 377 a default route or more specific route through which it can reach a 378 DHCP server, it need not be a router, or even have multiple 379 interfaces. 381 8. Acknowledgments 383 Thanks to Dave Thaler for suggesting that even though "everybody 384 knows" how DHCP servers are deployed in the real world, it might be 385 worthwhile to have an IETF document that explains what everybody 386 knows, because in reality not everybody is an expert in how DHCP 387 servers are administered. 389 9. Security Considerations 391 This document explains existing practice with respect to the use of 392 Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host 393 Configuration Protocol Version 6 [RFC3315]. The security 394 considerations for these protocols are described in their 395 specifications and in related documents that extend these protocols. 396 This document introduces no new functionality, and hence no new 397 security considerations. 399 10. IANA Considerations 400 The IANA is hereby absolved of any requirement to take any action in 401 relation to this document. 403 11. References 405 11.1. Normative References 407 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 408 2131, March 1997. 410 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 411 and M. Carney, "Dynamic Host Configuration Protocol for 412 IPv6 (DHCPv6)", RFC 3315, July 2003. 414 11.2. Informative References 416 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 417 STD 13, RFC 1034, November 1987. 419 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 420 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May 421 2011. 423 Authors' Addresses 425 Ted Lemon 426 Nominum, Inc. 427 2000 Seaport Blvd 428 Redwood City, CA 94063 429 USA 431 Phone: +1-650-381-6000 432 Email: Ted.Lemon@nominum.com 434 Tomek Mrugalski 435 Internet Systems Consortium, Inc. 436 950 Charter Street 437 Redwood City, CA 94063 438 USA 440 Phone: +1 650 423 1345 441 Email: tomasz.mrugalski@gmail.com