idnits 2.17.1 draft-ietf-homenet-naming-architecture-dhc-options-07.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 (April 19, 2020) is 1439 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 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-27) exists of draft-ietf-homenet-front-end-naming-delegation-10 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track R. Weber 5 Expires: October 21, 2020 Akamai 6 T. Mrugalski 7 Internet Systems Consortium, Inc. 8 C. Griffiths 10 W. Cloetens 11 April 19, 2020 13 DHCPv6 Options for Home Network Authoritative Naming Service 14 draft-ietf-homenet-naming-architecture-dhc-options-07 16 Abstract 18 This document defines DHCPv6 options so any agnostic Homnet Naming 19 Authority (HNA) can automatically proceed to the appropriate 20 configuration and outsource the authoritative naming service for the 21 home network. In most cases, the outsourcing mechanism is 22 transparent for the end user. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 21, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Client Public Key Option . . . . . . . . . . . . . . . . 5 63 4.2. Distribution Master Option . . . . . . . . . . . . . . . 5 64 4.3. Reverse Synchronization Server Option . . . . . . . . . . 6 65 5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 67 5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7 68 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations" . . . . . . . . . . . . . . . . . . 8 71 7.1. DNSSEC is recommended to authenticate DNS hosted data . . 8 72 7.2. Channel between the HNA and ISP DHCP Server MUST be 73 secured . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7.3. HNAs are sensitive to DoS . . . . . . . . . . . . . . . . 8 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 76 9. Scenarios and impact on the End User . . . . . . . . . . . . 9 77 10. Base Scenario . . . . . . . . . . . . . . . . . . . . . . . . 9 78 10.1. Third Party Registered Homenet Domain . . . . . . . . . 9 79 10.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 10 80 10.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . 11 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 11.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in 91 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 The reader is expected to be familiar with 95 [I-D.ietf-homenet-front-end-naming-delegation] and its terminology 96 section. This section defines terms that have not been defined in 97 [I-D.ietf-homenet-front-end-naming-delegation]: 99 o Client Public Key: designates a public key generated by the HNA 100 and used as an authentication credential for the HNA. 102 2. Introduction 104 [I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet 105 Naming Authority (HNA) outsources the Public Homenet Zone to an 106 Outsourcing Infrastructure. 108 In most cases the setting of the relation between the HNA and the 109 Outsourcing Infrastructure is not fully automated and involves the 110 end user. More specifically, the Outsourcing Infrastructure needs to 111 be able to authenticate the HNA as well as needs to ensure the HNA 112 owns the Registered Homenet Domain. As a result, the Outsourcing 113 Infrastructure is likely to be provided by a registrar. 115 This document describes DHCPv6 options that leverage a relation 116 between the ISP and an end user to fully automated these steps. This 117 enables an end user to provide the home network configuration to the 118 DHCPv6 server, so an HNA can outsource without any configuration. In 119 this case, outsourcing is achieved with zero-config and is resilient 120 to HNA change. This may provide the ability for an ISP to provide a 121 default outsourcing service to its customers, however this service 122 can be used by the end user for any specific Homenet registered 123 domain, not just the ones provided by the ISP and as such benefits 124 the end user. 126 The overall principle is that the HNA advertises the DHCPv6 server of 127 its Public Key. This Public Key will be used by the HNA for the 128 authentication during the TLS key exchange between the HNA and the 129 Distribution Master (DM) of the Public Homenet Zone and the Reverse 130 Homenet Zone. Note that a specific relation between the DHCPv6 131 server and the DM is required. When the DHCPv6 server is managed by 132 the ISP, such relation exist between DHCPv6 server and the DM of the 133 Reverse Homenet Zone. Such relation may also exist - but not 134 necessarily - between the DHCPv6 server and the DM of the Public 135 Homenet Zone. The DHCHv6 server provides the HNA the FQDN and Public 136 Keys of the respective DMs. 138 This document assumes the link between the HNA and the DHCPv6 server 139 is trustworthy for example using [I-D.ietf-dhc-sedhcpv6]. 141 3. Protocol Overview 143 This section illustrates how a HNA receives the necessary information 144 via DHCPv6 options to outsource its authoritative naming service on 145 the Outsourcing Infrastructure. For the sake of simplicity, this 146 section assumes that the DHCPv6 server is able to communicate to the 147 various DNS servers and to provide them the public key associated 148 with the HNA. Once each server got the public key, the HNA can 149 proceed to transactions in an authenticated and secure way. 151 This scenario has been chosen as it is believed to be the most 152 popular scenario. This document does not ignore scenarios where the 153 DHCP Server does not have privileged relations with the DM. 155 These cases are discussed latter in Section 9. Such scenario does 156 not necessarily require configuration for the end user and can also 157 be zero-config. 159 The scenario is as follows: 161 o 1) The HNA provides its Client Public Key to the DHCP Server using 162 a Client Public Key Option (OPTION_PUBLIC_KEY) and includes the 163 following option codes in its its Option Request Option (ORO): the 164 Distribution Master Option (OPTION_DM) and the Reverse 165 Distribution Master Option (OPTION_REVERSE_DM). 167 o 2) The DHCP Server makes the Client Public Key available to the DM 168 servers, so the HNA can secure its DNS transactions. How the 169 Client Public Key is transmitted to the various DNS servers is out 170 of scope of this document. Note that the Client Public Key alone 171 is not sufficient to perform the authentication and the key should 172 be, for example, associated with an identifier, or the concerned 173 domain name. How the binding is performed is out of scope of the 174 document. It can be a centralized database or various bindings 175 may be sent to the different servers. 177 o 3) The DHCP Server responds to the HNA with the requested DHCPv6 178 options, i.e. the Distribution Master Option (OPTION_DM) and the 179 Reverse Distribution Master Option (OPTION_REVERSE_DM). 181 o 4) Once the Homenet Zone has been set, the HNA uploads the zone to 182 the respective DMs. 184 4. Payload Description 186 This section details the payload of the DHCPv6 options. 188 4.1. Client Public Key Option 190 The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client 191 Public Key that is used to authenticate the HNA. This option is 192 defined in [I-D.ietf-dhc-sedhcpv6]. 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | OPTION_PUBLIC_KEY | option-len | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 / Public Key Data / 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 { #fig-public-key title="Client Public Key Option"} 206 o option-code (16 bits): OPTION_PUBLIC_KEY, the option code for the 207 Client Public Key Option (TBD1). 209 o option-len (16 bits): length in octets of the option-data field as 210 described in [RFC3315]. 212 o Client Public Key Data: contains the Client Public Key. The format 213 is the DNSKEY RDATA format as defined in [RFC4034]. 215 4.2. Distribution Master Option 217 The Synchronization Server Option (OPTION_SYNC_SERVER) provides 218 information necessary for the HNA to upload the Homenet Zone to the 219 Synchronization Server. Finally, the option provides the 220 authentication methods that are available to perform the upload. The 221 upload is performed via a DNS primary / secondary architecture or DNS 222 updates. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | OPTION_DIST_MASTER | option-len | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Server Port | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 231 | | 232 / DM FQDN / 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 { #fig-name-srv-set title="Synchronization Server Option"} 237 o option-code (16 bits): OPTION_SYNC_SERVER, the option code for the 238 Synchronization Server Option (TBD2). 240 o option-len (16 bits): length in octets of the option-data field as 241 described in [RFC3315]. 243 o Server Port (16 bits): defines the port the Synchronization Server 244 is listening. When multiple transport layers may be used, a 245 single and unique Server Port value applies to all the transport 246 layers. In the case of DNS for example, Server Port value 247 considers DNS exchanges using UDP and TCP. 249 o Synchronization Server FQDN (variable): the FQDN of the 250 Synchronization Server. 252 4.3. Reverse Synchronization Server Option 254 The Reverse Synchronization Server Option 255 (OPTION_REVERSE_SYNC_SERVER) provides information necessary for the 256 HNA to upload the Homenet Zone to the Synchronization Server. The 257 option provides the authentication methods that are available to 258 perform the upload. The upload is performed via a DNS primary / 259 secondary architecture or DNS updates. 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | OPTION_DIST_MASTER | option-len | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Server Port | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 268 | | 269 / Reverse DM FQDN / 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 1: Reverse Synchronization Server Option 275 o option-code (16 bits): OPTION_REVERSE_SYNC_SERVER, the option code 276 for the Reverse Synchronization Server Option (TBD3). 278 o option-len (16 bits): length in octets of the option-data field as 279 described in [RFC3315]. 281 o Server Port (16 bits): defines the port the Synchronization Server 282 is listening. 284 o Reverse Synchronization Server FQDN (variable): The FQDN of the 285 Reverse Synchronization Server. 287 5. DHCP Behavior 289 5.1. DHCPv6 Server Behavior 291 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 292 regards to option assignment. As a convenience to the reader, we 293 mention here that the server will send option foo only if configured 294 with specific values for foo and if the client requested it. In 295 particular, when configured the DHCP Server sends the Zone Template 296 Option, Synchronization Server Option, Reverse Synchronization Server 297 Option when requested by the DHCPv6 client by including necessary 298 option codes in its ORO. 300 The DHCP Server may receive a Client Public Key Option 301 (OPTION_PUBLIC_KEY) from the HNA. Upon receipt of this DHCPv6 302 option, the DHCP Server SHOULD acknowledge the reception of the 303 Client Public Key Option as described and communicate this credential 304 to the available DM and Reverse DM unless not configured to do so. 306 A HNA may update its Client Public Key by sending a new value in the 307 Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes 308 the link between the HNA and the DHCP Server is considered 309 authenticated and trusted. The server SHOULD process received Client 310 Public Key Option sent by the client unless not configured to do so. 312 5.2. DHCPv6 Client Behavior 314 The DHCPv6 client SHOULD send a Client Public Key Option 315 (OPTION_PUBLIC_KEY) to the DHCP Server. This Client Public Key 316 authenticates the HNA. 318 The DHCPv6 client sends a ORO with the necessary option codes: Zone 319 Template Option, Synchronization Server Option and Reverse 320 Synchronization Server Option. 322 Upon receiving a DHCP option described in this document in the Reply 323 message, the HNA SHOULD publish the zone as described in 324 [I-D.ietf-homenet-front-end-naming-delegation]. 326 5.3. DHCPv6 Relay Agent Behavior 328 There are no additional requirements for the DHCP Relay agents. 330 6. IANA Considerations 332 The DHCP options detailed in this document is: * OPTION_CLIENT_KEY: 333 TBD1 * OPTION_REGISTERED_DOMAIN: TBD2 * OPTION_SYNC_SERVER: TBD3 * 334 OPTION_REVERSE_SYNC_SERVER: TBD4 336 7. Security Considerations" 338 7.1. DNSSEC is recommended to authenticate DNS hosted data 340 It is recommended that the (Reverse) Homenet Zone is signed with 341 DNSSEC. The zone may be signed by the HNA or by a third party. We 342 recommend the zone to be signed by the HNA, and that the signed zone 343 is uploaded. 345 7.2. Channel between the HNA and ISP DHCP Server MUST be secured 347 The channel MUST be secured because the HNA provides authentication 348 credentials. Unsecured channel may result in HNA impersonation 349 attacks. 351 The document considers that the channel between the HNA and the ISP 352 DHCP Server is trusted. More specifically, the HNA is authenticated 353 and the exchanged messages are protected. The current document does 354 not specify how to secure the channel. [RFC3315] proposes a DHCP 355 authentication and message exchange protection, [RFC4301], [RFC7296] 356 propose to secure the channel at the IP layer. 358 7.3. HNAs are sensitive to DoS 360 HNA have not been designed for handling heavy load. The HNA are 361 exposed on the Internet, and their IP address is publicly published 362 on the Internet via the DNS. This makes the Home Network sensitive 363 to Deny of Service Attacks. The resulting outsourcing architecture 364 is described in [I-D.ietf-homenet-front-end-naming-delegation]. This 365 document shows how the outsourcing architecture can be automatically 366 set. 368 8. Acknowledgments 370 We would like to thank Marcin Siodelski and Bernie Volz for their 371 comments on the design of the DHCPv6 options. We would also like to 372 thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their 373 remarks on the architecture design. The designed solution has been 374 largely been inspired by Mark Andrews's document 375 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We 376 also thank Ray Hunter for its reviews, its comments and for 377 suggesting an appropriated terminology. 379 9. Scenarios and impact on the End User 381 This section details various scenarios and discuss their impact on 382 the end user. 384 10. Base Scenario 386 The base scenario is the one described in Section 3. It is typically 387 the one of an ISP that manages the DHCP Server, and all DNS servers. 389 The end user subscribes to the ISP (foo), and at subscription time 390 registers for example.foo as its Registered Homenet Domain 391 example.foo. 393 When the HNA is plugged (at least the first time), it provides its 394 Client Public Key to the DHCP Server. In this scenario, the DHCP 395 Server and the DNS Servers are managed by the ISP so the DHCP Server 396 can provide authentication credentials of the HNA to enable secure 397 authenticated transaction with the DM and the Reverse DM. 399 The main advantage of this scenario is that the naming architecture 400 is configured automatically and transparently for the end user. The 401 drawbacks are that the end user uses a Registered Homenet Domain 402 managed by the ISP and that it relies on the ISP naming 403 infrastructure. 405 10.1. Third Party Registered Homenet Domain 407 This section considers the case when the end user wants its home 408 network to use example.com as a Registered Homenet Domain instead of 409 example.foo that has been assigned by the ISP. We also suppose that 410 example.com is not managed by the ISP. 412 This can also be achieved without any configuration. When the end 413 user buys the domain name example.com, it may request to redirect the 414 name example.com to example.foo using static redirection with CNAME 415 [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 416 [I-D.sury-dnsext-cname-dname]. 418 This configuration is performed once when the domain name example.com 419 is registered. The only information the end user needs to know is 420 the domain name assigned by the ISP. Once this configuration is done 421 no additional configuration is needed anymore. More specifically, 422 the HNA may be changed, the zone can be updated as in Section 10 423 without any additional configuration from the end user. 425 The main advantage of this scenario is that the end user benefits 426 from the Zero Configuration of the Base Scenario Section 10. Then, 427 the end user is able to register for its home network an unlimited 428 number of domain names provided by an unlimited number of different 429 third party providers. 430 The drawback of this scenario may be that the end user still rely on 431 the ISP naming infrastructure. Note that the only case this may be 432 inconvenient is when the DNS Servers provided by the ISPs results in 433 high latency. 435 10.2. Third Party DNS Infrastructure 437 This scenario considers that the end user uses example.com as a 438 Registered Homenet Domain, and does not want to rely on the 439 authoritative servers provided by the ISP. 441 In this section we limit the outsourcing to the DM and Public 442 Authoritative Server(s) to a third party. The Reverse Public 443 Authoritative Server(s) and Reverse Synchronization Server remain 444 managed by the ISP as the IP prefix is managed by the ISP. 446 Outsourcing DM and Public Authoritative Server(s) requires: 448 1. Updating the DHCP Server Information. One can imagine a GUI 449 interface that enables the end user to modify its profile 450 parameters. Again, this configuration update is done once-for- 451 ever. 453 2. Upload the authentication credential of the HNA, that is the 454 Client Public Key of the HNA, to the third party. Unless we use 455 specific mechanisms, like communication between the DHCP Server 456 and the third party, or a specific token that is plugged into the 457 HNA, this operation is likely to be performed every time the HNA 458 is changed, and every time the Client Public Key generated by the 459 HNA is changed. 461 The main advantage of this scenario is that the DNS infrastructure is 462 completely outsourced to the third party. Most likely the Client 463 Public Key that authenticate the HNA needs to be configured for every 464 HNA. Configuration is expected to be HNA live-long. 466 10.3. Multiple ISPs 468 This scenario considers a HNA connected to multiple ISPs. 470 Suppose the HNA has been configured each of its interfaces 471 independently with each ISPS as described in Section 10. Each ISP 472 provides a different Registered Homenet Domain. The HNA Client 473 Public Key may be shared between the HNA and the multiple ISPs. 475 The protocol and DHCPv6 options described in this document are fully 476 compatible with a HNA connected to multiple ISPs with multiple 477 Registered Homenet Domains. However, the HNA should be able to 478 handle different Registered Homenet Domains. This is an 479 implementation issue which is outside the scope of the current 480 document. 482 If a HNA is not able to handle multiple Registered Homenet Domains, 483 the HNA may remain connected to multiple ISP with a single Registered 484 Homenet Domain. In this case, the one party is chosen to host the 485 Registered Homenet Domain. 487 This entity may be one of the ISP or a third party. Note that having 488 multiple ISPs can be motivated for bandwidth aggregation, or 489 connectivity fail-over. In the case of connectivity fail-over, the 490 fail-over concerns the access network and a failure of the access 491 network may not impact the core network where the DM Server and 492 Public Authoritative Primaries are hosted. In that sense, choosing 493 one of the ISP even in a scenario of multiple ISPs may make sense. 494 However, for sake of simplicity, this scenario assumes that a third 495 party has be chosen to host the Registered Homenet Domain. The DNS 496 settings for each ISP is described in Section 10.1 and Section 10.2. 497 With the configuration described in Section 10.1, the HNA is expect 498 to be able to handle multiple Homenet Registered Domain, as the third 499 party redirect to one of the ISPs Servers. With the configuration 500 described in Section 10.2, DNS zone are hosted and maintained by the 501 third party. A single DNS(SEC) Homenet Zone is built and maintained 502 by the HNA. This latter configuration is likely to match most HNA 503 implementations. 505 The protocol and DHCPv6 options described in this document are fully 506 compatible with a HNA connected to multiple ISPs. To configure or 507 not and how to configure the HNA depends on the HNA facilities. 508 Section 10 and Section 10.1 require the HNA to handle multiple 509 Registered Homenet Domain, whereas Section 10.2 does not have such 510 requirement. 512 11. References 514 11.1. Normative References 516 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 517 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 518 . 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, 522 DOI 10.17487/RFC2119, March 1997, 523 . 525 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 526 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 527 . 529 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 530 C., and M. Carney, "Dynamic Host Configuration Protocol 531 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 532 2003, . 534 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 535 Rose, "Resource Records for the DNS Security Extensions", 536 RFC 4034, DOI 10.17487/RFC4034, March 2005, 537 . 539 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 540 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 541 December 2005, . 543 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 544 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 545 . 547 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 548 Kivinen, "Internet Key Exchange Protocol Version 2 549 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 550 2014, . 552 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 553 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 554 May 2017, . 556 11.2. Informative References 558 [I-D.andrews-dnsop-pd-reverse] 559 Andrews, M., "Automated Delegation of IP6.ARPA reverse 560 zones with Prefix Delegation", draft-andrews-dnsop-pd- 561 reverse-02 (work in progress), November 2013. 563 [I-D.ietf-dhc-sedhcpv6] 564 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 565 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 566 in progress), February 2017. 568 [I-D.ietf-homenet-front-end-naming-delegation] 569 Migault, D., Weber, R., Richardson, M., Hunter, R., 570 Griffiths, C., and W. Cloetens, "Outsourcing Home Network 571 Authoritative Naming Service", draft-ietf-homenet-front- 572 end-naming-delegation-10 (work in progress), March 2020. 574 [I-D.sury-dnsext-cname-dname] 575 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 576 dnsext-cname-dname-00 (work in progress), April 2010. 578 Authors' Addresses 580 Daniel Migault 581 Ericsson 582 8275 Trans Canada Route 583 Saint Laurent, QC 4S 0B6 584 Canada 586 EMail: daniel.migault@ericsson.com 588 Ralf Weber 589 Akamai 591 EMail: ralf.weber@nominum.com 593 Tomek Mrugalski 594 Internet Systems Consortium, Inc. 595 950 Charter Street 596 Redwood City 94063 597 US 599 EMail: tomasz.mrugalski@gmail.com 600 Chris Griffiths 602 EMail: cgriffiths@gmail.com 604 Wouter Cloetens 606 EMail: wouter.cloetens@softathome.com