idnits 2.17.1 draft-ietf-ngtrans-dns-ops-req-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 541 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-ietf-ngtrans-interaction-00 -- Possible downref: Normative reference to a draft: ref. 'INTERACTION' -- Possible downref: Normative reference to a draft: ref. 'NAT-PT-ISSUES' ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) ** Downref: Normative reference to an Informational RFC: RFC 2826 ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Alain Durand 2 INTERNET-DRAFT SUN Microsystems 3 March 1, 2002 Johan Ihren 4 Expires Sep. 2, 2002 Autonomica AB 6 NGtrans IPv6 DNS operational requirements and roadmap 8 draft-ietf-ngtrans-dns-ops-req-04.txt 10 Status of this memo 12 This memo provides information to the Internet community. It does 13 not specify an Internet standard of any kind. This memo is in full 14 conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 16 The list of current Internet-Drafts can be accessed at 17 http://www.ietf.org/ietf/1id-abstracts.txt 18 The list of Internet-Draft Shadow Directories can be accessed at 19 http://www.ietf.org/shadow.html. 21 Abstract 23 This document describes IPv6 DNS operational requirements and 24 deployment roadmap steps. It is the result of discussion from members 25 of the IPv6, NGtrans, DNSop and DNSext working groups. The DNS is 26 looked as a critical part of the Internet infrastructure and is used 27 for much more purposes than name to address resolution. Thus a 28 smooth operation of the DNS is critical in the IPv6 transition. 30 Discussion of this memo should happen in the NGtrans mailing list. 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 1. DNS issues in a mixed IPv4/IPv6 environment 38 IPv4 and IPv6 are two versions of the same original concept, but they 39 are not "binary compatible". That is, a datagram send by one version 40 of IP cannot be received by the other. Several things can go wrong 41 when operating DNS in a mixed environment IPv4 and IPv6. 43 1.1 Following the referral chain 45 The caching resolver that tries to lookup a name starts out at the 46 root, and follows referrals until it is referred to a nameserver that 47 is authoritative for the name. If somewhere down the chain of 48 referrals it is referred to a nameserver that is only accessible over 49 a type of transport that is unavailable, a traditional nameserver is 50 unable to finish the task. 52 When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is 53 only a matter of time until this starts to happen and the complete 54 DNS hierarchy starts to fragment into a graph where authoritative 55 nameservers for certain nodes are only accessible over a certain 56 transport. What is feared is that a node using only a particular 57 version of IP, querying information about another node using the same 58 version of IP can not do it because, somewhere in the chain of 59 servers accessed during the resolution process, one or more of them 60 will only be accessible with the other version of IP. 62 1.2 Examples of problems for an IPv6 only resolver 64 This problem shows for IPv6 only resolver trying to fetch data from a 65 zone that is served by IPv6 servers when somewhere in the referral 66 chain, the list of name servers pointed at does not contain any IPv6 67 reachable server. 69 Hints for the root: 71 X.ROOT-SERVERS.NET IN A 100.100.100.101 72 X.ROOT-SERVERS.NET IN AAAA 3ffe:ffff:100:100::1 74 In the root zone: 76 org. IN NS dot-org.X.ROOT-SERVERS.NET 77 dot-org.X.ROOT-SERVERS.NET IN A 100.100.100.102 79 In the .org zone: 81 foobar.org. IN NS ns.foobar.org 82 ns.foobar.org IN A 200.200.200.201 83 ns.foobar.org IN AAAA 3ffe:ffff:200:200::201 85 In the foobar.org zone: 87 www.foorbar.org IN AAAA 3ffe:ffff:200:200::202 89 Although the zone foobar.org and the root are served by an IPv6 90 server, an IPv6 only resolver can not resolve www.foobar.org because 91 there is no IPv6 server for the parent zone .org. 93 1.3 Examples of problems for an IPv4 only resolver 95 Another instance of the problem shows for an IPv4 only MTA trying to 96 send mail to someone in an IPv6 only domain which has made provision 97 to have an IPv4 reachable MX. 99 In the .org zone: 101 foobar.org. IN NS ns.foobar.org 102 ns.foobar.org IN AAAA 3ffe:ffff:200:200::201 104 3rd_party_dualstack_mail.org. IN NS ns.3rd_party_dualstack.org. 105 ns.3rd_party_dualstack.org. IN A 100.100.100.103 107 in the foobar.org zone: 109 foobar.org IN MX 10 mail6.foobar.org. 110 foobar.org IN MX 20 mail4.3rd_party_dualstack.org. 111 mail6.foobar.org. IN AAAA 3ffe:ffff:200:200::202 113 in the 3rd_party_dualstack_mail.org zone: 115 mail4.3rd_party_dualstack.org. IN A 100.100.100.104 117 An IPv4 only host cannot get the information about the IPv4 MX relay 118 mail4.3rd_party_dualstack_mail.org because the foobar.org zone is not 119 served by an IPv4 DNS server. 121 2. Fundamental requirements 123 2.1 Uniqueness of the DNS root 125 [RFC2826] requires the existence of a globally unique public name 126 space derived from a unique root. This root is valid for both IPv4 127 and IPv6. 129 -------------------------------------------------------------------- 130 Requirement 1: 132 The public DNS has a unique root valid for IPv4 & IPv6. 133 -------------------------------------------------------------------- 135 2.2 DNS should be an IP version agnostic application 137 Although DNS is regarded as a key component of the Internet 138 infrastructure, it is an application at layer 7 of OSI model and 139 should be independent from particular protocol choice at the network 140 layer. Some record type, like CNAME or MX are clearly IP version 141 agnostic. Even data like A, AAAA or PTR records contained in the DNS 142 may be relevant to particular applications requesting then regardless 143 of the IP version used during the queries. Also, [RFC2826] states, "A 144 DNS name can be passed from one party to another without altering the 145 semantic intent of the name." So, this is not because a particular 146 host can only communicate with a certain version of IP that it should 147 be prevented to query information regarding the over version of IP. 148 Another way of saying this is to say that the DNS data are 149 independent of the particular version of IP used to carry them. 151 -------------------------------------------------------------------- 152 Requirement 2: 154 Any node SHOULD be able to query any data from the DNS regardless of 155 the IP versions used for the transport of the queries and responses 156 issued by the various parties in place. 157 -------------------------------------------------------------------- 159 There is ongoing discussion to know if queries should get the same 160 answer regardless of the IP version used during the process. This, of 161 course, would not apply to records in the additional sections. See 162 [NAT-PT-ISSUES] and [INTERACTION] section 5.2.1. 164 2.3 Transition is a long journey 166 It is usually believed that transition can happen simultaneously following 167 two main scenarios. 169 - Incremental deployment on existing network. 171 This needs to be done without disturbing IPv4 service. This 172 strategy relies heavily on dual-stack nodes and tunnels. It is 173 foreseen that this scenario is likely to happen in corporate 174 networks. 176 - Large scale deployment of new infrastructure 178 This scenario envision large to very large networks where public 179 IPv4 address space is not available and private address is not 180 practical. Nodes in this scenario will very likely be IPv6-only 181 or IPv6-mostly (getting an IPv4 address only on demand). Note 182 that those networks will still need to communicate with the rest 183 of the Internet. 185 Given the two above scenarios, the requirements discussed in this 186 memo are not targeted at transitioning the DNS from IPv4 only to IPv6 187 only, but more at the transition of IPv4 only to a mixed environment, 188 where some systems will be IPv4 only, some will be IPv6 only and 189 others will be dual-stacked. 191 It is generally admitted that, the burden of transition should be 192 placed on the new IPv6 systems and their local IPv6 infrastructure. 193 Ad-hoc administrative practices such as a local dual stack resolver 194 or locally Local dual stack resolver or locally administered NAT-PT 195 translator [RFC2766] could enable networks where some dual stacks 196 node are available to query IPv4 only DNS servers. (Note that NAT-PT 197 would have to be modified for that purpose as it translate AAAA 198 queries into A queries, see [NAT-PT-ISSUES].) Administrative 199 practices requiring any zone served by IPv6 only servers to be also 200 served by IPv4 servers would enable IPv4 only resolvers to perform 201 DNS queries for those zones. 203 However, the requirements described here are looking at solving the 204 long term problem. Although dual stack networks will be common in the 205 early days of transition, IPv6 only networks would eventually be a 206 reality and solutions describe above would not be practical. 208 -------------------------------------------------------------------- 209 Requirement 3: 211 A global approach IS REQUIRED to enable networks operating with only 212 one version of IP to query zones of the public DNS that are only 213 served by systems operating only with the over version of IP. 214 -------------------------------------------------------------------- 216 The choice and the details of this approach are beyond the scope of 217 this document and should be discussed in the DNSop and DNSext working 218 groups. It can be the case that communication can be achieved via a 219 set of agreed administrative procedures. It can be also the case that 220 a general purpose, ubiquitous translator will be the right thing or 221 that a DNS specific solution must be developed. If new pieces of 222 protocols are needed in the resolvers, due to the extraordinary 223 amount of time it takes to define then, implement them, test them, 224 ship them into existing products and get them deployed, works should 225 start as soon as possible. 227 3. Global approach requirements 229 Even though communication has to work both ways, it is not strictly 230 necessary to use the same technique in each direction. That is, it is 231 perfectly acceptable to havew two different approaches, one to enable 232 IPv4 only hosts to query IPv6 only DNS servers and one for IPv6 only 233 hosts to query IPv4 only DNS servers. It is also possible that part 234 of the approach consists of a set of administrative procedures 235 required to operate DNS zones. 237 3.1 IPv4 contraints 239 Due to the very large IPv4 deployment phase, any solution that will 240 require any change either on binaries or configurations on every IPv4 241 resolvers is out of scope. 243 3.2 Scaling 245 The aproach that enable a resolver to query data from a server which 246 use a different IP version will have to be in place for a long time. 247 It will be a key part of the general IPv6 transition and will heavily 248 be used. 250 -------------------------------------------------------------------- 251 Requirement 4: 253 Whatever approach will be chosen SHOULD have good scaling properties. 254 -------------------------------------------------------------------- 256 3.3 Scaling even more 258 Auto configuration is the tendency for end systems. If the global 259 approach involves resolvers connecting to intermediary systems, 260 Resolver SHOULD have a way to discover those components. This 261 discovery mechanism SHOULD also have good scaling properties. 263 -------------------------------------------------------------------- 264 Requirement 5: 266 If the agreed approach include discovery of intermediary components, 267 the discovery mechanism SHOULD have good scaling properties. 268 -------------------------------------------------------------------- 270 3.3 Scope 272 The agreed solution SHOULD be able to bridge any zones. In 273 particular, until there is an IPv6 root name server, the 274 communication systems SHOULD be able to bridge the IPv4 root. 276 -------------------------------------------------------------------- 277 Requirement 6: 278 All zones (even the root) SHOULD be reachable. 279 -------------------------------------------------------------------- 281 3.4 Security matters 283 Being a critical piece of the Internet infrastructure, the DNS is a 284 potential value target and thus should be protected. Great care 285 should be used not to introduce new security issues. 287 -------------------------------------------------------------------- 288 Requirement 7: 290 The solution SHOULD NOT introduce new security hazards. 291 -------------------------------------------------------------------- 293 3.5 Bridging from IPv4 295 Although the details are beyond the scope of this document, it may be 296 the case that there is no general solution to allow an unmodified 297 IPv4 resolver to query an IPv6 only name server. In that would be 298 the case, the IPv4 to IPv6 communication approach could consist of an 299 operational procedure: 301 -------------------------------------------------------------------- 302 Possible operational procedure to bridge from IPv4 to IPv6: 304 Any zone SHOULD be served by at least one IPv4 DNS server. 305 -------------------------------------------------------------------- 307 4. Roadmap for DNS service in a mixed environment IPv4/IPv6 309 4.1 Communication system 311 A communication system or a set of administrative proceduresr 312 satisfying all the above requirements SHOULD be in place as early as 313 possible to allow large scale IPv6 only DNS deployment. 315 -------------------------------------------------------------------- 316 Roadmap step 1: 318 A robust, scalable communication system and/or set of administrative 319 procedures should be defined, agreed and put in place as soon as 320 possible. 321 -------------------------------------------------------------------- 323 4.2 Root name service accessible via IPv6 325 The first DNS query a caching resolver will send is directed to a 326 root name server. This, if the configuration of the bridging system 327 is derived automatically from the DNS itself, there is a strong 328 requirement to make root name service available over IPv6 transport. 329 If the configuration is derived any other way or is done manually, 330 there is a possibility to operate the system without an IPv6 331 accessible root in certain cases. However, as this document does not 332 want to preclude any particular implementation of the bridging system 333 at this point, it is highly recommended that some IPv6 enable root 334 name server be in place as early as possible. It is an important 335 step to show that IPv6 DNS deployment is possible. 337 -------------------------------------------------------------------- 338 Roadmap step 2: 340 The root SHOULD have at least one IPv6 name server. 341 -------------------------------------------------------------------- 343 4.3 TLDs servers accessible via IPv6 345 Having the capability to query a root name server using IPv6 is just 346 the first step. The next one is to query a TLD for a NS record 347 pointing to a domain name. Again, although not strictly necessary 348 from a technical perspective, it is important to make sure that some 349 TLD servers are accessible from the beginning via IPv6 so at least 350 some label strings are resolvable with IPv6 transport without 351 resorting to the mechanims described above. 353 Also note that great care should be taken when adding IPv6 glue in 354 the TLD delegation by the root. 356 -------------------------------------------------------------------- 357 Roadmap step 3: 359 Each TLD zone SHOULD have at least one IPv6 name server. 360 -------------------------------------------------------------------- 362 4.4 IPv6 glue at TLD registries. 364 Whenever glue is needed, it is necessary for domains delegated under 365 a TLD to be able to specify an IPv6 name server address to the TLD 366 registry. This is not so much a protocol issue but a management and 367 procedural issue. 369 -------------------------------------------------------------------- 370 Roadmap step 4: 372 Domains registering under TLDs SHOULD be able to specify IPv6 glue 373 wherever they are specifying IPv4 glue today. 374 -------------------------------------------------------------------- 376 4.5 Reverse path DNS servers 378 Reverse DNS queries should also be supported in IPv6, for the same 379 reasons as direct queries. Today's resolvers do reverse nibbles 380 queries under the ip6.int tree. [RFC3152] has deprecated ip6.int, 381 thus reverse DNS queries MUST be moved to ip6.arpa. So, although 382 again not strictly speaking a technical requirement, it is important 383 to have at least one server for ip6.arpa accessible via IPv6. 385 -------------------------------------------------------------------- 386 Roadmap step 5: 388 The ip6.arpa zone SHOULD have at least one IPv6 server. 389 -------------------------------------------------------------------- 391 5. Security considerations 393 Any bridging system, acting as open relay, could be misused to create 394 denial of service attacks on external DNS servers. Some provision 395 SHOULD be made in the design of those relay to deal with this issue. 397 6 Authors addresses 399 Alain Durand 400 SUN Microsystems, Inc 401 901 San Antonio Road 402 MPK17-202 403 Palo Alto, CA 94303-4900 404 USA 405 Mail: Alain.Durand@sun.com 407 Johan Ihren 408 Autonomica AB 409 Bellmansgatan 30 410 SE-118 47 Stockholm, Sweden 411 johani@autonomica.se 413 7. References 415 [INTERACTION] Baudot, A. and al, 416 "Interaction of transition mechanisms", 417 draft-ietf-ngtrans-interaction-00.txt, Work in progress. 419 [NAT-PT-ISSUES] Durand, A., 420 "Issues with NAT-PT DNS ALG in RFC2766", 421 draft-durand-natpt-dns-alg-issues-00.txt, Work in progress. 423 [RFC2026] Bradner, S., 424 "The Internet Standards Process -- Revision 3", 425 BCP 9, RFC 2026, October 1996 427 [RFC2119] Bradner, S., 428 "Key words for use in RFCs to Indicate Requirement Levels", 429 BCP 14, RFC 2119, March 199 431 [RFC3152] Bush, R., 432 "Delegation of IP6.ARPA", 433 RFC 3152, August 2001 435 [RFC2826] Internet Architecture Board, 436 "IAB Technical Comment on the Unique DNS Root", 437 RFC 2826, May 2000 439 [RFC2766] Tsirtsis, G., Srisuresh, P., 440 "Network Address Translation - Protocol Translation (NAT-PT)", 441 RFC 2766, February 2000 443 8. Changes since -03 445 - remove the name "briging system" wherever possible 446 - add a open issue on wherever or not queries should get 447 the same answer regardless of the Ip version used 448 during the process. 449 - add refereces to [NAT_PT_ISSUES] and [INTERACTION]