idnits 2.17.00 (12 Aug 2021) /tmp/idnits58436/draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 14, 2014) is 3018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'RFC4641' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC4843' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 313, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4641 (Obsoleted by RFC 6781) ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet Working Group D. Taht 3 Internet-Draft Teklibre 4 Intended status: Informational E. Hunt 5 Expires: August 18, 2014 ISC 6 S. Kelley 7 Dnsmasq 8 February 14, 2014 10 DHCPv4 to SLAAC DNS naming 11 draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00 13 Abstract 15 This memo presents a technique for using the hostname acquired from a 16 DHCPv4 client request to publish AAAA records on that domain name for 17 public IPv6 addresses acquired by the same dual-stack host using 18 SLAAC. 20 On dual-stack networks, there is a need to automatically publish 21 entries in the DNS for the public IPv6 addresses of an IPv6 host when 22 it does not use DHCPv6. IPv6 hosts can acquire IPv6 addresses using 23 SLAAC, but there is no mechanism allowing them to register a name in 24 the DNS database other than a DNS update, which would create a very 25 difficult key management problem. By combining the DHCPv4 hostname 26 or client FQDN option with information acquired using ICMPv6, a 27 lightweight DHCPv4 server on a home gateway or SOHO gateway can 28 automatically publish AAAA records for such hosts. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 18, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Interactions with the DNS . . . . . . . . . . . . . . . . . . 4 68 5. Persistent storage of IPv6 addresses . . . . . . . . . . . . 4 69 6. Addition and removal of IPv6 prefixes . . . . . . . . . . . . 4 70 7. Router advertisements . . . . . . . . . . . . . . . . . . . . 5 71 8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 12. Appendix A - DNSmasq configuration . . . . . . . . . . . . . 6 76 12.1. Example 1: Without DHCPv6 . . . . . . . . . . . . . . . 6 77 12.2. Example 2: With stateless DHCPv6 & SLAAC . . . . . . . . 6 78 13. Appendix B - ISC-dhcp configuration . . . . . . . . . . . . . 6 79 14. Normative References . . . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 This memo presents a technique for using the hostname acquired for a 85 DHCPv4 [RFC2131] client request to publish AAAA records [RFC3596] on 86 that domain name for public IPv6 addresses acquired by the same dual- 87 stack host using SLAAC [RFC4862]. 89 On dual-stack networks, there is a need to automatically publish 90 entries in the DNS for the public IPv6 addresses of an IPv6 host when 91 it does not use DHCPv6. IPv6 hosts can acquire IPv6 addresses using 92 SLAAC, but there is no mechanism allowing them to register a name in 93 the DNS database other than a DNS update, which creates a very 94 difficult key management problem. By combining the DHCPv4 hostname 95 or client FQDN option, the client MAC address or DHCPPv4 client-ID 96 and information acquired using ICMPv6, a DHCPv4 server on a home 97 gateway or SOHO gateway can automatically publish AAAA records for 98 such hosts using the same route by which it publishes A records. 100 2. Methods 102 A DHCPv4 server which supports the hostname or FQDN options can 103 easily determine the tuple (link-layer address, hostname, broadcast 104 domain) for each DHCPv4 client which has completed a DHCPv4 lease. 105 The MAC address or client-id can be used to determine the host- 106 identifier which is likely to be used by the client if it configures 107 itself for IPv6 using SLAAC. If the server has access to the mapping 108 between broadcast domains and IPv6 prefixes, it can construct a list 109 of possible SLAAC-configured IPv6 addresses which the client may be 110 using. If some or all of these addresses can be confirmed as in-use, 111 then the server can infer a connection between the active IPv6 112 addresses and the hostname, and install that naming information into 113 the DNS using the same mechanisms it uses to public IPv4 naming 114 information. 116 3. Protocol 118 For each DHCPv4 lease which is in BOUND state and has a known name, 119 the DHCPv4 server attempts to determines the broadcast domain in 120 which the assigned IPv4 address exists and the IPv6 prefix(es) 121 associated with that broadcast domain. If the server has an 122 interface in the broadcast domain, then the server MAY use the 123 configuration of the interface in the form of IPv4 addresses and 124 netmasks, and IPv6 prefixes and prefix lengths to make this 125 determination. The implementation MAY also make it possible to 126 provide this information as part of the server's configuration. This 127 is likely to be a requirement when a DHCPv4 relay agent is in use and 128 the server does not have an interface in the broadcast domain. 130 The server MUST discard any IPv6 prefixes whose length is not 64, 131 since hosts cannot assign addresses in these prefixes using SLAAC. 132 The server MUST discard link-local prefixes. It MAY be configured to 133 discard site-local prefixes. This would be appropriate of the host 134 records were being inserted into the global DNS, but not if they were 135 being inserted into a local DNS view only available within the site. 137 Having determined the set of possible IPv6 prefixes (as above) the 138 implementation then determines a possible interface identifier. It 139 uses the client's link-layer address contained in the CHADDR field of 140 the DHCPv4 [RFC2131] packet, or encoded in the client-id as in 141 FIREWIRE [RFC3146] and applies the procedure given in [RFC4291] para 142 2.5.1 to calculate the SLAAC interface identifier. 144 The set of prefixes are combined with the interface identifier to 145 generate a set of putative IPv6 addresses for the client. This set 146 of addresses is then tested to determine if the client is actually 147 using them. To do this the server sends an ICMPv6 [](#RFC4443] echo 148 request to each putative address and awaits a reply. To avoid 149 problems with packet loss, the ICMP echo requests MUST be 150 retransmitted and the time between retransmissions MUST be subject to 151 a suitable backoff strategy to avoid flooding the network. When an 152 ICMPv6 echo reply is recieved from a putative address, that address 153 is marked as confirmed, and the (name, IPv6-address) pair SHOULD be 154 installed in the DNS. The server SHOULD cease sending IMCPv6 echo 155 requests to an address once it has been confirmed. It MAY cease 156 sending ICMPv6 echo requests is no answers are recieved after an 157 extended period, or it MAY implement a backoff strategy which reduces 158 the rate to sending echo requests to close to zero after an extended 159 period. One of these options MUST be implemented. 161 4. Interactions with the DNS 163 The exact mechanism by which a name is associated with a host, and 164 the name, address pair are installed in the DNS are beyond the scope 165 of this document. It is assumed that the mechanism which is used to 166 determine the name which is stored in the A record is re-used to the 167 AAAA record, and the mechanism by which the A record is inserted into 168 the DNS is re-used for the AAAA record. The lifetime and TTL of the 169 AAAA record should be the same as that for the A record. The same 170 strategy for removing DNS records on the expiry of a DHCPv4 lease is 171 used for AAAA records. The server MUST NOT insert AAAA records into 172 the DNS unless they have been confirmed by the receipt of an ICMPv6 173 echo reply. 175 5. Persistent storage of IPv6 addresses 177 The server MAY store the set of confirmed IPv6 addresses in the 178 persistent lease database so that they are preserved over a server 179 restart. Alternatively, after a server restart, the server MAY 180 repeat the generation and confirmation of the set of putative IPv6 181 addresses associated with each DHCPv4 lease. The server MUST NOT 182 assume that IPv6 addresses for existing leases are confirmed after a 183 server restart and MUST repeat the confirmation process unless the 184 status of the addresses is stored in the persistent database. 186 6. Addition and removal of IPv6 prefixes 188 When an new IPv6 prefix is added to a broadcast domain, the server 189 SHOULD add the corresponding IPv6 addresses to the set of putative 190 addressess for each existing DHCPv4 lease which is in BOUND state and 191 attempt to confirm its existence by sending ICMP6 echp requests and 192 listening for replies. When confirmed, the relevant AAAA records 193 should be added the relevant RRset. When an IPv6 prefix is removed 194 or becomes deprecated, the associated AAAA records should be removed 195 from the DNS. 197 7. Router advertisements 199 The implementation MAY arrange for unsolicited Router Advertisements 200 to be sent at short intervals, in the same way as after an interface 201 becomes an advertising interface, when a new DHCPv4 lease enters the 202 BOUND state from another state. This increases tha probability that 203 a new host appearing on the network will be assigned an address by 204 SLAAC promptly and be detected by the system. 206 8. Limitations 208 This technique will only install SLAAC addresses into the DNS. It 209 does not detect privacy addresses. It is unlikely to be useful to 210 insert privacy addresses into the DNS. A host which is required to 211 accept incoming connections should have a SLAAC address. It may make 212 outgoing connections from privacy addresses. 214 IPv6 addresses of Windows nodes (which do not generate IIDs according 215 to traditional SLAAC), and any nodes using CGAs, are also missed. 217 Nodes using stateful DHCPv6 do not need this technique as naming is 218 handled by DHCPv6. 220 This technique makes traditional DNS naming work on IPv6 for existing 221 deployed systems. It works, for instance, with hundreds of millions 222 of existing Android phones and tablets, most SLAAC enabled hosts that 223 supply a hostname with their DHCPv4 requests, and many printers. 225 9. Security Considerations 227 This document describes a simple and operational scheme for tying 228 DHCPv4 name requests to SLAAC generated addresses. Privacy addresses 229 remain private. 231 Exposure to the DNS is limited to SLAAC addresses. Automatic DNS 232 registry of these has privacy implications that may be undesirable in 233 some cases; user interfaces should provide appropriate mechanisms for 234 controlling which hosts' addresses are registered in the public DNS, 235 and which are not. 237 10. IANA Considerations 239 This document has no actions for IANA. 241 11. Conclusions 243 This document outlines a simple method for co-joining the DHCPv4 and 244 SLAAC assigned DNS namespace. It is lightweight, and robust. It has 245 been deployed as part of DNSMASQ since version 2.61, released 246 29-Apr-2012, and continually improved. Scripts have been available 247 for doing the equivalent with BIND9 and ISC-dhcp since 15-May-2011. 249 12. Appendix A - DNSmasq configuration 251 Dnsmasq is configured using simple option=value pairs. For each 252 interface you care about, the "ra-names" option will enable attempts 253 to leverage DHCPv4 information for naming SLAAC-derived addresses. 255 12.1. Example 1: Without DHCPv6 257 Use the DHCPv4 lease to derive the name, network segment and MAC 258 address and assume that the host will also have an IPv6 address 259 calculated using the SLAAC alogrithm. 261 dhcp-range=1234::, ra-names 263 12.2. Example 2: With stateless DHCPv6 & SLAAC 265 dhcp-range=1234::, ra-stateless, ra-names 267 For more details on configuration see the dnsmasq examples at http:// 268 www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example . 270 13. Appendix B - ISC-dhcp configuration 272 For more details on isc-dhcp configuration see the examples at https: 273 //github.com/dtaht/bufferbloat-rfcs/tree/master/dhcpv4_to_slaac/isc- 274 dhcp/ 276 14. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 282 2131, March 1997. 284 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 285 over IEEE 1394 Networks", RFC 3146, October 2001. 287 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 288 and M. Carney, "Dynamic Host Configuration Protocol for 289 IPv6 (DHCPv6)", RFC 3315, July 2003. 291 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 292 "DNS Extensions to Support IP Version 6", RFC 3596, 293 October 2003. 295 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 296 Host Configuration Protocol (DHCP) version 6", RFC 3633, 297 December 2003. 299 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 300 Architecture", RFC 4291, February 2006. 302 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 303 Message Protocol (ICMPv6) for the Internet Protocol 304 Version 6 (IPv6) Specification", RFC 4443, March 2006. 306 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 307 RFC 4641, September 2006. 309 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 310 for Overlay Routable Cryptographic Hash Identifiers 311 (ORCHID)", RFC 4843, April 2007. 313 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 314 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 315 September 2007. 317 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 318 Address Autoconfiguration", RFC 4862, September 2007. 320 Authors' Addresses 322 Dave Taht 323 Teklibre 324 2104 W First Street 325 Apt 2002 326 FT Myers, FL 33901 327 USA 329 Email: d@taht.net 330 URI: http://www.teklibre.com/ 331 Evan Hunt 332 ISC 333 950 Charter Street 334 Redwood City, CA 94063 335 USA 337 Email: each@isc.org 338 URI: http://www.isc.org/ 340 Simon Kelley 341 Dnsmasq 342 22 St Peters Street 343 Duxford, Cambridge CB22 4RP 344 GB 346 Phone: +44.07810386191 347 Email: simon@thekelleys.org.uk 348 URI: http://www.dnsmasq.org/