idnits 2.17.1 draft-ietf-homenet-naming-architecture-dhc-options-06.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 (June 25, 2018) is 2129 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 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-27) exists of draft-ietf-homenet-front-end-naming-delegation-06 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOMENET D. Migault (Ed) 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Mrugalski 5 Expires: December 27, 2018 ISC 6 C. Griffiths 8 R. Weber 9 Nominum 10 W. Cloetens 11 SoftAtHome 12 June 25, 2018 14 DHCPv6 Options for Homenet Naming Architecture 15 draft-ietf-homenet-naming-architecture-dhc-options-06 17 Abstract 19 The Homenet Naming Authority (HNA) is the designated device in charge 20 of outsourcing the service to a third party, which requires setting 21 up an architecture. 23 Such settings may be inappropriate for most end users. This document 24 defines DHCPv6 options so any agnostic HNA can automatically proceed 25 to the appropriate configuration and outsource the authoritative 26 naming service for the home network. In most cases, the outsourcing 27 mechanism is transparent for the end user. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 27, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Architecture and DHCPv6 Options Overview . . . . . . . . 6 68 4.2. Mechanisms Securing DNS Transactions . . . . . . . . . . 9 69 4.3. Primary / Secondary Synchronization versus DNS Update . . 10 70 5. HNA Configuration . . . . . . . . . . . . . . . . . . . . . . 11 71 5.1. HNA Primary / Secondary Synchronization Configurations . 11 72 5.1.1. HNA / Synchronization Server . . . . . . . . . . . . 11 73 5.1.2. HNA / Reverse Synchronization Server . . . . . . . . 11 74 5.2. HNA DNS Data Handling and Update Policies . . . . . . . . 12 75 5.2.1. Homenet Zone Template . . . . . . . . . . . . . . . . 12 76 5.2.2. DNS (Reverse) Homenet Zone . . . . . . . . . . . . . 12 77 6. Payload Description . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Supported Authentication Methods Field . . . . . . . . . 13 79 6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14 80 6.3. Client Public Key Option . . . . . . . . . . . . . . . . 14 81 6.4. Zone Template Option . . . . . . . . . . . . . . . . . . 14 82 6.5. Synchronization Server Option . . . . . . . . . . . . . . 15 83 6.6. Reverse Synchronization Server Option . . . . . . . . . . 16 84 7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 17 85 7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 17 86 7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 18 87 7.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 18 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 90 9.1. DNSSEC is recommended to authenticate DNS hosted data . . 19 91 9.2. Channel between the HNA and ISP DHCP Server MUST be 92 secured . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 9.3. HNAs are sensitive to DoS . . . . . . . . . . . . . . . . 19 95 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 98 11.2. Informational References . . . . . . . . . . . . . . . . 21 99 Appendix A. Scenarios and impact on the End User . . . . . . . . 22 100 A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 22 101 A.2. Third Party Registered Homenet Domain . . . . . . . . . . 23 102 A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 23 103 A.4. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 25 104 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 107 1. Requirements notation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Terminology 115 The reader is expected to be familiar with 116 [I-D.ietf-homenet-front-end-naming-delegation] and its terminology 117 section. This section defines terms that have not been defined in 118 [I-D.ietf-homenet-front-end-naming-delegation]: 120 - Client Public Key: designates a public key generated by the HNA. 121 This key is used as an authentication credential for the HNA. 123 - Homenet Zone Template: The template used as a basis to generate 124 the Homenet Zone. 126 - DNS Template Server: The DNS server that hosts the Homenet Zone 127 Template. 129 - Homenet Reverse Zone: The reverse zone file associated to the 130 Homenet Zone. 132 3. Introduction 134 HNAs are usually constrained devices with reduced network and CPU 135 capacities. As such, a HNA hosting on the Internet the authoritative 136 naming service for its home network may become vulnerable to resource 137 exhaustion attacks. Outsourcing the authoritative service to a third 138 party avoids exposing the HNA to such attacks. This third party can 139 be the ISP or any other independent third party. 141 Outsourcing the authoritative naming service to a third party 142 requires setting up an architecture designated in this document as 143 the Outsourcing Infrastructure. These settings may be inappropriate 144 for most end users that do not have the sufficient knowledge. To 145 address this issue, this document proposes DHCPv6 options so any 146 agnostic HNA can automatically set the Outsourcing Infrastructure. 147 In most cases, these DHCPv6 options are sufficient and do not require 148 any additional interaction from the end user, thus achieving a zero- 149 config settings. In some other cases, the end user is expected to 150 perform some limited manual configuration. 152 When the HNA is plugged, the DHCPv6 options described in the document 153 enable: 155 - 1. To build the Homenet Zone: Building the Homenet Zone requires 156 filling the zone with appropriated bindings such as bindings 157 between the names and the IP addresses of the different devices 158 of the home networks. How the HNA is aware of these binding is 159 out of scope of the document. They may be provided, for 160 example, by the DHCPv6 server hosted on the HNA. On the other 161 hand, building the Homenet Zone also requires configuration 162 parameters like the name of the Registered Domain Name 163 associated to the home network or the Public Authoritative 164 Server(s) the Homenet Zone is outsourced to. These 165 configuration parameters are stored in the Homenet Zone 166 Template. This document describes the Zone Template Option 167 which carries the FQDN associated to the Homenet Zone Template. 168 In order to retrieve the Homenet Zone Template, the HNA sends a 169 query of type AXFR [RFC1034], [RFC5936]. 171 - 2. To upload the Homenet Zone to the Synchronization Server, in 172 charge of publishing the Homenet Zone on the Public 173 Authoritative Server(s). This document describes the 174 Synchronization Server Option that provides the FQDN of the 175 appropriated server. Note that, the document does not consider 176 whether the Homenet Zone is signed or not, and if signed, which 177 entity is responsible to sign it. Such questions are out of 178 the scope of the current document. 180 - 3. To upload the Homenet Reverse Zone to the Reverse 181 Synchronization Server in charge of publishing the Homenet 182 Reverse Zone on the Reverse Public Authoritative Server(s). 183 This document describes the Reverse Synchronization Server 184 Option that provides the FQDN of the appropriated server. 185 Similarly to item 2., we do not consider in this document if 186 the Homenet Reverse Zone is signed or not, and if signed who 187 signs it. 189 - 4. To provide authentication credential (a public key) to the DHCP 190 Server: Information stored in the Homenet Zone Template, the 191 Homenet Zone and Homenet Reverse Zone belongs to the HNA, and 192 only the HNA should be able to update or upload these zones. 193 To authenticate the HNA, this document defines the Client 194 Public Key Option. This option is sent by the HNA to the 195 DHCPv6 server and provides the Client Public Key the HNA uses 196 to authenticate itself. This document does not describe 197 mechanisms used to transmit the Client Public Key from the 198 DHCPv6 server to the appropriate entities. If the DHCPv6 199 server is not able to provide the Client Public Key to the 200 appropriated entities, then the end user is likely to provide 201 manually the Client Public Key to these entities. This 202 document illustrates two scenarios: one where the DHCPv6 server 203 is responsible for distributing the Client Public Key to the 204 Synchronization Servers and Reverse Synchronization Server. In 205 the other scenarios, the Client Public Key is distributed out 206 of band. 208 The DHCPv6 options described in this document make possible to 209 configure an Outsourcing Infrastructure with no or little 210 configurations from the end user. A zero-config setting is achieved 211 if the the link between the HNA and the DHCPv6 server and the link 212 between the DHCPv6 server and the various DNS servers (Homenet Zone 213 Server, the Reverse Synchronization Server, Synchronization Server) 214 are trusted. For example, one way to provide a thrustworhy 215 connection between the HNA and the DHCPv6 server is defined in 216 [I-D.ietf-dhc-sedhcpv6]. When both links are trusted, the HNA is 217 able to provide its authentication credentials (a Client Public Key) 218 to the DHCPv6 server, that in turn forwards it to the various DNS 219 servers. With the authentication credentials on the DNS servers, the 220 HNA is able to securely update. 222 If the DHCPv6 server cannot provide the Client Public Key to one of 223 these servers (most likely the Synchronization Server) and the HNA 224 needs to interact with the server, then, the end user is expected to 225 provide the HNA's Client Public Key to these servers (the Reverse 226 Synchronization Server or the Synchronization Server) either manually 227 or using other mechanisms. Such mechanisms are outside the scope of 228 this document. In that case, the authentication credentials need to 229 be provided every time the key is modified. Appendix A provides more 230 details on how different scenarios impact the end users. 232 The remaining of this document is structured as follows. Section 4 233 provides an overview of the DHCPv6 options as well as the expected 234 interactions between the HNA and the various involved entities. This 235 section also provides an overview of available mechanisms to secure 236 DNS transactions and update DNS data. Section 5 describes how the 237 HNA may securely synchronize and update DNS data. Section 6 238 describes the payload of the DHCPv6 options and Section 7 details how 239 DHCPv6 client, server and relay agent behave. Section 8 lists the 240 new parameters to be registered at the IANA, Section 9 provides 241 security considerations. Finally, Appendix A describes how the HNA 242 may behave and be configured regarding various scenarios. 244 4. Protocol Overview 246 This section provides an overview of the HNA's interactions with the 247 Outsourcing Infrastructure in Section 4.1, and so the necessary for 248 its setting. In this document, the configuration is provided via 249 DHCPv6 options. Once configured, the HNA is expected to be able to 250 update and publish DNS data on the different components of the 251 Outsourcing Infrastructure. As a result authenticating and updating 252 mechanisms play an important role in the specification. Section 4.2 253 provides an overview of the different authentication methods and 254 Section 4.3 provides an overview of the different update mechanisms 255 considered to update the DNS data. 257 4.1. Architecture and DHCPv6 Options Overview 259 This section illustrates how a HNA receives the necessary information 260 via DHCPv6 options to outsource its authoritative naming service on 261 the Outsourcing Infrastructure. For the sake of simplicity, this 262 section assumes that the DHCPv6 server is able to communicate to the 263 various DNS servers and to provide them the public key associated 264 with the HNA. Once each server got the public key, the HNA can 265 proceed to transactions in an authenticated and secure way. 267 This scenario has been chosen as it is believed to be the most 268 popular scenario. This document does not ignore that scenarios where 269 the DHCP Server does not have privileged relations with the 270 Synchronization Server must be considered. These cases are discussed 271 latter in Appendix A. Such scenario does not necessarily require 272 configuration for the end user and can also be zero-config. 274 The scenario is represented in Figure 1. 276 - 1: The HNA provides its Client Public Key to the DHCP Server using 277 a Client Public Key Option (OPTION_PUBLIC_KEY) and includes the 278 following option codes in its its Option Request Option (ORO): 279 Zone Template Option (OPTION_DNS_ZONE_TEMPLATE), the 280 Synchronization Server Option (OPTION_SYNC_SERVER) and the 281 Reverse Synchronization Server Option 282 (OPTION_REVERSE_SYNC_SERVER). 284 - 2: The DHCP Server makes the Client Public Key available to the 285 DNS servers, so the HNA can secure its DNS transactions. How 286 the Client Public Key is transmitted to the various DNS servers 287 is out of scope of this document. Note that the Client Public 288 Key alone is not sufficient to perform the authentication and 289 the key should be, for example, associated with an identifier, 290 or the concerned domain name. How the binding is performed is 291 out of scope of the document. It can be a centralized database 292 or various bindings may be sent to the different servers. 293 Figure 1 represents the specific case where the DHCP Server 294 forwards the set (Client Public Key, Zone Template FQDN) to the 295 DNS Template Server, the set (Client Public Key, IPv6 subnet) 296 to the Reverse Synchronization Server and the set (Client 297 Public Key, Registered Homenet Domain) to the Synchronization 298 Server. 300 - 3: The DHCP Server responds to the HNA with the requested DHCPv6 301 options, i.e. the Client Public Key Option (OPTION_PUBLIC_KEY), 302 Zone Template Option OPTION_DNS_ZONE_TEMPLATE, Synchronization 303 Server Option (OPTION_SYNC_SERVER), Reverse Synchronization 304 Server Option (OPTION_REVERSE_SYNC_SERVER). Note that this 305 step may be performed in parallel to step 2, or even before. 306 In other words, there is no requirements that step 3 is 307 conducted after step 2. 309 - 4: Upon receiving the Zone Template Option 310 (OPTION_DNS_ZONE_TEMPLATE), the HNA performs an AXFR DNS query 311 for the Zone Template FQDN. The exchange is authenticated 312 according to the authentication methods defined in the 313 Supported Authentication Methods field of the DHCP option. 314 Once the HNA has retrieved the DNS Zone Template, the HNA can 315 build the Homenet Zone and the Homenet Reverse Zone. 316 Eventually the HNA signs these zones. 318 - 5: Once the Homenet Reverse Zone has been set, the HNA uploads the 319 zone to the Reverse Synchronization Server. The Reverse 320 Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER) 321 provides the Reverse Synchronization Server FQDN as well as the 322 upload method, and the Supported Authentication Methods 323 protocol to secure the upload. 325 - 6: Once the Homenet Zone has been set, the HNA uploads the zone to 326 the Synchronization Server. The Synchronization Server Option 327 (OPTION_SYNC_SERVER) provides the Synchronization Server FQDN 328 as well as the upload method and the authentication method to 329 secure the upload. 331 +---------------------+ 332 | DHCPv6 Server | 333 +---------------------+ 334 ^ ^ ^ 335 | | | 336 1.| |3. |2. 337 | | | 338 v v | 339 +------+ | +--------------------------------+ 340 | | 4. +--->| DNS Template Server | 341 | |<---------->| | 342 | | | +--------------------------------+ 343 | HNA | | 344 | | | +--------------------------------+ 345 | | 5./6. +--->| Reverse Synchronization | 346 | |<---------->| Server | 347 | | | +--------------------------------+ 348 | | | 349 | | | +--------------------------------+ 350 +------+ +--->| Synchronization Server | 351 | | 352 +--------------------------------+ 354 Figure 1: Protocol Overview 356 As described above, the HNA is likely to interact with various DNS 357 content. More specifically, the HNA is likely to update the: 359 - Homenet Zone Template: if the configuration of the zone may be 360 changed. This may include additional Public Authoritative 361 Server(s), a different Registered Homenet Domain as the one 362 initially proposed, or a redirection to another domain. 364 - Homenet Reverse Zone: every time a new device is connected or 365 dis-connected. 367 - Homenet Zone: every time a new device is connected, dis- 368 connected. 370 Step 2 and step 3 should be considered as independent steps and could 371 be re-ordered. In fact, the DHCPv6 server does not have to wait for 372 a confirmation from the DNS servers the Client Public Key has been 373 properly received, and is operational by the DNS servers. The DHCP 374 Server is expected to reply upon receiving the Client Public Key 375 Option. The reply to the message with a Client Public Key Option 376 from the DHCP Server is interpreted by the DHCPv6 client as a 377 confirmation of the reception of the option by the DHCP Server only. 378 It does not indicate whether the server had processed the option or 379 not. Debugging configurations errors or transmission error with one 380 of the DNS servers is let to the HNA and thus is outside of the scope 381 of the DHCPv6. First, it is unlikely a DNS server can validate that 382 the Client Public Key will be operational for the HNA, as multiple 383 causes of errors could occur. For example, the Client Public Key may 384 have been changed during the transmission or by the DHCP Server, or 385 the DNS server may be misconfigured. Second, the number of error 386 codes would be too complex. In addition to multiple causes of 387 errors, multiple architectures and multiple DNS servers may be 388 involved. Third, this may cause significant DHCP Server performance 389 degradation. 391 In fact, the HNA performs these updates in a secure manner. There 392 are multiple ways to secure a DNS transaction and this document 393 considers two mechanisms: nsupdate and primary/secondary 394 synchronization. Section 4.2 describes the authentication method 395 that may be use to secure the DNS transactions of the HNA. The 396 appropriate authentication methods may, for example, be chosen 397 according to the level of confidentiality or the level of 398 authentication requested by the HNA transactions. Section 4.3 399 positions the nsupdate and primary/secondary synchronization 400 mechanisms. The update appropriate update mechanism may depend on 401 the for example on the update frequency or the size of the DNS data 402 to update. 404 4.2. Mechanisms Securing DNS Transactions 406 Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] / 407 [RFC6347] may be used to secure DNS transactions between the HNA and 408 the DNS servers. This document limits its scope to authentication 409 method that have been designed specifically for DNS. This includes 410 DNSSEC [RFC4033], [RFC4034], [RFC4035] that authenticates and 411 provides integrity protection of DNS data, TSIG [RFC2845], [RFC2930] 412 that use a shared secret to secure a transaction between two end 413 points and SIG(0) [RFC2931] authenticates the DNS packet exchanged. 415 The key issue with TSIG is that a shared secret must be negotiated 416 between the HNA and the server. On the other hand, TSIG performs 417 symmetric cryptography which is light in comparison with asymmetric 418 cryptography used by SIG(0). As a result, over large zone transfer, 419 TSIG may be preferred to SIG(0). 421 This document does not provide means to distribute shared secret for 422 example using a specific DHCPv6 option. The only assumption made is 423 that the HNA generates or is assigned a public key. 425 As a result, when the document specifies the transaction is secured 426 with TSIG, it means that either the HNA and the DNS server have been 427 manually configured with a shared secret, or the shared secret has 428 been negotiated using TKEY [RFC2930], and the TKEY exchanged are 429 secured with SIG(0). 431 Exchanges with the DNS Template Server to retrieve the Homenet Zone 432 Template may be protected by SIG(0), TSIG or DNSSEC. When DNSSEC is 433 used, it means the DNS Template Server only provides integrity 434 protection, and does not necessarily prevent someone else to query 435 the Homenet Zone Template. In addition, DNSSEC is only a way to 436 protect the AXFR queries transaction, in other words, DNSSEC cannot 437 be used to secure updates. If DNSSEC is used to provide integrity 438 protection for the AXFR response, the HNA should proceed to the 439 DNSSEC signature checks. If signature check fails, it MUST reject 440 the response. If the signature check succeeds, the HNA removes all 441 DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before building the 442 Homenet Zone. In fact, these DNSSEC related fields are associated to 443 the Homenet Zone Template and not the Homenet Zone. 445 Any update exchange should use SIG(0) or TSIG to authenticate the 446 exchange. 448 4.3. Primary / Secondary Synchronization versus DNS Update 450 As updates only concern DNS zones, this document only considers DNS 451 update mechanisms such as DNS update [RFC2136] [RFC3007] or a 452 primary / secondary synchronization. 454 The Homenet Zone Template SHOULD be updated with DNS update as it 455 contains static configuration data that is not expected to evolve 456 over time. 458 The Homenet Reverse Zone and the Homenet Zone can be updated either 459 with DNS update or using a primary / secondary synchronization. As 460 these zones may be large, with frequent updates, we recommend to use 461 the primary / secondary architecture as described in 462 [I-D.ietf-homenet-front-end-naming-delegation]. The primary / 463 secondary mechanism is preferred as it better scales and avoids DoS 464 attacks: First the primary notifies the secondary the zone must be 465 updated, and leaves the secondary to proceed to the update when 466 possible. Then, the NOTIFY message sent by the primary is a small 467 packet that is less likely to load the secondary. At last, the AXFR 468 query performed by the secondary is a small packet sent over TCP 469 (section 4.2 [RFC5936]) which makes unlikely the secondary to perform 470 reflection attacks with a forged NOTIFY. On the other hand, DNS 471 updates can use UDP, packets require more processing than a NOTIFY, 472 and they do not provide the server the opportunity to postpone the 473 update. 475 5. HNA Configuration 477 5.1. HNA Primary / Secondary Synchronization Configurations 479 The primary / secondary architecture is described in 480 [I-D.ietf-homenet-front-end-naming-delegation]. The HNA hosts a 481 Hidden Primary that synchronizes with a Synchronization Server or the 482 Reverse Synchronization Server. 484 When the HNA is plugged its IP address may be unknown to the 485 secondary. The section details how the HNA or primary communicates 486 the necessary information to set up the secondary. 488 In order to set the primary / secondary configuration, both primary 489 and secondaries must agree on 1) the zone to be synchronized, 2) the 490 IP address and ports used by both primary and secondary. 492 5.1.1. HNA / Synchronization Server 494 The HNA is aware of the zone to be synchronized by reading the 495 Registered Homenet Domain in the Homenet Zone Template provided by 496 the Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address 497 of the secondary is provided by the Synchronization Server Option 498 (OPTION_SYNC_SERVER). 500 The Synchronization Server has been configured with the Registered 501 Homenet Domain and the Client Public Key that identifies the HNA. 502 The only missing information is the IP address of the HNA. This IP 503 address is provided by the HNA by sending a NOTIFY [RFC1996]. 505 When the HNA has built its Homenet Zone, it sends a NOTIFY message to 506 the Synchronization Servers. Upon receiving the NOTIFY message, the 507 secondary reads the Registered Homenet Domain and checks the NOTIFY 508 is sent by the authorized primary. This can be done using the shared 509 secret (TSIG) or the public key (SIG(0)). Once the NOTIFY has been 510 authenticated, the Synchronization Servers might consider the source 511 IP address of the NOTIFY query to configure the primaries attributes. 513 5.1.2. HNA / Reverse Synchronization Server 515 The HNA is aware of the zone to be synchronized by looking at its 516 assigned prefix. The IP address of the secondary is provided by the 517 Reverse Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER). 519 Configuration of the secondary is performed as illustrated in 520 Section 5.1.1. 522 5.2. HNA DNS Data Handling and Update Policies 524 5.2.1. Homenet Zone Template 526 The Homenet Zone Template contains at least the related fields of the 527 Public Authoritative Server(s) as well as the Homenet Registered 528 Domain, that is SOA, and NS fields. This template might be generated 529 automatically by the owner of the DHCP Server. For example, an ISP 530 might provide a default Homenet Registered Domain as well as default 531 Public Authoritative Server(s). This default settings should provide 532 the HNA the necessary pieces of information to set the homenet naming 533 architecture. 535 If the Homenet Zone Template is not subject to modifications or 536 updates, the owner of the template might only use DNSSEC to enable 537 integrity check. 539 On the other hand, the Homenet Zone Template might also be subject to 540 modification by the HNA. The advantage of using the standard DNS 541 zone format is that standard DNS update mechanism can be used to 542 perform updates. These updates might be accepted or rejected by the 543 owner of the Homenet Zone Template. Policies that defines what is 544 accepted or rejected is out of scope of this document. However, this 545 document assumes the Registered Homenet Domain is used as an index by 546 the Synchronization Server, and SIG(0), TSIG are used to authenticate 547 the HNA. As a result, the Registered Homenet Domain should not be 548 modified unless the Synchronization Server can handle with it. 550 5.2.2. DNS (Reverse) Homenet Zone 552 The Homenet Zone might be generated from the Homenet Zone Template. 553 How the Homenet Zone is generated is out of scope of this document. 554 In some cases, the Homenet Zone might be the exact copy of the 555 Homenet Zone Template. In other cases, it might be generated from 556 the Homenet Zone Template with additional RRsets. In some other 557 cases, the Homenet Zone might be generated without considering the 558 Homenet Zone Template, but only considering specific configuration 559 rules. 561 In the current document the HNA only sets a single zone that is 562 associated with one single Homenet Registered Domain. The domain 563 might be assigned by the owner of the Homenet Zone Template. This 564 constraint does not prevent the HNA to use multiple domain names. 565 How additional domains are considered is out of scope of this 566 document. One way to handle these additional zones is to configure 567 static redirections to the Homenet Zone using CNAME [RFC2181], 568 [RFC1034], DNAME [RFC6672] or CNAME+DNAME 569 [I-D.sury-dnsext-cname-dname]. 571 6. Payload Description 573 This section details the payload of the DHCPv6 options. A few DHCPv6 574 options are used to advertise a server the HNA may be expected to 575 interact with. Interaction may require to define update and 576 authentication methods. Update fields are shared by multiple DHCPv6 577 options and are described in separate sections. Section 6.1 578 describes the Supported Authentication Method field, Section 6.2 579 describes the Update field, the remaining Section 6.3, Section 6.4, 580 Section 6.5, Section 6.6 describe the DHCPv6 options. 582 6.1. Supported Authentication Methods Field 584 The Supported Authentication Methods field of the DHCPv6 option 585 represented in Figure 2 indicates the authentication method supported 586 by the DNS server. One of these mechanism MUST be chosen by the HNA 587 in order to perform a transaction with the DNS server. See 588 Section 4.2 for more details. 590 0 1 591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Supported Auth. Methods | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Figure 2: Supported Authentication Methods Filed 598 - DNS (Bit 0): indicates, when set to 1, that DNS without any 599 security extension is supported. 601 - DNSSEC (Bit 1): indicates, when set to 1, that DNSSEC provides 602 integrity protection. This can only be used for read 603 operations like retrieving the Homenet Zone Template. 605 - SIG(0) (Bit 2): indicates, when set to 1, that transaction 606 protected by SIG(0) are supported. 608 - TSIG (Bit 3): indicates, when set to 1, that transaction using 609 TSIG is supported. Note that if a shared secret has not been 610 previously negotiated between the two party, it should be 611 negotiated using TKEY. The TKEY exchanges MUST be protected 612 with SIG(0) even though SIG(0) is not supported. 614 - Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server 615 and MUST be ignored by the DHCPv6 client. 617 A Supported Authentication Methods field with all bits set to zero 618 indicates the operation is not permitted. The Supported 619 Authentication Methods field may be set to zero when updates 620 operations are not permitted for the DNS Homenet Template. In any 621 other case this is an error. 623 6.2. Update Field 625 The Update Field of the DHCPv6 option is represented in Figure 3. It 626 indicates the update mechanism supported by the DNS server. See 627 Section 4.3 for more details. 629 0 630 0 1 2 3 4 5 6 7 631 +-+-+-+-+-+-+-+-+ 632 | Update | 633 +-+-+-+-+-+-+-+-+ 635 Figure 3: Update Field 637 - Primary / Secondary (Bit 0): indicates, when set to 1, that DNS 638 Server supports data synchronization using a Primary / 639 Secondary mechanism. 641 - DNS Update (Bit 1): indicates, when set to 1, that DNS Server 642 supports data synchronization using DNS Updates. 644 - Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCPv6 server 645 and MUST be ignored by the DHCPv6 client. 647 6.3. Client Public Key Option 649 The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client 650 Public Key that is used to authenticate the HNA. This option is 651 defined in [I-D.ietf-dhc-sedhcpv6]. 653 6.4. Zone Template Option 655 The Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option indicates 656 the HNA how to retrieve the Homenet Zone Template. It provides a 657 FQDN the HNA SHOULD query with a DNS query of type AXFR as well as 658 the authentication methods associated to the AXFR query or the 659 nsupdate queries. Homenet Zone Template update, if permitted MUST 660 use the DNS Update mechanism. 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | OPTION_DNS_ZONE_TEMPLATE | option-len | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Supp. Auth. Methods (axfr) | Supp. Auth. Methods (update) | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | 670 / Zone Template FQDN / 671 | | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Figure 4: Zone Template Option 676 - option-code: (16 bits): OPTION_DNS_ZONE_TEMPLATE, the option code 677 for the Zone Template Option (TBD1). 679 - option-len (16 bits): length in octets of the option-data field as 680 described in [RFC3315]. 682 - Supported Authentication Methods(axfr) (16 bits): defines which 683 authentication methods are supported by the DNS server. This 684 field concerns the AXFR and consultation queries, not the 685 update queries. See Section 6.1 for more details. 687 - Supported Authentication Methods (16 bits): defines which 688 authentication methods are supported by the DNS server. This 689 field concerns the update. See Section 6.1 for more details. 691 - Zone Template FQDN FQDN (variable): the FQDN of the DNS server 692 hosting the Homenet Zone Template. 694 6.5. Synchronization Server Option 696 The Synchronization Server Option (OPTION_SYNC_SERVER) provides 697 information necessary for the HNA to upload the Homenet Zone to the 698 Synchronization Server. Finally, the option provides the 699 authentication methods that are available to perform the upload. The 700 upload is performed via a DNS primary / secondary architecture or DNS 701 updates. 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | OPTION_SYNC_SERVER | option-len | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Supported Auth. Methods | Update | Server / 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 / Port | | 711 +-+-+-+-+-+-+-+-+ | 712 | | 713 / Synchronization Server FQDN / 714 | | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Figure 5: Synchronization Server Option 719 - option-code (16 bits): OPTION_SYNC_SERVER, the option code for the 720 Synchronization Server Option (TBD2). 722 - option-len (16 bits): length in octets of the option-data field as 723 described in [RFC3315]. 725 - Supported Authentication Methods (16 bits): defines which 726 authentication methods are supported by the DNS server. See 727 Section 6.1 for more details. 729 - Update (8 bits): defines which update mechanisms are supported by 730 the DNS server. See Section 4.3 for more details. 732 - Server Port (16 bits): defines the port the Synchronization Server 733 is listening. When multiple transport layers may be used, a 734 single and unique Server Port value applies to all the 735 transport layers. In the case of DNS for example, Server Port 736 value considers DNS exchanges using UDP and TCP. 738 - Synchronization Server FQDN (variable): the FQDN of the 739 Synchronization Server. 741 6.6. Reverse Synchronization Server Option 743 The Reverse Synchronization Server Option 744 (OPTION_REVERSE_SYNC_SERVER) provides information necessary for the 745 HNA to upload the Homenet Zone to the Synchronization Server. The 746 option provides the authentication methods that are available to 747 perform the upload. The upload is performed via a DNS primary / 748 secondary architecture or DNS updates. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | OPTION_REVERSE_SYNC_SERVER | option-len | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Supported Auth. Methods | Update | Server / 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 / Port | | 758 +-+-+-+-+-+-+-+-+-+ | 759 | | 760 / Reverse Synchronization Server FQDN / 761 | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Figure 6: Reverse Synchronization Server Option 766 - option-code (16 bits): OPTION_REVERSE_SYNC_SERVER, the option code 767 for the Reverse Synchronization Server Option (TBD3). 769 - option-len (16 bits): length in octets of the option-data field as 770 described in [RFC3315]. 772 - Supported Authentication Methods (16 bits): defines which 773 authentication methods are supported by the DNS server. See 774 Section 6.1 for more details. 776 - Update (8 bits): defines which update mechanisms are supported by 777 the DNS server. See Section 4.3 for more details. 779 - Server Port (16 bits): defines the port the Synchronization Server 780 is listening. 782 - Reverse Synchronization Server FQDN (variable): The FQDN of the 783 Reverse Synchronization Server. 785 7. DHCP Behavior 787 7.1. DHCPv6 Server Behavior 789 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 790 regards to option assignment. As a convenience to the reader, we 791 mention here that the server will send option foo only if configured 792 with specific values for foo and if the client requested it. In 793 particular, when configured the DHCP Server sends the Zone Template 794 Option, Synchronization Server Option, Reverse Synchronization Server 795 Option when requested by the DHCPv6 client by including necessary 796 option codes in its ORO. 798 The DHCP Server may receive a Client Public Key Option 799 (OPTION_PUBLIC_KEY) from the HNA. Upon receipt of this DHCPv6 800 option, the DHCP Server SHOULD acknowledge the reception of the 801 Client Public Key Option as described in Section 4.1 and communicate 802 this credential to the available DNS Servers like the DNS Template 803 Server, the Synchronization Server and the Reverse Synchronization 804 Server, unless not configured to do so. 806 A HNA may update its Client Public Key by sending a new value in the 807 Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes 808 the link between the HNA and the DHCP Server is considered 809 authenticated and trusted. The server SHOULD process received Client 810 Public Key Option sent by the client (see step 2 in Section 4.1), 811 unless not configured to do so. 813 7.2. DHCPv6 Client Behavior 815 The DHCPv6 client SHOULD send a Client Public Key Option 816 (OPTION_PUBLIC_KEY) to the DHCP Server. This Client Public Key 817 authenticates the HNA. 819 The DHCPv6 client sends a ORO with the necessary option codes: Zone 820 Template Option, Synchronization Server Option and Reverse 821 Synchronization Server Option. 823 Upon receiving a DHCP option described in this document in the Reply 824 message, the HNA SHOULD retrieve or update DNS zones using the 825 associated Supported Authentication Methods and update protocols, as 826 described in Section 5. 828 7.3. DHCPv6 Relay Agent Behavior 830 There are no additional requirements for the DHCP Relay agents. 832 8. IANA Considerations 834 The DHCP options detailed in this document is: 836 - OPTION_DNS_ZONE_TEMPLATE: TBD1 838 - OPTION_SYNC_SERVER: TBD2 840 - OPTION_REVERSE_SYNC_SERVER: TBD3 842 9. Security Considerations 844 9.1. DNSSEC is recommended to authenticate DNS hosted data 846 It is recommended that the (Reverse) Homenet Zone is signed with 847 DNSSEC. The zone may be signed by the HNA or by a third party. We 848 recommend the zone to be signed by the HNA, and that the signed zone 849 is uploaded. 851 9.2. Channel between the HNA and ISP DHCP Server MUST be secured 853 The channel MUST be secured because the HNA provides authentication 854 credentials. Unsecured channel may result in HNA impersonation 855 attacks. 857 The document considers that the channel between the HNA and the ISP 858 DHCP Server is trusted. More specifically, the HNA is authenticated 859 and the exchanged messages are protected. The current document does 860 not specify how to secure the channel. [RFC3315] proposes a DHCP 861 authentication and message exchange protection, [RFC4301], [RFC7296] 862 propose to secure the channel at the IP layer. 864 9.3. HNAs are sensitive to DoS 866 HNA have not been designed for handling heavy load. The HNA are 867 exposed on the Internet, and their IP address is publicly published 868 on the Internet via the DNS. This makes the Home Network sensitive 869 to Deny of Service Attacks. The resulting outsourcing architecture 870 is described in [I-D.ietf-homenet-front-end-naming-delegation]. This 871 document shows how the outsourcing architecture can be automatically 872 set. 874 10. Acknowledgments 876 We would like to thank Marcin Siodelski and Bernie Volz for their 877 comments on the design of the DHCPv6 options. We would also like to 878 thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their 879 remarks on the architecture design. The designed solution has been 880 largely been inspired by Mark Andrews's document 881 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We 882 also thank Ray Hunter for its reviews, its comments and for 883 suggesting an appropriated terminology. 885 11. References 886 11.1. Normative References 888 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 889 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 890 . 892 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 893 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 894 August 1996, . 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, 898 DOI 10.17487/RFC2119, March 1997, 899 . 901 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 902 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 903 RFC 2136, DOI 10.17487/RFC2136, April 1997, 904 . 906 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 907 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 908 . 910 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 911 Wellington, "Secret Key Transaction Authentication for DNS 912 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 913 . 915 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 916 RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000, 917 . 919 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 920 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 921 2000, . 923 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 924 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 925 . 927 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 928 C., and M. Carney, "Dynamic Host Configuration Protocol 929 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 930 2003, . 932 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 933 Rose, "DNS Security Introduction and Requirements", 934 RFC 4033, DOI 10.17487/RFC4033, March 2005, 935 . 937 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 938 Rose, "Resource Records for the DNS Security Extensions", 939 RFC 4034, DOI 10.17487/RFC4034, March 2005, 940 . 942 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 943 Rose, "Protocol Modifications for the DNS Security 944 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 945 . 947 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 948 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 949 December 2005, . 951 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 952 (TLS) Protocol Version 1.2", RFC 5246, 953 DOI 10.17487/RFC5246, August 2008, 954 . 956 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 957 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 958 . 960 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 961 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 962 January 2012, . 964 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 965 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 966 . 968 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 969 Kivinen, "Internet Key Exchange Protocol Version 2 970 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 971 2014, . 973 11.2. Informational References 975 [I-D.andrews-dnsop-pd-reverse] 976 Andrews, M., "Automated Delegation of IP6.ARPA reverse 977 zones with Prefix Delegation", draft-andrews-dnsop-pd- 978 reverse-02 (work in progress), November 2013. 980 [I-D.ietf-dhc-sedhcpv6] 981 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 982 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 983 in progress), February 2017. 985 [I-D.ietf-homenet-front-end-naming-delegation] 986 Migault, D., Weber, R., Hunter, R., Griffiths, C., and W. 987 Cloetens, "Outsourcing Home Network Authoritative Naming 988 Service", draft-ietf-homenet-front-end-naming- 989 delegation-06 (work in progress), October 2017. 991 [I-D.sury-dnsext-cname-dname] 992 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 993 dnsext-cname-dname-00 (work in progress), April 2010. 995 Appendix A. Scenarios and impact on the End User 997 This section details various scenarios and discuss their impact on 998 the end user. 1000 A.1. Base Scenario 1002 The base scenario is the one described in Section 4. It is typically 1003 the one of an ISP that manages the DHCP Server, and all DNS servers. 1005 The end user subscribes to the ISP (foo), and at subscription time 1006 registers for example.foo as its Registered Homenet Domain 1007 example.foo. Since the ISP knows the Registered Homenet Domain and 1008 the Public Authoritative Server(s) the ISP is able to build the 1009 Homenet Zone Template. 1011 The ISP manages the DNS Template Server, so it is able to load the 1012 Homenet Zone Template on the DNS Template Server. 1014 When the HNA is plugged (at least the first time), it provides its 1015 Client Public Key to the DHCP Server. In this scenario, the DHCP 1016 Server and the DNS Servers are managed by the ISP so the DHCP Server 1017 can provide authentication credentials of the HNA to enable secure 1018 authenticated transaction between the HNA and these DNS servers. 1019 More specifically, credentials are provided to: 1021 - Synchronization Server 1023 - Reverse Synchronization Server 1025 - DNS Template Server 1026 The HNA can update the zone using DNS update or a primary / secondary 1027 configuration in a secure way. 1029 The main advantage of this scenario is that the naming architecture 1030 is configured automatically and transparently for the end user. 1032 The drawbacks are that the end user uses a Registered Homenet Domain 1033 managed by the ISP and that it relies on the ISP naming 1034 infrastructure. 1036 A.2. Third Party Registered Homenet Domain 1038 This section considers the case when the end user wants its home 1039 network to use example.com as a Registered Homenet Domain instead of 1040 example.foo that has been assigned by the ISP. We also suppose that 1041 example.com is not managed by the ISP. 1043 This can also be achieved without any configuration. When the end 1044 user buys the domain name example.com, it may request to redirect the 1045 name example.com to example.foo using static redirection with CNAME 1046 [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 1047 [I-D.sury-dnsext-cname-dname]. 1049 This configuration is performed once when the domain name example.com 1050 is registered. The only information the end user needs to know is 1051 the domain name assigned by the ISP. Once this configuration is done 1052 no additional configuration is needed anymore. More specifically, 1053 the HNA may be changed, the zone can be updated as in Appendix A.1 1054 without any additional configuration from the end user. 1056 The main advantage of this scenario is that the end user benefits 1057 from the Zero Configuration of the Base Scenario Appendix A.1. Then, 1058 the end user is able to register for its home network an unlimited 1059 number of domain names provided by an unlimited number of different 1060 third party providers. 1062 The drawback of this scenario may be that the end user still rely on 1063 the ISP naming infrastructure. Note that the only case this may be 1064 inconvenient is when the DNS Servers provided by the ISPs results in 1065 high latency. 1067 A.3. Third Party DNS Infrastructure 1069 This scenario considers that the end user uses example.com as a 1070 Registered Homenet Domain, and does not want to rely on the 1071 authoritative servers provided by the ISP. 1073 In this section we limit the outsourcing to the Synchronization 1074 Server and Public Authoritative Server(s) to a third party. All 1075 other DNS Servers DNS Template Server, Reverse Public Authoritative 1076 Server(s) and Reverse Synchronization Server remain managed by the 1077 ISP. The reason we consider that Reverse Public Authoritative 1078 Server(s) and Reverse Synchronization Server remains managed by the 1079 ISP are that the prefix is managed by the ISP, so outsourcing these 1080 resources requires some redirection agreement with the ISP. More 1081 specifically the ISP will need to configure the redirection on one of 1082 its Reverse DNS Servers. That said, outsourcing these resources is 1083 similar as outsourcing Synchronization Server and Public 1084 Authoritative Server(s) to a third party. Similarly, the DNS 1085 Template Server can be easily outsourced as detailed in this section 1087 Outsourcing Synchronization Server and Public Authoritative Server(s) 1088 requires: 1090 - 1) Updating the Homenet Zone Template: this can be easily done as 1091 detailed in Section 4.3 as the DNS Template Server is still 1092 managed by the ISP. Such modification can be performed once by 1093 any HNA. Once this modification has been performed, the HNA 1094 can be changed, the Client Public Key of the HNA may be 1095 changed, this does not need to be done another time. One can 1096 imagine a GUI on the HNA asking the end user to fill the field 1097 with Registered Homenet Domain, optionally Public Authoritative 1098 Server(s), with a button "Configure Homenet Zone Template". 1100 - 2) Updating the DHCP Server Information. In fact the Reverse 1101 Synchronization Server returned by the ISP is modified. One 1102 can imagine a GUI interface that enables the end user to modify 1103 its profile parameters. Again, this configuration update is 1104 done once-for-ever. 1106 - 3) Upload the authentication credential of the HNA, that is the 1107 Client Public Key of the HNA, to the third party. Unless we 1108 use specific mechanisms, like communication between the DHCP 1109 Server and the third party, or a specific token that is plugged 1110 into the HNA, this operation is likely to be performed every 1111 time the HNA is changed, and every time the Client Public Key 1112 generated by the HNA is changed. 1114 The main advantage of this scenario is that the DNS infrastructure is 1115 completely outsourced to the third party. Most likely the Client 1116 Public Key that authenticate the HNA need to be configured for every 1117 HNA. Configuration is expected to be HNA live-long. 1119 A.4. Multiple ISPs 1121 This scenario considers a HNA connected to multiple ISPs. 1123 Firstly, suppose the HNA has been configured with the based scenarios 1124 exposed in Appendix A.1. The HNA has multiple interfaces, one for 1125 each ISP, and each of these interface is configured using DHCP. The 1126 HNA sends to each ISP its Client Public Key Option as well as a 1127 request for a Zone Template Option, a Synchronization Server Option 1128 and a Reverse Synchronization Server Option. Each ISP provides the 1129 requested DHCP options, with different values. Note that this 1130 scenario assumes, the home network has a different Registered Homenet 1131 Domain for each ISP as it is managed by the ISP. On the other hand, 1132 the HNA Client Public Key may be shared between the HNA and the 1133 multiple ISPs. The HNA builds the associate DNS(SEC) Homenet Zone, 1134 and proceeds to the various settings as described in Appendix A.1. 1136 The protocol and DHCPv6 options described in this document are fully 1137 compatible with a HNA connected to multiple ISPs with multiple 1138 Registered Homenet Domains. However, the HNA should be able to 1139 handle different Registered Homenet Domains. This is an 1140 implementation issue which is outside the scope of the current 1141 document. More specifically, multiple Registered Homenet Domains 1142 leads to multiple DNS(SEC) Homenet Zones. A basic implementation may 1143 erase the DNS(SEC) Homenet Zone that exists when it receives DHCPv6 1144 options, and rebuild everything from scratch. This will work for an 1145 initial configuration but comes with a few drawbacks. First, updates 1146 to the DNS(SEC) Homenet Zone may only push to one of the multiple 1147 Registered Homenet Domain, the latest Registered Homenet Domain that 1148 has been set, and this is most likely expected to be almost randomly 1149 chosen as it may depend on the latency on each ISP network at the 1150 boot time. As a results, this leads to unsynchronized Registered 1151 Homenet Domains. Secondly, if the HNA handles in some ways 1152 resolution, only the latest Registered Homenet Domain set may be able 1153 to provide naming resolution in case of network disruption. 1155 Secondly, suppose the HNA is connected to multiple ISP with a single 1156 Registered Homenet Domain. In this case, the one party is chosen to 1157 host the Registered Homenet Domain. This entity may be one of the 1158 ISP or a third party. Note that having multiple ISPs can be 1159 motivated for bandwidth aggregation, or connectivity fail-over. In 1160 the case of connectivity fail-over, the fail-over concerns the access 1161 network and a failure of the access network may not impact the core 1162 network where the Synchronization Server and Public Authoritative 1163 Primaries are hosted. In that sense, choosing one of the ISP even in 1164 a scenario of multiple ISPs may make sense. However, for sake of 1165 simplicity, this scenario assumes that a third party has be chosen to 1166 host the Registered Homenet Domain. The DNS settings for each ISP is 1167 described in Appendix A.2 and Appendix A.3. With the configuration 1168 described in Appendix A.2, the HNA is expect to be able to handle 1169 multiple Homenet Registered Domain, as the third party redirect to 1170 one of the ISPs Servers. With the configuration described in 1171 Appendix A.3, DNS zone are hosted and maintained by the third party. 1172 A single DNS(SEC) Homenet Zone is built and maintained by the HNA. 1173 This latter configuration is likely to match most HNA 1174 implementations. 1176 The protocol and DHCPv6 options described in this document are fully 1177 compatible with a HNA connected to multiple ISPs. To configure or 1178 not and how to configure the HNA depends on the HNA facilities. 1179 Appendix A.1 and Appendix A.2 require the HNA to handle multiple 1180 Registered Homenet Domain, whereas Appendix A.3 does not have such 1181 requirement. 1183 Appendix B. Document Change Log 1185 [RFC Editor: This section is to be removed before publication] 1187 -05: changing Master to Primary, Slave to Secondary 1189 -04: Working Version Major modifications are: 1191 - Re-structuring the draft: description and comparison of update and 1192 authentication methods have been integrated into the Overview 1193 section. a Configuration section has been created to describe 1194 both configuration and corresponding behavior of the HNA. 1196 - Adding Ports parameters: Server Set can configure a port. The 1197 Port Server parameter have been added in the DHCPv6 option 1198 payloads because middle boxes may not be configured to let port 1199 53 packets and it may also be useful to split servers among 1200 different ports, assigning each end user a different port. 1202 - Multiple ISP scenario: In order to address comments, the multiple 1203 ISPs scenario has been described to explicitly show that the 1204 protocol and DHCPv6 options do not prevent a HNA connected to 1205 multiple independent ISPs. 1207 -03: Working Version Major modifications are: 1209 - Redesigning options/scope: according to feed backs received from 1210 the IETF89 presentation in the dhc WG. 1212 - Redesigning architecture: according to feed backs received from 1213 the IETF89 presentation in the homenet WG, discussion with Mark 1214 and Lorenzo. 1216 -02: Working Version Major modifications are: 1218 - Redesigning options/scope: As suggested by Bernie Volz 1220 -01: Working Version Major modifications are: 1222 - Remove the DNS Zone file construction: As suggested by Bernie Volz 1224 - DHCPv6 Client behavior: Following options guide lines 1226 - DHCPv6 Server behavior: Following options guide lines 1228 -00: version published in the homenet WG. Major modifications are: 1230 - Reformatting of DHCPv6 options: Following options guide lines 1232 - DHCPv6 Client behavior: Following options guide lines 1234 - DHCPv6 Server behavior: Following options guide lines 1236 -00: First version published in dhc WG. 1238 Authors' Addresses 1240 Daniel Migault 1241 Ericsson 1242 8400 boulevard Decarie 1243 Montreal, QC H4P 2N2 1244 Canada 1246 Email: daniel.migault@ericsson.com 1248 Tomek Mrugalski 1249 Internet Systems Consortium, Inc. 1250 950 Charter Street 1251 Redwood City, CA 94063 1252 USA 1254 Email: tomasz.mrugalski@gmail.com 1255 URI: http://www.isc.org 1257 Chris Griffiths 1259 Email: cgriffiths@gmail.com 1260 Ralf Weber 1261 Nominum 1262 2000 Seaport Blvd #400 1263 Redwood City, CA 94063 1264 US 1266 Email: ralf.weber@nominum.com 1267 URI: http://www.nominum.com 1269 Wouter Cloetens 1270 SoftAtHome 1271 vaartdijk 3 701 1272 3018 Wijgmaal 1273 Belgium 1275 Email: wouter.cloetens@softathome.com