doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc5735.txt b/doc/rfc/rfc5735.txt
new file mode 100644
index 0000000..363f6fc
--- /dev/null
+++ b/doc/rfc/rfc5735.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         M. Cotton
+Request for Comments: 5735                                     L. Vegoda
+BCP: 153                                                           ICANN
+Obsoletes: 3330                                             January 2010
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+                       Special Use IPv4 Addresses
+
+Abstract
+
+   This document obsoletes RFC 3330.  It describes the global and other
+   specialized IPv4 address blocks that have been assigned by the
+   Internet Assigned Numbers Authority (IANA).  It does not address IPv4
+   address space assigned to operators and users through the Regional
+   Internet Registries, nor does it address IPv4 address space assigned
+   directly by IANA prior to the creation of the Regional Internet
+   Registries.  It also does not address allocations or assignments of
+   IPv6 addresses or autonomous system numbers.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   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).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5735.
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+   (http://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
+
+
+
+
+
+Cotton & Vegoda          Best Current Practice                  [Page 1]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+3.  Global and Other Specialized Address Blocks  . . . . . . . . .  3
+4.  Summary Table  . . . . . . . . . . . . . . . . . . . . . . . .  6
+5.  Assignments of IPv4 Blocks for New Specialized Uses  . . . . .  6
+6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
+7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
+9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+  9.1.  Normative References . . . . . . . . . . . . . . . . . . .  7
+  9.2.  Informative References . . . . . . . . . . . . . . . . . .  7
+Appendix A.  Differences between This Document and RFC 3330  . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cotton & Vegoda          Best Current Practice                  [Page 2]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+1.  Introduction
+
+   Throughout its history, the Internet has employed a central Internet
+   Assigned Numbers Authority (IANA) responsible for the allocation and
+   assignment of various identifiers needed for the operation of the
+   Internet [RFC1174].  In the case of the IPv4 address space, the IANA
+   allocates parts of the address space to Regional Internet Registries
+   (RIRs) according to their established needs.  These RIRs are
+   responsible for the registration of IPv4 addresses to operators and
+   users of the Internet within their regions.
+
+   On an ongoing basis, the IANA has been designated by the IETF to make
+   assignments in support of the Internet Standards Process [RFC2860].
+   Section 4 of that document describes that assignment process.
+
+   Small portions of the IPv4 address space have been allocated or
+   assigned directly by the IANA for global or other specialized
+   purposes.  These allocations and assignments have been documented in
+   a variety of RFCs and other documents.  This document is intended to
+   collect these scattered references and provide a current list of
+   special use IPv4 addresses.
+
+   This document is a revision of RFC 3330 [RFC3330], which it
+   obsoletes; its primary purpose is to reflect the changes to the list
+   of special IPv4 assignments since the publication of RFC 3330.  It is
+   a companion to [RFC5156], which describes special IPv6 addresses.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, [RFC2119].
+
+3.  Global and Other Specialized Address Blocks
+
+   0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
+   network.  Address 0.0.0.0/32 may be used as a source address for this
+   host on this network; other addresses within 0.0.0.0/8 may be used to
+   refer to specified hosts on this network ([RFC1122], Section
+   3.2.1.3).
+
+   10.0.0.0/8 - This block is set aside for use in private networks.
+   Its intended use is documented in [RFC1918].  As described in that
+   RFC, addresses within this block do not legitimately appear on the
+   public Internet.  These addresses can be used without any
+   coordination with IANA or an Internet registry.
+
+
+
+
+
+Cotton & Vegoda          Best Current Practice                  [Page 3]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+   127.0.0.0/8 - This block is assigned for use as the Internet host
+   loopback address.  A datagram sent by a higher-level protocol to an
+   address anywhere within this block loops back inside the host.  This
+   is ordinarily implemented using only 127.0.0.1/32 for loopback.  As
+   described in [RFC1122], Section 3.2.1.3, addresses within the entire
+   127.0.0.0/8 block do not legitimately appear on any network anywhere.
+
+   169.254.0.0/16 - This is the "link local" block.  As described in
+   [RFC3927], it is allocated for communication between hosts on a
+   single link.  Hosts obtain these addresses by auto-configuration,
+   such as when a DHCP server cannot be found.
+
+   172.16.0.0/12 - This block is set aside for use in private networks.
+   Its intended use is documented in [RFC1918].  As described in that
+   RFC, addresses within this block do not legitimately appear on the
+   public Internet.  These addresses can be used without any
+   coordination with IANA or an Internet registry.
+
+   192.0.0.0/24 - This block is reserved for IETF protocol assignments.
+   At the time of writing this document, there are no current
+   assignments.  Allocation policy for future assignments is given in
+   [RFC5736].
+
+   192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in
+   documentation and example code.  It is often used in conjunction with
+   domain names example.com or example.net in vendor and protocol
+   documentation.  As described in [RFC5737], addresses within this
+   block do not legitimately appear on the public Internet and can be
+   used without any coordination with IANA or an Internet registry.  See
+   [RFC1166].
+
+   192.88.99.0/24 - This block is allocated for use as 6to4 relay
+   anycast addresses, in [RFC3068].  In contrast with previously
+   described blocks, packets destined to addresses from this block do
+   appear in the public Internet.  [RFC3068], Section 7, describes
+   operational practices to prevent the malicious use of this block in
+   routing protocols.
+
+   192.168.0.0/16 - This block is set aside for use in private networks.
+   Its intended use is documented in [RFC1918].  As described in that
+   RFC, addresses within this block do not legitimately appear on the
+   public Internet.  These addresses can be used without any
+   coordination with IANA or an Internet registry.
+
+   198.18.0.0/15 - This block has been allocated for use in benchmark
+   tests of network interconnect devices.  [RFC2544] explains that this
+   range was assigned to minimize the chance of conflict in case a
+
+
+
+
+Cotton & Vegoda          Best Current Practice                  [Page 4]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+   testing device were to be accidentally connected to part of the
+   Internet.  Packets with source addresses from this range are not
+   meant to be forwarded across the Internet.
+
+   198.51.100.0/24 - This block is assigned as "TEST-NET-2" for use in
+   documentation and example code.  It is often used in conjunction with
+   domain names example.com or example.net in vendor and protocol
+   documentation.  As described in [RFC5737], addresses within this
+   block do not legitimately appear on the public Internet and can be
+   used without any coordination with IANA or an Internet registry.
+
+   203.0.113.0/24 - This block is assigned as "TEST-NET-3" for use in
+   documentation and example code.  It is often used in conjunction with
+   domain names example.com or example.net in vendor and protocol
+   documentation.  As described in [RFC5737], addresses within this
+   block do not legitimately appear on the public Internet and can be
+   used without any coordination with IANA or an Internet registry.
+
+   224.0.0.0/4 - This block, formerly known as the Class D address
+   space, is allocated for use in IPv4 multicast address assignments.
+   The IANA guidelines for assignments from this space are described in
+   [RFC3171].
+
+   240.0.0.0/4 - This block, formerly known as the Class E address
+   space, is reserved for future use; see [RFC1112], Section 4.
+
+   The one exception to this is the "limited broadcast" destination
+   address 255.255.255.255.  As described in [RFC0919] and [RFC0922],
+   packets with this destination address are not forwarded at the IP
+   layer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cotton & Vegoda          Best Current Practice                  [Page 5]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+4.  Summary Table
+
+Address Block       Present Use                Reference
+------------------------------------------------------------------
+0.0.0.0/8           "This" Network             RFC 1122, Section 3.2.1.3
+10.0.0.0/8          Private-Use Networks       RFC 1918
+127.0.0.0/8         Loopback                   RFC 1122, Section 3.2.1.3
+169.254.0.0/16      Link Local                 RFC 3927
+172.16.0.0/12       Private-Use Networks       RFC 1918
+192.0.0.0/24        IETF Protocol Assignments  RFC 5736
+192.0.2.0/24        TEST-NET-1                 RFC 5737
+192.88.99.0/24      6to4 Relay Anycast         RFC 3068
+192.168.0.0/16      Private-Use Networks       RFC 1918
+198.18.0.0/15       Network Interconnect
+                    Device Benchmark Testing   RFC 2544
+198.51.100.0/24     TEST-NET-2                 RFC 5737
+203.0.113.0/24      TEST-NET-3                 RFC 5737
+224.0.0.0/4         Multicast                  RFC 3171
+240.0.0.0/4         Reserved for Future Use    RFC 1112, Section 4
+255.255.255.255/32  Limited Broadcast          RFC 919, Section 7
+                                               RFC 922, Section 7
+
+5.  Assignments of IPv4 Blocks for New Specialized Uses
+
+   The IANA has responsibility for making assignments of protocol
+   parameters used in the Internet according to the requirements of the
+   "Memorandum of Understanding Concerning the Technical Work of the
+   Internet Assigned Numbers Authority" [RFC2860].  Among other things,
+   [RFC2860] requires that protocol parameters be assigned according to
+   the criteria and procedures specified in RFCs, including Proposed,
+   Draft, and full Internet Standards and Best Current Practice
+   documents, and any other RFC that calls for IANA assignment.
+
+   The domain name and IP address spaces involve policy issues (in
+   addition to technical issues) so that the requirements of [RFC2860]
+   do not apply generally to those spaces.  Nonetheless, the IANA is
+   responsible for ensuring assignments of IPv4 addresses as needed in
+   support of the Internet Standards Process.  When a portion of the
+   IPv4 address space is specifically required by an RFC, the technical
+   requirements (e.g., size, prefix length) for the portion should be
+   described [RFC5226].  Immediately before the RFC is published, the
+   IANA will, in consultation with the Regional Internet Registries,
+   make the necessary assignment and notify the RFC Editor of the
+   particulars for inclusion in the RFC as published.
+
+   As required by [RFC2860], the IANA will also make necessary
+   experimental assignments of IPv4 addresses, also in consultation with
+   the Regional Internet Registries.
+
+
+
+Cotton & Vegoda          Best Current Practice                  [Page 6]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+6.  IANA Considerations
+
+   This document describes the IANA's past and current practices and
+   does not create any new requirements for assignments or allocations
+   by the IANA.
+
+7.  Security Considerations
+
+   The particular assigned values of special use IPv4 addresses
+   cataloged in this document do not directly raise security issues.
+   However, the Internet does not inherently protect against abuse of
+   these addresses.  If you expect (for instance) that all packets from
+   a private address space such as the 10.0.0.0/8 block or the link
+   local block 169.254.0.0/16 originate within your subnet, all routers
+   at the border of your network should filter such packets that
+   originate from outside your network.  Attacks have been mounted that
+   depend on the unexpected use of some of these addresses.
+
+   It should also be noted that some of these address spaces may be used
+   legitimately outside a single administrative domain, and may appear
+   on the global Internet.  Security policy SHOULD NOT blindly filter
+   all of these address spaces without due consideration, and network
+   operators are encouraged to review this document, and references
+   contained therein, and determine what security policies should be
+   associated with each of these address blocks within their specific
+   operating environments.
+
+8.  Acknowledgments
+
+   Many people have made comments on draft versions of this document.
+   The authors would especially like to thank Scott Bradner, Randy Bush,
+   Harald Alvestrand, Peter Koch, Alfred Hoenes, and Jari Arkko for
+   their constructive feedback and comments.  They would also like to
+   offer a special note of thanks to APNIC, which nominated
+   198.51.100.0/24 and 203.0.113.0/24.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+9.2.  Informative References
+
+   [RFC0919]  Mogul, J., "Broadcasting Internet Datagrams", STD 5,
+              RFC 919, October 1984.
+
+
+
+
+Cotton & Vegoda          Best Current Practice                  [Page 7]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+   [RFC0922]  Mogul, J., "Broadcasting Internet datagrams in the
+              presence of subnets", STD 5, RFC 922, October 1984.
+
+   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
+              RFC 1112, August 1989.
+
+   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC1166]  Kirkpatrick, S., Stahl, M., and M. Recker, "Internet
+              numbers", RFC 1166, July 1990.
+
+   [RFC1174]  Cerf, V., "IAB recommended policy on distributing internet
+              identifier assignment and IAB recommended policy change to
+              internet "connected" status", RFC 1174, August 1990.
+
+   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
+              October 1994.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC2544]  Bradner, S. and J. McQuaid, "Benchmarking Methodology for
+              Network Interconnect Devices", RFC 2544, March 1999.
+
+   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
+              Understanding Concerning the Technical Work of the
+              Internet Assigned Numbers Authority", RFC 2860, June 2000.
+
+   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
+              RFC 3068, June 2001.
+
+   [RFC3171]  Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
+              "IANA Guidelines for IPv4 Multicast Address Assignments",
+              BCP 51, RFC 3171, August 2001.
+
+   [RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330,
+              September 2002.
+
+   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+              Configuration of IPv4 Link-Local Addresses", RFC 3927,
+              May 2005.
+
+   [RFC5156]  Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
+              April 2008.
+
+
+
+
+
+Cotton & Vegoda          Best Current Practice                  [Page 8]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC5736]  Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special
+              Purpose Address Registry", RFC 5736, January 2010.
+
+   [RFC5737]  Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
+              Reserved for Documentation", RFC 5737, January 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cotton & Vegoda          Best Current Practice                  [Page 9]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+Appendix A.  Differences between This Document and RFC 3330
+
+   Address blocks that were reserved for a special purpose in RFC 3330
+   but are no longer reserved for any special purpose and are available
+   for allocation are no longer listed in Sections 4 or 5.  The
+   following blocks have become available:
+
+   -  14.0.0.0/8 is no longer set aside for assignments to the
+      international system of Public Data Networks [RFC1700], page 181.
+      It is now available for allocation to RIRs in the normal way.
+
+   -  24.0.0.0/8 is no longer listed as the addresses in that block have
+      been managed by the American Registry for Internet Numbers (ARIN)
+      in the normal way since 2001.
+
+   -  39.0.0.0/8 is no longer listed as it has been subject to
+      allocation to an RIR for assignment in the normal manner since
+      2001.
+
+   -  128.0.0.0/16 is not reserved and is subject to future allocation
+      by a Regional Internet Registry for assignment in the normal
+      manner.
+
+   -  191.255.0.0/16 is not reserved and is subject to future allocation
+      by a RIR for assignment in the normal manner.
+
+   -  198.51.100.0/24 is assigned as "TEST-NET-2" for use in
+      documentation and example code.
+
+   -  203.0.113.0/24 is assigned as "TEST-NET-3" for use in
+      documentation and example code.
+
+   -  223.255.255.0/24 is not reserved and is subject to future
+      allocation by an RIR for assignment in the normal manner.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cotton & Vegoda          Best Current Practice                 [Page 10]
+
+RFC 5735               Special Use IPv4 Addresses           January 2010
+
+
+Authors' Addresses
+
+   Michelle Cotton
+   Internet Corporation for Assigned Names and Numbers
+   4676 Admiralty Way, Suite 330
+   Marina del Rey, CA  90292
+   USA
+
+   Phone: +1-310-823-9358
+   EMail: michelle.cotton@icann.org
+   URI:   http://www.iana.org/
+
+
+   Leo Vegoda
+   Internet Corporation for Assigned Names and Numbers
+   4676 Admiralty Way, Suite 330
+   Marina del Rey, CA  90292
+   USA
+
+   Phone: +1-310-823-9358
+   EMail: leo.vegoda@icann.org
+   URI:   http://www.iana.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cotton & Vegoda          Best Current Practice                 [Page 11]
+