idnits 2.17.1 draft-ietf-dnsop-v6-name-space-fragmentation-01.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-25) 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 348 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 20 instances of lines with control characters in the document. == 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 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 (March 2002) is 8077 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) == Missing Reference: 'RFC2119' is mentioned on line 44, but not defined == Unused Reference: 'RFC1034' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC2826' is defined on line 327, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2826 -- Possible downref: Non-RFC (?) normative reference: ref. 'DNS-proxy' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNS-opreq' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Johan Ihren 2 draft-ietf-dnsop-v6-name-space-fragmentation-01.txt Autonomica AB 3 March 2002 4 Expires in six months 6 IPv4-to-IPv6 migration and DNS namespace fragmentation 8 Status of this Memo 10 This memo provides information to the Internet community. It does 11 no specify an Internet standard of any kind. This memo is still not 12 in full conformance with all provisions of Section 10 of RFC2026. 14 The list of current Internet-Drafts can be accessed at 15 http://www.ietf.org/ietf/1id-abstracts.txt The list of 16 Internet-Draft Shadow Directories can be accessed at 17 http://www.ietf.org/shadow.html. 19 Abstract 21 This memo documents some problems forseen in transitioning from a 22 IPv4-only DNS hierarchy via a long period of mixture to an 23 IPv6-mostly situation sometime in the future. The mixture period is 24 expected to be very long, and hence design choices should very much 25 take this into account, rather than just regard the transition as a 26 relatively short period of pain. 28 The main problem with transition that this paper focus on is what 29 to do about the namespace fragmentation that may result from 30 certain DNS data only being available over one type of transport 31 (i.e. v4 or v6) which is thereby likely unavailable to hosts that 32 can cannot utilize that transport. 34 Two orthogonal issues are identified and discussed: deployment and 35 use. The former while technically simple holds certain dangers that 36 should be avoided. The "use" (as in performing DNS lookups) is much 37 more complicated, and a suggested roadmap for this is presented. 39 1. Terminology 41 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", 42 "RECOMMENDED", and "MAY", when used un uppercase, in this document 43 are to be interpreted as described in RFC 2119 [RFC2119]. 45 The phrase "v4 name server" indicates a name server available over 46 IPv4 transport. It does not imply anything about what DNS data is 47 served. Likewise, "v6 name server" indicates a name server 48 available over IPv6 transport. In general this document only 49 discuss transport issues and does not care exactly what is 50 transported. 52 2. Introduction to the problem of namespace fragmentation 54 With all DNS data only available over IPv4 transport everything is 55 simple. IPv4 resolvers can use the intended mechanism of following 56 referrals from the root and down while IPv6 resolvers have to work 57 through a "translator", i.e. they have to use a second name server 58 on a so-called "dual stack" host as a "forwarder" since they cannot 59 access the DNS data directly. This is not a scalable solution. 61 With all DNS data only available over IPv6 transport everything 62 would be equally simple, with the exception of old legacy IPv4 name 63 servers having to switch to a forwarding configuration. 65 However, the second situation will not arise in a foreseeable 66 time. Instead, it is expected that the transition will be from IPv4 67 only to a mixture of IPv4 and IPv6, with DNS data of theoretically 68 three types of availability, depending on whether it is available 69 only over IPv4 transport, only over IPv6 or both. 71 The latter is the best situation, and a major question is how to 72 ensure that it as quickly as possible becomes the norm. However, 73 while it is obvious that some DNS data will only be available over 74 v4 transport for a long time it is also obvious that it is 75 important to avoid fragmenting the namespace available to IPv4 76 only hosts. I.e. during transition it is not acceptable to break 77 the namespace that we presently have available for IPv4-only hosts. 79 2.1. Namespace fragmentation vs. unreachability. 81 Something that is presently not clear is whether it is actually 82 necessary to provide access to the "Internet namespace" as defined 83 by what is visble on the public v4 Internet also on v6 transport. 85 The reason for the unclarity is that if one regards "the Internet" 86 as the largest set of nodes that have a mutual 1-1 reachability for 87 any pair of nodes over IP and adjust the "Internet namespace" to 88 fit this set, then there is by definition no need to bridge or do 89 any special tricks (since they can all reach each other anyhow). 91 On the other hand, if we regard "the Internet" as the set of nodes 92 that share a namespace that we can refer to as "the Internet 93 namespace" regardless of whether they can all reach each other or 94 not, then we have to ensure that this namespace is accessible to 95 every node, regardless of its available transport. 97 It is out of scope for this document to make a choice between the 98 two alternatives, and therefore the rest of this document has to 99 work from the assumption that the same namespace should, if 100 possible, be made available to all nodes that claim to be part of 101 the Internet. 103 3. Consequences of deploying a "IPv6 root name server" 105 If and when a root name server that is accessible over IPv6 106 transport is deployed it will immediately for the first time become 107 possible to change IPv6-only name servers to a "native 108 configuration", i.e. to a configuration where they follow referrals 109 directly from the root (which is now accessible to them because of 110 the v6 transport). 112 However, initially they will typically quite soon get a referral to 113 a name server only available over IPv4 transport, and this will be 114 impossible to follow, since there is no common transport available. 115 Therefore the name it is trying to lookup will not get resolved and 116 the result is that the v6-only name server cannot lookup the same 117 set of domain names that its v4-only counterpart can. 119 This is fragmentation of the namespace. 121 Regardless of how this problem is handled it is important to 122 realize that at first it will only concern the namespace as viewed 123 from an IPv6-host. I.e. the IPv4 namespace will not (initially) be 124 fragmented, and an important question is possibly how to keep it 125 unfragmented. 127 4. A taxonomy of alternatives to avoid fragmentation. 129 4.1. Ignore the problem. 131 It is possible to ignore the fragmentation issue. Whether that is 132 an acceptable choice or not has to be very carefully considered. Is 133 it reasonable to allow v4 only hosts to over time lose access to 134 parts of the Internet namespace just because they are not 135 "IPv6-aware"? 137 4.2. DNS transport bridging. 139 By providing some sort of "DNS transport bridging", i.e. create a 140 fallback mechanism that enables a name server with only one type of 141 transport to reach a name server only available over the other 142 transport via some sort of proxy service it would be possible to 143 unify the DNS zones available on each transport into a common 144 namespace. 146 The general consensus is that it is not possible to design such a 147 bridging solution that works in both directions. However, it may be 148 possible to design one that allows v6 clients to query v4 servers. 149 See for instance [DNS-opreq] and [DNS-proxy] for more detailed 150 discussions. 152 4.3. Policy based avoidance of fragmentation. 154 Today there are only a limited number of DNS zones on the public 155 Internet that are only available over v6 transport, and they can 156 mostly be regarded as "experimental". However, as soon as there is 157 a root name server available over v6 transport it is reasonable to 158 expect that it will become more common with v6-only zones over 159 time. 161 Such a development would erode the Internet namespace as viewed 162 from an v4-only client. There are obviously strong reasons to find 163 a mechanism to avoid this happening. 165 4.3.1. Requirement of zone reachability over IPv4 transport. 167 To ensure that all zones remain available over IPv4 transport one 168 method would be to require that nameservers authoritative for a 169 zone as part of the zone validation process ensure that there are 170 IPv4 address records available for the name servers of any child 171 delegations within the zone). 173 I.e. the future policy could be: 175 "Every delegation point delegated to nameservers available 176 over v6 transport should have the same availability 177 requirements for servers over both v4 and v6 transport as v4 178 only zones have over v4 transport. 180 I.e. if the parent requires "multiple nameservers" for a child, 181 then the requirement becomes "multiple nameservers available over 182 v4 transport plus multiple nameservers available over v6 transport" 184 I.e. for given the domain EXAMPLE.COM with the following data 186 $ORIGIN example.com. 187 child.example.com. IN NS ns.example.com. 188 child.example.com. IN NS dns.autonomica.se. 189 ns.example.com. IN A 1.2.3.4 191 the delegation of CHILD.EXAMPLE.COM is to the two name servers 192 "ns.example.com" and "dns.autonomica.se". The first name server, 193 "ns.example.com", obviously has an IPv4 address (as shown by the 194 "glue" record on the last line). 196 However, "ns.example.com" may have additional addresses assiciated 197 with it. Also there is no way for the server loading the zone to 198 know the address(es) of "dns.autonomica.se". Therefore, to find out 199 all the publicly available addresses they have to be queried for. 201 To ensure this the authoritative server will have to lookup the 202 address records of the name servers that are part of any 203 "delegation" points in the zone. However, this operation is very 204 costly for large, delegation-dense zones and therefore it is likely 205 that compromises a la 207 * only validate on the master (this is likely always good practice) 209 * validate as an offline process (i.e. not part of the zone loading) 211 * only validate at time of delegation 213 * never validate 215 Clearly, as validation is relaxed the amount of errors will 216 increase, so the sum of pain as usual remains mostly constant. 218 4.3.2. Zone validation for non-recursive servers. 220 Non-recursive authoritative servers are name servers that run 221 without ever asking questions. A change in the zone validation 222 requirements that force them to query for the addresses of name 223 servers that are part of delegations in the zone change this, since 224 they now have to query for these addresses. 226 However, the main reason that it is important to be able to run 227 without asking questions is to avoid "caching" possibly bogus 228 answers. This need can be managed by requiring that a non recursive 229 name server throw away the looked up address information after 230 having used it for validation of the delegations in the zone. 232 4.3.3. Future requirement of zone reachability over IPv6 transport. 234 The immediate need for clarified policies for delegation is to 235 ensure that IPv4 namespace does not start to fragment. Over time, 236 however, it is reasonable to expect that it may become important to 237 add a similar requirement to IPv6 namespace. 239 I.e. an even more refined policy possible at some point in the 240 future would be: 242 "Every delegation point should have at least one name server 243 for the child zone reachable over IPv4 transport (i.e. should 244 have an A record) and at least one name server reachable over 245 IPv6 transport (i.e. should have e.g. an AAAA record)". 247 4.3.4. Implementation issues for new zone validation requirements. 249 Exactly what action should be taken when a zone does not validate 250 is not immediately clear. Immediate alternatives include: 252 a) fail the entire parent zone (the extreme case, not suggested) 254 b) load the zone but remove the delegation that failed validation 255 (also drastic, and not suggested) 257 c) load the entire zone but issue a warning message about the 258 delegation that failed validation (more reasonable) 260 Implementations should make it configurable what action to take. In 261 the case of registries that have a business realtion to the child 262 zone it is also in principle possible to work on the deployment of 263 child zones over v6 transport by cost diffentiation for the 264 customer. 266 5. Overview of suggested transition method. 268 By following the steps outlined below it will be possible to 269 transition without outages or lack of service. The assumption is 270 that the site has only v4 name servers or possibly v4 name servers 271 plus v6 name server in a forwarding configuration. All DNS data is 272 on the v4 name servers. 274 1) Do not change the method of resolution on any (recursive) name 275 server. I.e. v4 servers go to the root and follow referrals 276 while v6 servers go to their translator/forwarder which lookup 277 the name and return the end result. 279 2) Start serving authoritative DNS data on v6 transport by 280 providing name servers with v6 transport serving the zones. Add 281 v6 address information to to the zones and as glue at the parent 282 zone. Note that it is of crucial importance that the zone should 283 have the same contents regardless of whether it is the v4 284 version or the v6 version. Anything else will lead to confusion. 286 4) Wait for the announcement of the DNS root zone being available 287 from a v6 name server. 289 5) Ensure that the entire path from the root down to the domain in 290 question is reachable over both IPv4 and IPv6 transport. 292 When this is accomplished it it possible to begin a migration of 293 the lookup of selected services to be available over IPv6 294 (i.e. typically by adding a IPv6 address record, eg. AAAA record, 295 for a server of some sort). 297 6. Security Considerations 299 Much of the security of the Internet relies, often wrongly, but 300 still, on the DNS. Thus, changes to the characteristics of the DNS 301 may impact the security of Internet based services. 303 Although it will be avoided, there may be unintended consequences 304 as a result of operational deployment of RR types and protocols 305 already approved by the IETF. When or if such consequences are 306 identified, appropriate feedback will be provided to the IETF and 307 the operational community on the efficacy of said interactions. 309 7. Summary. 311 The namespace fragmentation problem is identified and examined at 312 some length. 314 A solution based upon a change in the validation method of 315 delegation points is suggested. This will both help keep the v4 316 namespace unfragmented and may also help speed up deployment of 317 DNS hierarchy in v6 space. 319 9. References 321 [RFC1034] Domain names - concepts and facilities. 322 P.V. Mockapetris. 324 [RFC1035] Domain names - implementation and specification. 325 P.V. Mockapetris. 327 [RFC2826] IAB Technical Comment on th Unique DNS Root 329 [DNS-proxy] draft-durand-dns-proxy-00.txt 330 Alain Durand 332 [DNS-opreq] draft-ietf-ngtrans-dns-ops-req-02.txt 333 Alain Durand 335 A. Authors' Address 337 Johan Ihren 338 Autonomica 339 Bellmansgatan 30 340 SE-118 47 Stockholm, Sweden 341 johani@autonomica.se