idnits 2.17.1 draft-lemon-dhc-dns-pd-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 17, 2012) is 4295 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) 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 4 Intended status: Standards Track July 17, 2012 5 Expires: January 18, 2013 7 Populating the DNS Reverse Tree for DHCP Delegated Prefixes 8 draft-lemon-dhc-dns-pd-01.txt 10 Abstract 12 This document describes three alternatives for populating the DNS 13 reverse tree for prefixes delegated using DHCP, and provides 14 mechanisms for implementing each alternative. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 18, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Methods for populating the reverse tree . . . . . . . . . . . 5 53 3.1. Site-managed reverse tree . . . . . . . . . . . . . . . . 5 54 3.2. Provider-managed reverse tree . . . . . . . . . . . . . . 5 55 3.3. Provider-managed spoofed reverse tree . . . . . . . . . . 5 56 3.4. Other solutions not documented here . . . . . . . . . . . 5 57 4. Negotiating the reverse tree population method . . . . . . . . 7 58 5. Configuring a site-managed reverse tree . . . . . . . . . . . 9 59 5.1. Requesting Router Behavior . . . . . . . . . . . . . . . . 9 60 5.2. Delegating Router Behavior . . . . . . . . . . . . . . . . 10 61 6. Configuring a provider-managed reverse tree . . . . . . . . . 12 62 6.1. Requesting Router Behavior . . . . . . . . . . . . . . . . 12 63 6.2. Delegating Router Behavior . . . . . . . . . . . . . . . . 12 64 7. Configuring a spoofed reverse tree . . . . . . . . . . . . . . 13 65 8. Configuring no reverse tree . . . . . . . . . . . . . . . . . 14 66 9. Encoding of options . . . . . . . . . . . . . . . . . . . . . 15 67 9.1. Prefix Delegation Method Types . . . . . . . . . . . . . . 15 68 9.2. Prefix Delegation Zone Preference Option . . . . . . . . . 15 69 9.3. Prefix Delegation Zone Method Option . . . . . . . . . . . 15 70 9.4. Prefix Delegation Zone Server Option . . . . . . . . . . . 15 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 75 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 1. Introduction 80 When a site is numbered using DHCP prefix delegation [RFC3633], there 81 are three ways of populating the Domain Name System [RFC1035] reverse 82 tree. Which mechanism is chosen depends on the capabilities of the 83 site's DNS infrastructure, if any, on the capabilities and policies 84 of the service provider, and on the preferences of the site 85 administration. 87 This document does not take a position on which mechanism, if any, is 88 best for populating the reverse tree, but simply documents each of 89 the possible mechanisms for doing so, and provides a means whereby 90 site administrators and service providers can negotiate the mechanism 91 whereby the reverse tree for a particular site will be populated. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Methods for populating the reverse tree 101 There are three common methods of populating the reverse tree for a 102 delegated prefix: delegation, dynamic dns, and zone spoofing. In 103 addition, of course, it is possible to leave the reverse tree 104 unpopulated. 106 3.1. Site-managed reverse tree 108 To populate the reverse tree by delegation, the site administrator 109 must provide a DNS authoritative name server for the delegated zone. 110 The site administrator must communicate the IP address of the 111 authoritative name server to the service provider. The service 112 provider must then add a delegation for that zone using the IP 113 address or addresses of the DNS authoritative servers provided by the 114 site administrator. 116 3.2. Provider-managed reverse tree 118 To populate the reverse tree using DNS updates, the service provider 119 must provide an authoritative name server for the zone. The site 120 administrator must provide a key to the service provider that can be 121 used to authenticate DNS updates. The site administrator must then 122 provide a mechanism whereby DNS updates will automatically be 123 generated, using the provided key, whenever IP addresses are 124 allocated within the delegated prefix. 126 3.3. Provider-managed spoofed reverse tree 128 In some cases the site administrator may not be willing or able to 129 populate a reverse tree. However, the service provider may wish to 130 provide meaningful answers to reverse zone queries for the delegated 131 zone. It's not possible to populate the delegated zone: a fully 132 populated zone for a /64 would require 1.8x10^19 names. However, the 133 names in such a zone would never change; consequently it is possible 134 for a name server to spoof the zone contents, constructing answers 135 for queries against any name within the zone on the fly. Because the 136 contents of the zone never change, the zone can have a consistent 137 authority record. 139 3.4. Other solutions not documented here 141 It's worth noting that there are several other ways that the zone for 142 a delegated prefix could be populated, but we are not covering these 143 mechanisms because they seem more difficult to implement and deploy. 144 For instance, nodes configured with addresses within a delegated 145 prefix could issue their own DNS updates to an authoritative server 146 operated by the service provider. The problem of key management in 147 this case becomes intractable, however. 149 It would also be possible for the site to have its own key management 150 infrastructure, and for some agent on the requesting router to act as 151 an intermediary in updating a zone maintained by the service 152 provider. However, this is substantially more complicated than 153 either of the proposed solutions. 155 Another option is to simply not populate the reverse tree. This is 156 an attractive option in the IETF in particular because the reverse 157 tree is frequently used for purposes to which it is not suited, and 158 some IETF participants believe that in order to discourage these 159 applications, it's better simply to not populate the reverse tree. 160 This document takes no position on this question, but does offer a 161 means whereby the site administrator can indicate that the reverse 162 tree should not be populated. 164 4. Negotiating the reverse tree population method 166 The prefix delegation process is initiated by a requesting router. 167 If a delegating router chooses to delegate a prefix to the requesting 168 router, it replies with a prefix. The requesting router may receive 169 responses from more than one delegating router, and may choose one or 170 more such delegated prefixes. For delegating routers whose offer is 171 accepted, the requesting router sends a request for the offered 172 address; at this point the delegating router commits the delegation 173 to stable storage and sends a confirmation to the requesting router. 175 The messages used to complete this transaction are the DHCP Discover, 176 DHCP Advertise, DHCP Request and DHCP Reply messages, respectively. 177 The negotiation as to how the reverse tree will be populated 178 piggybacks on this four-message process. 180 In the DHCP Discover message, the requesting router indicates the 181 site administrator's preference for how the reverse tree for the 182 delegated prefix will be populated. It does this by including, in 183 each IA_PD option it sends, a Prefix Delegation Zone Preference 184 option (PDZP) containing one or more preference codes. These codes 185 are listed in order of preference with the most preferred mechanism 186 first. A requesting router that includes a PDZP option MUST send an 187 Option Request option (ORO) that requests the Prefix Delegation Zone 188 Method (PDZM) option. 190 If the delegating router chooses not to delegate a prefix to the 191 requesting router, no special action need be taken in response to the 192 PDZP option. The remainder of this section describes what happens if 193 the delegating router chooses to delegate a prefix to the requesting 194 router. 196 Delegating routers that implement this specification can be 197 configured with a list of supported reverse tree population methods. 198 When a requesting router receives an IA_PD option that includes a 199 PDZP option, if it has been configured with a reverse tree population 200 method list, it iterates across the list of methods in the PDZP 201 option. For each entry in the PDZP option, the requesting router 202 tests to see if that method has been configured by the site 203 administrator as being supported. If the method is on the list, the 204 iteration stops at this point. 206 Upon completion of this iteration, if a method was found in the PDZA 207 that is supported by the delegating router, that is the method that 208 will be used to populate the reverse tree for the delegated zone. 209 The delegating router constructs a PDZM option indicating that this 210 method will be used and includes this in the DHCP Advertise message. 212 If no supported method was found, this means that the service 213 provider will not cooperate with the site administrator in populating 214 the reverse tree. The delegating router indicates that this is the 215 case by not including a PDZM option in the DHCP Advertise message.. 217 The requesting router may receive one or more DHCP Advertise messages 218 containing delegated prefixes. The requesting router MUST silently 219 discard any DHCP Advertise message containing a PDZM option that 220 indicates a method that was not listed in the PDZP option sent in the 221 DHCP Discover message. 223 The requesting router may then choose to respond to one or more of 224 the remaining DHCP Advertise messages, if any. The lack of a PDZM 225 option indicates either that the delegating router does not implement 226 DNS for delegated prefixes, or that it is not configured to support 227 DNS for delegated prefixs. The requesting router MAY prefer DHCP 228 Advertise messages containing PDZM options over DHCP Advertise 229 messages that do not contain PDZM options. 231 When responding to any DHCP Advertise messages containing PDZM 232 options, the requesting router MUST include a PDZM option containing 233 the same method indicated in the received PDZM option. 235 Each delegating router that receives a DHCP Request message 236 containing a PDZM option MUST check the method indicated in the PDZM 237 option is supported; if not, the delegating router MUST silently 238 discard the DHCP Request option. 240 The requesting and delegating routers should follow the same 241 procedure specified for the DHCP Request/DHCP Reply sequence whenever 242 a DHCP Renew or DHCP Rebind is sent and a DHCP reply sent in 243 response, if that response renews the delegated prefix. In the case 244 that the response does not renew the prefix, the delegating router 245 MUST NOT send a PDZM in the IA_PD option. 247 5. Configuring a site-managed reverse tree 249 If the PDZM option returned by the delegating router in the DHCP 250 Advertise message specifies the Site Managed method, the requesting 251 router must arrange to set up one or more authoritative name servers 252 that will provide service for the zone or zones that correspond to 253 the delegated prefix. It must also communicate to the delegating 254 router the IP address or addresses of these servers. 256 5.1. Requesting Router Behavior 258 The requesting router MUST include a Prefix Delegation Zone Server 259 (PDZS) option in each IA_PD in the DHCP Request message, which 260 includes zero or more IP addresses of authoritative name servers for 261 the delegated zone. IPv4 addresses MUST be represented as IPv4- 262 Embedded IPv6 addresses using the Well-Known prefix [RFC6052]. 264 Authoritative name service for these zones may be provided by any or 265 all of the following three types of authoritative name servers: 267 o An authoritative name server running on a node that has an IP 268 address known to the requesting router that is not obtained from 269 the prefix being delegated. 271 o An authoritative name server running on the requesting router. 273 o An authoritative name server running on a node that will obtain 274 its only IP address from the prefix being delegated. 276 In the first case, it is possible that the reverse zone for the 277 delegated prefix is already configured on the authoritative name 278 server. In this case, the requesting router SHOULD include the IP 279 address of the authoritative name servers for the delegated zone in 280 the PDZS option. 282 However, if the prefix is being delegated for the first time, the 283 delegating router will not have had an opportunity to configure it 284 prior to sending the DHCP Request message. In this case, the 285 delegating router SHOULD NOT include the IP Address of this name 286 server in the PDZS option that's send in the DHCP Request message; 287 instead, it should send a DHCP Renew once the authoritative server 288 has been configured, and list the server's IP address in the PDZS 289 option in the DHCP Renew message. 291 In the second case, the requesting router may already have an IP 292 address, and may be able to configure the authoritative server for 293 the delegated zone before sending the DHCP Request. In this case, 294 the requesing router SHOULD include its own IP address in the PDZS 295 option in the DHCP Request message. 297 If the requesting router does not have an IP address at this time, it 298 SHOULD send a DHCP Renew message containing a PDZS option that lists 299 all the authoritative servers for the reverse zone or zones for the 300 delegated prefix after it has an IP address and has configured the 301 authoritative servers. 303 If the authoritative name server is running on a node that will 304 configure its IP address from the delegated prefix, this name server 305 cannot even be configured until it has an IP address. The process of 306 configuring this name server is beyond the scope of the document; 307 however, once the name server has been configured, the requesting 308 router SHOULD send a DHCP Renew message for the delegated prefix with 309 an IA_PD containing a PDZS option that lists the IP address of this 310 name server. 312 In general, if there are any globally-reachable name servers that are 313 authoritative for the zone or zones that provide the reverse tree for 314 the delegated prefix at the time that the DHCP Request message is 315 sent, the requesting router should list the IP addresses of these 316 name servers in the PDZS option in the associated IA_PD option in the 317 DHCP Request message. 319 If new globally-reachable name servers that are authoritative for the 320 reverse zone or zones become available after the DHCP Request has 321 been sent and the DHCP Reply received, the requesting router SHOULD 322 send a DHCP Renew message containing an IA_PD for the delegated 323 prefix and a PDZS option listing the name servers for that prefix 324 that have come online. The requesting router SHOULD be aware of all 325 outstanding name server configuration processes and minimize the 326 number of DHCP Renew message sent. 328 When a requesting router sends a DHCP Renew or DHCP Rebind message to 329 renew a delegated prefix, if a site-managed reverse tree was 330 successfully configured, the requesting router MUST send a PDZM 331 option containing the same method sent in the original DHCP Request 332 message. The requesting router MUST also send a PDZS option that 333 contains one or more IP addresses for authoritative servers for the 334 reverse tree for the delegated prefix. 336 5.2. Delegating Router Behavior 338 When a delegating router receives a valid DHCP Request message 339 containing an IA_PD that contains both a PDZM option indicating the 340 Site Managed method and a PDZS option containing at least one IP 341 address, it compares the IP addresses in the PDZM option to any 342 previous record it may have for that delegation. If the contents of 343 the PDZM option differ from the previous record, or if there is no 344 previous record, the delegating router MUST issue a DNS Update to add 345 a delegation to the parent zone of the reverse tree zone for the 346 delegated prefix. 348 In the event that the PDZS option contains zero IP addresses, the 349 delegating router does not update the zone. 351 If the delegated prefix must be represented as more than one zone, 352 the delegating router adds delegations to the parent zone for each 353 such zone. 355 When a delegating router receives a DHCP Renew or DHCP Rebind message 356 for a prefix it delegated and elects to renew the prefix, it MUST 357 check its record for that prefix to see if a delegation exists. If 358 the contents of the PDZS differ from the recorded list of 359 authoritative name servers for that prefix, the delegating router 360 MUST update the parent zone with the new delegations. 362 When a delegating router receives a DHCP Renew or DHCP Rebind message 363 for a prefix it delegated, and elects not to renew the delegation, 364 the delegating router MUST check to see if it has a site-managed 365 reverse tree configuration for that pprefix. If it does, it must 366 update the parent zone to remove any delegations that were added, and 367 update its record for the delegated prefix to indicate that no site- 368 managed reverse tree configuration for that prefix is present. 370 When a delegated prefix expires without being renewed by the 371 requesting router, the same procedure should be followed to update 372 the parent zone. 374 In all cases where the delegating router updates the delegation for 375 the zone, it must first query the name server or servers listed in 376 the PDZS opton for an SOA record for each delegated zone. If the 377 name server does not respond within the standard timeout period, or 378 does not provide an authoritative answer, the delegating router MUST 379 NOT add a delegation for that name server. 381 6. Configuring a provider-managed reverse tree 383 If the PDZM returned by a delegating router in the DHCP Advertise 384 message specifies the Provider Managed method, the delegating router 385 must arrange to set up a reverse zone for the delegated prefix. The 386 requesting router must communicate a key to the delegating router 387 that can be used to secure updates to the reverse zone. 389 6.1. Requesting Router Behavior 391 In order to update the provider-managed reverse zone, the requesting 392 router must provide a key to the delegating router. Because DHCP 393 does not provide confidentiality, this key must be the public half of 394 a private key. 396 Typically sites that wish to populate their reverse tree with 397 meaningful information maintain a site-specific or company-wide DNS 398 zone. In order to update the reverse zone, the site administrator 399 must publish a SIG(0) key in this zone. The requesting router MUST 400 include a Prefix Delegation SIG(0) Key FQDN (PDSKF) option in the 401 DHCP Request message and any subsequent DHCP Renew messages. It must 402 use the private half of the SIG(0) key in any DNS updates to the 403 reverse zone. 405 6.2. Delegating Router Behavior 407 There are two cases that the delegating router needs to handle: the 408 case where the prefix being delegated was previously delegated to the 409 same requesting router, and the case where it was not. 411 In the case where the prefix was previously delegated to the same 412 requesting router, the delegating router need take no action to 413 populate the zone, because it should already be populated. 415 In the case where the prefix was previously delegated to a different 416 requesting router, the delegating router MUST remove the old zone 417 information from the master authoritative name server for the zone. 419 In this case, and in the case where no previous delegation had been 420 done, the delegating router must then configure a new reverse zone on 421 the master server. 423 In any case, the delegating router must configure the reverse zone so 424 that it can be updated using the SIG(0) key stored on the name 425 provided by the requesting router in the PDSKF option. 427 7. Configuring a spoofed reverse tree 429 A spoofed reverse tree can be configured either unilaterally by the 430 service provider or upon request of the site administrator. The site 431 administrator would list this as an option to indicate a preference 432 for a spoofed reverse tree over no reverse tree; the choice doesn't 433 make any sense otherwise. 435 Generally speaking, the service provider has the option of either 436 setting up spoofed zones on demand, or setting them up when 437 requested. If the service provider only offers spoofed zones, it 438 makes some sense to set them up in advance; otherwise they should be 439 set up whenever a prefix is delegated to a particular requesting 440 router for the first time. 442 In some cases the site administration may request a spoofed zone 443 because they do not wish to populate the reverse tree, but wish for 444 it to appear populated. A service provider may support this option 445 in addition to the site-managed option, the provider-managed option, 446 and the no zone option. In this case, when a prefix is delegated to 447 a new router for the first time, there may be an old zone configured 448 differently. In this case, the delegated router MUST remove the old 449 zone configuration before setting up the spoofed zone. 451 8. Configuring no reverse tree 453 A service provider may choose to simply not populate reverse trees 454 for delegated prefixes. This is a desirable option in the sense that 455 it minimizes the work required to support the reverse DNS tree, and 456 avoids creating spoofed nonsense records. The service provider may 457 also simply offer it as an option for sites that prefer not to have a 458 populated reverse tree. 460 In this case, if the non-populated reverse tree is an option, and the 461 prefix had previously been delegated to a different router, the 462 delegating router must remove any previously-existing zone for the 463 delegated prefix. 465 9. Encoding of options 467 9.1. Prefix Delegation Method Types 469 Prefix delegation methods are encoded as numbers. Currently three 470 prefix delegation methods are defined: 472 0 Site-Managed 474 1 Provider-managed 476 2 Provider-managed spoofed reverse tree 478 9.2. Prefix Delegation Zone Preference Option 480 The Prefix Delegation Zone Preference option consists of an option 481 code, OPT_PDZP, followed by a length, followed by one or more Prefix 482 Delegation method type codes. 484 0 1 2 3 485 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | OPT_PDZP | length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type 1 | ... | Type N | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 9.3. Prefix Delegation Zone Method Option 494 The Prefix Delegation Zone Method option consists of an option code, 495 OPT_PDZM, followed by a length, followed by one Prefix Delegation 496 method type code. 498 0 1 2 3 499 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | OPT_PDZM | length | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type | 504 +-+-+-+-+-+-+-+ 506 9.4. Prefix Delegation Zone Server Option 508 The Prefix Delegation Zone Server option consists of an option code, 509 OPT_PDZS, followed by a length, followed by zero or more IPv6 510 addresses. 512 0 1 2 3 513 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | OPT_PDZS | length | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | DNS Server IP Address 1 | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | DNS Server IP Address 1 (cont'd) | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | DNS Server IP Address 1 (cont'd) | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | DNS Server IP Address 1 (cont'd) | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 ... 527 10. Security Considerations 529 Some ISPs may have concerns about allowing site-managed DNS 530 subdelegations for the reverse zone, but this concern is a policy 531 issue, not a security issue. In the presence of properly agreed-to 532 terms of service, population of a reverse tree by the end-user is 533 simply a value-added service the ISP may or may not choose to 534 provide. Even in the absence of a legally binding ToS agreement, the 535 worse an end-user could do would be to publish nasty words or bogus 536 PTR records, neither of which is a security concern. 538 If an implementation were to fail to follow the advice on validating 539 authoritative name servers supplied by the requesting router, it 540 would probably be possible for a coordinated set of requesting 541 routers to perform a DDoS attack on a target by arranging for various 542 entities on the network to query the reverse tree for one or more of 543 the IP addresses in the delegated prefix. However, this would 544 require, first, that the implementation not follow the specification, 545 and second, a fairly complicated setup. In practice, there are 546 easier ways to get a DDoS amplification. 548 11. IANA Considerations 550 We request that IANA assign three new option codes from the DHCP 551 Option Codes table of the Dynamic Host Configuration Protocol for 552 IPv6 (DHCPv6) parameters registry maintained in http://www.iana.org/ 553 assignments/dhcpv6-parameters/dhcpv6-parameters.xml These option 554 codes will be assigned to the Prefix Delegation Zone Preference 555 (OPT_PDZP), Prefix Delegation Zone Method (OPT_PDZM) and Prefix 556 Delegation Zone Servers (OPT_PDZS) options. 558 We also request that the IANA add a new table, the Prefix Delegation 559 Zone Method Types table, to the same registry. The first three 560 entries in the table will contain the values specified in the section 561 above titled "Prefix Delegation Zone Method Types." New entries to 562 the table may be added according to the "Specification Required" IANA 563 policy [RFC5226]. 565 12. References 567 12.1. Normative References 569 [RFC1035] Mockapetris, P., "Domain names - implementation and 570 specification", STD 13, RFC 1035, November 1987. 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 576 Host Configuration Protocol (DHCP) version 6", RFC 3633, 577 December 2003. 579 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 580 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 581 October 2010. 583 12.2. Informative References 585 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 586 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 587 May 2008. 589 Author's Address 591 Ted Lemon 592 Nominum 593 2000 Seaport Blvd 594 Redwood City, CA 94063 595 USA 597 Phone: +1 650 381 6000 598 Email: mellon@nominum.com