idnits 2.17.1 draft-huston-6to4-reverse-dns-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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 470. ** 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 : ---------------------------------------------------------------------------- == There are 3 instances 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 (October 23, 2006) is 6387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DNS' is mentioned on line 83, but not defined ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Summary: 4 errors (**), 0 flaws (~~), 4 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 October 23, 2006 5 Expires: April 26, 2007 7 6to4 Reverse DNS Delegation Specification 8 draft-huston-6to4-reverse-dns-07.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 April 26, 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 mechanism is based on a 44 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 [DNS] zone which provides the PTR records for that IP address. 84 For ordinary IPv6 addresses, the necessary DNS servers and records 85 for IPv6 reverse lookups would be maintained by the each 86 organization to which an address block is delegated; the 87 delegation path of DNS records reflects the delegation of address 88 blocks themselves. However, for IPv6 addresses beginning with the 89 6to4 address prefix, the DNS records would need to reflect IPv4 90 address delegation. Since the entire motivation of 6to4 is to 91 decouple site deployment of IPv6 from infrastructure deployment of 92 IPv6, such records cannot be expected to be present for a site 93 using 6to4 - especially for a site whose ISP did not yet support 94 IPv6 in 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 (the ip6.arpa zone is specified in [RFC3596]), 235 delegating zones only at the 48th bit position. The corresponds with 236 individual delegations related to a single /32 IPv4 address, or the 237 equivalent of a single 6to4 local site. 239 The zone files containing the end site delegations are to be operated 240 with a low TTL (configured to be a time value in the scale of hours 241 rather than days or weeks), and updates for delegation requests in 242 the 2.0.0.2.ipv6.arpa zone are to be made using dynamic DNS updates 243 [RFC2136]. 245 The delegation system is to be self-driven by clients residing within 246 6to4 networks. The 6to4 reverse DNS delegation function is to be 247 accessible only by clients using 6to4 IPv6 source addresses, and the 248 only delegation that can be managed is that corresponding to the /48 249 prefix of the IPv6 source address of the client. 251 This service is to operate the delegation management service using 252 web-based server access using Transport Layer Security (TLS) 253 [RFC4346] (accessible via a "https:" URL). This is intended to 254 ensure that the source address-driven delegation selection function 255 cannot be disrupted through proxy caching of the web server's 256 responses, and also to ensure that the delegation service cannot be 257 readily mimicked. 259 The service is to be found at https://6to4.nro.net 261 This service is implemented by web servers that are operated on a 262 dual-stack IPv4 / IPv6 server, accessible via SSL. The web server's 263 actions will be determined by the source address of the client. If 264 the client uses a 6to4 source address the server will present a 265 delegation interface for the corresponding 6to4 reverse zone. 266 Otherwise the server will provide a description of the delegation 267 process. 269 When accessed by a 6to4 source address, the interface presented by 270 the delegation service is a conventional DNS delegation interface, 271 allowing the client to enter the details of a number of DNS servers 272 for the corresponding reverse domain. The targets of the DNS 273 delegation are checked by the delegation manager using IPv4 and IPv6, 274 according to the addresses of the targets, to ensure that they are 275 responding, that they are configured consistently and are 276 authoritative for the delegated domain. If these conditions are met 277 the delegation details are entered into the zone at the primary 278 master. In order to avoid the server being used as a denial of 279 service platform the server should throttle the number of DNS 280 delegation requests made to any single IP address, and also throttle 281 the number of redelegation requests for any single 6to4 zone. 283 In other cases the system provides diagnostic information to the 284 client. 286 The benefits of this structure include a fully automated mode of 287 operation. The service delivery is on demand and the system only 288 permits self-operation of the delegation function. 290 The potential issues with this structure include: 291 o Clients inside a 6to4 site could alter the delegation details 292 without the knowledge of the site administrator. It is noted that 293 this is intended for small-scale sites. Where there are potential 294 issues of unauthorized access to this delegation function the 295 local site administrator could take appropriate access control 296 measures. 297 o IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses 298 dynamically-assigned external IPv4 interface addresses, could 299 inherit nonsense reverse entries created by previous users of the 300 dynamically assigned address. In this case the client site could 301 request delegation of the reverse zone as required. 302 o The approach does not scale efficiently, as there is the potential 303 that the flat zone file may grow considerably. However it is 304 noted that 6to4 is intended to be a transition mechanism useful 305 for a limited period of time in a limited context of isolated 306 network where other forms of tunnelled connection is not feasible. 307 It is envisaged that at some point the density of IPv6 adoption in 308 stub network would provide adequate drivers for widespread 309 adoption of native IPv6 services, obviating the need for continued 310 scaling of 6to4 support services. An estimate of the upper bound 311 of the size of the 6to4 reverse delegation zone would be of the 312 order of millions of entries. It is also noted that the value of 313 a reverse delegation is a questionable proposition and many 314 deployment environments have no form of reverse delegation. 315 o It is also conceivable that an enterprise network could decide to 316 use 6to4 internally in some form of private context, with the 317 hosts only visible in internal DNS servers. In this mechanism the 318 reverse delegation, if desired, would need to be implemented in an 319 internal private (non-delegated) corresponding zone of the 6to4 320 reverse domain space. 322 There may be circumstances where an IPv4 address controller wishes to 323 "block" the ability for users of these addresses to use this 6to4 324 scheme. Scenarios that would motivate this concern would include 325 situations when the IPv4 provider is also offering an IPv6 service, 326 and native IPv6 should be deployed instead of 6to4. In such 327 circumstances the 6to4 reverse zone operator should allow for such a 328 6to4 reverse delegation blocking function upon application to the 329 delegation zone operator. 331 For a delegation to be undertaken the following conditions should 332 hold: 333 o The 6to4 site must have configured a minimum of one primary and 334 one secondary server for the 6to4 IPv6 reverse address zone. 335 o At the time of the delegation request, the primary and secondary 336 servers must be online, reachable, correctly configured, and in a 337 mutually consistent state with respect to the 6to4 reverse zone. 338 In this context "mutually consistent" implies the same SOA RR and 339 identical NS RRSets. 340 o The 6to4 reverse delegation service will only accept delegation 341 requests associated with the 6to4 source address of the requesting 342 client. 344 The approach described here, of a fully automated system driven by 345 the site administrators of the 6to4 client networks, appears to 346 represent an appropriate match of the operational requirements of 347 managing reverse DNS domains for 6to4 addresses. 349 For maintenance of the reverse delegation zones the service maintains 350 an email contact point for each active delegation, derived from the 351 zone's SOA contact address (SOA RNAME), or explicitly entered in the 352 delegation interface. This contact point would be informed upon any 353 subsequent change of delegation details. 355 The 6to4 reverse DNS management system also undertakes a periodic 356 sweep of all active delegations, so that each delegation is checked 357 every 30 days. If the delegation fails this integrity check the 358 email contact point is informed of the problem, and a further check 359 scheduled in a further 14 days. If this second check fails, the 360 delegation is automatically removed, and a further notice is issued 361 to the contact point. 363 5. Security Considerations 365 This system offers a rudimentary level of assurance in attempting to 366 ensure that delegation requests from a 6to4 site can only direct the 367 delegation of the corresponding 6to4 reverse dns domain and no other. 369 Address-based authentication is not a very robust method from a 370 security perspective, as addresses can be readily spoofed. 371 Accordingly, reverse delegation information does not provide reliable 372 information in either validating a domain name or in validating an IP 373 address, and no conclusions should be drawn from the presence or 374 otherwise of a reverse DNS mapping for any IP address. 376 The service management interface allows a 6to4 client to insert any 377 server name as a DNS server, potentially directing the delegation 378 test system to make a DNS query to any nominated system. The server 379 throttles the number of requests made to any single IP address to 380 mitigate the attendant risk of a high volume of bogus DNS queries 381 being generated by the server. For similar reasons, the server also 382 throttles the number of redelegation requests for any single 6to4 383 zone. 385 6. IANA Considerations 387 The IANA is requested to delegate the 2.0.0.2.ip6.arpa domain 388 according to delegation instructions provided by the Internet 389 Architecture Board. 391 7. Acknowledgements 393 The author acknowledges the prior work of Keith Moore in preparing a 394 document that enumerated a number of possible approaches to undertake 395 the delegation and discovery of reverse zones. The author 396 acknowledges the assistance of George Michaelson and Andrei 397 Robachevsky in preparing this document, and Peter Koch, Pekka Savola, 398 Jun-ichiro Itojun Hagino and Catherine Meadows for their helpful 399 review comments. 401 8. References 403 8.1. Normative References 405 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 406 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 407 RFC 2136, April 1997. 409 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 410 via IPv4 Clouds", RFC 3056, February 2001. 412 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 413 "DNS Extensions to Support IP Version 6", RFC 3596, 414 October 2003. 416 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 417 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 419 8.2. Informative References 421 [6to4-dns] 422 Moore, K., "Work in progress: 6to4 and DNS", April 2003. 424 Author's Address 426 Geoff Huston 427 APNIC 429 Email: gih@apnic.net 430 URI: http://www.apnic.net 432 Full Copyright Statement 434 Copyright (C) The Internet Society (2006). 436 This document is subject to the rights, licenses and restrictions 437 contained in BCP 78, and except as set forth therein, the authors 438 retain all their rights. 440 This document and the information contained herein are provided on an 441 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 442 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 443 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 444 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 445 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 448 Intellectual Property 450 The IETF takes no position regarding the validity or scope of any 451 Intellectual Property Rights or other rights that might be claimed to 452 pertain to the implementation or use of the technology described in 453 this document or the extent to which any license under such rights 454 might or might not be available; nor does it represent that it has 455 made any independent effort to identify any such rights. Information 456 on the procedures with respect to rights in RFC documents can be 457 found in BCP 78 and BCP 79. 459 Copies of IPR disclosures made to the IETF Secretariat and any 460 assurances of licenses to be made available, or the result of an 461 attempt made to obtain a general license or permission for the use of 462 such proprietary rights by implementers or users of this 463 specification can be obtained from the IETF on-line IPR repository at 464 http://www.ietf.org/ipr. 466 The IETF invites any interested party to bring to its attention any 467 copyrights, patents or patent applications, or other proprietary 468 rights that may cover technology that may be required to implement 469 this standard. Please address the information to the IETF at 470 ietf-ipr@ietf.org. 472 Acknowledgment 474 Funding for the RFC Editor function is provided by the IETF 475 Administrative Support Activity (IASA).