doc: Add RFC documents

1 files changed, 201 insertions, 0 deletions

diff --git a/doc/rfc/rfc9637.txt b/doc/rfc/rfc9637.txt
new file mode 100644
index 0000000..f8a1e1f
--- /dev/null
+++ b/doc/rfc/rfc9637.txt
@@ -0,0 +1,201 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         G. Huston
+Request for Comments: 9637                                         APNIC
+Updates: 3849                                                N. Buraglio
+Category: Informational                          Energy Sciences Network
+ISSN: 2070-1721                                              August 2024
+
+
+                 Expanding the IPv6 Documentation Space
+
+Abstract
+
+   The document describes the reservation of an additional IPv6 address
+   prefix for use in documentation.  This update to RFC 3849 expands on
+   the existing 2001:db8::/32 address block with the reservation of an
+   additional, larger prefix.  The addition of a /20 prefix allows
+   documented examples to more closely reflect a broader range of
+   realistic, current deployment scenarios and more closely aligns with
+   contemporary allocation models for large networks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9637.
+
+Copyright Notice
+
+   Copyright (c) 2024 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Requirements Language
+   3.  Current Assignment and Allocation Data
+   4.  Filtering and Appropriate Use
+   5.  Security Considerations
+   6.  IANA Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   [RFC3849] introduced the IPv6 address prefix 2001:db8::/32 as a
+   reserved prefix for use in documentation.  The rationale for this
+   reservation was to reduce the likelihood of conflict and confusion
+   when relating documented examples to deployed systems.
+
+   As the global deployment of IPv6 expands and evolves, individual IPv6
+   network deployment scenarios have also increased in size and
+   diversity, and there is a requirement for documentation to reflect
+   this increased diversity and scope.  The original 2001:db8::/32
+   reservation is inadequate to describe many realistic, current
+   deployment scenarios.
+
+   Without this additional address allocation, documentation prefixes
+   are drawn from address blocks already allocated or assigned to
+   existing organizations or well-known ISPs, or they are drawn from the
+   currently unallocated address pool.  Such use conflicts with existing
+   or future allocations or assignments of IPv6 address space.  The
+   reservation of a /20 IPv6 address prefix from the Global Unicast
+   Address pool [RFC4291] for documentation purposes allows such
+   conflicts to be avoided.
+
+2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Current Assignment and Allocation Data
+
+   According to the allocation and assignment data published by the
+   Regional Internet Registries (RIRs) (see [NROStatsReport]), in August
+   2023, 25.9% of the 62,770 recorded IPv6 unicast allocations and
+   assignments were larger than a /32 in size.  The most common
+   allocation or assignment size was a /29, used in 24.8% of cases.
+
+   The four largest assignments made to end users have been /19s, but
+   these allocations were made before the RIRs moved away from the use
+   of a fixed /48 site address prefix in IPv6 address assignment
+   policies, and in the foreseeable future, it is unlikely that
+   individual networks will require more than a /20.  It is believed
+   that reservation of a /20 will cover the documentation needs as they
+   relate to the broad range of realistic network deployments.
+
+4.  Filtering and Appropriate Use
+
+   Documentation prefixes are for the use of relaying configuration and
+   documentation examples, and as such, they MUST NOT be used for actual
+   traffic, MUST NOT be globally advertised, and SHOULD NOT be used
+   internally for routed production traffic or other connectivity.
+   Documentation prefixes should be considered bogon [BOGON] and
+   filtered in routing advertisements as appropriate.
+
+5.  Security Considerations
+
+   This special-use prefix should be marked as and considered bogon
+   [BOGON].  As is appropriate with bogon prefixes, packets whose source
+   or destination belongs to this prefix should be dropped and
+   disallowed over the public Internet.
+
+6.  IANA Considerations
+
+   IANA has registered the following in the "IANA IPv6 Special-Purpose
+   Address Registry" [IANA-IPv6-SPAR].
+
+   Address Block:  3fff::/20
+   Name:  Documentation
+   RFC:  RFC 9637
+   Allocation Date  2024-07
+   Termination Date:  N/A
+   Source:  False
+   Destination:  False
+   Forwardable:  False
+   Globally Reachable :  False
+   Reserved-by-Protocol:  False
+
+7.  References
+
+7.1.  Normative References
+
+   [IANA-IPv6-SPAR]
+              IANA, "IANA IPv6 Special-Purpose Address Registry",
+              <https://www.iana.org/assignments/iana-ipv6-special-
+              registry>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+7.2.  Informative References
+
+   [BOGON]    Team Cymru, "Unravelling the Mystery of Bogons: A senior
+              stakeholder and IT professional guide", July 2023,
+              <https://www.team-cymru.com/post/unravelling-the-mystery-
+              of-bogons-a-senior-stakeholder-and-it-professional-guide>.
+
+   [NROStatsReport]
+              "NRO Stats Reports",
+              <https://ftp.ripe.net/pub/stats/ripencc/nro-stats>.
+
+   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
+              Reserved for Documentation", RFC 3849,
+              DOI 10.17487/RFC3849, July 2004,
+              <https://www.rfc-editor.org/info/rfc3849>.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
+              2006, <https://www.rfc-editor.org/info/rfc4291>.
+
+Acknowledgments
+
+   The authors would like to acknowledge the valuable input from XiPeng
+   Xiao, Chris Cummings, Russ White, Kevin Myers, Ed Horley, Tom
+   Coffeen, and Scott Hogg.
+
+Authors' Addresses
+
+   Geoff Huston
+   APNIC
+   Email: gih@apnic.net
+
+
+   Nick Buraglio
+   Energy Sciences Network
+   Email: buraglio@forwardingplane.net