idnits 2.17.1 draft-ietf-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 (October 21, 2013) is 3840 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 October 21, 2013 5 Expires: April 24, 2014 7 Populating the DNS Reverse Tree for DHCP Delegated Prefixes 8 draft-ietf-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 April 24, 2014. 33 Copyright Notice 35 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Methods for populating the reverse tree . . . . . . . . . . . 3 53 3.1. Site-managed reverse tree . . . . . . . . . . . . . . . . 3 54 3.2. Provider-managed reverse tree . . . . . . . . . . . . . . 3 55 3.3. Provider-managed spoofed reverse tree . . . . . . . . . . 3 56 3.4. Other solutions not documented here . . . . . . . . . . . 3 57 4. Negotiating the reverse tree population method . . . . . . . 4 58 5. Configuring a site-managed reverse tree . . . . . . . . . . . 6 59 5.1. Requesting Router Behavior . . . . . . . . . . . . . . . 6 60 5.2. Delegating Router Behavior . . . . . . . . . . . . . . . 8 61 6. Configuring a provider-managed reverse tree . . . . . . . . . 9 62 6.1. Requesting Router Behavior . . . . . . . . . . . . . . . 9 63 6.2. Delegating Router Behavior . . . . . . . . . . . . . . . 9 64 7. Configuring a spoofed reverse tree . . . . . . . . . . . . . 10 65 8. Configuring no reverse tree . . . . . . . . . . . . . . . . . 10 66 9. Encoding of options . . . . . . . . . . . . . . . . . . . . . 10 67 9.1. Prefix Delegation Method Types . . . . . . . . . . . . . 10 68 9.2. Prefix Delegation Zone Preference Option . . . . . . . . 11 69 9.3. Prefix Delegation Zone Method Option . . . . . . . . . . 11 70 9.4. Prefix Delegation Zone Server Option . . . . . . . . . . 11 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 12.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Methods for populating the reverse tree 100 There are three common methods of populating the reverse tree for a 101 delegated prefix: delegation, dynamic dns, and zone spoofing. In 102 addition, of course, it is possible to leave the reverse tree 103 unpopulated. 105 3.1. Site-managed reverse tree 107 To populate the reverse tree by delegation, the site administrator 108 must provide a DNS authoritative name server for the delegated zone. 109 The site administrator must communicate the IP address of the 110 authoritative name server to the service provider. The service 111 provider must then add a delegation for that zone using the IP 112 address or addresses of the DNS authoritative servers provided by the 113 site administrator. 115 3.2. Provider-managed reverse tree 117 To populate the reverse tree using DNS updates, the service provider 118 must provide an authoritative name server for the zone. The site 119 administrator must provide a key to the service provider that can be 120 used to authenticate DNS updates. The site administrator must then 121 provide a mechanism whereby DNS updates will automatically be 122 generated, using the provided key, whenever IP addresses are 123 allocated within the delegated prefix. 125 3.3. Provider-managed spoofed reverse tree 127 In some cases the site administrator may not be willing or able to 128 populate a reverse tree. However, the service provider may wish to 129 provide meaningful answers to reverse zone queries for the delegated 130 zone. It's not possible to populate the delegated zone: a fully 131 populated zone for a /64 would require 1.8x10^19 names. However, the 132 names in such a zone would never change; consequently it is possible 133 for a name server to spoof the zone contents, constructing answers 134 for queries against any name within the zone on the fly. Because the 135 contents of the zone never change, the zone can have a consistent 136 authority record. 138 3.4. Other solutions not documented here 140 It's worth noting that there are several other ways that the zone for 141 a delegated prefix could be populated, but we are not covering these 142 mechanisms because they seem more difficult to implement and deploy. 143 For instance, nodes configured with addresses within a delegated 144 prefix could issue their own DNS updates to an authoritative server 145 operated by the service provider. The problem of key management in 146 this case becomes intractable, however. 148 It would also be possible for the site to have its own key management 149 infrastructure, and for some agent on the requesting router to act as 150 an intermediary in updating a zone maintained by the service 151 provider. However, this is substantially more complicated than 152 either of the proposed solutions. 154 Another option is to simply not populate the reverse tree. This is 155 an attractive option in the IETF in particular because the reverse 156 tree is frequently used for purposes to which it is not suited, and 157 some IETF participants believe that in order to discourage these 158 applications, it's better simply to not populate the reverse tree. 159 This document takes no position on this question, but does offer a 160 means whereby the site administrator can indicate that the reverse 161 tree should not be populated. 163 4. Negotiating the reverse tree population method 165 The prefix delegation process is initiated by a requesting router. 166 If a delegating router chooses to delegate a prefix to the requesting 167 router, it replies with a prefix. The requesting router may receive 168 responses from more than one delegating router, and may choose one or 169 more such delegated prefixes. For delegating routers whose offer is 170 accepted, the requesting router sends a request for the offered 171 address; at this point the delegating router commits the delegation 172 to stable storage and sends a confirmation to the requesting router. 174 The messages used to complete this transaction are the DHCP Discover, 175 DHCP Advertise, DHCP Request and DHCP Reply messages, respectively. 176 The negotiation as to how the reverse tree will be populated 177 piggybacks on this four-message process. 179 In the DHCP Discover message, the requesting router indicates the 180 site administrator's preference for how the reverse tree for the 181 delegated prefix will be populated. It does this by including, in 182 each IA_PD option it sends, a Prefix Delegation Zone Preference 183 option (PDZP) containing one or more preference codes. These codes 184 are listed in order of preference with the most preferred mechanism 185 first. A requesting router that includes a PDZP option MUST send an 186 Option Request option (ORO) that requests the Prefix Delegation Zone 187 Method (PDZM) option. 189 If the delegating router chooses not to delegate a prefix to the 190 requesting router, no special action need be taken in response to the 191 PDZP option. The remainder of this section describes what happens if 192 the delegating router chooses to delegate a prefix to the requesting 193 router. 195 Delegating routers that implement this specification can be 196 configured with a list of supported reverse tree population methods. 197 When a requesting router receives an IA_PD option that includes a 198 PDZP option, if it has been configured with a reverse tree population 199 method list, it iterates across the list of methods in the PDZP 200 option. For each entry in the PDZP option, the requesting router 201 tests to see if that method has been configured by the site 202 administrator as being supported. If the method is on the list, the 203 iteration stops at this point. 205 Upon completion of this iteration, if a method was found in the PDZA 206 that is supported by the delegating router, that is the method that 207 will be used to populate the reverse tree for the delegated zone. 208 The delegating router constructs a PDZM option indicating that this 209 method will be used and includes this in the DHCP Advertise message. 211 If no supported method was found, this means that the service 212 provider will not cooperate with the site administrator in populating 213 the reverse tree. The delegating router indicates that this is the 214 case by not including a PDZM option in the DHCP Advertise message.. 216 The requesting router may receive one or more DHCP Advertise messages 217 containing delegated prefixes. The requesting router MUST silently 218 discard any DHCP Advertise message containing a PDZM option that 219 indicates a method that was not listed in the PDZP option sent in the 220 DHCP Discover message. 222 The requesting router may then choose to respond to one or more of 223 the remaining DHCP Advertise messages, if any. The lack of a PDZM 224 option indicates either that the delegating router does not implement 225 DNS for delegated prefixes, or that it is not configured to support 226 DNS for delegated prefixs. The requesting router MAY prefer DHCP 227 Advertise messages containing PDZM options over DHCP Advertise 228 messages that do not contain PDZM options. 230 When responding to any DHCP Advertise messages containing PDZM 231 options, the requesting router MUST include a PDZM option containing 232 the same method indicated in the received PDZM option. 234 Each delegating router that receives a DHCP Request message 235 containing a PDZM option MUST check the method indicated in the PDZM 236 option is supported; if not, the delegating router MUST silently 237 discard the DHCP Request option. 239 The requesting and delegating routers should follow the same 240 procedure specified for the DHCP Request/DHCP Reply sequence whenever 241 a DHCP Renew or DHCP Rebind is sent and a DHCP reply sent in 242 response, if that response renews the delegated prefix. In the case 243 that the response does not renew the prefix, the delegating router 244 MUST NOT send a PDZM in the IA_PD option. 246 5. Configuring a site-managed reverse tree 248 If the PDZM option returned by the delegating router in the DHCP 249 Advertise message specifies the Site Managed method, the requesting 250 router must arrange to set up one or more authoritative name servers 251 that will provide service for the zone or zones that correspond to 252 the delegated prefix. It must also communicate to the delegating 253 router the IP address or addresses of these servers. 255 5.1. Requesting Router Behavior 257 The requesting router MUST include a Prefix Delegation Zone Server 258 (PDZS) option in each IA_PD in the DHCP Request message, which 259 includes zero or more IP addresses of authoritative name servers for 260 the delegated zone. IPv4 addresses MUST be represented as 261 IPv4-Embedded IPv6 addresses using the Well-Known prefix [RFC6052]. 263 Authoritative name service for these zones may be provided by any or 264 all of the following three types of authoritative name servers: 266 o An authoritative name server running on a node that has an IP 267 address known to the requesting router that is not obtained from 268 the prefix being delegated. 270 o An authoritative name server running on the requesting router. 272 o An authoritative name server running on a node that will obtain 273 its only IP address from the prefix being delegated. 275 In the first case, it is possible that the reverse zone for the 276 delegated prefix is already configured on the authoritative name 277 server. In this case, the requesting router SHOULD include the IP 278 address of the authoritative name servers for the delegated zone in 279 the PDZS option. 281 However, if the prefix is being delegated for the first time, the 282 delegating router will not have had an opportunity to configure it 283 prior to sending the DHCP Request message. In this case, the 284 delegating router SHOULD NOT include the IP Address of this name 285 server in the PDZS option that's send in the DHCP Request message; 286 instead, it should send a DHCP Renew once the authoritative server 287 has been configured, and list the server's IP address in the PDZS 288 option in the DHCP Renew message. 290 In the second case, the requesting router may already have an IP 291 address, and may be able to configure the authoritative server for 292 the delegated zone before sending the DHCP Request. In this case, 293 the requesing router SHOULD include its own IP address in the PDZS 294 option in the DHCP Request message. 296 If the requesting router does not have an IP address at this time, it 297 SHOULD send a DHCP Renew message containing a PDZS option that lists 298 all the authoritative servers for the reverse zone or zones for the 299 delegated prefix after it has an IP address and has configured the 300 authoritative servers. 302 If the authoritative name server is running on a node that will 303 configure its IP address from the delegated prefix, this name server 304 cannot even be configured until it has an IP address. The process of 305 configuring this name server is beyond the scope of the document; 306 however, once the name server has been configured, the requesting 307 router SHOULD send a DHCP Renew message for the delegated prefix with 308 an IA_PD containing a PDZS option that lists the IP address of this 309 name server. 311 In general, if there are any globally-reachable name servers that are 312 authoritative for the zone or zones that provide the reverse tree for 313 the delegated prefix at the time that the DHCP Request message is 314 sent, the requesting router should list the IP addresses of these 315 name servers in the PDZS option in the associated IA_PD option in the 316 DHCP Request message. 318 If new globally-reachable name servers that are authoritative for the 319 reverse zone or zones become available after the DHCP Request has 320 been sent and the DHCP Reply received, the requesting router SHOULD 321 send a DHCP Renew message containing an IA_PD for the delegated 322 prefix and a PDZS option listing the name servers for that prefix 323 that have come online. The requesting router SHOULD be aware of all 324 outstanding name server configuration processes and minimize the 325 number of DHCP Renew message sent. 327 When a requesting router sends a DHCP Renew or DHCP Rebind message to 328 renew a delegated prefix, if a site-managed reverse tree was 329 successfully configured, the requesting router MUST send a PDZM 330 option containing the same method sent in the original DHCP Request 331 message. The requesting router MUST also send a PDZS option that 332 contains one or more IP addresses for authoritative servers for the 333 reverse tree for the delegated prefix. 335 5.2. Delegating Router Behavior 337 When a delegating router receives a valid DHCP Request message 338 containing an IA_PD that contains both a PDZM option indicating the 339 Site Managed method and a PDZS option containing at least one IP 340 address, it compares the IP addresses in the PDZM option to any 341 previous record it may have for that delegation. If the contents of 342 the PDZM option differ from the previous record, or if there is no 343 previous record, the delegating router MUST issue a DNS Update to add 344 a delegation to the parent zone of the reverse tree zone for the 345 delegated prefix. 347 In the event that the PDZS option contains zero IP addresses, the 348 delegating router does not update the zone. 350 If the delegated prefix must be represented as more than one zone, 351 the delegating router adds delegations to the parent zone for each 352 such zone. 354 When a delegating router receives a DHCP Renew or DHCP Rebind message 355 for a prefix it delegated and elects to renew the prefix, it MUST 356 check its record for that prefix to see if a delegation exists. If 357 the contents of the PDZS differ from the recorded list of 358 authoritative name servers for that prefix, the delegating router 359 MUST update the parent zone with the new delegations. 361 When a delegating router receives a DHCP Renew or DHCP Rebind message 362 for a prefix it delegated, and elects not to renew the delegation, 363 the delegating router MUST check to see if it has a site-managed 364 reverse tree configuration for that pprefix. If it does, it must 365 update the parent zone to remove any delegations that were added, and 366 update its record for the delegated prefix to indicate that no site- 367 managed reverse tree configuration for that prefix is present. 369 When a delegated prefix expires without being renewed by the 370 requesting router, the same procedure should be followed to update 371 the parent zone. 373 In all cases where the delegating router updates the delegation for 374 the zone, it must first query the name server or servers listed in 375 the PDZS opton for an SOA record for each delegated zone. If the 376 name server does not respond within the standard timeout period, or 377 does not provide an authoritative answer, the delegating router MUST 378 NOT add a delegation for that name server. 380 6. Configuring a provider-managed reverse tree 382 If the PDZM returned by a delegating router in the DHCP Advertise 383 message specifies the Provider Managed method, the delegating router 384 must arrange to set up a reverse zone for the delegated prefix. The 385 requesting router must communicate a key to the delegating router 386 that can be used to secure updates to the reverse zone. 388 6.1. Requesting Router Behavior 390 In order to update the provider-managed reverse zone, the requesting 391 router must provide a key to the delegating router. Because DHCP 392 does not provide confidentiality, this key must be the public half of 393 a private key. 395 Typically sites that wish to populate their reverse tree with 396 meaningful information maintain a site-specific or company-wide DNS 397 zone. In order to update the reverse zone, the site administrator 398 must publish a SIG(0) key in this zone. The requesting router MUST 399 include a Prefix Delegation SIG(0) Key FQDN (PDSKF) option in the 400 DHCP Request message and any subsequent DHCP Renew messages. It must 401 use the private half of the SIG(0) key in any DNS updates to the 402 reverse zone. 404 6.2. Delegating Router Behavior 406 There are two cases that the delegating router needs to handle: the 407 case where the prefix being delegated was previously delegated to the 408 same requesting router, and the case where it was not. 410 In the case where the prefix was previously delegated to the same 411 requesting router, the delegating router need take no action to 412 populate the zone, because it should already be populated. 414 In the case where the prefix was previously delegated to a different 415 requesting router, the delegating router MUST remove the old zone 416 information from the master authoritative name server for the zone. 418 In this case, and in the case where no previous delegation had been 419 done, the delegating router must then configure a new reverse zone on 420 the master server. 422 In any case, the delegating router must configure the reverse zone so 423 that it can be updated using the SIG(0) key stored on the name 424 provided by the requesting router in the PDSKF option. 426 7. Configuring a spoofed reverse tree 428 A spoofed reverse tree can be configured either unilaterally by the 429 service provider or upon request of the site administrator. The site 430 administrator would list this as an option to indicate a preference 431 for a spoofed reverse tree over no reverse tree; the choice doesn't 432 make any sense otherwise. 434 Generally speaking, the service provider has the option of either 435 setting up spoofed zones on demand, or setting them up when 436 requested. If the service provider only offers spoofed zones, it 437 makes some sense to set them up in advance; otherwise they should be 438 set up whenever a prefix is delegated to a particular requesting 439 router for the first time. 441 In some cases the site administration may request a spoofed zone 442 because they do not wish to populate the reverse tree, but wish for 443 it to appear populated. A service provider may support this option 444 in addition to the site-managed option, the provider-managed option, 445 and the no zone option. In this case, when a prefix is delegated to 446 a new router for the first time, there may be an old zone configured 447 differently. In this case, the delegated router MUST remove the old 448 zone configuration before setting up the spoofed zone. 450 8. Configuring no reverse tree 452 A service provider may choose to simply not populate reverse trees 453 for delegated prefixes. This is a desirable option in the sense that 454 it minimizes the work required to support the reverse DNS tree, and 455 avoids creating spoofed nonsense records. The service provider may 456 also simply offer it as an option for sites that prefer not to have a 457 populated reverse tree. 459 In this case, if the non-populated reverse tree is an option, and the 460 prefix had previously been delegated to a different router, the 461 delegating router must remove any previously-existing zone for the 462 delegated prefix. 464 9. Encoding of options 466 9.1. Prefix Delegation Method Types 468 Prefix delegation methods are encoded as numbers. Currently three 469 prefix delegation methods are defined: 471 0 Site-Managed 473 1 Provider-managed 474 2 Provider-managed spoofed reverse tree 476 9.2. Prefix Delegation Zone Preference Option 478 The Prefix Delegation Zone Preference option consists of an option 479 code, OPT_PDZP, followed by a length, followed by one or more Prefix 480 Delegation method type codes. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | OPT_PDZP | length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type 1 | ... | Type N | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 9.3. Prefix Delegation Zone Method Option 492 The Prefix Delegation Zone Method option consists of an option code, 493 OPT_PDZM, followed by a length, followed by one Prefix Delegation 494 method type code. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | OPT_PDZM | length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type | 502 +-+-+-+-+-+-+-+ 504 9.4. Prefix Delegation Zone Server Option 506 The Prefix Delegation Zone Server option consists of an option code, 507 OPT_PDZS, followed by a length, followed by zero or more IPv6 508 addresses. 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | OPT_PDZS | length | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | DNS Server IP Address 1 | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | DNS Server IP Address 1 (cont'd) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | DNS Server IP Address 1 (cont'd) | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | DNS Server IP Address 1 (cont'd) | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 ... 525 10. Security Considerations 527 Some ISPs may have concerns about allowing site-managed DNS 528 subdelegations for the reverse zone, but this concern is a policy 529 issue, not a security issue. In the presence of properly agreed-to 530 terms of service, population of a reverse tree by the end-user is 531 simply a value-added service the ISP may or may not choose to 532 provide. Even in the absence of a legally binding ToS agreement, the 533 worst an end-user could do would be to publish nasty words or bogus 534 PTR records, neither of which is a security concern. 536 If an implementation were to fail to follow the advice on validating 537 authoritative name servers supplied by the requesting router, it 538 would probably be possible for a coordinated set of requesting 539 routers to perform a DDoS attack on a target by arranging for various 540 entities on the network to query the reverse tree for one or more of 541 the IP addresses in the delegated prefix. However, this would 542 require, first, that the implementation not follow the specification, 543 and second, a fairly complicated setup. In practice, there are 544 easier ways to get a DDoS amplification. 546 11. IANA Considerations 548 We request that IANA assign three new option codes from the DHCP 549 Option Codes table of the Dynamic Host Configuration Protocol for 550 IPv6 (DHCPv6) parameters registry maintained in http://www.iana.org/ 551 assignments/dhcpv6-parameters/dhcpv6-parameters.xml These option 552 codes will be assigned to the Prefix Delegation Zone Preference 553 (OPT_PDZP), Prefix Delegation Zone Method (OPT_PDZM) and Prefix 554 Delegation Zone Servers (OPT_PDZS) options. 556 We also request that the IANA add a new table, the Prefix Delegation 557 Zone Method Types table, to the same registry. The first three 558 entries in the table will contain the values specified in the section 559 above titled "Prefix Delegation Zone Method Types." New entries to 560 the table may be added according to the "Specification Required" IANA 561 policy [RFC5226]. 563 12. References 565 12.1. Normative References 567 [RFC1035] Mockapetris, P., "Domain names - implementation and 568 specification", STD 13, RFC 1035, November 1987. 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, March 1997. 573 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 574 Host Configuration Protocol (DHCP) version 6", RFC 3633, 575 December 2003. 577 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 578 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 579 October 2010. 581 12.2. Informative References 583 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 584 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 585 May 2008. 587 Author's Address 589 Ted Lemon 590 Nominum 591 2000 Seaport Blvd 592 Redwood City, CA 94063 593 USA 595 Phone: +1 650 381 6000 596 Email: mellon@nominum.com