1 Network Working Group                                          A. Durand   
    2 Request for Comments: 3901                        SUN Microsystems, Inc.   
    3 BCP: 91                                                         J. Ihren   
    4 Category: Best Current Practice                               Autonomica   
    5                                                           September 2004   
    6                                                                            
    7                                                                            
    8                DNS IPv6 Transport Operational Guidelines                   
    9                                                                            
   10 Status of this Memo                                                        
   11                                                                            
   12    This document specifies an Internet Best Current Practices for the      
   13    Internet Community, and requests discussion and suggestions for         
   14    improvements.  Distribution of this memo is unlimited.                  
   15                                                                            
   16 Copyright Notice                                                           
   17                                                                            
   18    Copyright (C) The Internet Society (2004).                              
   19                                                                            
   20 Abstract                                                                   
   21                                                                            
   22    This memo provides guidelines and Best Current Practice for operating   
   23    DNS in a world where queries and responses are carried in a mixed       
   24    environment of IPv4 and IPv6 networks.                                  
   25                                                                            
   26 1.  Introduction to the Problem of Name Space Fragmentation:               
   27     following the referral chain                                           
   28                                                                            
   29    A resolver that tries to look up a name starts out at the root, and     
   30    follows referrals until it is referred to a name server that is         
   31    authoritative for the name.  If somewhere down the chain of referrals   
   32    it is referred to a name server that is only accessible over a          
   33    transport which the resolver cannot use, the resolver is unable to      
   34    finish the task.                                                        
   35                                                                            
   36    When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is   
   37    only a matter of time until this starts to happen.  The complete DNS    
   38    hierarchy then starts to fragment into a graph where authoritative      
   39    name servers for certain nodes are only accessible over a certain       
   40    transport.  The concern is that a resolver using only a particular      
   41    version of IP and querying information about another node using the     
   42    same version of IP can not do it because somewhere in the chain of      
   43    servers accessed during the resolution process, one or more of them     
   44    will only be accessible with the other version of IP.                   
   45                                                                            
   46    With all DNS data only available over IPv4 transport everything is      
   47    simple.  IPv4 resolvers can use the intended mechanism of following     
   48    referrals from the root and down while IPv6 resolvers have to work      
   49                                                                            
   50                                                                            
   51                                                                            
   52 Durand & Ihren           Best Current Practice                  [Page 1]   

   53 RFC 3901             DNS IPv6 Transport Guidelines        September 2004   
   54                                                                            
   55                                                                            
   56    through a "translator", i.e., they have to use a recursive name         
   57    server on a so-called "dual stack" host as a "forwarder" since they     
   58    cannot access the DNS data directly.                                    
   59                                                                            
   60    With all DNS data only available over IPv6 transport everything would   
   61    be equally simple, with the exception of IPv4 recursive name servers    
   62    having to switch to a forwarding configuration.                         
   63                                                                            
   64    However, the second situation will not arise in the foreseeable         
   65    future.  Instead, the transition will be from IPv4 only to a mixture    
   66    of IPv4 and IPv6, with three categories of DNS data depending on        
   67    whether the information is available only over IPv4 transport, only     
   68    over IPv6 or both.                                                      
   69                                                                            
   70    Having DNS data available on both transports is the best situation.     
   71    The major question is how to ensure that it becomes the norm as         
   72    quickly as possible.  However, while it is obvious that some DNS data   
   73    will only be available over v4 transport for a long time it is also     
   74    obvious that it is important to avoid fragmenting the name space        
   75    available to IPv4 only hosts.  For example, during transition it is     
   76    not acceptable to break the name space that we presently have           
   77    available for IPv4-only hosts.                                          
   78                                                                            
   79 2.  Terminology                                                            
   80                                                                            
   81    The phrase "IPv4 name server" indicates a name server available over    
   82    IPv4 transport.  It does not imply anything about what DNS [1,2] data   
   83    is served.  Likewise, "IPv6 [4,5,6] name server" indicates a name       
   84    server available over IPv6 transport.  The phrase "dual-stack name      
   85    server" indicates a name server that is actually configured to run      
   86    both protocols, IPv4 and IPv6, and not merely a server running on a     
   87    system capable of running both but actually configured to run only      
   88    one.                                                                    
   89                                                                            
   90 3.  Policy Based Avoidance of Name Space Fragmentation                     
   91                                                                            
   92    Today there are only a few DNS "zones" on the public Internet that      
   93    are available over IPv6 transport, and most of them can be regarded     
   94    as "experimental".  However, as soon as the root and top level          
   95    domains are available over IPv6 transport, it is reasonable to expect   
   96    that it will become more common to have zones served by IPv6 servers.   
   97                                                                            
   98    Having those zones served only by IPv6-only name server would not be    
   99    a good development, since this will fragment the previously             
  100    unfragmented IPv4 name space and there are strong reasons to find a     
  101    mechanism to avoid it.                                                  
  102                                                                            
  103                                                                            
  104                                                                            
  105                                                                            
  106                                                                            
  107 Durand & Ihren           Best Current Practice                  [Page 2]   

  108 RFC 3901             DNS IPv6 Transport Guidelines        September 2004   
  109                                                                            
  110                                                                            
  111    The recommended approach to maintain name space continuity is to use    
  112    administrative policies, as described in the next section.              
  113                                                                            
  114 4.  DNS IPv6 Transport recommended Guidelines                              
  115                                                                            
  116    In order to preserve name space continuity, the following               
  117    administrative policies are recommended:                                
  118                                                                            
  119       - every recursive name server SHOULD be either IPv4-only or dual     
  120         stack,                                                             
  121                                                                            
  122          This rules out IPv6-only recursive servers.  However, one might   
  123          design configurations where a chain of IPv6-only name server      
  124          forward queries to a set of dual stack recursive name server      
  125          actually performing those recursive queries.                      
  126                                                                            
  127       - every DNS zone SHOULD be served by at least one IPv4-reachable     
  128         authoritative name server.                                         
  129                                                                            
  130          This rules out DNS zones served only by IPv6-only authoritative   
  131          name servers.                                                     
  132                                                                            
  133    Note: zone validation processes SHOULD ensure that there is at least    
  134    one IPv4 address record available for the name servers of any child     
  135    delegations within the zone.                                            
  136                                                                            
  137 5.  Security Considerations                                                
  138                                                                            
  139    The guidelines described in this memo introduce no new security         
  140    considerations into the DNS protocol or associated operational          
  141    scenarios.                                                              
  142                                                                            
  143 6.  Acknowledgment                                                         
  144                                                                            
  145    This document is the result of many conversations that happened in      
  146    the DNS community at IETF and elsewhere since 2001.  During that        
  147    period of time, a number of Internet drafts have been published to      
  148    clarify various aspects of the issues at stake.  This document          
  149    focuses on the conclusion of those discussions.                         
  150                                                                            
  151    The authors would like to acknowledge the role of Pekka Savola in his   
  152    thorough review of the document.                                        
  153                                                                            
  154                                                                            
  155                                                                            
  156                                                                            
  157                                                                            
  158                                                                            
  159                                                                            
  160                                                                            
  161                                                                            
  162 Durand & Ihren           Best Current Practice                  [Page 3]   

  163 RFC 3901             DNS IPv6 Transport Guidelines        September 2004   
  164                                                                            
  165                                                                            
  166 7.  Normative References                                                   
  167                                                                            
  168    [1]  Mockapetris, P., "Domain names - concepts and facilities", STD     
  169         13, RFC 1034, November 1987.                                       
  170                                                                            
  171    [2]  Mockapetris, P., "Domain names - implementation and                
  172         specification", STD 13, RFC 1035, November 1987.                   
  173                                                                            
  174    [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP   
  175         9, RFC 2026, October 1996.                                         
  176                                                                            
  177    [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)    
  178         Specification", RFC 2460, December 1998.                           
  179                                                                            
  180    [5]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)     
  181         Addressing Architecture", RFC 3513, April 2003.                    
  182                                                                            
  183    [6]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS        
  184         Extensions to Support IP Version 6", RFC 3596, October 2003.       
  185                                                                            
  186 8.  Authors' Addresses                                                     
  187                                                                            
  188    Alain Durand                                                            
  189    SUN Microsystems, Inc                                                   
  190    17 Network circle UMPK17-202                                            
  191    Menlo Park, CA, 94025                                                   
  192    USA                                                                     
  193                                                                            
  194    EMail: Alain.Durand@sun.com                                             
  195                                                                            
  196                                                                            
  197    Johan Ihren                                                             
  198    Autonomica                                                              
  199    Bellmansgatan 30                                                        
  200    SE-118 47 Stockholm                                                     
  201    Sweden                                                                  
  202                                                                            
  203    EMail: johani@autonomica.se                                             
  204                                                                            
  205                                                                            
  206                                                                            
  207                                                                            
  208                                                                            
  209                                                                            
  210                                                                            
  211                                                                            
  212                                                                            
  213                                                                            
  214                                                                            
  215                                                                            
  216                                                                            
  217 Durand & Ihren           Best Current Practice                  [Page 4]   

  218 RFC 3901             DNS IPv6 Transport Guidelines        September 2004   
  219                                                                            
  220                                                                            
  221 9.  Full Copyright Statement                                               
  222                                                                            
  223    Copyright (C) The Internet Society (2004).                              
  224                                                                            
  225    This document is subject to the rights, licenses and restrictions       
  226    contained in BCP 78, and except as set forth therein, the authors       
  227    retain all their rights.                                                
  228                                                                            
  229    This document and the information contained herein are provided on an   
  230    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE             
  231    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE    
  232    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR     
  233    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF      
  234    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED      
  235    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.      
  236                                                                            
  237 Intellectual Property                                                      
  238                                                                            
  239    The IETF takes no position regarding the validity or scope of any       
  240    Intellectual Property Rights or other rights that might be claimed to   
  241    pertain to the implementation or use of the technology described in     
  242    this document or the extent to which any license under such rights      
  243    might or might not be available; nor does it represent that it has      
  244    made any independent effort to identify any such rights.  Information   
  245    on the IETF's procedures with respect to rights in IETF Documents can   
  246    be found in BCP 78 and BCP 79.                                          
  247                                                                            
  248    Copies of IPR disclosures made to the IETF Secretariat and any          
  249    assurances of licenses to be made available, or the result of an        
  250    attempt made to obtain a general license or permission for the use of   
  251    such proprietary rights by implementers or users of this                
  252    specification can be obtained from the IETF on-line IPR repository at   
  253    http://www.ietf.org/ipr.                                                
  254                                                                            
  255    The IETF invites any interested party to bring to its attention any     
  256    copyrights, patents or patent applications, or other proprietary        
  257    rights that may cover technology that may be required to implement      
  258    this standard.  Please address the information to the IETF at ietf-     
  259    ipr@ietf.org.                                                           
  260                                                                            
  261 Acknowledgement                                                            
  262                                                                            
  263    Funding for the RFC Editor function is currently provided by the        
  264    Internet Society.                                                       
  265                                                                            
  266                                                                            
  267                                                                            
  268                                                                            
  269                                                                            
  270                                                                            
  271                                                                            
  272 Durand & Ihren           Best Current Practice                  [Page 5]   
  273                                                                            

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.