idnits 2.17.1 draft-huston-6to4-reverse-dns-03.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 416. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == 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 (October 5, 2004) is 7136 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission G. Huston 2 Internet-Draft APNIC 3 Expires: April 5, 2005 October 5, 2004 5 6to4 Reverse DNS Delegation 6 draft-huston-6to4-reverse-dns-03.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 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 20 Internet-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 5, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 This memo describes a potential mechanism for entering a description 42 of DNS servers which provide "reverse lookup" of 6to4 addresses into 43 the 6to4 reverse zone file. The proposed mechanism is a conventional 44 DNS delegation interface, allowing the client to enter the details of 45 a number of DNS servers for the delegated domain. The client is 46 authenticated by its source address and is authorised to use the 47 function if its IPv6 /48 address prefix corresponds to the requested 48 delegation point. 50 1. Introduction 52 6to4 [1] defines a mechanism for allowing isolated IPv6 sites to 53 communicate using IPv6 over the public IPv4 Internet. This is 54 achieved through the use of a dedicated IPv6 global unicast address 55 prefix. A 6to4 'router' can use its IPv4 address value in 56 conjunction with this global prefix to create a local IPv6 site 57 prefix. Local IPv6 hosts use this site prefix to form their local 58 IPv6 address. 60 This address structure allows any site that is connected to the IPv4 61 Internet the ability to use IPv6 via automatically created IPv6 over 62 IPv4 tunnels. The advantage of this approach is that it allows the 63 piecemeal deployment of IPv6 using tunnels to traverse IPv4 network 64 segments. A local site can connect to a IPv6 network without 65 necessarily obtaining IPv6 services from its adjacent upstream 66 network provider. 68 As noted in [3], the advantage of this approach is that: "it 69 decouples deployment of IPv6 by the core of the network (e.g. 70 Internet Service Providers or ISPs) from deployment of IPv6 at the 71 edges (e.g. customer sites), allowing each site or ISP to deploy 72 IPv6 support in its own time frame according to its own priorities. 73 With 6to4, the edges may communicate with one another using IPv6 even 74 if one or more of their ISPs do not yet provide native IPv6 service." 76 The particular question here is the task of setting up a set of 77 delegations that allows "reverse lookups" for this address space. 79 "[This] requires that there be a delegation path for the IP 80 address being queried, from the DNS root to the servers for the 81 DNA zone which provides the PTR records for that IP address. For 82 ordinary IPv6 addresses, the necessary DNS servers and records for 83 IPv6 reverse lookups would be maintained by the each organization 84 to which an address block is delegated; the delegation path of DNS 85 records reflects the delegation of address blocks themselves. 86 However, for IPv6 addresses beginning with the 6to4 address 87 prefix, the DNS records would need to reflect IPv4 address 88 delegation. Since the entire motivation of 6to4 is to decouple 89 site deployment of IPv6 from infrastructure deployment of IPv6, 90 such records cannot be expected to be present for a site using 91 6to4 - especially for a site whose ISP did not yet support IPv6 in 92 any form." [3] 94 The desired characteristics of a reverse lookup delegation mechanism 95 are that it: 96 * is deployable with minimal overhead or tool development 97 * has no impact on existing DNS software and existing DNS 98 operations 99 * performs name lookup efficiently 100 * does not compromise any DNS security functions 102 2. Potential Approaches 104 There are a number of approaches to this problem, ranging from a 105 conventional explicit delegation structure to various forms of 106 modified server behaviours that attempt to guess the location of non- 107 delegated servers for fragments of this address space. These 108 approaches have been explored in some detail in terms of their 109 advantages and drawbacks in [3], so only a summary of these 110 approaches will be provided here. 112 2.1 Conventional Address Delegation 114 The problem with this form of delegation is the anticipated piecemeal 115 deployment of 6to4 sites. The reason why a site would use 6to4 is 116 commonly that the upstream provider does not support a IPv6 transit 117 service and the end site is using 6to4 to tunnel through to IPv6 118 connectivity. A conventional environment would have the 6to4 site 119 using provider-based IPv4 addresses. In the IPv4 "in-addr.arpa" 120 domain the local site would have an entry in the upstream's reverse 121 DNS zone file, or would have authoritative local name servers that 122 are delegated from the upstream's DNS zone. In the case of the 123 mapped IPv6 space the upstream is not using IPv6 and therefore would 124 not be expected to have a 6to4 delegation for its IPv4 address block. 126 Sub-delegations of IPv4 provider address space are not consistently 127 recorded, and any 6to4 reverse zone operator would be required to 128 undertake reverse zone delegations in the absence of reliable current 129 address assignment information, undertaking a "hop over" of the 130 upstream provider's address block. Similarly, a delegated entity may 131 need to support the same "hop over" when undertaking further 132 delegations in their reverse zone. 134 2.2 Guessing a Non-Delegated 6to4 Reverse Server 136 One way to avoid such unreliable delegations is to alter server 137 behaviour for reverse servers in this zone. Where no explicit 138 delegation information exists in the zone file the server could look 139 up the in-addr.arpa domain for the servers for the equivalent IPv4 140 address root used in the 6to4 address. These servers could then be 141 queried for the IPv6 PTR query. 143 The issues with fielding altered server behaviours for this domain 144 are not to be taken lightly, and the delegation chain for IPv4 will 145 not be the same for 6to4 in any case. An isolated 6to4 site uses a 146 single IPv4 /32 address, and it is improbable that a single address 147 would have explicit in-addr.arpa delegation. In other words it is 148 not likely that the server delegation for IPv4 would parallel that of 149 6to4. 151 2.3 Locating Local Servers at Reserved Addresses 153 Another approach uses an altered server to resolve non-delegated 6to4 154 reverse queries. The 6to4 query is decoded to recover the original 155 6to4 IP address. The site-specific part of the address is rewritten 156 to a constant value, and this value is used as the target of a lookup 157 query. This requires that a 6to4 site should reserve local 158 addresses, and configure reverse servers on these addresses. Again 159 this is a weak approach in that getting the DNS to query 160 non-delegated addresses is a case of generation of spurious traffic. 162 2.4 Synthesized Responses 164 The final approach is to synthesize an answer when no explicit 165 delegation exists. This approach would construct a pseudo host name 166 using the IPv6 query address as the seed. Given that the host name 167 has no valid forward DNS mapping, then this becomes a case of 168 transforming one invalid DNS object into another. 170 2.5 Selecting a Reasonable Approach 172 It would appear that the most reasonable approach is to support a 173 model of conventional standard delegation. The consequent task is to 174 reduce the administrative overheads in managing the zone, supporting 175 delegation of reverse zone files on a basis of providing a delegation 176 capability directly to each 6to4 site. 178 3. 6to4 Networks Address Use 180 A 6to4 client network is an isolated IPv6 network composed as a set 181 of IPv6 hosts and a dual stack (IPv4 and IPv6) local router connected 182 to the local IPv6 network and the external IPv4 network. 184 An example of a 6to4 network is as follows: 186 +-------------+ 187 IPv6-in-IPv4 packets (A)| | IPv6 packets 188 ------------------------| 6to4router |-------------------------- 189 | | | | | | | 190 +-------------+ local IPv6 clients 192 IPv4 network IPv6 network 193 Figure 1 195 The IPv4 address used as part of the generation of 6to4 addresses for 196 the local IPv6 network is the external IPv4 network (labelled '(A)' 197 in the above diagram). For example, if the interface (A) has the 198 IPv4 address 192.0.2.1, then the local IPv6 clients will use a common 199 IPv6 address prefix of the form 2002:{192.0.2.1}::/48 (or 200 (2002:C000:201::/48 in hex notation). All the local IPv6 clients 201 share this common /48 address prefix, irrespective of any local IPv4 202 address that such host may use if they are operating in a dual stack 203 mode. 205 An example of a 6to4 network with addressing: 207 +-------------+ 208 IPv4 network | | IPv6 network 209 -------------------| 6to4router |------------- 210 192.0.2.1| | | | | interface identifier 211 +-------------+ 1A | | local IPv6 address 212 2002:C000:201::1A 213 | | 214 1B | 215 2002:C000:201::1B 216 | 217 1C 218 2002:C000:201::1C 220 Figure 2 222 4. Delegation Administration 224 This document proposes to use a a single delegation level in the 225 2.0.0.2.ip6.arpa zone, delegating zones only at the 48th bit 226 position. The corresponds with individual delegations corresponding 227 to a /32 IPv4 address, or the equivalent of a single 6to4 local site. 229 The zone files containing the end site delegations are proposed to be 230 operated with a TTL (configured to be a time value in the scale of 231 hours rather than days or weeks), and updates from delegation 232 requests are to be made using incremental DNS updates [2]. 234 The delegation system is proposed to be self-driven by clients 235 residing within 6to4 networks. The server's delegation function is 236 proposed to be accessible only by clients using 6to4 IPv6 source 237 addresses, and the only delegation that can be managed is that 238 corresponding to the /48 prefix of the IPv6 source address of the 239 client. 241 It is proposed to operate the delegation management service using 242 secure web-based servers. This will ensure that the source address- 243 driven delegation selection function cannot be disrupted through 244 proxy caching of the server's responses. 246 The URL of this service is https://6to4.nro.net 248 It is proposed that the secure web servers be operated on a 249 dual-stack IPv4 / IPv6 server. The service is to be available on a) 250 an IPv4 address (instructions only), b) a native IPv6 address 251 (instructions plus delegation service) and c) a 6to4 address 252 (instructions plus delegation service). 254 The server's actions will be determined by the source address of the 255 client. If the client uses a 6to4 source address the server will 256 present a delegation interface for the corresponding 6to4 reverse 257 zone. Otherwise the server will provide a description of the 258 delegation process. 260 When accessed by a 6to4 source address, the interface presented by 261 the delegation server is a standard DNS delegation interface, 262 allowing the client to enter the details of a number of DNS servers 263 for the corresponding reverse domain. The delegation servers are 264 checked by the delegation manager to ensure that they are responding, 265 that they are configured consistently and are authoritative for the 266 delegated domain. If these conditions are met the delegation details 267 are entered into the primary zone. In order to avoid the server 268 being used as a denial of service platform the server should throttle 269 the number of DNS requests made to any single IP address, and also 270 throttle the number of redelegation requests for any single 6to4 271 zone. 273 In other cases the system provides diagnostic information to the 274 client. 276 The benefits of this proposed structure include a fully automated 277 mode of operation. The service delivery is on demand and the system 278 only permits self-operation of the delegation function. 280 The potential issues with this structure include: 281 o Clients inside a 6to4 site could alter the delegation details 282 without the knowledge of the site administrator. It is noted that 283 this is intended for small-scale sites. Where there are potential 284 issues of unauthorized access to this delegation function the 285 local site administrator could take appropriate access control 286 measures. 287 o IPv4 DHCP-based 6to4 sites could inherit nonsense reverse entries 288 created by previous users of the DHCP address. In this case the 289 client site could request delegation of the reverse zone as 290 required. 291 o The approach does not scale efficiently, as there is the potential 292 that the flat zone file may grow considerably. However it is 293 noted that 6to4 is intended to be a transition mechanism useful 294 for a limited period of time in a limited context of isolated 295 network where other forms of tunnelled connection is not feasible. 296 It is envisaged that at some point the density of IPv6 adoption in 297 stub network would provide adequate drivers for widespread 298 adoption of native IPv6 services, obviating the need for continued 299 scaling of 6to4 support services. An estimate of the upper bound 300 of the size of the 6to4 reverse delegation zone would be of the 301 order of millions of entries. It is also noted that the value of 302 a reverse delegation is a questionable proposition and many 303 deployment environments have no form of reverse delegation. 304 o It is also conceivable that an enterprise network could decide to 305 use 6to4 internally in some form of private context, with the 306 hosts only visible in internal DNS servers. In this proposed 307 mechanism the reverse delegation, if desired, would need to be 308 implemented in an internal private (non-delegated) corresponding 309 zone of the 6to4 reverse domain space. 311 It is envisaged that there may be circumstances with an IPv4 address 312 controller wishes to "block" the ability for "children" to use this 313 6to4 scheme. It is envisaged that scenarios that would motivate this 314 concern would include when the IPv4 provider is also offering an IPv6 315 service, and native IPv6 should be deployed instead of 6to4. In such 316 circumstances the 2002 zone operator should allow for such a 317 delegation blocking function upon application to the delegation zone 318 operator. 320 For a delegation to be undertaken the following must hold: 321 o The 6to4 site must have connectivity to the global IPv6 network 322 o The 6to4 site must have configured a minimum of one primary and 323 one secondary server for the 6to4 IPv6 reverse address zone. 324 o At the time of the delegation request, the primary and secondary 325 servers should be online, reachable, correctly configured, and in 326 a mutually consistent state with respect to the 6to4 reverse zone. 327 o The delegation server will only accept delegation requests 328 associated with the 6to4 source address of the requesting client. 330 The approach suggested here, of a fully automated system driven by 331 the site administrators of the 6to4 client networks, appears to 332 represent an appropriate match the requirements of reverse DNS 333 domains. 335 For maintenance of the reverse delegation zones it is proposed to 336 maintain an email contact point for each active delegation, derived 337 from the zone's SOA contact address, or explicitly entered in the 338 delegation interface. This contact point would be informed upon any 339 subsequent change of delegation details. 341 The management system will also undertake a periodic sweep of all 342 active delegations, so that each delegation is checked every 30 days. 343 If the delegation fails this integrity check the email contact point 344 is informed of the problem, and a further check scheduled in a 345 further 14 days. If this second check fails, the delegation is 346 automatically removed, and a further notice is issued to the contact 347 point. 349 5. Security Considerations 351 The system proposed here offers a moderate level of assurance in 352 attempting to ensure that a 6to4 site can only direct the delegation 353 of the corresponding reverse domain and no other. 355 Address-based authentication is not useful in a security sense. 356 Accordingly, reverse delegation information does not provide useful 357 information in either validating a domain name or in validating an IP 358 address, and that no conclusions should be drawn from the presence or 359 otherwise of a reverse mapping for any IP address. 361 The service management interface allows a 6to4 client to insert any 362 server name as a DNS server, potentially directing the server to make 363 a DNS query to any nominated system. The server should throttle the 364 number of requests made to any single IP address to mitigate this 365 risk of a high volume of bogus DNS queries being generated by the 366 server. For similar reasons, the server should also throttle the 367 number of redelegation requests for any single 6to4 zone. 369 6. Acknowledgements 371 The author acknowledges the prior work of Keith Moore in preparing a 372 document that enumerated a number of possible approaches to undertake 373 the delegation and discovery of reverse zones. The author 374 acknowledges the assistance of George Michaelson and Andrei 375 Robachevsky in preparing this document, and Pekka Savola and 376 Jun-ichiro itojun Hagino for their review comments. 378 7 References 380 [1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 381 Clouds", RFC 3056, February 2001. 383 [2] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 384 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 385 1997. 387 [3] Moore, K., "Work in progress: 6to4 and DNS", April 2003. 389 Author's Address 391 Geoff Huston 392 APNIC 394 Intellectual Property Statement 396 The IETF takes no position regarding the validity or scope of any 397 Intellectual Property Rights or other rights that might be claimed to 398 pertain to the implementation or use of the technology described in 399 this document or the extent to which any license under such rights 400 might or might not be available; nor does it represent that it has 401 made any independent effort to identify any such rights. Information 402 on the procedures with respect to rights in RFC documents can be 403 found in BCP 78 and BCP 79. 405 Copies of IPR disclosures made to the IETF Secretariat and any 406 assurances of licenses to be made available, or the result of an 407 attempt made to obtain a general license or permission for the use of 408 such proprietary rights by implementers or users of this 409 specification can be obtained from the IETF on-line IPR repository at 410 http://www.ietf.org/ipr. 412 The IETF invites any interested party to bring to its attention any 413 copyrights, patents or patent applications, or other proprietary 414 rights that may cover technology that may be required to implement 415 this standard. Please address the information to the IETF at 416 ietf-ipr@ietf.org. 418 Disclaimer of Validity 420 This document and the information contained herein are provided on an 421 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 422 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 423 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 424 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 425 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 426 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 428 Copyright Statement 430 Copyright (C) The Internet Society (2004). This document is subject 431 to the rights, licenses and restrictions contained in BCP 78, and 432 except as set forth therein, the authors retain all their rights. 434 Acknowledgment 436 Funding for the RFC Editor function is currently provided by the 437 Internet Society.