idnits 2.17.1 draft-huston-6to4-reverse-dns-06.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 453. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (August 1, 2006) is 6477 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft APNIC 4 Intended status: Informational August 1, 2006 5 Expires: February 2, 2007 7 6to4 Reverse DNS Delegation Specification 8 draft-huston-6to4-reverse-dns-06.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 2, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This memo describes the service mechanism for entering a delegation 42 of DNS servers which provide reverse lookup of 6to4 IPv6 addresses 43 into the 6to4 reverse zone file. The proposed mechanism is based on 44 a conventional DNS delegation service interface, allowing the service 45 client to enter the details of a number of DNS servers for the 46 delegated domain. In the context of a 6to4 reverse delegation, the 47 client is primarily authenticated by its source address used in the 48 delegation request, and is authorised to use the function if its IPv6 49 address prefix corresponds to an address from within the requested 50 6to4 delegation address block. 52 1. Introduction 54 6to4 [RFC3056] defines a mechanism for allowing isolated IPv6 sites 55 to communicate using IPv6 over the public IPv4 Internet. This is 56 achieved through the use of a dedicated IPv6 global unicast address 57 prefix. A 6to4 'router' can use its IPv4 address value in 58 conjunction with this global prefix to create a local IPv6 site 59 prefix. Local IPv6 hosts use this site prefix to form their local 60 IPv6 address. 62 This address structure allows any site that is connected to the IPv4 63 Internet the ability to use IPv6 via automatically created IPv6 over 64 IPv4 tunnels. The advantage of this approach is that it allows the 65 piecemeal deployment of IPv6 using tunnels to traverse IPv4 network 66 segments. A local site can connect to a IPv6 network without 67 necessarily obtaining IPv6 services from its adjacent upstream 68 network provider. 70 As noted in [6to4-dns], the advantage of this approach is that: "it 71 decouples deployment of IPv6 by the core of the network (e.g. 72 Internet Service Providers or ISPs) from deployment of IPv6 at the 73 edges (e.g. customer sites), allowing each site or ISP to deploy IPv6 74 support in its own time frame according to its own priorities. With 75 6to4, the edges may communicate with one another using IPv6 even if 76 one or more of their ISPs do not yet provide native IPv6 service." 78 The particular question here is the task of setting up a set of 79 delegations that allows "reverse lookups" for this address space. 81 "[This] requires that there be a delegation path for the IP 82 address being queried, from the DNS root to the servers for the 83 DNA zone which provides the PTR records for that IP address. For 84 ordinary IPv6 addresses, the necessary DNS servers and records for 85 IPv6 reverse lookups would be maintained by the each organization 86 to which an address block is delegated; the delegation path of DNS 87 records reflects the delegation of address blocks themselves. 88 However, for IPv6 addresses beginning with the 6to4 address 89 prefix, the DNS records would need to reflect IPv4 address 90 delegation. Since the entire motivation of 6to4 is to decouple 91 site deployment of IPv6 from infrastructure deployment of IPv6, 92 such records cannot be expected to be present for a site using 93 6to4 - especially for a site whose ISP did not yet support IPv6 in 94 any form." [6to4-dns] 96 The desired characteristics of a reverse lookup delegation mechanism 97 are that it: 98 * is deployable with minimal overhead or tool development 99 * has no impact on existing DNS software and existing DNS 100 operations 101 * performs name lookup efficiently 102 * does not compromise any DNS security functions 104 2. Potential Approaches 106 There are a number of approaches to this problem, ranging from a 107 conventional explicit delegation structure to various forms of 108 modified server behaviours that attempt to guess the location of non- 109 delegated servers for fragments of this address space. These 110 approaches have been explored in some detail in terms of their 111 advantages and drawbacks in [6to4-dns], so only a summary of these 112 approaches will be provided here. 114 2.1. Conventional Address Delegation 116 The problem with this form of delegation is the anticipated piecemeal 117 deployment of 6to4 sites. The reason why an end site would use 6to4 118 is commonly that the upstream Internet Service Provider does not 119 support an IPv6 transit service and the end site is using 6to4 to 120 tunnel through to IPv6 connectivity. A conventional end site 121 environment of this form would have the end site using provider-based 122 IPv4 addresses, where the end site's IPv4 address is a more specific 123 address block drawn from the upstream provider's address block and 124 the end site would have an entry in the upstream provider's reverse 125 DNS zone file, or would have authoritative local name servers that 126 are delegated from the upstream provider's DNS zone. In the case of 127 the 6to4 mapped IPv6 space the upstream may not be providing any 128 IPv6-based services at all, and therefore would not be expected to 129 have a 6to4 reverse DNS delegation for its IPv4 address block. The 130 general observation is that 6to4 IPv6 reverse DNS delegations cannot 131 necessarily always precisely match the corresponding IPv4 reverse DNS 132 delegations. 134 Sub-delegations of IPv4 provider address space are not consistently 135 recorded, and any 6to4 reverse zone operator would be required to 136 undertake reverse zone delegations in the absence of reliable current 137 address assignment information, undertaking a "hop over" of the 138 upstream provider's address block. Similarly, a delegated entity may 139 need to support the same "hop over" when undertaking further 140 delegations in their reverse zone. 142 2.2. Guessing a Non-Delegated 6to4 Reverse Server 144 One way to avoid such unreliable delegations is to alter server 145 behaviour for reverse servers in this zone. Where no explicit 146 delegation information exists in the zone file the server could look 147 up the in-addr.arpa domain for the servers for the equivalent IPv4 148 address root used in the 6to4 address. These servers could then be 149 queried for the IPv6 PTR query. 151 The issues with fielding altered server behaviours for this domain 152 are not to be taken lightly, and the delegation chain for IPv4 will 153 not be the same for 6to4 in any case. An isolated 6to4 site uses a 154 single IPv4 /32 address, and it is improbable that a single address 155 would have explicit in-addr.arpa delegation. In other words it is 156 not likely that the delegation for IPv4 would parallel that of 6to4. 158 2.3. Locating Local Servers at Reserved Addresses 160 Another approach uses an altered server to resolve non-delegated 6to4 161 reverse queries. The 6to4 query is decoded to recover the original 162 6to4 IP address. The site-specific part of the address is rewritten 163 to a constant value, and this value is used as the target of a lookup 164 query. This requires that a 6to4 site should reserve local 165 addresses, and configure reverse servers on these addresses. Again 166 this is a weak approach in that getting the DNS to query non- 167 delegated addresses is a case of generation of spurious traffic. 169 2.4. Synthesized Responses 171 The final approach considered here is to synthesize an answer when no 172 explicit delegation exists. This approach would construct a pseudo 173 host name using the IPv6 query address as the seed. Given that the 174 host name has no valid forward DNS mapping, then this becomes a case 175 of transforming one invalid DNS object into another. 177 2.5. Selecting a Reasonable Approach 179 It would appear that the most reasonable approach from this set of 180 potential candidates is to support a model of conventional standard 181 delegation. The consequent task is to reduce the administrative 182 overheads in managing the zone, supporting delegation of reverse zone 183 files on a basis of providing a delegation capability directly to 184 each 6to4 site. 186 3. 6to4 Networks Address Use 188 A 6to4 client network is an isolated IPv6 network composed as a set 189 of IPv6 hosts and a dual stack (IPv4 and IPv6) local router connected 190 to the local IPv6 network and the external IPv4 network. 192 An example of a 6to4 network is as follows: 194 +-------------+ 195 IPv6-in-IPv4 packets (A)| | IPv6 packets 196 ------------------------| 6to4router |-------------------------- 197 | | | | | | | 198 +-------------+ local IPv6 clients 200 IPv4 network IPv6 network 202 Figure 1 204 The IPv4 address used as part of the generation of 6to4 addresses for 205 the local IPv6 network is that of the external IPv4 network interface 206 address (labelled '(A)' in the above diagram). For example, if the 207 interface (A) has the IPv4 address 192.0.2.1, then the local IPv6 208 clients will use a common IPv6 address prefix of the form 2002: 209 {192.0.2.1}::/48 (or (2002:C000:201::/48 in hex notation). All the 210 local IPv6 clients share this common /48 address prefix, irrespective 211 of any local IPv4 address that such host may use if they are 212 operating in a dual stack mode. 214 An example of a 6to4 network with addressing: 216 +-------------+ 217 IPv4 network (A)| | IPv6 network 218 -------------------| 6to4router |------------- 219 192.0.2.1| | | | | interface identifier 220 +-------------+ 1A | | local IPv6 address 221 2002:C000:201::1A 222 | | 223 1B | 224 2002:C000:201::1B 225 | 226 1C 227 2002:C000:201::1C 229 Figure 2 231 4. Delegation Administration 233 This specification uses a a single delegation level in the 234 2.0.0.2.ip6.arpa zone, delegating zones only at the 48th bit 235 position. The corresponds with individual delegations corresponding 236 to a /32 IPv4 address, or the equivalent of a single 6to4 local site. 238 The zone files containing the end site delegations are proposed to be 239 operated with a low TTL (configured to be a time value in the scale 240 of hours rather than days or weeks), and updates for delegation 241 requests are to be made using dynamic DNS updates [RFC2136]. 243 The delegation system is proposed to be self-driven by clients 244 residing within 6to4 networks. The 6to4 reverse DNS delegation 245 function is proposed to be accessible only by clients using 6to4 IPv6 246 source addresses, and the only delegation that can be managed is that 247 corresponding to the /48 prefix of the IPv6 source address of the 248 client. 250 It is proposed to operate the delegation management service using 251 web-based server access using secure socket layer (SSL) services 252 (accessible via a "https:" URL). This is intended to ensure that the 253 source address-driven delegation selection function cannot be 254 disrupted through proxy caching of the web server's responses, and 255 also to ensure that the delegation service cannot be readily mimiced. 257 The service is to be found at https://6to4.nro.net 259 This service is implemented by web servers that are operated on a 260 dual-stack IPv4 / IPv6 server, accessible via SSL. The web server's 261 actions will be determined by the source address of the client. If 262 the client uses a 6to4 source address the server will present a 263 delegation interface for the corresponding 6to4 reverse zone. 264 Otherwise the server will provide a description of the delegation 265 process. 267 When accessed by a 6to4 source address, the interface presented by 268 the delegation service is a conventional DNS delegation interface, 269 allowing the client to enter the details of a number of DNS servers 270 for the corresponding reverse domain. The targets of the DNS 271 delegation are checked by the delegation manager using IPv4 and IPv6, 272 accordinging to the addresses of the targets, to ensure that they are 273 responding, that they are configured consistently and are 274 authoritative for the delegated domain. If these conditions are met 275 the delegation details are entered into the zone at the primary 276 master. In order to avoid the server being used as a denial of 277 service platform the server should throttle the number of DNS 278 delegation requests made to any single IP address, and also throttle 279 the number of redelegation requests for any single 6to4 zone. 281 In other cases the system provides diagnostic information to the 282 client. 284 The benefits of this structure include a fully automated mode of 285 operation. The service delivery is on demand and the system only 286 permits self-operation of the delegation function. 288 The potential issues with this structure include: 289 o Clients inside a 6to4 site could alter the delegation details 290 without the knowledge of the site administrator. It is noted that 291 this is intended for small-scale sites. Where there are potential 292 issues of unauthorized access to this delegation function the 293 local site administrator could take appropriate access control 294 measures. 295 o IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses 296 dynamically-assigned external IPv4 interface addresses, could 297 inherit nonsense reverse entries created by previous users of the 298 dynamically assigned address. In this case the client site could 299 request delegation of the reverse zone as required. 300 o The approach does not scale efficiently, as there is the potential 301 that the flat zone file may grow considerably. However it is 302 noted that 6to4 is intended to be a transition mechanism useful 303 for a limited period of time in a limited context of isolated 304 network where other forms of tunnelled connection is not feasible. 305 It is envisaged that at some point the density of IPv6 adoption in 306 stub network would provide adequate drivers for widespread 307 adoption of native IPv6 services, obviating the need for continued 308 scaling of 6to4 support services. An estimate of the upper bound 309 of the size of the 6to4 reverse delegation zone would be of the 310 order of millions of entries. It is also noted that the value of 311 a reverse delegation is a questionable proposition and many 312 deployment environments have no form of reverse delegation. 313 o It is also conceivable that an enterprise network could decide to 314 use 6to4 internally in some form of private context, with the 315 hosts only visible in internal DNS servers. In this proposed 316 mechanism the reverse delegation, if desired, would need to be 317 implemented in an internal private (non-delegated) corresponding 318 zone of the 6to4 reverse domain space. 320 There may be circumstances where an IPv4 address controller wishes to 321 "block" the ability for users of these addresses to use this 6to4 322 scheme. Scenarios that would motivate this concern would include 323 situations when the IPv4 provider is also offering an IPv6 service, 324 and native IPv6 should be deployed instead of 6to4. In such 325 circumstances the 6to4 reverse zone operator should allow for such a 326 6to4 reverse delegation blocking function upon application to the 327 delegation zone operator. 329 For a delegation to be undertaken the following conditions should 330 hold: 332 o The 6to4 site must have configured a minimum of one primary and 333 one secondary server for the 6to4 IPv6 reverse address zone. 334 o At the time of the delegation request, the primary and secondary 335 servers must be online, reachable, correctly configured, and in a 336 mutually consistent state with respect to the 6to4 reverse zone. 337 In this context "mutually consistent" implies the same SOA RR and 338 identical NS RRSets. 339 o The 6to4 reverse delegation service will only accept delegation 340 requests associated with the 6to4 source address of the requesting 341 client. 343 The approach described here, of a fully automated system driven by 344 the site administrators of the 6to4 client networks, appears to 345 represent an appropriate match of the operational requirements of 346 managing reverse DNS domains for 6to4 addresses. 348 For maintenance of the reverse delegation zones the service maintains 349 an email contact point for each active delegation, derived from the 350 zone's SOA contact address (SOA RNAME), or explicitly entered in the 351 delegation interface. This contact point would be informed upon any 352 subsequent change of delegation details. 354 The 6to4 reverse DNS management system also undertakes a periodic 355 sweep of all active delegations, so that each delegation is checked 356 every 30 days. If the delegation fails this integrity check the 357 email contact point is informed of the problem, and a further check 358 scheduled in a further 14 days. If this second check fails, the 359 delegation is automatically removed, and a further notice is issued 360 to the contact point. 362 5. Security Considerations 364 This system offers a rudimentary level of assurance in attempting to 365 ensure that delegation requests from a 6to4 site can only direct the 366 delegation of the corresponding 6to4 reverse dns domain and no other. 368 Address-based authentication is not a very robust method from a 369 security perspective, as addresses can be readily spoofed. 370 Accordingly, reverse delegation information does not provide reliable 371 information in either validating a domain name or in validating an IP 372 address, and no conclusions should be drawn from the presence or 373 otherwise of a reverse DNS mapping for any IP address. 375 The service management interface allows a 6to4 client to insert any 376 server name as a DNS server, potentially directing the delegation 377 test system to make a DNS query to any nominated system. The server 378 throttles the number of requests made to any single IP address to 379 mitigate the attendant risk of a high volume of bogus DNS queries 380 being generated by the server. For similar reasons, the server also 381 throttles the number of redelegation requests for any single 6to4 382 zone. 384 6. Acknowledgements 386 The author acknowledges the prior work of Keith Moore in preparing a 387 document that enumerated a number of possible approaches to undertake 388 the delegation and discovery of reverse zones. The author 389 acknowledges the assistance of George Michaelson and Andrei 390 Robachevsky in preparing this document, and Peter Koch, Pekka Savola, 391 Jun-ichiro Itojun Hagino and Catherine Meadows for their helpful 392 review comments. 394 7. References 396 7.1. Normative References 398 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 399 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 400 RFC 2136, April 1997. 402 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 403 via IPv4 Clouds", RFC 3056, February 2001. 405 7.2. Informative References 407 [6to4-dns] 408 Moore, K., "Work in progress: 6to4 and DNS", April 2003. 410 Author's Address 412 Geoff Huston 413 APNIC 415 Full Copyright Statement 417 Copyright (C) The Internet Society (2006). 419 This document is subject to the rights, licenses and restrictions 420 contained in BCP 78, and except as set forth therein, the authors 421 retain all their rights. 423 This document and the information contained herein are provided on an 424 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 425 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 426 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 427 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 428 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 429 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 431 Intellectual Property 433 The IETF takes no position regarding the validity or scope of any 434 Intellectual Property Rights or other rights that might be claimed to 435 pertain to the implementation or use of the technology described in 436 this document or the extent to which any license under such rights 437 might or might not be available; nor does it represent that it has 438 made any independent effort to identify any such rights. Information 439 on the procedures with respect to rights in RFC documents can be 440 found in BCP 78 and BCP 79. 442 Copies of IPR disclosures made to the IETF Secretariat and any 443 assurances of licenses to be made available, or the result of an 444 attempt made to obtain a general license or permission for the use of 445 such proprietary rights by implementers or users of this 446 specification can be obtained from the IETF on-line IPR repository at 447 http://www.ietf.org/ipr. 449 The IETF invites any interested party to bring to its attention any 450 copyrights, patents or patent applications, or other proprietary 451 rights that may cover technology that may be required to implement 452 this standard. Please address the information to the IETF at 453 ietf-ipr@ietf.org. 455 Acknowledgment 457 Funding for the RFC Editor function is provided by the IETF 458 Administrative Support Activity (IASA).