RFC 3681

Delegation of E.F.F.3.IP6.ARPA

📅 published January 2004, from ietf

RFC 3681: Delegation of E.F.F.3.IP6.ARPA 💖

okay bestie, the title block first 🎀

  • Number and title: RFC 3681, Delegation of E.F.F.3.IP6.ARPA
  • Category: Best Current Practice, BCP 80 🌸
  • Date: January 2004
  • Authors: R. Bush (IIJ) and R. Fink 🫶
  • Obsoletes and updates: the original doesn't list any, so this doc doesn't claim to replace or update anything ✨

Status of This Memo ✨

this is a Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements 💬 distribution of this memo is unlimited, so share away 🦋

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 🔥

this doc talks about why the E.F.F.3.IP6.ARPA DNS zone needs to be delegated so people can do reverse lookups for 6bone addresses 🧚 it also gives specific recommendations for how to make that happen, and honestly it's the whole plan 💜

1. 6bone and DNS 🌈

the 6bone got its address space from [RFC2471], and it's been a playground for IPv6 experimentation for seven years, for all sorts of purposes 🍓 up until now, reverse lookups for 6bone addresses have run through IP6.INT. it's now important that the thousands of 6bone users update their IPv6 software to use IP6.ARPA [RFC3152] 😭

the 6bone has a limited life, since a phaseout plan is being discussed at the IETF right now [I-D.fink-6bone-phaseout]. even so, it's likely to keep running for another 2.5 to 3.5 years. during that time, IP6.ARPA reverse lookup services for the 3ffe::/16 address space are required 💀

the 6bone and RIR communities talked about having the RIRs run this service. at the San Francisco IETF meeting in March 2003, everyone agreed it made more sense for the 6bone to provide it for itself ✨ that takes the costs off the RIRs, but the IP6.ARPA authority can still end the service when the planned 6bone termination date hits, which is currently expected to be June 6, 2006 👑

the 6bone operational community's current plan is to add new inet6num attributes to the 6bone registry database. that way, top level 6bone address space holders can request delegation to their reverse path servers 🦋

2. IANA Considerations 🎀

this memo asks IANA to delegate the E.F.F.3.IP6.ARPA domain to the 6bone, as described in instructions the IAB is going to provide 🫶 names in this zone are then delegated further within the top level 6bone ISPs (known as pTLAs), following the delegation of the 6bone 3FFE::/16 address space ⭐

3. Security Considerations 🔥

okay, serious moment, bestie 😭 DNS spoofing of address to name mapping has been exploited in IPv4. the good news is that delegating the E.F.F.3.IP6.ARPA zone creates no new threats to the security of the internet 🫶 this doc doesn't claim anything beyond that.

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.

5. Intellectual Property Statement 🧚

the IETF doesn't take a position on whether any intellectual property or other rights claimed for the technology in this doc are valid or in scope, or whether any license under those rights is available. it also doesn't say it has tried to find any such rights 🙈 info on the IETF's procedures for rights in standards-track and standards-related docs is in BCP-11. copies of rights claims made available for publication, plus any assurances of licenses, or the results of an attempt to get a general license for implementers or users, can be obtained from the IETF Secretariat 📬

the IETF invites anyone to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to practice this standard. send that info 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

Copyright (C) The Internet Society (2004). All Rights Reserved.

you can copy and share this doc and translations of it, and you can make derivative works that comment on or explain it or help implement it. those can be prepared, copied, published and distributed, in whole or in part, with no real restrictions 🎀 the only catch is that the copyright notice and this paragraph have to stay on every copy and derivative work 🌈

this doc itself can't be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations. the exceptions are when it's needed for developing Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when it's translated into languages other than English 💅

the permissions above are perpetual and won't be revoked by the Internet Society or its successors or assignees ⭐

this doc and the information in it are provided "AS IS", 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 💜

📦 where this page comes from