1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc3681.txt b/doc/rfc/rfc3681.txt
new file mode 100644
index 0000000..2c1d8ff
--- /dev/null
+++ b/doc/rfc/rfc3681.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                            R. Bush
+Request for Comments: 3681                                           IIJ
+BCP: 80                                                          R. Fink
+Category: Best Current Practice                             January 2004
+
+
+                     Delegation of E.F.F.3.IP6.ARPA
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document discusses the need for delegation of the
+   E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for
+   6bone addresses, and makes specific recommendations for the process
+   needed to accomplish this.
+
+1.  6bone and DNS
+
+   The 6bone, whose address space was allocated by [RFC2471], has
+   provided a network for IPv6 experimentation for numerous purposes for
+   seven years.  Up to the present time, reverse lookups for 6bone
+   addresses have been accomplished through IP6.INT.  It is now
+   important that the thousands of 6bone users be able to update their
+   IPv6 software to use IP6.ARPA [RFC3152].
+
+   Although the 6bone has a limited life, as a phaseout plan is being
+   discussed at the IETF at this time [I-D.fink-6bone-phaseout], there
+   is likely to be 2.5 to 3.5 more years of operation.  During this
+   remaining 6bone lifetime IP6.ARPA reverse lookup services for the
+   3ffe::/16 address space are required.
+
+   Discussions have been underway between the 6bone and RIR communities,
+   about having the RIRs perform this service.  It was agreed at the San
+   Francisco IETF meeting in March 2003 that it was more practical for
+   the 6bone to provide this service for itself.  This would relieve the
+   RIRs of the costs of providing this service, yet still provide the
+   IP6.ARPA authority the ability to terminate the service when the
+   planned 6bone termination date is reached (currently anticipated to
+   be June 6, 2006).
+
+
+
+Bush & Fink              Best Current Practice                  [Page 1]
+
+RFC 3681             Delegation of E.F.F.3.IP6.ARPA         January 2004
+
+
+   The current planning within the 6bone operational community is to
+   provide new inet6num attributes in the 6bone registry database for
+   top level 6bone address space holders to request delegation to their
+   reverse path servers.
+
+2.  IANA Considerations
+
+   This memo requests that the IANA delegate the E.F.F.3.IP6.ARPA domain
+   to the 6bone, as will be described in instructions to be provided by
+   the IAB.  Names within this zone are to be further delegated within
+   the top level 6bone ISPs (known as pTLAs) in accordance with the
+   delegation of 6bone 3FFE::/16 address space.
+
+3.  Security Considerations
+
+   While DNS spoofing of address to name mapping has been exploited in
+   IPv4, delegation of the E.F.F.3.IP6.ARPA zone creates no new threats
+   to the security of the internet.
+
+4.  References
+
+4.1.  Normative References
+
+   [RFC2471]                 Hinden, R., Fink, R. and J. Postel, "IPv6
+                             Testing Address Allocation", RFC 2471,
+                             December 1998.
+
+4.2.  Informative References
+
+   [I-D.fink-6bone-phaseout] Fink, R. and R. Hinden, "6bone (IPv6
+                             Testing Address Allocation) Phaseout", Work
+                             in Progress.
+
+   [RFC3152]                 Bush, R., "Delegation of IP6.ARPA", BCP 49,
+                             RFC 3152, August 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush & Fink              Best Current Practice                  [Page 2]
+
+RFC 3681             Delegation of E.F.F.3.IP6.ARPA         January 2004
+
+
+5.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication 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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+6.  Authors' Addresses
+
+   Randy Bush
+   IIJ
+   5147 Crystal Springs
+   Bainbrisge Island, WA  98110
+   US
+
+   Phone: +1 206 780 0431
+   EMail: randy@psg.com
+   URI:   http://psg.com/~randy/
+
+
+   Robert Fink
+   Truckee, CA
+   US
+
+   EMail: bob@thefinks.com
+
+
+
+
+
+
+
+
+
+
+
+Bush & Fink              Best Current Practice                  [Page 3]
+
+RFC 3681             Delegation of E.F.F.3.IP6.ARPA         January 2004
+
+
+7.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush & Fink              Best Current Practice                  [Page 4]
+