idnits 2.17.1 draft-huston-6to4-reverse-dns-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (April 14, 2004) is 7317 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft Telstra 4 Expires: October 13, 2004 April 14, 2004 6 6to4 Reverse DNS Delegation 7 draft-huston-6to4-reverse-dns-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on October 13, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This memo describes a potential mechanism for entering a description 38 of DNS servers which provide "reverse lookup" of 6to4 addresses into 39 the 6to4 reverse zone file. The proposed mechanism is a conventional 40 DNS delegation interface, allowing the client to enter the details of 41 a number of DNS servers for the delegated domain. The client is 42 authenticated by its source address and is authorised to use the 43 function if its IPv6 /48 address prefix corresponds to the requested 44 delegation point. 46 1. Introduction 48 6to4 [1] defines a mechanism for allowing isolated IPv6 sites to 49 communicate using IPv6 over the public IPv4 Internet. This is 50 achieved through the use of a dedicated IPv6 global unicast address 51 prefix. A 6to4 'router' can use its IPv4 address value in conjunction 52 with this global prefix to create a local IPv6 site prefix. Local 53 IPv6 hosts use this site prefix to form their local IPv6 address. 55 This address structure allows any site that is connected to the IPv4 56 Internet the ability to use IPv6 via automatically created IPv6 over 57 IPv4 tunnels. The advantage of this approach is that it allows the 58 piecemeal deployment of IPv6 using tunnels to traverse IPv4 network 59 segments. A local site can connect to a IPv6 network without 60 necessarily obtaining IPv6 services from its adjacent upstream 61 network provider. 63 As noted in [3], the advantage of this approach is that: "it 64 decouples deployment of IPv6 by the core of the network (e.g. 65 Internet Service Providers or ISPs) from deployment of IPv6 at the 66 edges (e.g. customer sites), allowing each site or ISP to deploy IPv6 67 support in its own time frame according to its own priorities. With 68 6to4, the edges may communicate with one another using IPv6 even if 69 one or more of their ISPs do not yet provide native IPv6 service." 71 The particular question here is the task of setting up a set of 72 delegations that allows "reverse lookups" for this address space. 74 "[This] requires that there be a delegation path for the IP 75 address being queried, from the DNS root to the servers for the 76 DNA zone which provides the PTR records for that IP address. For 77 ordinary IPv6 addresses, the necessary DNS servers and records for 78 IPv6 reverse lookups would be maintained by the each organization 79 to which an address block is delegated; the delegation path of DNS 80 records reflects the delegation of address blocks themselves. 81 However, for IPv6 addresses beginning with the 6to4 address 82 prefix, the DNS records would need to reflect IPv4 address 83 delegation. Since the entire motivation of 6to4 is to decouple 84 site deployment of IPv6 from infrastructure deployment of IPv6, 85 such records cannot be expected to be present for a site using 86 6to4 - especially for a site whose ISP did not yet support IPv6 in 87 any form." [3] 89 The desired characteristics of a reverse lookup delegation mechanism 90 are that it: 91 * is deployable with minimal overhead or tool development 92 * has no impact on existing DNS software and existing DNS 93 operations 94 * performs name lookup efficiently 95 * does not compromise any DNS security functions 97 2. Potential Approaches 99 There are a number of approaches to this problem, ranging from a 100 conventional explicit delegation structure to various forms of 101 modified server behaviours that attempt to guess the location of non- 102 delegated servers for fragments of this address space. These 103 approaches have been explored in some detail in terms of their 104 advantages and drawbacks in [3], so only a summary of these 105 approaches will be provided here. 107 2.1 Conventional Address Delegation 109 The problem with this form of delegation is the anticipated piecemeal 110 deployment of 6to4 sites. The reason why a site would use 6to4 is 111 commonly that the upstream provider does not support a IPv6 transit 112 service and the end site is using 6to4 to tunnel through to IPv6 113 connectivity. A conventional environment would have the 6to4 site 114 using provider-based IPv4 addresses. In the IPv4 "in-addr.arpa" 115 domain the local site would have an entry in the upstream's reverse 116 DNS zone file, or would have authoritative local name servers that 117 are delegated from the upstream's DNS zone. In the case of the mapped 118 IPv6 space the upstream is not using IPv6 and therefore would not be 119 expected to have a 6to4 delegation for its IPv4 address block. 121 Sub-delegations of IPv4 provider address space are not consistently 122 recorded, and any 6to4 reverse zone operator would be required to 123 undertake reverse zone delegations in the absence of reliable current 124 address assignment information, undertaking a "hop over" of the 125 upstream provider's address block. Similarly, a delegated entity may 126 need to support the same "hop over" when undertaking further 127 delegations in their reverse zone. 129 2.2 Guessing a Non-Delegated 6to4 Reverse Server 131 One way to avoid such unreliable delegations is to alter server 132 behaviour for reverse servers in this zone. Where no explicit 133 delegation information exists in the zone file the server could look 134 up the in-addr.arpa domain for the servers for the equivalent IPv4 135 address root used in the 6to4 address. These servers could then be 136 queried for the IPv6 PTR query. 138 The issues with fielding altered server behaviours for this domain 139 are not to be taken lightly, and the delegation chain for IPv4 will 140 not be the same for 6to4 in any case. An isolated 6to4 site uses a 141 single IPv4 /32 address, and it is improbable that a single address 142 would have explicit in-addr.arpa delegation. In other words it is not 143 likely that the server delegation for IPv4 would parallel that of 144 6to4. 146 2.3 Locating Local Servers at Reserved Addresses 148 Another approach uses an altered server to resolve non-delegated 6to4 149 reverse queries. The 6to4 query is decoded to recover the original 150 6to4 IP address. The site-specific part of the address is rewritten 151 to a constant value, and this value is used as the target of a lookup 152 query. This requires that a 6to4 site should reserve local addresses, 153 and configure reverse servers on these addresses. Again this is a 154 weak approach in that getting the DNS to query non-delegated 155 addresses is a case of generation of spurious traffic. 157 2.4 Synthesized Responses 159 The final approach is to synthesize an answer when no explicit 160 delegation exists. This approach would construct a pseudo host name 161 using the IPv6 query address as the seed. Given that the host name 162 has no valid forward DNS mapping, then this becomes a case of 163 transforming one invalid DNS object into another. 165 2.5 Selecting a Reasonable Approach 167 It would appear that the most reasonable approach is to support a 168 model of conventional standard delegation. The consequent task is to 169 reduce the administrative overheads in managing the zone, supporting 170 delegation of reverse zone files on a basis of providing a delegation 171 capability directly to each 6to4 site. 173 3. 6to4 Networks Address Use 175 A 6to4 client network is an isolated IPv6 network composed as a set 176 of IPv6 hosts and a dual stack (IPv4 and IPv6) local router connected 177 to the local IPv6 network and the external IPv4 network. 179 An example of a 6to4 network is as follows: 181 +-------------+ 182 IPv6-in-IPv4 packets (A)| | IPv6 packets 183 ------------------------| 6to4router |-------------------------- 184 | | | | | | | 185 +-------------+ local IPv6 clients 187 IPv4 network IPv6 network 189 Figure 1 191 The IPv4 address used as part of the generation of 6to4 addresses for 192 the local IPv6 network is the external IPv4 network (labelled '(A)' 193 in the above diagram). For example, if the interface (A) has the IPv4 194 address 192.0.2.1, then the local IPv6 clients will use a common IPv6 195 address prefix of the form 2002:{192.0.2.1}::/48 (or 196 (2002:C000:201::/48 in hex notation). All the local IPv6 clients 197 share this common /48 address prefix, irrespective of any local IPv4 198 address that such host may use if they are operating in a dual stack 199 mode. 201 An example of a 6to4 network with addressing: 203 +-------------+ 204 IPv4 network | | IPv6 network 205 -------------------| 6to4router |------------- 206 192.0.2.1| | | | | interface identifier 207 +-------------+ 1A | | local IPv6 address 208 2002:C000:201::1A 209 | | 210 1B | 211 2002:C000:201::1B 212 | 213 1C 214 2002:C000:201::1C 216 Figure 2 218 4. Delegation Administration 220 This document proposes to use a a single delegation level in the 221 2.0.0.2.ip6.arpa zone, delegating zones only at the 48th bit 222 position. The corresponds with individual delegations corresponding 223 to a /32 IPv4 address, or the equivalent of a single 6to4 local site. 225 The zone files containing the end site delegations are proposed to be 226 operated with a TTL (configured to be a time value in the scale of 227 hours rather than days or weeks), and updates from delegation 228 requests are to be made using incremental DNS updates [2]. 230 The delegation system is proposed to be self-driven by clients 231 residing within 6to4 networks. The server's delegation function is 232 proposed to be accessible only by clients using 6to4 IPv6 source 233 addresses, and the only delegation that can be managed is that 234 corresponding to the /48 prefix of the IPv6 source address of the 235 client. 237 It is proposed to operate the delegation management service using 238 secure web-based servers. This will ensure that the source address- 239 driven delegation selection function cannot be disrupted through 240 proxy caching of the server's responses. 242 It is proposed that the secure web servers be operated on a 243 dual-stack IPv4 / IPv6 server. The service is to be available on a) 244 an IPv4 address (instructions only), b) a native IPv6 address 245 (instructions plus delegation service) and c) a 6to4 address 246 (instructions plus delegation service). 248 The server's actions will be determined by the source address of the 249 client. If the client uses a 6to4 source address the server will 250 present a delegation interface for the corresponding 6to4 reverse 251 zone. Otherwise the server will provide a description of the 252 delegation process. 254 When accessed by a 6to4 source address, the interface presented by 255 the delegation server is a standard DNS delegation interface, 256 allowing the client to enter the details of a number of DNS servers 257 for the corresponding reverse domain. The delegation servers are 258 checked by the delegation manager to ensure that they are responding, 259 that they are configured consistently and are authoritative for the 260 delegated domain. If these conditions are met the delegation details 261 are entered into the primary zone. In order to avoid the server being 262 used as a denial of service platform the server should throttle the 263 number of DNS requests made to any single IP address, and also 264 throttle the number of redelegation requests for any single 6to4 265 zone. 267 In other cases the system provides diagnostic information to the 268 client. 270 The benefits of this proposed structure include a fully automated 271 mode of operation. The service delivery is on demand and the system 272 only permits self-operation of the delegation function. 274 The potential issues with this structure include: 275 o Clients inside a 6to4 site could alter the delegation details 276 without the knowledge of the site administrator. It is noted that 277 this is intended for small-scale sites. Where there are potential 278 issues of unauthorized access to this delegation function the 279 local site administrator could take appropriate access control 280 measures. 281 o IPv4 DHCP-based 6to4 sites could inherit nonsense reverse entries 282 created by previous users of the DHCP address. In this case the 283 client site could request delegation of the reverse zone as 284 required. 285 o The approach does not scale efficiently, as there is the potential 286 that the flat zone file may grow considerably. However it is noted 287 that 6to4 is intended to be a transition mechanism useful for a 288 limited period of time in a limited context of isolated network 289 where other forms of tunnelled connection is not feasible. It is 290 envisaged that at some point the density of IPv6 adoption in stub 291 network would provide adequate drivers for widespread adoption of 292 native IPv6 services, obviating the need for continued scaling of 293 6to4 support services. An estimate of the upper bound of the size 294 of the 6to4 reverse delegation zone would be of the order of 295 millions of entries. It is also noted that the value of a reverse 296 delegation is a questionable proposition and many deployment 297 environments have no form of reverse delegation. 298 o It is also conceivable that an enterprise network could decide to 299 use 6to4 internally in some form of private context, with the 300 hosts only visible in internal DNS servers. In this proposed 301 mechanism the reverse delegation, if desired, would need to be 302 implemented in an internal private (non-delegated) corresponding 303 zone of the 6to4 reverse domain space. 305 It is envisaged that there may be circumstances with an IPv4 address 306 controller wishes to "block" the ability for "children" to use this 307 6to4 scheme. It is envisaged that scenarios that would motivate this 308 concern would include when the IPv4 provider is also offering an IPv6 309 service, and native IPv6 should be deployed instead of 6to4. In such 310 circumstances the 2002 zone operator should allow for such a 311 delegation blocking function upon application to the delegation zone 312 operator. 314 For a delegation to be undertaken the following must hold: 315 o The 6to4 site must have connectivity to the global IPv6 network 316 o The 6to4 site must have configured a minimum of one primary and 317 one secondary server for the 6to4 IPv6 reverse address zone. 318 o At the time of the delegation request, the primary and secondary 319 servers should be online, reachable, correctly configured, and in 320 a mutually consistent state with respect to the 6to4 reverse zone. 321 o The delegation server will only accept delegation requests 322 associated with the 6to4 source address of the requesting client. 324 The approach suggested here, of a fully automated system driven by 325 the site administrators of the 6to4 client networks, appears to 326 represent an appropriate match the requirements of reverse DNS 327 domains. 329 For maintenance of the reverse delegation zones it is proposed to 330 maintain an email contact point for each active delegation, derived 331 from the zone's SOA contact address, or explicitly entered in the 332 delegation interface. This contact point would be informed upon any 333 subsequent change of delegation details. 335 The management system will also undertake a periodic sweep of all 336 active delegations, so that each delegation is checked every 30 days. 337 If the delegation fails this integrity check the email contact point 338 is informed of the problem, and a further check scheduled in a 339 further 14 days. If this second check fails, the delegation is 340 automatically removed, and a further notice is issued to the contact 341 point. 343 5. Security Considerations 345 The system proposed here offers a moderate level of assurance in 346 attempting to ensure that a 6to4 site can only direct the delegation 347 of the corresponding reverse domain and no other. 349 Address-based authentication is not useful in a security sense. 350 Accordingly, reverse delegation information does not provide useful 351 information in either validating a domain name or in validating an IP 352 address, and that no conclusions should be drawn from the presence or 353 otherwise of a reverse mapping for any IP address. 355 The service management interface allows a 6to4 client to insert any 356 server name as a DNS server, potentially directing the server to make 357 a DNS query to any nominated system. The server should throttle the 358 number of requests made to any single IP address to mitigate this 359 risk of a high volume of bogus DNS queries being generated by the 360 server. For similar reasons, the server should also throttle the 361 number of redelegation requests for any single 6to4 zone. 363 6. Acknowledgements 365 The author acknowledges the prior work of Keith Moore in preparing a 366 document that enumerated a number of possible approaches to undertake 367 the delegation and discovery of reverse zones. The author 368 acknowledges the assistance of George Michealson and Andrei 369 Robachevsky in preparing this document, and Pekka Savola and 370 Jun-ichiro itojun Hagino for their review comments. 372 Normative References 374 [1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 375 Clouds", RFC 3056, February 2001. 377 Informative References 379 [2] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 380 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 381 1997. 383 [3] Moore, K., "Work in progress: 6to4 and DNS", April 2003. 385 Author's Address 387 Geoff Huston 388 Telstra 390 Intellectual Property Statement 392 The IETF takes no position regarding the validity or scope of any 393 intellectual property or other rights that might be claimed to 394 pertain to the implementation or use of the technology described in 395 this document or the extent to which any license under such rights 396 might or might not be available; neither does it represent that it 397 has made any effort to identify any such rights. Information on the 398 IETF's procedures with respect to rights in standards-track and 399 standards-related documentation can be found in BCP-11. Copies of 400 claims of rights made available for publication and any assurances of 401 licenses to be made available, or the result of an attempt made to 402 obtain a general license or permission for the use of such 403 proprietary rights by implementors or users of this specification can 404 be obtained from the IETF Secretariat. 406 The IETF invites any interested party to bring to its attention any 407 copyrights, patents or patent applications, or other proprietary 408 rights which may cover technology that may be required to practice 409 this standard. Please address the information to the IETF Executive 410 Director. 412 Full Copyright Statement 414 Copyright (C) The Internet Society (2004). All Rights Reserved. 416 This document and translations of it may be copied and furnished to 417 others, and derivative works that comment on or otherwise explain it 418 or assist in its implementation may be prepared, copied, published 419 and distributed, in whole or in part, without restriction of any 420 kind, provided that the above copyright notice and this paragraph are 421 included on all such copies and derivative works. However, this 422 document itself may not be modified in any way, such as by removing 423 the copyright notice or references to the Internet Society or other 424 Internet organizations, except as needed for the purpose of 425 developing Internet standards in which case the procedures for 426 copyrights defined in the Internet Standards process must be 427 followed, or as required to translate it into languages other than 428 English. 430 The limited permissions granted above are perpetual and will not be 431 revoked by the Internet Society or its successors or assignees. 433 This document and the information contained herein is provided on an 434 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 435 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 436 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 437 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 438 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 440 Acknowledgment 442 Funding for the RFC Editor function is currently provided by the 443 Internet Society.