GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5158

Network Working Group G. Huston Request for Comments: 5158 APNIC Category: Informational March 2008

             6to4 Reverse DNS Delegation Specification

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Abstract

 This memo describes the service mechanism for entering a delegation
 of DNS servers that provide reverse lookup of 6to4 IPv6 addresses
 into the 6to4 reverse zone file.  The mechanism is based on a
 conventional DNS delegation service interface, allowing the service
 client to enter the details of a number of DNS servers for the
 delegated domain.  In the context of a 6to4 reverse delegation, the
 client is primarily authenticated by its source address used in the
 delegation request, and is authorized to use the function if its IPv6
 address prefix corresponds to an address from within the requested
 6to4 delegation address block.

Huston Informational [Page 1] RFC 5158 6to4 Reverse DNS March 2008

1. Introduction

 6to4 [RFC3056] defines a mechanism for allowing isolated IPv6 sites
 to communicate using IPv6 over the public IPv4 Internet.  This is
 achieved through the use of a dedicated IPv6 global unicast address
 prefix.  A 6to4 'router' can use its IPv4 address value in
 conjunction with this global prefix to create a local IPv6 site
 prefix.  Local IPv6 hosts use this site prefix to form their local
 IPv6 address.
 This address structure allows any site that is connected to the IPv4
 Internet the ability to use IPv6 via automatically created IPv6 over
 IPv4 tunnels.  The advantage of this approach is that it allows the
 piecemeal deployment of IPv6 using tunnels to traverse IPv4 network
 segments.  A local site can connect to an IPv6 network without
 necessarily obtaining IPv6 services from its adjacent upstream
 network provider.
 As noted in [6to4-dns], the advantage of this approach is that: "it
 decouples deployment of IPv6 by the core of the network (e.g.
 Internet Service Providers or ISPs) from deployment of IPv6 at the
 edges (e.g. customer sites), allowing each site or ISP to deploy IPv6
 support in its own time frame according to its own priorities.  With
 6to4, the edges may communicate with one another using IPv6 even if
 one or more of their ISPs do not yet provide native IPv6 service."
 The particular question here is the task of setting up a set of
 delegations that allows "reverse lookups" for this address space.
    "[This] requires that there be a delegation path for the IP
    address being queried, from the DNS root to the servers for the
    [DNS] zone which provides the PTR records for that IP address.
    For ordinary IPv6 addresses, the necessary DNS servers and records
    for IPv6 reverse lookups would be maintained by the each
    organization to which an address block is delegated; the
    delegation path of DNS records reflects the delegation of address
    blocks themselves.  However, for IPv6 addresses beginning with the
    6to4 address prefix, the DNS records would need to reflect IPv4
    address delegation.  Since the entire motivation of 6to4 is to
    decouple site deployment of IPv6 from infrastructure deployment of
    IPv6, such records cannot be expected to be present for a site
    using 6to4 - especially for a site whose ISP did not yet support
    IPv6 in any form." [6to4-dns]

Huston Informational [Page 2] RFC 5158 6to4 Reverse DNS March 2008

 The desired characteristics of a reverse lookup delegation mechanism
 are that it:
  • is deployable with minimal overhead or tool development
  • has no impact on existing DNS software and existing DNS

operations

  • performs name lookup efficiently
  • does not compromise any DNS security functions

2. Potential Approaches

 There are a number of approaches to this problem, ranging from a
 conventional explicit delegation structure to various forms of
 modified server behaviors that attempt to guess the location of non-
 delegated servers for fragments of this address space.  These
 approaches have been explored in some detail in terms of their
 advantages and drawbacks in [6to4-dns], so only a summary of these
 approaches will be provided here.

2.1. Conventional Address Delegation

 The problem with this form of delegation is the anticipated piecemeal
 deployment of 6to4 sites.  The reason why an end site would use 6to4
 is commonly that the upstream Internet Service Provider does not
 support an IPv6 transit service and the end site is using 6to4 to
 tunnel through to IPv6 connectivity.  A conventional end site
 environment of this form would have the end site using provider-based
 IPv4 addresses, where the end site's IPv4 address is a more specific
 address block drawn from the upstream provider's address block, and
 the end site would have an entry in the upstream provider's reverse
 DNS zone file, or it would have authoritative local name servers that
 are delegated from the upstream provider's DNS zone.  In the case of
 the 6to4 mapped IPv6 space, the upstream may not be providing any
 IPv6-based services at all, and therefore would not be expected to
 have a 6to4 reverse DNS delegation for its IPv4 address block.  The
 general observation is that 6to4 IPv6 reverse DNS delegations cannot
 necessarily always precisely match the corresponding IPv4 reverse DNS
 delegations.

Huston Informational [Page 3] RFC 5158 6to4 Reverse DNS March 2008

 Sub-delegations of IPv4 provider address space are not consistently
 recorded, and any 6to4 reverse zone operator would be required to
 undertake reverse zone delegations in the absence of reliable current
 address assignment information, undertaking a "hop over" of the
 upstream provider's address block.  Similarly, a delegated entity may
 need to support the same "hop over" when undertaking further
 delegations in their reverse zone.

2.2. Guessing a Non-Delegated 6to4 Reverse Server

 One way to avoid such unreliable delegations is to alter server
 behavior for reverse servers in this zone.  Where no explicit
 delegation information exists in the zone file, the server could look
 up the in-addr.arpa domain for the servers for the equivalent IPv4
 address root used in the 6to4 address.  These servers could then be
 queried for the IPv6 PTR query.
 The issues with fielding altered server behaviors for this domain are
 not to be taken lightly, and the delegation chain for IPv4 will not
 be the same for 6to4 in any case.  An isolated 6to4 site uses a
 single IPv4 /32 address, and it is improbable that a single address
 would have explicit in-addr.arpa delegation.  In other words, it is
 not likely that the delegation for IPv4 would parallel that of 6to4.

2.3. Locating Local Servers at Reserved Addresses

 Another approach uses an altered server to resolve non-delegated 6to4
 reverse queries.  The 6to4 query is decoded to recover the original
 6to4 IP address.  The site-specific part of the address is rewritten
 to a constant value, and this value is used as the target of a lookup
 query.  This requires that a 6to4 site should reserve local
 addresses, and configure reverse servers on these addresses.  Again,
 this is a weak approach in that getting the DNS to query non-
 delegated addresses is a case of generation of spurious traffic.

2.4. Synthesized Responses

 The final approach considered here is to synthesize an answer when no
 explicit delegation exists.  This approach would construct a pseudo
 host name using the IPv6 query address as the seed.  Given that the
 host name has no valid forward DNS mapping, then this becomes a case
 of transforming one invalid DNS object into another.

Huston Informational [Page 4] RFC 5158 6to4 Reverse DNS March 2008

2.5. Selecting a Reasonable Approach

 It would appear that the most reasonable approach from this set of
 potential candidates is to support a model of conventional standard
 delegation.  The consequent task is to reduce the administrative
 overheads in managing the zone, supporting delegation of reverse zone
 files on a basis of providing a delegation capability directly to
 each 6to4 site.

3. 6to4 Networks Address Use

 A 6to4 client network is an isolated IPv6 network composed as a set
 of IPv6 hosts and a dual stack (IPv4 and IPv6) local router connected
 to the local IPv6 network and the external IPv4 network.
 An example of a 6to4 network is as follows:
                         +-------------+
 IPv6-in-IPv4 packets (A)|             |     IPv6 packets
 ------------------------| 6to4router  |--------------------------
                         |             |    |  |   |     |   |
                         +-------------+   local IPv6 clients
    IPv4 network                              IPv6 network
                               Figure 1
 The IPv4 address used as part of the generation of 6to4 addresses for
 the local IPv6 network is that of the external IPv4 network interface
 address (labelled '(A)' in the above diagram).  For example, if the
 interface (A) has the IPv4 address 192.0.2.1, then the local IPv6
 clients will use a common IPv6 address prefix of the form 2002:
 {192.0.2.1}::/48 (or (2002:C000:201::/48 in hex notation).  All the
 local IPv6 clients share this common /48 address prefix, irrespective
 of any local IPv4 address that such host may use if they are
 operating in a dual stack mode.

Huston Informational [Page 5] RFC 5158 6to4 Reverse DNS March 2008

 An example of a 6to4 network with addressing:
                     +-------------+
     IPv4 network (A)|             | IPv6 network
  -------------------| 6to4router  |-------------
            192.0.2.1|             |    |  |   | interface identifier
                     +-------------+   1A  |   | local IPv6 address
                                       2002:C000:201::1A
                                           |   |
                                           1B  |
                                           2002:C000:201::1B
                                               |
                                               1C
                                               2002:C000:201::1C
                               Figure 2

4. Delegation Administration

 This specification uses a single delegation level in the
 2.0.0.2.ip6.arpa zone (the ip6.arpa zone is specified in [RFC3596]),
 delegating zones only at the 48th bit position.  This corresponds
 with individual delegations related to a single /32 IPv4 address, or
 the equivalent of a single 6to4 local site.
 The zone files containing the end site delegations are to be operated
 with a low TTL (configured to be a time value in the scale of hours
 rather than days or weeks), and updates for delegation requests in
 the 2.0.0.2.ipv6.arpa zone are to be made using dynamic DNS updates
 [RFC2136].
 The delegation system is to be self-driven by clients residing within
 6to4 networks.  The 6to4 reverse DNS delegation function is to be
 accessible only by clients using 6to4 IPv6 source addresses, and the
 only delegation that can be managed is that corresponding to the /48
 prefix of the IPv6 source address of the client.
 This service is to operate the delegation management service using
 web-based server access using Transport Layer Security (TLS)
 [RFC4346] (accessible via a "https:" URL).  This is intended to
 ensure that the source address-driven delegation selection function
 cannot be disrupted through proxy caching of the web server's
 responses, and also to ensure that the delegation service cannot be
 readily mimicked.
 The service is to be found at https://6to4.nro.net

Huston Informational [Page 6] RFC 5158 6to4 Reverse DNS March 2008

 This service is implemented by web servers that are operated on a
 dual-stack IPv4 / IPv6 server, accessible via SSL.  The web server's
 actions will be determined by the source address of the client.  If
 the client uses a 6to4 source address, the server will present a
 delegation interface for the corresponding 6to4 reverse zone.
 Otherwise, the server will provide a description of the delegation
 process.
 When accessed by a 6to4 source address, the interface presented by
 the delegation service is a conventional DNS delegation interface,
 allowing the client to enter the details of a number of DNS servers
 for the corresponding reverse domain.  The targets of the DNS
 delegation are checked by the delegation manager using IPv4 and IPv6,
 according to the addresses of the targets, to ensure that they are
 responding, that they are configured consistently, and are
 authoritative for the delegated domain.  If these conditions are met,
 the delegation details are entered into the zone at the primary
 master.  In order to avoid the server being used as a denial of
 service platform, the server should throttle the number of DNS
 delegation requests made to any single IP address, and also throttle
 the number of redelegation requests for any single 6to4 zone.
 In other cases the system provides diagnostic information to the
 client.
 The benefits of this structure include a fully automated mode of
 operation.  The service delivery is on demand and the system only
 permits self-operation of the delegation function.
 The potential issues with this structure include:
 o  Clients inside a 6to4 site could alter the delegation details
    without the knowledge of the site administrator.  It is noted that
    this is intended for small-scale sites.  Where there are potential
    issues of unauthorized access to this delegation function, the
    local site administrator could take appropriate access control
    measures.
 o  IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses
    dynamically-assigned external IPv4 interface addresses, could
    inherit nonsense reverse entries created by previous users of the
    dynamically assigned address.  In this case, the client site could
    request delegation of the reverse zone as required.  More
    generally, given the potentially for inheritance of 'stale'
    reverse DNS information in this context, in those cases where the
    issues of potential inheritance of 'stale' reverse DNS information
    is a concern, it is recommended that a 6to4 site either use a
    static IPv4 address in preference to a dynamically-assigned

Huston Informational [Page 7] RFC 5158 6to4 Reverse DNS March 2008

    address, or ensure that the reverse delegation information is
    updated using the service mechanism described here upon each
    dynamic address assignment event.
 o  The approach does not scale efficiently, as there is the potential
    that the flat zone file may grow considerably.  However, it is
    noted that 6to4 is intended to be a transition mechanism useful
    for a limited period of time in a limited context of an isolated
    network where other forms of a tunnelled connection is not
    feasible.  It is envisaged that at some point the density of IPv6
    adoption in stub network would provide adequate drivers for
    widespread adoption of native IPv6 services, obviating the need
    for continued scaling of 6to4 support services.  An estimate of
    the upper bound of the size of the 6to4 reverse delegation zone
    would be of the order of millions of entries.  It is also noted
    that the value of a reverse delegation is a questionable
    proposition and many deployment environments have no form of
    reverse delegation.
 o  It is also conceivable that an enterprise network could decide to
    use 6to4 internally in some form of private context, with the
    hosts only visible in internal DNS servers.  In this mechanism the
    reverse delegation, if desired, would need to be implemented in an
    internal private (non-delegated) corresponding zone of the 6to4
    reverse domain space.
 There may be circumstances where an IPv4 address controller wishes to
 "block" the ability for users of these addresses to use this 6to4
 scheme.  Scenarios that would motivate this concern would include
 situations when the IPv4 provider is also offering an IPv6 service,
 and native IPv6 should be deployed instead of 6to4.  In such
 circumstances the 6to4 reverse zone operator should allow for such a
 6to4 reverse delegation blocking function upon application to the
 delegation zone operator.
 For a delegation to be undertaken the following conditions should
 hold:
 o  The 6to4 site must have configured a minimum of one primary and
    one secondary server for the 6to4 IPv6 reverse address zone.
 o  At the time of the delegation request, the primary and secondary
    servers must be online, reachable, correctly configured, and in a
    mutually consistent state with respect to the 6to4 reverse zone.
    In this context, "mutually consistent" implies the same SOA RR and
    identical NS RRSets.

Huston Informational [Page 8] RFC 5158 6to4 Reverse DNS March 2008

 o  The 6to4 reverse delegation service will only accept delegation
    requests associated with the 6to4 source address of the requesting
    client.
 The approach described here, of a fully automated system driven by
 the site administrators of the 6to4 client networks, appears to
 represent an appropriate match of the operational requirements of
 managing reverse DNS domains for 6to4 addresses.
 For maintenance of the reverse delegation zones the service maintains
 an email contact point for each active delegation, derived from the
 zone's SOA contact address (SOA RNAME), or explicitly entered in the
 delegation interface.  This contact point would be informed upon any
 subsequent change of delegation details.
 The 6to4 reverse DNS management system also undertakes a periodic
 sweep of all active delegations, so that each delegation is checked
 every 30 days.  If the delegation fails this integrity check the
 email contact point is informed of the problem, and a further check
 is scheduled for 14 days later.  If this second check fails, the
 delegation is automatically removed, and a further notice is issued
 to the contact point.

5. Security Considerations

 This system offers a rudimentary level of assurance in attempting to
 ensure that delegation requests from a 6to4 site can only direct the
 delegation of the corresponding 6to4 reverse DNS domain and no other.
 Address-based authentication is not a very robust method from a
 security perspective, as addresses can be readily spoofed.
 Accordingly, reverse delegation information does not provide reliable
 information in either validating a domain name or in validating an IP
 address, and no conclusions should be drawn from the presence or
 otherwise of a reverse DNS mapping for any IP address.
 The service management interface allows a 6to4 client to insert any
 server name as a DNS server, potentially directing the delegation
 test system to make a DNS query to any nominated system.  The server
 throttles the number of requests made to any single IP address to
 mitigate the attendant risk of a high volume of bogus DNS queries
 being generated by the server.  For similar reasons, the server also
 throttles the number of redelegation requests for any single 6to4
 zone.
 For a general threat analysis of 6to4, especially the additional risk
 of address spoofing in 2002::/16, see [RFC3964].

Huston Informational [Page 9] RFC 5158 6to4 Reverse DNS March 2008

 Section 4 notes that the local site administrator could take
 appropriate access control measures to prevent clients inside a 6to4
 site performing unauthorized changes to the delegation details.  This
 may be in the form of a firewall configuration, regarding control of
 access to the service from the interior of a 6to4 site, or a similar
 mechanism that enforces local access policies.

6. IANA Considerations

 The IANA has delegated the 2.0.0.2.ip6.arpa domain according to
 delegation instructions provided by the Internet Architecture Board.

7. Acknowledgements

 The author acknowledges the prior work of Keith Moore in preparing a
 document that enumerated a number of possible approaches to undertake
 the delegation and discovery of reverse zones.  The author
 acknowledges the assistance of George Michaelson and Andrei
 Robachevsky in preparing this document, and Peter Koch, Pekka Savola,
 Jun-ichiro Itojun Hagino, and Catherine Meadows for their helpful
 review comments.

8. References

8.1. Normative References

 [RFC2136]   Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
             "Dynamic Updates in the Domain Name System (DNS UPDATE)",
             RFC 2136, April 1997.
 [RFC3056]   Carpenter, B. and K. Moore, "Connection of IPv6 Domains
             via IPv4 Clouds", RFC 3056, February 2001.
 [RFC3596]   Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
             "DNS Extensions to Support IP Version 6", RFC 3596,
             October 2003.
 [RFC4346]   Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.1", RFC 4346, April 2006.

8.2. Informative References

 [6to4-dns]  Moore, K., "6to4 and DNS", Work in Progress, April 2003.
 [RFC3964]   Savola, P. and C. Patel, "Security Considerations for
             6to4", RFC 3964, December 2004.

Huston Informational [Page 10] RFC 5158 6to4 Reverse DNS March 2008

Author's Address

 Geoff Huston
 APNIC
 EMail: gih@apnic.net
 URI:   http://www.apnic.net

Huston Informational [Page 11] RFC 5158 6to4 Reverse DNS March 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Huston Informational [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5158.txt · Last modified: 2008/03/05 18:28 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki