idnits 2.17.1 draft-ietf-dnsop-ipv6-dns-issues-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1165. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1171. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1187), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 21) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 12, 2004) is 7286 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) ** Downref: Normative reference to an Informational RFC: RFC 3363 (ref. '2') -- Obsolete informational reference (is this intentional?): RFC 3152 (ref. '4') (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '6') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '10') (Obsoleted by RFC 4941) == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-01 == Outdated reference: A later version (-07) exists of draft-huston-6to4-reverse-dns-02 == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-misbehavior-against-aaaa-01 == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-bad-dns-res-01 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-3gpp-analysis-09 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-v6onbydefault-02 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-onlinkassumption-02 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-application-transition-02 -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '25') (Obsoleted by RFC 8415) == Outdated reference: A later version (-12) exists of draft-jeong-dnsop-ipv6-dns-discovery-01 -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '28') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '30') (Obsoleted by RFC 4862) == Outdated reference: A later version (-12) exists of draft-ietf-dhc-ddns-resolution-06 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-fqdn-option-06 == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-dhcid-rr-07 -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '36') (Obsoleted by RFC 4966) == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-renumbering-procedure-00 == Outdated reference: A later version (-07) exists of draft-ietf-dnsop-inaddr-required-05 -- Obsolete informational reference (is this intentional?): RFC 2671 (ref. '40') (Obsoleted by RFC 6891) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-02 == Outdated reference: A later version (-09) exists of draft-ietf-ipv6-unique-local-addr-03 Summary: 8 errors (**), 0 flaws (~~), 21 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations WG A. Durand 3 Internet-Draft SUN Microsystems, Inc. 4 Expires: November 10, 2004 J. Ihren 5 Autonomica 6 P. Savola 7 CSC/FUNET 8 May 12, 2004 10 Operational Considerations and Issues with IPv6 DNS 11 draft-ietf-dnsop-ipv6-dns-issues-07.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 10, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This memo presents operational considerations and issues with IPv6 45 Domain Name System (DNS), including a summary of special IPv6 46 addresses, documentation of known DNS implementation misbehaviour, 47 recommendations and considerations on how to perform DNS naming for 48 service provisioning and for DNS resolver IPv6 support, 49 considerations for DNS updates for both the forward and reverse 50 trees, and miscellaneous issues. This memo is aimed to include a 51 summary of information about IPv6 DNS considerations for those who 52 have experience with IPv4 DNS. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 58 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 59 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 60 1.4 Query Type 'ANY' and A/AAAA Records . . . . . . . . . . . 5 61 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 62 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 63 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 64 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 66 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 67 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 68 4. Recommendations for Service Provisioning using DNS . . . . . . 8 69 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 70 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 71 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 72 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 73 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 11 74 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 12 75 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13 76 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 13 77 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 14 78 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 15 79 6. Considerations about Forward DNS Updating . . . . . . . . . . 15 80 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 15 81 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 15 82 7. Considerations about Reverse DNS Updating . . . . . . . . . . 16 83 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 17 84 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17 85 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 18 86 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18 87 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 19 88 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 20 89 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 20 90 8.2 Renumbering Procedures and Applications' Use of DNS . . . 20 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 92 10. Security Considerations . . . . . . . . . . . . . . . . . . 21 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 95 11.2 Informative References . . . . . . . . . . . . . . . . . . . 21 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 97 A. Site-local Addressing Considerations for DNS . . . . . . . . . 25 98 Intellectual Property and Copyright Statements . . . . . . . . 27 100 1. Introduction 102 This memo presents operational considerations and issues with IPv6 103 DNS; it is meant to be an extensive summary and a list of pointers 104 for more information about IPv6 DNS considerations for those with 105 experience with IPv4 DNS. 107 The purpose of this document is to give information about various 108 issues and considerations related to DNS operations with IPv6; it is 109 not meant to be a normative specification or standard for IPv6 DNS. 111 The first section gives a brief overview of how IPv6 addresses and 112 names are represented in the DNS, how transport protocols and 113 resource records (don't) relate, and what IPv4/IPv6 name space 114 fragmentation means and how to avoid it; all of these are described 115 at more length in other documents. 117 The second section summarizes the special IPv6 address types and how 118 they relate to DNS. The third section describes observed DNS 119 implementation misbehaviours which have a varying effect on the use 120 of IPv6 records with DNS. The fourth section lists recommendations 121 and considerations for provisioning services with DNS. The fifth 122 section in turn looks at recommendations and considerations about 123 providing IPv6 support in the resolvers. The sixth and seventh 124 sections describe considerations with forward and reverse DNS 125 updates, respectively. The eighth section introduces several 126 miscellaneous IPv6 issues relating to DNS for which no better place 127 has been found in this memo. Appendix A looks briefly at the 128 requirements for site-local addressing. 130 1.1 Representing IPv6 Addresses in DNS Records 132 In the forward zones, IPv6 addresses are represented using AAAA 133 records. In the reverse zones, IPv6 address are represented using 134 PTR records in the nibble format under the ip6.arpa. tree. See [1] 135 for more about IPv6 DNS usage, and [2] or [4] for background 136 information. 138 In particular one should note that the use of A6 records in the 139 forward tree or Bitlabels in the reverse tree is not recommended [2]. 140 Using DNAME records is not recommended in the reverse tree in 141 conjunction with A6 records; the document did not mean to take a 142 stance on any other use of DNAME records [5]. 144 1.2 Independence of DNS Transport and DNS Records 146 DNS has been designed to present a single, globally unique name space 147 [7]. This property should be maintained, as described here and in 148 Section 1.3. 150 In DNS, the IP version used to transport the queries and responses is 151 independent of the records being queried: AAAA records can be queried 152 over IPv4, and A records over IPv6. The DNS servers must not make 153 any assumptions about what data to return for Answer and Authority 154 sections. 156 However, there is some debate whether the addresses in Additional 157 section could be selected or filtered using hints obtained from which 158 transport was being used; this has some obvious problems because in 159 many cases the transport protocol does not correlate with the 160 requests, and because a "bad" answer is in a way worse than no answer 161 at all (consider the case where the client is led to believe that a 162 name received in the additional record does not have any AAAA records 163 to begin with). 165 As stated in [1]: 167 The IP protocol version used for querying resource records is 168 independent of the protocol version of the resource records; e.g., 169 IPv4 transport can be used to query IPv6 records and vice versa. 171 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation 173 To avoid the DNS name space from fragmenting into parts where some 174 parts of DNS are only visible using IPv4 (or IPv6) transport, the 175 recommendation is to always keep at least one authoritative server 176 IPv4-enabled, and to ensure that recursive DNS servers support IPv4. 177 See DNS IPv6 transport guidelines [3] for more information. 179 1.4 Query Type 'ANY' and A/AAAA Records 181 QTYPE=* is typically only used for debugging or management purposes; 182 it is worth keeping in mind that QTYPE=* ("ANY" queries; note that 183 QTYPE=* is the technically correct, though oxymoronic, term) 184 literally return any available RRsets, not *all* the RRsets, as only 185 some of these may be present in the caches. Therefore, to get both A 186 and AAAA records reliably, two separate queries must be made. 188 2. DNS Considerations about Special IPv6 Addresses 190 There are a couple of IPv6 address types which are somewhat special; 191 these are considered here. 193 2.1 Limited-scope Addresses 195 The IPv6 addressing architecture [6] includes two kinds of local-use 196 addresses: link-local (fe80::/10) and site-local (fec0::/10). The 197 site-local addresses are being deprecated [8], and are only discussed 198 in Appendix A. 200 Link-local addresses should never be published in DNS (whether in 201 forward or reverse tree), because they have only local (to the 202 connected link) significance [9]. 204 2.2 Temporary Addresses 206 Temporary addresses defined in RFC3041 [10] (sometimes called 207 "privacy addresses") use a random number as the interface identifier. 208 Publishing DNS records relating to such addresses would defeat the 209 purpose of the mechanism and is not recommended. If absolutely 210 necessary, a mapping could be made to some non-identifiable name, as 211 described in [10]. 213 2.3 6to4 Addresses 215 6to4 [11] specifies an automatic tunneling mechanism which maps a 216 public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. 217 Providing reverse DNS delegation path for such addresses is not 218 straightforward and practically impossible. 220 Note that it does not seem feasible to provide reverse DNS with the 221 other automatic tunneling mechanism, Teredo [12]; this is because the 222 IPv6 address is based on the IPv4 address and UDP port of the current 223 NAT mapping which is likely to be relatively short-lived. 225 If the reverse DNS population would be desirable (see Section 7.1 for 226 applicability), there are a number of ways to tackle the delegation 227 path problem [13], some more applicable than the others. 229 The main proposal [14] has been to allocate 2.0.0.2.ip6.arpa. to 230 Regional Internet Registries (RIRs) and let them do subdelegations in 231 accordance to the delegations of the respective IPv4 address space. 232 This has a major practical drawback: those ISPs and IPv4 address 233 space holders where 6to4 is being used do not, in general, provide 234 any IPv6 services -- as otherwise, most people would not have to use 235 6to4 to begin with -- and it is improbable that the reverse 236 delegation chain would be completed either. In most cases, creating 237 such delegation chains might just lead to latencies caused by lookups 238 for (almost always) non-existent DNS records. 240 Another proposal [15] aims to design an autonomous reverse-delegation 241 system that anyone being capable of communicating using a specific 242 6to4 address would be able to set up a reverse delegation to the 243 corresponding 6to4 prefix. This could be deployed by e.g., RIRs. 244 This is a more practical solution, but may have some scalability 245 concerns. 247 3. Observed DNS Implementation Misbehaviour 249 Several classes of misbehaviour in DNS servers, load-balancers and 250 resolvers have been observed. Most of these are rather generic, not 251 only applicable to IPv6 -- but in some cases, the consequences of 252 this misbehaviour are extremely severe in IPv6 environments and 253 deserve to be mentioned. 255 3.1 Misbehaviour of DNS Servers and Load-balancers 257 There are several classes of misbehaviour in certain DNS servers and 258 load-balancers which have been noticed and documented [16]: some 259 implementations silently drop queries for unimplemented DNS records 260 types, or provide wrong answers to such queries (instead of a proper 261 negative reply). While typically these issues are not limited to 262 AAAA records, the problems are aggravated by the fact that AAAA 263 records are being queried instead of (mainly) A records. 265 The problems are serious because when looking up a DNS name, typical 266 getaddrinfo() implementations, with AF_UNSPEC hint given, first try 267 to query the AAAA records of the name, and after receiving a 268 response, query the A records. This is done in a serial fashion -- 269 if the first query is never responded to (instead of properly 270 returning a negative answer), significant timeouts will occur. 272 In consequence, this is an enormous problem for IPv6 deployments, and 273 in some cases, IPv6 support in the software has even been disabled 274 due to these problems. 276 The solution is to fix or retire those misbehaving implementations, 277 but that is likely not going to be effective. There are some 278 possible ways to mitigate the problem, e.g. by performing the 279 lookups somewhat in parallel and reducing the timeout as long as at 280 least one answer has been received; but such methods remain to be 281 investigated; slightly more on this is included in Section 5. 283 3.2 Misbehaviour of DNS Resolvers 285 Several classes of misbehaviour have also been noticed in DNS 286 resolvers [17]. However, these do not seem to directly impair IPv6 287 use, and are only referred to for completeness. 289 4. Recommendations for Service Provisioning using DNS 291 When names are added in the DNS to facilitate a service, there are 292 several general guidelines to consider to be able to do it as 293 smoothly as possible. 295 4.1 Use of Service Names instead of Node Names 297 When a node includes multiple services, one should keep them 298 logically separate in the DNS. This can be done by the use of 299 service names instead of node names (or, "hostnames"). This 300 operational technique is not specific to IPv6, but required to 301 understand the considerations described in Section 4.2 and Section 302 4.3. 304 For example, assume a node named "pobox.example.com" provides both 305 SMTP and IMAP service. Instead of configuring the MX records to 306 point at "pobox.example.com", and configuring the mail clients to 307 look up the mail via IMAP from "pobox.example.com", one should use 308 e.g. "smtp.example.com" for SMTP (for both message submission and 309 mail relaying between SMTP servers) and "imap.example.com" for IMAP. 310 Note that in the specific case of SMTP relaying, the server itself 311 must typically also be configured to know all its names to ensure 312 loops do not occur. DNS can provide a layer of indirection between 313 service names and where the service actually is, and using which 314 addresses. (Obviously, when wanting to reach a specific node, one 315 should use the hostname rather than a service name.) 317 This is a good practice with IPv4 as well, because it provides more 318 flexibility and enables easier migration of services from one host to 319 another. A specific reason why this is relevant for IPv6 is that the 320 different services may have a different level of IPv6 support -- that 321 is, one node providing multiple services might want to enable just 322 one service to be IPv6-visible while keeping some others as 323 IPv4-only. Using service names enables more flexibility with 324 different IP versions as well. 326 4.2 Separate vs the Same Service Names for IPv4 and IPv6 328 The service naming can be achieved in basically two ways: when a 329 service is named "service.example.com" for IPv4, the IPv6-enabled 330 service could be either added to "service.example.com", or added 331 separately to a sub-domain, like, "service.ipv6.example.com". 333 Both methods have different characteristics. Using a sub-domain 334 allows for easier service piloting, minimizing the disturbance to the 335 "regular" users of IPv4 service; however, the service would not be 336 used without explicitly asking for it (or, within a restricted 337 network, modifying the DNS search path) -- so it will not actually be 338 used that much. Using the same service name is the "long-term" 339 solution, but may degrade performance for those clients whose IPv6 340 performance is lower than IPv4, or does not work as well (see the 341 next subsection for more). 343 In most cases, it makes sense to pilot or test a service using 344 separate service names, and move to the use of the same name when 345 confident enough that the service level will not degrade for the 346 users unaware of IPv6. 348 4.3 Adding the Records Only when Fully IPv6-enabled 350 The recommendation is that AAAA records for a service should not be 351 added to the DNS until all of following are true: 353 1. The address is assigned to the interface on the node. 355 2. The address is configured on the interface. 357 3. The interface is on a link which is connected to the IPv6 358 infrastructure. 360 In addition, if the AAAA record is added for the node, instead of 361 service as recommended, all the services of the node should be 362 IPv6-enabled prior to adding the resource record. 364 For example, if an IPv6 node is isolated from an IPv6 perspective 365 (e.g., it is not connected to IPv6 Internet) constraint #3 would mean 366 that it should not have an address in the DNS. 368 Consider the case of two dual-stack nodes, which both have IPv6 369 enabled, but the server does not have (global) IPv6 connectivity. As 370 the client looks up the server's name, only A records are returned 371 (if the recommendations above are followed), and no IPv6 372 communication, which would have been unsuccessful, is even attempted. 374 The issues are not always so black-and-white. Usually it's important 375 if the service offered using both protocols is of roughly equal 376 quality, using the appropriate metrics for the service (e.g., 377 latency, throughput, low packet loss, general reliability, etc.) -- 378 this is typically very important especially for interactive or 379 real-time services. In many cases, the quality of IPv6 connectivity 380 is not yet equal to that of IPv4, at least globally -- this has to be 381 taken into consideration when enabling services [18]. 383 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments 385 Consider the case where the query name is so long, the number of the 386 additional records is so high, or for other reasons that the entire 387 response would not fit in a single UDP packet. In some cases, the 388 responder truncates the response with the TC bit being set (leading 389 to a retry with TCP), in order for the querier to get the entire 390 response later. 392 However, note that if too much additional information that is not 393 strictly necessary would be added, one should remove unnecessary 394 information instead of setting TC bit for this "courtesy" information 395 [19]. 397 Also notice that there are two kinds of additional data: 399 1. glue, i.e., "critical" additional data; this must be included in 400 all scenarios, with all the RRsets as possible, and 402 2. "courtesy" additional data; this could be sent in full, with only 403 a few RRsets, or with no RRsets, and can be fetched separately as 404 well but could lead to non-optimal results. 406 Meanwhile, resource record sets (RRsets) are never "broken up", so if 407 a name has 4 A records and 5 AAAA records, you can either return all 408 9, all 4 A records, all 5 AAAA records or nothing. Notice that for 409 the "critical" additional data getting all the RRsets can be 410 critical. 412 An example of the "courtesy" additional data is A/AAAA records in 413 conjunction of MX records as shown in the next section; an example of 414 the "critical" additional data is shown below (where getting both the 415 A and AAAA RRsets is critical): 417 child.example.com. IN NS ns.child.example.com. 418 ns.child.example.com. IN A 192.0.2.1 419 ns.child.example.com. IN AAAA 2001:db8::1 421 In the case of too much additional data (whether courtesy or 422 critical), it might be tempting to not return the AAAA records if the 423 transport for DNS query was IPv4, or not return the A records, if the 424 transport was IPv6. However, this breaks the model of independence 425 of DNS transport and resource records, as noted in Section 1.2. 427 This temptation would have significant problems in multiple areas. 428 Remember that often the end-node, which will be using the records, is 429 not the same one as the node requesting them from the authoritative 430 DNS server (or even a caching resolver). So, whichever version the 431 requestor ("the middleman") uses makes no difference to the ultimate 432 user of the records. This might result in e.g., inappropriately 433 returning A records to an IPv6-only node, going through a 434 translation, or opening up another IP-level session (e.g., a PDP 435 context [20]). 437 The problem of too much additional data seems to be an operational 438 one: the zone administrator entering too many records which will be 439 returned either truncated or missing some RRsets to the users. A 440 protocol fix for this is using EDNS0 [40] to signal the capacity for 441 larger UDP packet sizes, pushing up the relevant threshold. Further, 442 DNS server implementations should rather omit courtesy additional 443 data completely rather than including only some RRsets. An 444 operational fix for this is having the DNS server implementations 445 return a warning when the administrators create the zones which would 446 result in too much additional data being returned. 448 Additionally, to avoid the case where an application would not get an 449 address at all due to non-critical additional data being omitted, the 450 applications should be able to query the specific records of the 451 desired protocol, not just rely on getting all the required RRsets in 452 the additional section. 454 4.5 The Use of TTL for IPv4 and IPv6 RRs 456 In the previous section, we discussed a danger with queries, 457 potentially leading to omitting RRsets from the additional section; 458 this could happen to both critical and "courtesy" additional data. 459 This section discusses another problem with the latter, leading to 460 omitting RRsets in cached data, highlighted in the IPv4/IPv6 461 environment. 463 The behaviour of DNS caching when different TTL values are used for 464 different RRsets of the same name requires explicit discussion. For 465 example, let's consider a part of a zone: 467 example.com. 300 IN MX foo.example.com. 468 foo.example.com. 300 IN A 192.0.2.1 469 foo.example.com. 100 IN AAAA 2001:db8::1 471 When a caching resolver asks for the MX record of example.com, it 472 gets back "foo.example.com". It may also get back either one or both 473 of the A and AAAA records in the additional section. So, there are 474 three cases about returning records for the MX in the additional 475 section: 477 1. We get back no A or AAAA RRsets: this is the simplest case, 478 because then we have to query which information is required 479 explicitly, guaranteeing that we get all the information we're 480 interested in. 482 2. We get back all the RRsets: this is an optimization as there is 483 no need to perform more queries, causing lower latency. However, 484 it is impossible to guarantee that in fact we would always get 485 back all the records (the only way to ensure that is to send a 486 AAAA query for the name after getting the cached reply); however, 487 one could try to work in the direction to try to ensure it as far 488 as possible. 490 3. We only get back A or AAAA RRsets even if both existed: this is 491 indistinguishable from the previous case, and problematic as 492 described in the previous section. 494 As the third case was considered in the previous section, we assume 495 we get back both A and AAAA records of foo.example.com, or the stub 496 resolver explicitly asks, in two separate queries, both A and AAAA 497 records. 499 After 100 seconds, the AAAA record is removed from the cache(s) 500 because its TTL expired. It would be useful for the caching 501 resolvers to discard the A record when the shorter TTL (in this case, 502 for the AAAA record) expires; this would avoid the situation where 503 there would be a window of 200 seconds when incomplete information is 504 returned from the cache. However, this is not mandated or mentioned 505 by the specification(s). 507 To simplify the situation, it might help to use the same TTL for all 508 the resource record sets referring to the same name, unless there is 509 a particular reason for not doing so. However, there are some 510 scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where 511 a different strategy is preferable. 513 Thus, applications that use the response should not rely on a 514 particular TTL configuration. For example, even if an application 515 gets a response that only has the A record in the example described 516 above, it should not assume there is no AAAA record for 517 "foo.example.com". Instead, the application should try to fetch the 518 missing records by itself if it needs the record. 520 4.6 IPv6 Transport Guidelines for DNS Servers 522 As described in Section 1.3 and [3], there should continue to be at 523 least one authoritative IPv4 DNS server for every zone, even if the 524 zone has only IPv6 records. (Note that obviously, having more 525 servers with robust connectivity would be preferable, but this is the 526 minimum recommendation; also see [21].) 528 5. Recommendations for DNS Resolver IPv6 Support 530 When IPv6 is enabled on a node, there are several things to consider 531 to ensure that the process is as smooth as possible. 533 5.1 DNS Lookups May Query IPv6 Records Prematurely 535 The system library that implements the getaddrinfo() function for 536 looking up names is a critical piece when considering the robustness 537 of enabling IPv6; it may come in basically three flavours: 539 1. The system library does not know whether IPv6 has been enabled in 540 the kernel of the operating system: it may start looking up AAAA 541 records with getaddrinfo() and AF_UNSPEC hint when the system is 542 upgraded to a system library version which supports IPv6. 544 2. The system library might start to perform IPv6 queries with 545 getaddrinfo() only when IPv6 has been enabled in the kernel. 546 However, this does not guarantee that there exists any useful 547 IPv6 connectivity (e.g., the node could be isolated from the 548 other IPv6 networks, only having link-local addresses). 550 3. The system library might implement a toggle which would apply 551 some heuristics to the "IPv6-readiness" of the node before 552 starting to perform queries; for example, it could check whether 553 only link-local IPv6 address(es) exists, or if at least one 554 global IPv6 address exists. 556 First, let us consider generic implications of unnecessary queries 557 for AAAA records: when looking up all the records in the DNS, AAAA 558 records are typically tried first, and then A records. These are 559 done in serial, and the A query is not performed until a response is 560 received to the AAAA query. Considering the misbehaviour of DNS 561 servers and load-balancers, as described in Section 3.1, the look-up 562 delay for AAAA may incur additional unnecessary latency, and 563 introduce a component of unreliability. 565 One option here could be to do the queries partially in parallel; for 566 example, if the final response to the AAAA query is not received in 567 0.5 seconds, start performing the A query while waiting for the 568 result (immediate parallelism might be unoptimal without information 569 sharing between the look-up threads, as that would probably lead to 570 duplicate non-cached delegation chain lookups). 572 An additional concern is the address selection, which may, in some 573 circumstances, prefer AAAA records over A records, even when the node 574 does not have any IPv6 connectivity [22]. In some cases, the 575 implementation may attempt to connect or send a datagram on a 576 physical link [23], incurring very long protocol timeouts, instead of 577 quickly failing back to IPv4. 579 Now, we can consider the issues specific to each of the three 580 possibilities: 582 In the first case, the node performs a number of completely useless 583 DNS lookups as it will not be able to use the returned AAAA records 584 anyway. (The only exception is where the application desires to know 585 what's in the DNS, but not use the result for communication.) One 586 should be able to disable these unnecessary queries, for both latency 587 and reliability reasons. However, as IPv6 has not been enabled, the 588 connections to IPv6 addresses fail immediately, and if the 589 application is programmed properly, the application can fall 590 gracefully back to IPv4 [24]. 592 The second case is similar to the first, except it happens to a 593 smaller set of nodes when IPv6 has been enabled but connectivity has 594 not been provided yet; similar considerations apply, with the 595 exception that IPv6 records, when returned, will be actually tried 596 first which may typically lead to long timeouts. 598 The third case is a bit more complex: optimizing away the DNS lookups 599 with only link-locals is probably safe (but may be desirable with 600 different lookup services which getaddrinfo() may support), as the 601 link-locals are typically automatically generated when IPv6 is 602 enabled, and do not indicate any form of IPv6 connectivity. That is, 603 performing DNS lookups only when a non-link-local address has been 604 configured on any interface could be beneficial -- this would be an 605 indication that either the address has been configured either from a 606 router advertisement, DHCPv6 [25], or manually. Each would indicate 607 at least some form of IPv6 connectivity, even though there would not 608 be guarantees of it. 610 These issues should be analyzed at more depth, and the fixes found 611 consensus on, perhaps in a separate document. 613 5.2 Obtaining a List of DNS Recursive Resolvers 615 In scenarios where DHCPv6 is available, a host can discover a list of 616 DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" 617 option [29]. This option can be passed to a host through a subset of 618 DHCPv6 [28]. 620 The IETF is considering the development of alternative mechanisms for 621 obtaining the list of DNS recursive name servers when DHCPv6 is 622 unavailable or inappropriate. No decision about taking on this 623 development work has been reached as of this writing (May 2004). 625 In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms 626 under consideration for development of dnsop WG include the use of 627 well-known addresses [26], the use of Router Advertisements to convey 628 the information [27]. 630 Note that even though IPv6 DNS resolver discovery is a recommended 631 procedure, it is not required for dual-stack nodes in dual-stack 632 networks as IPv6 DNS records can be queried over IPv4 as well as 633 IPv6. Obviously, nodes which are meant to function without manual 634 configuration in IPv6-only networks must implement DNS resolver 635 discovery function. 637 5.3 IPv6 Transport Guidelines for Resolvers 639 As described in Section 1.3 and [3], the recursive resolvers should 640 be IPv4-only or dual-stack to be able to reach any IPv4-only DNS 641 server. Note that this requirement is also fulfilled by an IPv6-only 642 stub resolver pointing to a dual-stack recursive DNS resolver. 644 6. Considerations about Forward DNS Updating 646 While the topic how to enable updating the forward DNS, i.e., the 647 mapping from names to the correct new addresses, is not specific to 648 IPv6, it bears thinking about especially due to adding Stateless 649 Address Autoconfiguration [30] to the mix. 651 Typically forward DNS updates are more manageable than doing them in 652 the reverse DNS, because the updater can, typically, be assumed to 653 "own" a certain DNS name -- and we can create a form of security 654 relationship with the DNS name and the node allowed to update it to 655 point to a new address. 657 A more complex form of DNS updates -- adding a whole new name into a 658 DNS zone, instead of updating an existing name -- is considered out 659 of scope for this memo. Adding a new name in the forward zone is a 660 problem which is still being explored with IPv4, and IPv6 does not 661 seem to add much new in that area. 663 6.1 Manual or Custom DNS Updates 665 The DNS mappings can be maintained by hand, in a semi-automatic 666 fashion or by running non-standardized protocols. These are not 667 considered at more length in this memo. 669 6.2 Dynamic DNS 671 Dynamic DNS updates (DDNS) [31][32] is a standardized mechanism for 672 dynamically updating the DNS. It works equally well with stateless 673 address autoconfiguration (SLAAC), DHCPv6 or manual address 674 configuration. The only (minor) twist is that with SLAAC, the DNS 675 server cannot tie the authentication of the user to the IP address, 676 and stronger mechanisms must be used [32]. As relying on IP 677 addresses for Dynamic DNS is rather insecure at best, stronger 678 authentication should always be used; however, this requires that the 679 authorization keying will be explicitly configured using unspecified 680 operational methods. 682 Note that with DHCP it is also possible that the DHCP server updates 683 the DNS, not the host. The host might only indicate in the DHCP 684 exchange which hostname it would prefer, and the DHCP server would 685 make the appropriate updates. Nonetheless, while this makes setting 686 up a secure channel between the updater and the DNS server easier, it 687 does not help much with "content" security, i.e., whether the 688 hostname was acceptable -- if the DNS server does not include 689 policies, they must be included in the DHCP server (e.g., a regular 690 host should not be able to state that its name is "www.example.com"). 691 DHCP-initiated DDNS updates have been extensively described in [33], 692 [34] and [35]. 694 The nodes must somehow be configured with the information about the 695 servers where they will attempt to update their addresses, sufficient 696 security material for authenticating themselves to the server, and 697 the hostname they will be updating. Unless otherwise configured, the 698 first could be obtained by looking up the authoritative name servers 699 for the hostname; the second must be configured explicitly unless one 700 chooses to trust the IP address-based authentication (not a good 701 idea); and lastly, the nodename is typically pre-configured somehow 702 on the node, e.g. at install time. 704 Care should be observed when updating the addresses not to use longer 705 TTLs for addresses than are preferred lifetimes for the 706 autoconfigured addresses, so that if the node is renumbered in a 707 managed fashion, the amount of stale DNS information is kept to the 708 minimum. That is, if the preferred lifetime of an address expires, 709 the TTL of the record needs be modified unless it was already done 710 before the expiration. For better flexibility, the DNS TTL should be 711 much shorter (e.g., a half or a third) than the lifetime of an 712 address; that way, the node can start lowering the DNS TTL if it 713 seems like the address has not been renewed/refreshed in a while. 714 Some discussion on how an administrator could manage the DNS TTL is 715 included in [37]; this could be applied to (smart) hosts as well. 717 7. Considerations about Reverse DNS Updating 719 Updating the reverse DNS zone may be difficult because of the split 720 authority over an address. However, first we have to consider the 721 applicability of reverse DNS in the first place. 723 7.1 Applicability of Reverse DNS 725 Today, some applications use reverse DNS to either look up some hints 726 about the topological information associated with an address (e.g. 727 resolving web server access logs), or as a weak form of a security 728 check, to get a feel whether the user's network administrator has 729 "authorized" the use of the address (on the premises that adding a 730 reverse record for an address would signal some form of 731 authorization). 733 One additional, maybe slightly more useful usage is ensuring the 734 reverse and forward DNS contents match and correspond to a configured 735 name or domain. As a security check, it is typically accompanied by 736 other mechanisms, such as a user/password login; the main purpose of 737 the DNS check is to weed out the majority of unauthorized users, and 738 if someone managed to bypass the checks, he would still need to 739 authenticate "properly". 741 It is not clear whether it makes sense to require or recommend that 742 reverse DNS records be updated. In many cases, it would just make 743 more sense to use proper mechanisms for security (or topological 744 information lookup) in the first place. At minimum, the applications 745 which use it as a generic authorization (in the sense that a record 746 exists at all) should be modified as soon as possible to avoid such 747 lookups completely. 749 The applicability is discussed at more length in [38]. 751 7.2 Manual or Custom DNS Updates 753 Reverse DNS can of course be updated using manual or custom methods. 754 These are not further described here, except for one special case. 756 One way to deploy reverse DNS would be to use wildcard records, for 757 example, by configuring one name for a subnet (/64) or a site (/48). 758 As a concrete example, a site (or the site's ISP) could configure the 759 reverses of the prefix 2001:db8:f00::/48 to point to one name using a 760 wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR 761 site.example.com." Naturally, such a name could not be verified from 762 the forward DNS, but would at least provide some form of "topological 763 information" or "weak authorization" if that is really considered to 764 be useful. Note that this is not actually updating the DNS as such, 765 as the whole point is to avoid DNS updates completely by manually 766 configuring a generic name. 768 7.3 DDNS with Stateless Address Autoconfiguration 770 Dynamic DNS with SLAAC simpler than forward DNS updates in some 771 regard, while being more difficult in another. 773 The address space administrator decides whether the hosts are trusted 774 to update their reverse DNS records or not. If they are, a simple 775 address-based authorization is typically sufficient (i.e., check that 776 the DNS update is done from the same IP address as the record being 777 updated); stronger security can also be used [32]. If they aren't 778 allowed to update the reverses, no update can occur. 780 Address-based authorization is simpler with reverse DNS (as there is 781 a connection between the record and the address) than with forward 782 DNS. However, when a stronger form of security is used, forward DNS 783 updates are simpler to manage because the host knows the record it's 784 updating, and can be assumed to have an association with the domain. 785 Note that the user may roam to different networks, and does not 786 necessarily have any association with the owner of that address space 787 -- so, assuming stronger form of authorization for reverse DNS 788 updates than an address association is generally unfeasible. 790 Moreover, the reverse zones must be cleaned up by an unspecified 791 janitorial process: the node does not typically know a priori that it 792 will be disconnected, and cannot send a DNS update using the correct 793 source address to remove a record. 795 A problem with defining the clean-up process is that it is difficult 796 to ensure that a specific IP address and the corresponding record are 797 no longer being used. Considering the huge address space, and the 798 unlikelihood of collision within 64 bits of the interface 799 identifiers, a process which would remove the record after no traffic 800 has been seen from a node in a long period of time (e.g., a month or 801 year) might be one possible approach. 803 To insert or update the record, the node must discover the DNS server 804 to send the update to somehow, similar to as discussed in Section 805 6.2. One way to automate this is looking up the DNS server 806 authoritative (e.g., through SOA record) for the IP address being 807 updated, but the security material (unless the IP address-based 808 authorization is trusted) must also be established by some other 809 means. 811 7.4 DDNS with DHCP 813 With DHCPv4, the reverse DNS name is typically already inserted to 814 the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One 815 can assume similar practice may become commonplace with DHCPv6 as 816 well; all such mappings would be pre-configured, and would require no 817 updating. 819 If a more explicit control is required, similar considerations as 820 with SLAAC apply, except for the fact that typically one must update 821 a reverse DNS record instead of inserting one (if an address 822 assignment policy that reassigns disused addresses is adopted) and 823 updating a record seems like a slightly more difficult thing to 824 secure. However, it is yet uncertain how DHCPv6 is going to be used 825 for address assignment. 827 Note that when using DHCP, either the host or the DHCP server could 828 perform the DNS updates; see the implications in Section 6.2. 830 If disused addresses were to be reassigned, host-based DDNS reverse 831 updates would need policy considerations for DNS record modification, 832 as noted above. On the other hand, if disused address were not to be 833 assigned, host-based DNS reverse updates would have similar 834 considerations as SLAAC in Section 7.3. Server-based updates have 835 similar properties except that the janitorial process could be 836 integrated with DHCP address assignment. 838 7.5 DDNS with Dynamic Prefix Delegation 840 In cases where a prefix, instead of an address, is being used and 841 updated, one should consider what is the location of the server where 842 DDNS updates are made. That is, where the DNS server is located: 844 1. At the same organization as the prefix delegator. 846 2. At the site where the prefixes are delegated to. In this case, 847 the authority of the DNS reverse zone corresponding to the 848 delegated prefix is also delegated to the site. 850 3. Elsewhere; this implies a relationship between the site and where 851 DNS server is located, and such a relationship should be rather 852 straightforward to secure as well. Like in the previous case, 853 the authority of the DNS reverse zone is also delegated. 855 In the first case, managing the reverse DNS (delegation) is simpler 856 as the DNS server and the prefix delegator are in the same 857 administrative domain (as there is no need to delegate anything at 858 all); alternatively, the prefix delegator might forgo DDNS reverse 859 capability altogether, and use e.g., wildcard records (as described 860 in Section 7.2). In the other cases, it can be slighly more 861 difficult, particularly as the site will have to configure the DNS 862 server to be authoritative for the delegated reverse zone, implying 863 automatic configuration of the DNS server -- as the prefix may be 864 dynamic. 866 Managing the DDNS reverse updates is typically simple in the second 867 case, as the updated server is located at the local site, and 868 arguably IP address-based authentication could be sufficient (or if 869 not, setting up security relationships would be simpler). As there 870 is an explicit (security) relationship between the parties in the 871 third case, setting up the security relationships to allow reverse 872 DDNS updates should be rather straightforward as well. In the first 873 case, however, setting up and managing such relationships might be a 874 lot more difficult. 876 8. Miscellaneous DNS Considerations 878 This section describes miscellaneous considerations about DNS which 879 seem related to IPv6, for which no better place has been found in 880 this document. 882 8.1 NAT-PT with DNS-ALG 884 NAT-PT [36] DNS-ALG is a critical component (unless something 885 replacing that functionality is specified) which mangles A records to 886 look like AAAA records to the IPv6-only nodes. Numerous problems 887 have been identified with DNS-ALG [39]. 889 8.2 Renumbering Procedures and Applications' Use of DNS 891 One of the most difficult problems of systematic IP address 892 renumbering procedures [37] is that an application which looks up a 893 DNS name disregards information such as TTL, and uses the result 894 obtained from DNS as long as it happens to be stored in the memory of 895 the application. For applications which run for a long time, this 896 could be days, weeks or even months; some applications may be clever 897 enough to organize the data structures and functions in such a manner 898 that look-ups get refreshed now and then. 900 While the issue appears to have a clear solution, "fix the 901 applications", practically this is not reasonable immediate advice; 902 the TTL information is not typically available in the APIs and 903 libraries (so, the advice becomes "fix the applications, APIs and 904 libraries"), and a lot more analysis is needed on how to practically 905 go about to achieve the ultimate goal of avoiding using the names 906 longer than expected. 908 9. Acknowledgements 910 Some recommendations (Section 4.3, Section 5.1) about IPv6 service 911 provisioning were moved here from [41] by Erik Nordmark and Bob 912 Gilligan. Havard Eidnes and Michael Patton provided useful feedback 913 and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark 914 Andrews helped in clarifying the issues regarding additional data and 915 the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei 916 Tatuya, Iljitsch van Beijnum, and Edward Lewis provided useful 917 feedback during the WG last call. 919 10. Security Considerations 921 This document reviews the operational procedures for IPv6 DNS 922 operations and does not have security considerations in itself. 924 However, it is worth noting that in particular with Dynamic DNS 925 Updates, security models based on the source address validation are 926 very weak and cannot be recommended. On the other hand, it should be 927 noted that setting up an authorization mechanism (e.g., a shared 928 secret, or public-private keys) between a node and the DNS server has 929 to be done manually, and may require quite a bit of time and 930 expertise. 932 To re-emphasize which was already stated, reverse DNS checks provide 933 very weak security at best, and the only (questionable) 934 security-related use for them may be in conjunction with other 935 mechanisms when authenticating a user. 937 11. References 939 11.1 Normative References 941 [1] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 942 Extensions to Support IP Version 6", RFC 3596, October 2003. 944 [2] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, 945 "Representing Internet Protocol version 6 (IPv6) Addresses in 946 the Domain Name System (DNS)", RFC 3363, August 2002. 948 [3] Durand, A. and J. Ihren, "DNS IPv6 transport operational 949 guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02 (work 950 in progress), March 2004. 952 11.2 Informative References 954 [4] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 955 2001. 957 [5] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for 958 Internet Protocol version 6 (IPv6)", RFC 3364, August 2002. 960 [6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 961 Addressing Architecture", RFC 3513, April 2003. 963 [7] Internet Architecture Board, "IAB Technical Comment on the 964 Unique DNS Root", RFC 2826, May 2000. 966 [8] Huitema, C. and B. Carpenter, "Deprecating Site Local 967 Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work in 968 progress), March 2004. 970 [9] Hazel, P., "IP Addresses that should never appear in the public 971 DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in 972 progress), February 2002. 974 [10] Narten, T. and R. Draves, "Privacy Extensions for Stateless 975 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 977 [11] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 978 IPv4 Clouds", RFC 3056, February 2001. 980 [12] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 981 draft-huitema-v6ops-teredo-01 (work in progress), February 982 2004. 984 [13] Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in 985 progress), October 2002. 987 [14] Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa", 988 draft-ymbk-6to4-arpa-delegation-00 (work in progress), February 989 2003. 991 [15] Huston, G., "6to4 Reverse DNS", 992 draft-huston-6to4-reverse-dns-02 (work in progress), April 993 2004. 995 [16] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS 996 Queries for IPv6 Addresses", 997 draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in 998 progress), April 2004. 1000 [17] Larson, M. and P. Barber, "Observed DNS Resolution 1001 Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in 1002 progress), June 2003. 1004 [18] Savola, P., "Moving from 6bone to IPv6 Internet", 1005 draft-savola-v6ops-6bone-mess-01 (work in progress), November 1006 2002. 1008 [19] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 1009 RFC 2181, July 1997. 1011 [20] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", 1012 draft-ietf-v6ops-3gpp-analysis-09 (work in progress), March 1013 2004. 1015 [21] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and 1016 Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1017 1997. 1019 [22] Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack IPv6 1020 on by Default", draft-ietf-v6ops-v6onbydefault-02 (work in 1021 progress), May 2004. 1023 [23] Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery 1024 On-Link Assumption Considered Harmful", 1025 draft-ietf-v6ops-onlinkassumption-02 (work in progress), May 1026 2004. 1028 [24] Shin, M., "Application Aspects of IPv6 Transition", 1029 draft-ietf-v6ops-application-transition-02 (work in progress), 1030 March 2004. 1032 [25] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 1033 Carney, "Dynamic Host Configuration Protocol for IPv6 1034 (DHCPv6)", RFC 3315, July 2003. 1036 [26] Ohta, M., "Preconfigured DNS Server Addresses", 1037 draft-ohta-preconfigured-dns-01 (work in progress), February 1038 2004. 1040 [27] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement", 1041 draft-jeong-dnsop-ipv6-dns-discovery-01 (work in progress), 1042 February 2004. 1044 [28] Droms, R., "Stateless Dynamic Host Configuration Protocol 1045 (DHCP) Service for IPv6", RFC 3736, April 2004. 1047 [29] Droms, R., "DNS Configuration options for Dynamic Host 1048 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 1049 2003. 1051 [30] Thomson, S. and T. Narten, "IPv6 Stateless Address 1052 Autoconfiguration", RFC 2462, December 1998. 1054 [31] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 1055 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1056 April 1997. 1058 [32] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1059 Update", RFC 3007, November 2000. 1061 [33] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP 1062 Clients", draft-ietf-dhc-ddns-resolution-06 (work in progress), 1063 October 2003. 1065 [34] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", 1066 draft-ietf-dhc-fqdn-option-06 (work in progress), October 2003. 1068 [35] Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for encoding 1069 DHCP information (DHCID RR)", draft-ietf-dnsext-dhcid-rr-07 1070 (work in progress), October 2003. 1072 [36] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 1073 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 1075 [37] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering 1076 an IPv6 Network without a Flag Day", 1077 draft-ietf-v6ops-renumbering-procedure-00 (work in progress), 1078 February 2004. 1080 [38] Senie, D., "Requiring DNS IN-ADDR Mapping", 1081 draft-ietf-dnsop-inaddr-required-05 (work in progress), April 1082 2004. 1084 [39] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", 1085 draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress), 1086 February 2003. 1088 [40] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 1089 August 1999. 1091 [41] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 1092 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in 1093 progress), February 2004. 1095 [42] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1096 Addresses", draft-ietf-ipv6-unique-local-addr-03 (work in 1097 progress), February 2004. 1099 Authors' Addresses 1101 Alain Durand 1102 SUN Microsystems, Inc. 1103 17 Network circle UMPL17-202 1104 Menlo Park, CA 94025 1105 USA 1107 EMail: Alain.Durand@sun.com 1109 Johan Ihren 1110 Autonomica 1111 Bellmansgatan 30 1112 SE-118 47 Stockholm 1113 Sweden 1115 EMail: johani@autonomica.se 1117 Pekka Savola 1118 CSC/FUNET 1120 Espoo 1121 Finland 1123 EMail: psavola@funet.fi 1125 Appendix A. Site-local Addressing Considerations for DNS 1127 As site-local addressing is being deprecated, the considerations for 1128 site-local addressing are discussed briefly here. Unique local 1129 addressing format [42] has been proposed as a replacement, but being 1130 work-in-progress, it is not considered further. 1132 The interactions with DNS come in two flavors: forward and reverse 1133 DNS. 1135 To actually use site-local addresses within a site, this implies the 1136 deployment of a "split-faced" or a fragmented DNS name space, for the 1137 zones internal to the site, and the outsiders' view to it. The 1138 procedures to achieve this are not elaborated here. The implication 1139 is that site-local addresses must not be published in the public DNS. 1141 To faciliate reverse DNS (if desired) with site-local addresses, the 1142 stub resolvers must look for DNS information from the local DNS 1143 servers, not e.g. starting from the root servers, so that the 1144 site-local information may be provided locally. Note that the 1145 experience of private addresses in IPv4 has shown that the root 1146 servers get loaded for requests for private address lookups in any 1147 case. 1149 Intellectual Property Statement 1151 The IETF takes no position regarding the validity or scope of any 1152 Intellectual Property Rights or other rights that might be claimed to 1153 pertain to the implementation or use of the technology described in 1154 this document or the extent to which any license under such rights 1155 might or might not be available; nor does it represent that it has 1156 made any independent effort to identify any such rights. Information 1157 on the procedures with respect to rights in RFC documents can be 1158 found in BCP 78 and BCP 79. 1160 Copies of IPR disclosures made to the IETF Secretariat and any 1161 assurances of licenses to be made available, or the result of an 1162 attempt made to obtain a general license or permission for the use of 1163 such proprietary rights by implementers or users of this 1164 specification can be obtained from the IETF on-line IPR repository at 1165 http://www.ietf.org/ipr. 1167 The IETF invites any interested party to bring to its attention any 1168 copyrights, patents or patent applications, or other proprietary 1169 rights that may cover technology that may be required to implement 1170 this standard. Please address the information to the IETF at 1171 ietf-ipr@ietf.org. 1173 Disclaimer of Validity 1175 This document and the information contained herein are provided on an 1176 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1177 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1178 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1179 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1180 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1181 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1183 Copyright Statement 1185 Copyright (C) The Internet Society (2004). This document is subject 1186 to the rights, licenses and restrictions contained in BCP 78, and 1187 except as set forth therein, the authors retain all their rights. 1189 Acknowledgment 1191 Funding for the RFC Editor function is currently provided by the 1192 Internet Society.