idnits 2.17.1 draft-howard-isp-ip6rdns-05.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 6 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 2012) is 4175 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2535' is defined on line 538, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Howard 3 Internet-Draft Time Warner Cable 4 Intended status: Informational November 20, 2012 5 Expires: May 24, 2013 7 Reverse DNS in IPv6 for Internet Service Providers 8 draft-howard-isp-ip6rdns-05 10 Abstract 12 In IPv4, Internet Service Providers (ISPs) commonly provide IN- 13 ADDR.ARPA. information for their customers by prepopulating the zone 14 with one PTR record for every available address. This practice does 15 not scale in IPv6. This document analyzes different approaches for 16 ISPs to manage the ip6.arpa zone for IPv6 address space assigned to 17 many customers. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 24, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3 67 1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . . 4 68 2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. No Response . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.2. Wildcard match . . . . . . . . . . . . . . . . . . . . . . 5 71 2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6 73 2.3.2. Dynamic DNS through Residential Gateways . . . . . . . 7 74 2.3.3. Dynamic DNS Delegations . . . . . . . . . . . . . . . 7 75 2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . . 8 76 2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8 77 2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 9 78 2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . . 9 79 2.5. Dynamically Generate PTR When Queried ("On the Fly") . . . 9 80 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 10 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 4.1. Using Reverse DNS for Security . . . . . . . . . . . . . . 10 83 4.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 10 84 4.3. Considerations for Other Uses of the DNS . . . . . . . . . 11 85 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 Best practice [RFC1033] is that "Every Internet-reachable host should 95 have a name"[RFC1912]that is recorded with a PTR resource record in 96 the .ARPA zone. Many network services perform a PTR lookup on the 97 source address of incoming packets before performing services. 99 Some of the most common uses for reverse DNS include: 101 o Building trust. An administrator who spends time and effort 102 properly maintaining DNS records might be assumed to spend time 103 and effort on other maintenance, so the network might be more 104 trustworthy. 106 o Validating other data. Information from reverse DNS may be 107 compared to information higher in the stack (for instance, mail 108 originator), with a lower trustworthiness if they are dissimilar. 110 o Some degree of location information can often be inferred, since 111 most administrators create reverse zones corresponding to 112 aggregation points, which often correspond with geographical 113 areas. This information is useful for geolocation services and 114 for law enforcement. 116 Individual Internet users in the residential or consumer scale, 117 including small and home businesses, are constantly joining or moving 118 on the Internet. For large Internet service providers who serve 119 residential users, maintenance of individual PTR records is often 120 impractical. Administrators at ISPs should evaluate methods for 121 responding to reverse DNS queries in IPv6. 123 1.1. Reverse DNS in IPv4 125 ISPs that provide access to many residential users typically assign 126 one or a few IPv4 addresses to each of those users, and populate an 127 IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some 128 ISPs also configure forward zones with matching A records, so that 129 lookups match. For instance, if an ISP Example.com aggregated 130 192.0.2.0/24 at a network hub in Anytown in the province of AnyWhere, 131 the reverse zone might look like: 133 1.2.0.192.IN-ADDR-ARPA. IN PTR 1.user.anytown.AW.example.com. 135 2.2.0.192.IN-ADDR-ARPA. IN PTR 2.user.anytown.AW.example.com. 137 3.2.0.192.IN-ADDR-ARPA. IN PTR 3.user.anytown.AW.example.com. 139 . 141 . 143 . 145 254.2.0.192.IN-ADDR-ARPA. IN PTR 146 254.user.anytown.AW.example.com. 148 The conscientious Example.com might then also have a zone: 150 1.user.anytown.AW.example.com. IN A 192.0.2.1 152 2.user.anytown.AW.example.com. IN A 192.0.2.2 154 3.user.anytown.AW.example.com. IN A 192.0.2.3 156 . 158 . 160 . 162 254.user.anytown.AW.example.com. IN A 192.0.2.254 164 Many ISPs generate PTR records for all IP addresses used for 165 customers, and many create the matching A record. 167 1.2. Reverse DNS Considerations in IPv6 169 The length of individual addresses makes manual zone entries 170 cumbersome. A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56: 171 789a might be: 173 a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2 174 .IP6.ARPA. IN PTR 1.user.anytown.AW.example.com. 176 Since 2^^80 possible addresses could be configured in the 2001:db8: 177 f00/48 zone alone, it is impractical to write a zone with every 178 possible address entered. If 1000 entries could be written per 179 second, the zone would still not be complete after 38 trillion years. 181 Furthermore, since the 64 bits in the host portion of the address are 182 frequently assigned using SLAAC [RFC4862] when the host comes online, 183 it is not possible to know which addresses may be in use ahead of 184 time. 186 [RFC1912]is an informational document that says "PTR records must 187 point back to a valid A record" and further that the administrator 188 should "Make sure your PTR and A records match."[RFC1912] DNS 189 administrators of residential ISPs should consider how to follow this 190 advice for AAAA and PTR RRs in the residential ISP. 192 2. Alternatives in IPv6 194 Several options exist for providing reverse DNS in IPv6. All of 195 these options also exist for IPv4, but the scaling problem is much 196 less severe in IPv4. Each option should be evaluated for its scaling 197 ability, its compliance with existing standards and best practices, 198 and its availability in common systems. 200 2.1. No Response 202 Some ISP DNS administrators may choose to provide only a NXDomain 203 response to PTR queries for subscriber addresses. Providing a 204 negative response in response to PTR queries does not satisfy the 205 expectation in[RFC1912] for entries to match. Users of services 206 which are dependent on a successful lookup will have a poor 207 experience. For instance, some web services and SSH connections wait 208 for a DNS response, even NXDOMAIN, before responding. DNS 209 administrators should consider the uses for reverse DNS records and 210 the number of services affecting the number of users when evaluating 211 this option. 213 2.2. Wildcard match 215 The use of wildcards in the DNS is described in [RFC4592], and their 216 use in IPv6 reverse DNS is described in [RFC4472]. 218 While recording all possible addresses is not scalable, it may be 219 possible to record a wildcard entry for each prefix assigned to a 220 customer. Consider also that "inclusion of wildcard NS RRSets in a 221 zone is discouraged, but not barred. "[RFC4035] 223 This solution generally scales well. However, since the response 224 will match any address in the wildcard range (/48, /56, /64, etc.), a 225 forward DNS lookup on that response given will not be able to return 226 the same hostname. This method therefore fails the expectation in 227 [RFC1912] for forward and reverse to match. DNSsec [RFC4035] 228 scalability is limited to signing the wildcard zone, which may be 229 satisfactory. 231 2.3. Dynamic DNS 233 One way to ensure forward and reverse records match is for hosts to 234 update DNS servers dynamically, once interface configuration (whether 235 SLAAC, DHCPv6, or other means) is complete, as described in[RFC4472]. 236 Hosts would need to provide both AAAA and PTR updates, and would need 237 to know which servers would accept the information. 239 This option should scale as well or as poorly as IPv4 dynamic DNS 240 does. Dynamic DNS may not scale effectively in large ISP networks 241 which have no single master name server. The ISP's DNS system may 242 provide a point for Denial of Service attacks, including many 243 attempted dDNS updates. Accepting updates only from authenticated 244 sources may mitigate this risk, but only if authentication itself 245 does not require excessive overhead. No authentication of dynamic 246 DNS updates is inherently provided; implementers should consider use 247 of TSIG[RFC2845], or at least ingress filtering so updates are only 248 accepted from customer address space from internal network 249 interfaces, and consider impacts on scalability. UDP is allowed per 250 [RFC2136] so transmission control is not assured, though the host 251 should expect an ERROR or NOERROR message from the server [RFC2136]; 252 TCP provides transmission control, but the updating host would need 253 to be configured to use TCP. 255 Administrators should consider what domain will contain the records, 256 and who will provide the names. If subscribers provide hostnames, 257 they may provide inappropriate strings. Consider "ihate.example.com" 258 or "badword.customer.example.com" or 259 "celebrityname.committed.illegal.acts.example.com." 261 2.3.1. Dynamic DNS from Individual Hosts 263 In the simplest case, a residential user will have a single host 264 connected to the ISP. Since the typical residential user cannot 265 configure IPv6 addresses and resolving name servers on their hosts, 266 the ISP should provide address information conventionally (i.e., 267 their normal combination of RAs, DHCP, etc.), and should provide a 268 DNS Recursive Name Server and Domain Search List as described in 269 [RFC3646] or [RFC6106]. In determining its Fully Qualified Domain 270 Name, a host will typically use a domain from the Domain Search List. 271 This is an overloading of the parameter; multiple domains could be 272 listed, since hosts may need to search for unqualified names in 273 multiple domains, without necessarily being a member of those 274 domains. Administrators should consider whether the domain search 275 list actually provides an appropriate DNS suffix(es) when considering 276 use of this option. For purposes of dynamic DNS, the host would 277 concatenate its local hostname (e.g., "hostname") plus the domain(s) 278 in the Domain Search List (e.g., "customer.example.com"), as in 279 "hostname.customer.example.com." 281 Once it learns its address, and has a resolving name server, the host 282 must perform an SOA lookup on the ip6.arpa record to be added, to 283 find the owner, which will lead to the SOA record. Several recursive 284 lookups may be required to find the longest prefix which has been 285 delegated. The DNS administrator must designate the Primary Master 286 Server for the longest match required. Once found, the host sends 287 dynamic AAAA and PTR updates using the concatenation defined above 288 ("hostname.customer.example.com"). 290 In order to use this alternative, hosts must be configured to use 291 dynamic DNS. This is not default behavior for many hosts, which is 292 an inhibitor for the large ISP. This option may be scalable, 293 although registration following an outage may cause signficant load, 294 and hosts using privacy extensions [RFC4941] may update records 295 daily. It is up to the host to provide matching forward and reverse 296 records, and to update them when the address changes. 298 2.3.2. Dynamic DNS through Residential Gateways 300 Residential customers may have a gateway, which may provide DHCPv6 301 service to hosts from a delegated prefix. ISPs should provide a DNS 302 Recursive Name Server and Domain Search List to the gateway, as 303 described above and in[RFC3646] and [RFC6106]. There are two options 304 for how the gateway uses this information. The first option is for 305 the gateway to respond to DHCPv6 requests with the same DNS Recursive 306 Name Server and Domain Search List provided by the ISP. The 307 alternate option is for the gateway to relay dynamic DNS updates from 308 hosts to the servers and domain provided by the ISP. Host behavior 309 is unchanged; they should provide updates to the ISP's servers as 310 described above. 312 2.3.3. Dynamic DNS Delegations 314 An ISP may delegate authority for a subdomain such as 315 "customer12345.anytown.AW.customer.example.com" or 316 "customer12345.example.com" to the customer's gateway. Each domain 317 thus delegated must be unique within the DNS. The ISP may also then 318 delegate the ip6.arpa zone for the prefix delegated to the customer, 319 as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa." 320 Then the customer could provide updates to their own gateway, with 321 forward and reverse. However, individual hosts connected directly to 322 the ISP rarely have the capability to run DNS for themselves; 323 therefore, an ISP can only delegate to customers with gateways 324 capable of being authoritative name servers. If a device requests a 325 DHCPv6 Prefix Delegation, that may be considered a reasonably 326 reliable indicator that it is a gateway, rather than an individual 327 host. It is not necessarily an indicator that the gateway is capable 328 of providing DNS services, and therefore cannot be relied upon as a 329 way to test whether this option is feasible. 331 If the customer's gateway is the name server, it provides its own 332 information to hosts on the network, as normally done for enterprise 333 networks, and as described in [RFC2136]. 335 An ISP may elect to provide authoritative responses as a secondary 336 server to the customer's primary server. 338 To implement this alternative, users' residential gateways must be 339 capable of acting as authoritative name servers capable of dynamic 340 DNS updates. There is no mechanism for an ISP to dynamically 341 communicate to a user's equipment that a zone has been delegated, so 342 user action would be required. Most users have neither the equipment 343 nor the expertise to run DNS servers, so this option is unavailable 344 to the residential ISP. 346 2.3.4. Generate Dynamic Records 348 An ISP's name server that receives a dynamic forward or reverse DNS 349 update may create a matching entry. Since a host capable of updating 350 one is generally capable of updating the other, this should not be 351 required, but redundant record creation will ensure a record exists. 352 ISPs implementing this method should check whether a record already 353 exists before accepting or creating updates. 355 This method is also dependent on hosts being capable of providing 356 dynamic DNS updates, which is not default behavior for many hosts. 358 2.3.5. Populate from DHCP Server 360 A ISP's DHCPv6 server may populate the forward and reverse zones when 361 the DHCP request is received, if the request contains enough 362 information. [RFC4704] 364 However, this method will only work for a single host address 365 (IA_NA); the ISP's DHCP server would not have enough information to 366 update all records for a prefix delegation. If the zone authority is 367 delegated to a home gateway which used this method, the gateway could 368 update records for residential hosts. To implement this alternative, 369 users' residential gateways would have to support the FQDN DHCP 370 option, and would have to either have the zones configured, or send 371 dDNS messages to the ISP's name server. 373 2.3.6. Populate from RADIUS Server 375 A user may receive an address or prefix from a RADIUS [RFC2865] 376 server, the details of which may be recorded via RADIUS Accounting 377 [RFC2866] data. The ISP may populate the forward and reverse zones 378 from the accounting data if it contains enough information. This 379 solution allows the ISP to populate data concerning allocated 380 prefixes (as per 2.2 (wildcards)) and CPE endpoints, but as with 381 2.3.5 does not allow the ISP to populate information concerning 382 individual hosts. 384 2.4. Delegate DNS 386 For customers who are able to run their own DNS servers, such as 387 commercial customers, often the best option is to delegate the 388 reverse DNS zone to them, as described in [RFC2317] (for IPv4). 389 However, since most residential users have neither the equipment nor 390 the expertise to run DNS servers, this method is unavailable to 391 residential ISPs. 393 This is a general case of the specific case described 394 inSection 2.3.3. All of the same considerations still apply. 396 2.5. Dynamically Generate PTR When Queried ("On the Fly") 398 Common practice in IPv4 is to provide PTR records for all addresses, 399 regardless of whether a host is actually using the address. In IPv6, 400 ISPs may generate PTR records for all IPv6 addresses as the records 401 are requested. Configuring records "on the fly" may consume more 402 processor resource than other methods, but only on demand. A denial 403 of service is therefore possible, which may be mitigated with rate- 404 limiting and normal countermeasures. 406 An ISP using this option should generate a PTR record on demand, and 407 cache or prepopulate the forward (AAAA) entry for the duration of the 408 time-to-live of the PTR. This option has the advantage of assuring 409 matching forward and reverse entries, while being simpler than 410 dynamic DNS. Administrators should consider whether the lack of 411 user-specified hostnames is a drawback. 413 This method may not scale well in conjunction with DNSsec [RFC4035], 414 because of the additional load, but since keys may be pregenerated 415 for zones, and not for each record, the risk is moderate. Unsigned 416 records can indicate that these records are less trusted, which might 417 be acceptable. 419 Another consideration is that the algorithm used for generating the 420 record must be the same on all servers for a zone. In other words, 421 any server for the zone must produce the same response for a given 422 query. Administrators managing a variety of rules within a zone 423 might find it difficult to keep those rules synchronized on all 424 servers. 426 3. Recommendations 428 The best accuracy would be achieved if ISPs delegate authority along 429 with address delegation. Where users do not operate authoritative 430 name servers, dynamic DNS updates can provide accurate data, if user 431 hosts support it, and if it scales. Where dynamic DNS is 432 impractical, an ISP has no knowledge of hostnames, and therefore can 433 either provide a wildcard response or a dynamically generated 434 response. It may be noted that some ISPs currently provide a 435 negative response for PTR queries for IPv6 addresses. 437 4. Security Considerations 439 4.1. Using Reverse DNS for Security 441 Some people think the existence of reverse DNS records, or matching 442 forward and reverse DNS records, provides useful information about 443 the hosts with those records. For example, one might infer that the 444 administrator of a network with properly configured DNS records was 445 better-informed, and by further inference more responsible, than the 446 administrator of a less-thoroughly configured network. For instance, 447 most email providers will not accept incoming connections on port 25 448 unless forward and reverse DNS entries match. If they match, but 449 information higher in the stack (for instance, mail source) is 450 inconsistent, the packet is questionable. These records may be 451 easily forged though, unless DNSsec or other measures are taken. The 452 string of inferences is questionable, and may become unneeded if 453 other means for evaluating trustworthiness (such as positive 454 reputations) become predominant in IPv6. 456 Providing location information in PTR records is useful for 457 troubleshooting, law enforcement, and geolocation services, but for 458 the same reasons can be considered sensitive information. 460 4.2. DNS Security with Dynamic DNS 462 Security considerations of using dynamic DNS are described in 463 [RFC3007]. DNS Security Extensions are documented in[RFC4033]. 465 Interactions with DNSsec are described throughout this document. 467 4.3. Considerations for Other Uses of the DNS 469 Several methods exist for providing encryption keys in the DNS. Any 470 of the options presented here may interfere with these key 471 techniques. 473 5. Acknowledgements 475 The author would like to thank Alain Durand, JINMEI Tatuya, David 476 Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis, 477 John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence, 478 Ted Lemon, and Chris Roosenraad. 480 6. IANA Considerations 482 There are no IANA considerations or implications that arise from this 483 document. 485 7. References 487 7.1. Normative References 489 [RFC1033] Lottor, M., "Domain Administrators Operators Guide", 490 November 1987. 492 [RFC1912] Barr, D., "Common DNS Operational and Configuration 493 Errors", February 1996. 495 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 496 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 497 April 1917. 499 [RFC2845] "Secret Key Transaction Authentication for DNS (TSIG)". 501 [RFC2865] "Remote Authentication Dial In User Service (RADIUS)". 503 [RFC2866] "RADIUS Accounting". 505 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 506 Update", November 2000. 508 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 509 Host Configuration Protocol for IPv6 (DHCPv6)", 510 December 2003. 512 [RFC4033] "DNS Security Introduction and Requirements". 514 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 515 Rose, "Protocol Modifications for the DNS Security 516 Extensions", March 2005. 518 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 519 System", July 2006. 521 [RFC4704] Stapp, M., Volz, Y., and Y. Rekhter, "The Dynamic Host 522 Configuration Protocol for IPv6 (DHCPv6) Client Fully 523 Qualified Domain Name (FQDN) Option". 525 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 526 Address Autoconfiguration", September 2007. 528 [RFC4941] "Privacy Extensions for Stateless Address 529 Autoconfiguration in IPv6". 531 [RFC6106] "IPv6 Router Advertisement Options for DNS Configuration". 533 7.2. Informative References 535 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 536 ADDR.ARPA delegation", March 1998. 538 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 539 March 1999. 541 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 542 Considerations and Issues with IPv6 DNS", April 2006. 544 [inaddr-reqd] 545 Senie, D., "draft-ietf-dnsop-inaddr-required-07", 546 August 2005. 548 [rmap-consider] 549 Senie, D. and A. Sullivan, 550 "draft-ietf-dnsop-reverse-mapping-considerations-06", 551 March 2008. 553 Author's Address 555 Lee Howard 556 Time Warner Cable 557 13820 Sunrise Valley Drive 558 Herndon, VA 20171 559 US 561 Email: lee.howard@twcable.com