idnits 2.17.1 draft-lemon-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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 (April 13, 2013) is 4030 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: 2 errors (**), 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 April 13, 2013 5 Expires: October 15, 2013 7 Customizing DHCP Configuration on the Basis of Network Topology 8 draft-lemon-dhc-topo-conf-01 10 Abstract 12 DHCP servers have evolved over the years to provide significant 13 functionality beyond that which is described in the DHCP base 14 specifications. One aspect of this functionality is support for 15 context-specific configuration information. This memo describes some 16 such features and makes recommendations as to how they can be used. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 15, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Locality . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 5 55 4. Regional Configuration Example . . . . . . . . . . . . . . . 6 56 5. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 9.2. Informative References . . . . . . . . . . . . . . . . . 9 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications 68 describe how addresses can be allocated to clients based on network 69 topology information provided by the DHCP relay infrastructure. 70 Address allocation decisions are integral to the allocation of 71 addresses and prefixes in DHCP. 73 The DHCP protocol also describes mechanisms for provisioning devices 74 with additional configuration information; for example, DNS [RFC1034] 75 server addresses, default DNS search domains, and similar 76 information. 78 Although it was the intent of the authors of these specifications 79 that DHCP servers would provision devices with configuration 80 information appropriate to each device's location on the network, 81 this practice was never documented, much less described in detail. 83 Existing DHCP server implementations do in fact provide such 84 capabilities; the goal of this document is to describe those 85 capabilities for the benefit both of operators and of protocol 86 designers who may wish to use DHCP as a means for configuring their 87 own servies, but may not be aware of the capabilities provided by 88 modern DHCP servers. 90 2. Locality 92 Figure 1 illustrates a simple hierarchy of network links with Link D 93 serving as a backbone to which the DHCP server is attached. 95 Link A Link B 96 |===+===========| |===========+======| 97 | | 98 | | 99 +---+---+ +---+---+ 100 | relay | | relay | 101 | A | | B | 102 +---+---+ +---+---+ 103 | | 104 | Link C | 105 |===+==========+=================+======| 106 | 107 | 108 +----+---+ +--------+ 109 | router | | DHCP | 110 | A | | Server | 111 +----+---+ +----+---+ 112 | | 113 | | 114 | Link D | 115 |==============+=================+======| 116 | 117 | 118 +----+---+ 119 | router | 120 | B | 121 +----+---+ 122 | 123 | 124 |===+==========+=================+======| 125 | Link E | 126 | | 127 +---+---+ +---+---+ 128 | relay | | relay | 129 | C | | D | 130 +---+---+ +---+---+ 131 | | 132 | | 133 |===+===========| |===========+======| 134 Link F Link G 136 Figure 1 138 This diagram allows us to represent a variety of different network 139 configurations and illustrate how existing DHCP servers can provide 140 configuration information customized to the particular location from 141 which a client is making its request. 143 It's important to understand the background of how DHCP works when 144 considering this diagram. DHCP clients are assumed not to have 145 routable IP addresses when they are attempting to obtain 146 configuration information. 148 The reason for making this assumption is that one of the functions of 149 DHCP is to bootstrap the DHCP client's IP address configuration; if 150 the client does not yet have an IP address configuration, it cannot 151 route packets to an off-link DHCP server, and so some kind of relay 152 mechanism is required. 154 The details of how this works are different between DHCPv4 and 155 DHCPv6, but the essence is the same: whether or not the client 156 actually has an IP configuration, it generally communicates with the 157 DHCP server by sending its requests to a DHCP relay agent on the 158 local link; this relay agent, which has a routable IP address, then 159 forwards the DHCP requests to the DHCP server. In some cases in 160 DHCPv4, when a DHCP client has a routable IPv4 adddress. 162 In either case, the DHCP server is able to obtain an IP address that 163 it knows is on-link for the link to which the DHCP client is 164 connected: either the DHCPv4 client's routable IPv4 address, or the 165 relay agent's IP address on the link to which the client is 166 connected. 168 DHCPv6 also has support for more finely grained link identification, 169 using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA). In this 170 case, in addition to receiving an IPv6 address that is on-link for 171 the link to which the client is connected, the DHCPv6 server also 172 receives an Interface Identifier option from the relay agent that can 173 be used to more precisely identify the client's location on the 174 network. 176 What this means in practice is that the DHCP server in all cases has 177 sufficient information to pinpoint, at the very least, the layer 3 178 link to which the client is connected, and in some cases which layer 179 2 link the client is connected to, when the layer 3 link is 180 aggregated out of multiple layer 2 links. 182 In all cases, then, the DHCP server will have a link-identifying IP 183 address, and in some cases it may also have a link-specific 184 identifier. It should be noted that there is no guarantee that the 185 link-specific identifier will be unique outside the scope of the 186 link-identifying IP address. 188 It is also possible for link-specific identifiers to be nested, so 189 that the actual identifier that identifies the link is an aggregate 190 of two or more link-specific identifiers sent by a set of LDRAs in a 191 chain; in general this functions exactly as if a single identifier 192 were received from a single LDRA, so we do not treat it specially in 193 the discussion below, but sites that use chained LDRA configurations 194 will need to be aware of this when configuring their DHCP servers. 196 Routable IP address: an IP address with a scope of use wider than the 197 local link. 199 So let's examine the implications of this in terms of how a DHCP 200 server can deliver targeted supplemental configuration information to 201 DHCP clients. 203 3. Simple Subnetted Network 205 Consider Figure 1 in the context of a simple subnetted network. In 206 this network, there are four leaf subnets: links A, B, F and G, on 207 which DHCP clients will be configured. In a simple network like 208 this, there may be no need for link-specific configuration in DHCPv6, 209 since local routing information is delivered through router 210 advertisements. 212 However, in IPv4, it is very typical to configure the default route 213 using DHCP; in this case, the default route will be different on each 214 link. In order to accomplish this, the DHCP server will need a link- 215 specific configuration for the default route. 217 To illustrate, we will use an example from a hypothetical DHCP server 218 that uses a simple JSON notation for configuration. Although we know 219 of no DHCP server that uses this specific syntax, every commercial 220 DHCP server provides similar functionality. 222 {"prefixes": 223 {"10.0.0.0/24": {"options": {"routers": ["10.0.0.1"]} 224 "on-link": ["a"]}} 225 "10.0.1.0/24": {"options": {"routers": ["10.0.1.1"}} 226 "on-link": ["b"]} 227 "10.0.2.0/24": {"options": {"routers": ["10.0.2.1"}} 228 "on-link": ["f"]} 229 "10.0.3.0/24": {"options": {"routers": ["10.0.3.1"}} 230 "on-link": ["g"]}} 232 Figure 2 234 In figure 2, we see a configuration example for this scenario: a set 235 of prefixes, each of which has a set of options and a list of links 236 for which it is on-link. We have defined one option for each prefix: 238 a routers option. This option contains a list of values; each list 239 only has one value, and that value is the IP address of the router 240 specific to the prefix. 242 When the DHCP server receives a request, it searches the list of 243 prefixes for one that encloses the link-identifying IP address 244 provided by the client or relay agent. The DHCP server then examines 245 the options list associated with that prefix and returns those 246 options to the client. 248 So for example a client connected to link A in the example would have 249 a link-identifying IP address within the 10.0.0.0/24 prefix, so the 250 DHCP server would match it to that prefix. Based on the 251 configuration, the DHCP server would then return a routers option 252 containing a single IP address: 10.0.0.1. A client on link F would 253 have a link-identifying address in the 10.0.2.0/24 prefix, and would 254 receive a routers option containing the IP address 10.0.2.1. 256 4. Regional Configuration Example 258 In this example, link C is a regional backbone for an ISP. Link E is 259 also a regional backbone for that ISP. Relays A, B, C and D are PE 260 routers, and Links A, B, F and G are actually link aggregators with 261 individual layer 2 circuits to each customer-\u002Dfor example, the 262 relays might be DSLAMs or cable head-end systems. At each customer 263 site we assume there is a single CPE device attached to the link. 265 We further assume that links A, B, F and G are each addressed by a 266 single prefix, although it would be equally valid for each CPE device 267 to be numbered on a separate prefix. 269 In a real-world deployment, there would likely be many more than two 270 PE routers connected to each regional backbone; we have kept the 271 number small for simplicity. 273 In this example, the goal is to configure all the devices within a 274 region with server addresses local to that region, so that service 275 traffic does not have to be routed between regions unnecessarily. 277 {"prefixes": 278 {"2001:DB8:0:0::/40": {"on-link": ["A"]}} 279 "2001:DB8:100:0::/40": {"on-link": ["B"]} 280 "2001:DB8:200:0::/40": {"on-link": ["F"]} 281 "2001:DB8:300:0::/40": {"on-link": ["G"]}} 283 {"links": 284 {"A": {"region": "omashu"}, 285 "B": {"region": "omashu"}, 286 "F": {"region": "gaoling"}, 287 "G": {"region": "gaoling"}}} 289 {"regions": 290 {"omashu": {"options": {"sip-servers": ["sip.omashu.example.org"], 291 "dns-servers": ["dns1.omashu.example.org", 292 "dns2.omashu.example.org"]}}, 293 "gaoling": {"options": {"sip-servers": ["sip.gaoling.example.org"], 294 "dns-servers": ["dns1.gaoling.example.org", 295 "dns2.gaoling.example.org"]}}}} 297 Figure 3 299 In this example, when a request comes in to the DHCP server with a 300 link-identifying IP address in the 2001:DB8:0:0::/40 prefix, it is 301 identified as being on link A. The DHCP server then looks on the 302 list of links to see what region the client is in. Link A is 303 identified as being in omashu. The DHCP server then looks up omashu 304 in the set of regions, and discovers a list of region-specific 305 options. 307 The DHCP server then resolves the domain names listed in the options 308 and sends a sip-server option containing the IP addresses that the 309 resolver returned for sip.omashu.example.org, and a dns-server option 310 containing the IP addresses returned by the resolver for 311 dns1.omashu.example.org and dns2.omashu.example.org. 313 Similarly, if the DHCP server receives a request from a DHCP client 314 where the link-identifying IP address is contained by the prefix 315 2001:DB8:300:0::/40, then the DHCP server identifies the client as 316 being connected to link G. The DHCP server then identifies link G as 317 being in the gaoling region, and returns the sip-servers and dns- 318 servers options specific to that region. 320 As with the previous example, the exact configuration syntax and 321 structure shown above does not precisely match what existing DHCP 322 servers do, but the behavior illustrated in this example can be 323 accomplished with all existing commercial DHCP servers. 325 5. Dynamic Lookup 327 In the Regional example, the configuration listed several domain 328 names as values for the sip-servers and dns-servers options. The 329 wire format of both of these options contains one or more IPv6 330 addresses-\u002Dthere is no way to return a domain name to the 331 client. 333 This was understood to be an issue when the original DHCP protocol 334 was defined, and historical implementations even from the very early 335 days would accept domain names and resolve them. Some early DHCP 336 implementations, particularly those based on earlier BOOTP 337 implementations, had very limited capacity for reconfiguration. 339 However, all modern commercial DHCP servers handle name resolution by 340 querying the resolver each time a DHCP packet comes in. This means 341 that if DHCP servers and DNS servers are managed by different 342 administrative entities, there is no need for the administrators of 343 the DHCP servers and DNS servers to communicate when changes are 344 made. When changes are made to the DNS server, these changes are 345 immediately and automatically adopted by the DHCP server. Similarly, 346 when DHCP server configurations change, DNS server administrators 347 need not be aware of this. 349 6. Acknowledgments 351 Thanks to Dave Thaler for suggesting that even though "everybody 352 knows" how DHCP servers are deployed in the real world, it might be 353 worthwhile to have an IETF document that explains what everybody 354 knows, because in reality not everybody is an expert in how DHCP 355 servers are administered. 357 7. Security Considerations 359 This document explaine existing practice with respect to the use of 360 Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host 361 Configuration Protocol Version 6 [RFC3315]. The security 362 considerations for these protocols are described in their 363 specifications and in related documents that extend these protocols. 364 This document introduces no new functionality, and hence no new 365 security considerations. 367 8. IANA Considerations 369 The IANA is hereby absolved of any requirement to take any action in 370 relation to this document. 372 9. References 374 9.1. Normative References 376 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 377 2131, March 1997. 379 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 380 and M. Carney, "Dynamic Host Configuration Protocol for 381 IPv6 (DHCPv6)", RFC 3315, July 2003. 383 9.2. Informative References 385 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 386 STD 13, RFC 1034, November 1987. 388 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 389 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May 390 2011. 392 Author's Address 394 Ted Lemon 395 Nominum, Inc. 396 2000 Seaport Blvd 397 Redwood City, CA 94063 398 USA 400 Phone: +1-650-381-6000 401 Email: Ted.Lemon@nominum.com