One document matched: draft-iana-rfc3330bis-07.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<!--<?rfc rfcedstyle="yes"?>-->
<?rfc sortrefs="yes" ?>
<!-- noModification3978 -->
<rfc category="bcp" ipr="trust200811" docName="draft-iana-rfc3330bis-07" obsoletes="3330">
<front>
<title abbrev="Special Use IPv4 Addresses">
Special Use IPv4 Addresses
</title>
<author initials="M." surname="Cotton" fullname="Michelle Cotton">
<organization abbrev="ICANN">
Internet Corporation for Assigned Names and Numbers
</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<code>90292</code> <city>Marina del Rey</city>
<country>United States of America</country>
</postal>
<phone>+310-823-9358</phone>
<email>michelle.cotton@icann.org</email>
<uri>
http://www.iana.org/
</uri>
</address>
</author>
<author initials="L." surname="Vegoda" fullname="Leo Vegoda">
<organization abbrev="ICANN">
Internet Corporation for Assigned Names and Numbers
</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<code>90292</code> <city>Marina del Rey</city>
<country>United States of America</country>
</postal>
<phone>+310-823-9358</phone>
<email>leo.vegoda@icann.org</email>
<uri>
http://www.iana.org/
</uri>
</address>
</author>
<date month="June" year="2009"/>
<keyword>special</keyword>
<keyword>addresses</keyword>
<keyword>ipv4</keyword>
<abstract>
<t>
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.
Special IPv6 addresses are described in RFC 5156.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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 <xref target="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.
</t>
<t>
On an ongoing basis, the IANA has been designated by the IETF
to make assignments in support of the Internet Standards
Process <xref target="RFC2860"/>. Section 4 of this document describes that
assignment process.
</t>
<t>
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.
</t>
<t>
This document is a revision of RFC 3330 <xref target="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.
</t>
</section>
<section title="Terminology">
<t>
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, <xref target="RFC2119"/>.
</t>
</section>
<section title="Global and Other Specialized Address Blocks">
<t>
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 <xref target="RFC1122"/>, section 3.2.1.3.
</t>
<t>
10.0.0.0/8 - This block is set aside for use in
private networks. Its intended use is documented
in <xref target="RFC1918"/>. As described in that
RFC, addresses within this block do not appear
on the public Internet. These addresses can be used
without any coordination with IANA or an Internet
registry.
</t>
<t>
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
<xref target="RFC1122"/>, Section 3.2.1.3,
addresses within the entire 127.0.0.0/8 block do
not appear on any network anywhere.
</t>
<t>
169.254.0.0/16 - This is the "link local" block. As described in
<xref target="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.
</t>
<t>
172.16.0.0/12 - This block is set aside for use in
private networks. Its intended use is documented
in <xref target="RFC1918"/>. As described in that
RFC, addresses within this block do not appear on
the public Internet. These addresses can be used
without any coordination with IANA or an Internet
registry.
</t>
<t>
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 <xref target="I-D.iana-special-ipv4-registry"/>.
</t>
<t>
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
[TBD-REF-IANA-IPV4-EXAMPLES], addresses within this
block do not appear on the public Internet and can
be used without any coordination with IANA or an
Internet registry. See <xref target="RFC1166"/>.
</t>
<t>
192.88.99.0/24 - This block is allocated for use as
6to4 relay anycast addresses, in to
<xref target="RFC3068"/>. In contrast with previously
described blocks, packets destined to addresses from
this block do appear in the public
Internet. <xref target="RFC3068"/>, Section 7
describes operational practices to prevent the
malicious use of this block in routing protocols.
</t>
<t>
192.168.0.0/16 - This block is set aside for use in
private networks. Its intended use is documented in
<xref target="RFC1918"/>. As described in that
RFC, addresses within this block do not appear on
the public Internet. These addresses can be used
without any coordination with IANA or an Internet
registry.
</t>
<t>
198.18.0.0/15 - This block has been allocated for use in benchmark
tests of network interconnect devices. <xref target="RFC2544"/> explains
that this range was assigned to minimize the chance of conflict in case a
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.
</t>
<t>
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
[TBD-REF-IANA-IPV4-EXAMPLES], addresses within this
block do not appear on the public Internet and can
be used without any coordination with IANA or an
Internet registry.
</t>
<t>
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
[TBD-REF-IANA-IPV4-EXAMPLES], addresses within this
block do not appear on the public Internet and can
be used without any coordination with IANA or an
Internet registry.
</t>
<t>
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
<xref target="RFC3171"/>.
</t>
<t>
240.0.0.0/4 - This block, formerly known as the
Class E address space, is reserved for future use,
see <xref target="RFC1112"/>, section 4.
<vspace blankLines='1'/>
The one exception to this is the "limited
broadcast" destination address 255.255.255.255. As
described in <xref target="RFC0919"/> and
<xref target="RFC0922"/>, packets with this
destination address are not forwarded at IP layer.
</t>
</section>
<section title="Summary Table">
<figure><artwork>
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
192.0.2.0/24 TEST-NET-1 TBD-REF-IANA-IPV4EXAMPLES
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 TBD-REF-IANA-IPV4EXAMPLES
203.0.113.0/24 TEST-NET-3 TBD-REF-IANA-IPV4EXAMPLES
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
</artwork></figure>
</section>
<section title="Assignments of IPv4 Blocks for New Specialized Uses">
<t>
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" <xref target="RFC2860"/>. Among other things,
<xref target="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.
</t>
<t>
The domain name and IP address spaces involve policy issues (in
addition to technical issues) so that the requirements of <xref target="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 <xref target="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.
</t>
<t>
As required by <xref target="RFC2860"/>, the IANA will also make necessary
experimental assignments of IPv4 addresses, also in consultation
with the Regional Internet Registries.
</t>
</section>
<section title="IANA Considerations">
<t>
This document describes the IANA's past and current practices and
does not create any new requirements for assignments or allocations
by the IANA.
</t>
</section>
<section title="Security Considerations">
<t>
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.
</t>
<t>
It should also be noted that some of these address spaces may be used
legitimately outside of 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.
</t>
</section>
<section title="Acknowledgments">
<t>
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.
</t>
</section>
</middle>
<!-- REFERENCE TEMPLATE
<reference anchor="reference.XXX">
<front>
<title>XXX</title>
<author initials="X." surname="XXX" fullname="XXX">
<organization abbrev="XXX">XXX</organization>
<address>
<postal>
<street>XXX</street>
<city>XXX</city>
<region>XXX</region>
<code>XXX</code>
<country>XXX</country>
</postal>
<phone>XXX</phone>
<facsimile>XXX</facsimile>
<email>XXX</email>
<uri>XXX</uri>
</address>
</author>
<date month="XXX" year="XXX"/>
</front>
<seriesInfo name="XXX" value="XXX"/>
<format type="XXX" target="XXX"/>
</reference>
-->
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.I-D.draft-iana-special-ipv4-registry-01" ?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.0919" ?>
<?rfc include="reference.RFC.0922" ?>
<?rfc include="reference.RFC.1112" ?>
<?rfc include="reference.RFC.1122" ?>
<?rfc include="reference.RFC.1166" ?>
<?rfc include="reference.RFC.1174" ?>
<?rfc include="reference.RFC.1700" ?>
<?rfc include="reference.RFC.1918" ?>
<?rfc include="reference.RFC.2544" ?>
<?rfc include="reference.RFC.2606"?>
<?rfc include="reference.RFC.2860" ?>
<?rfc include="reference.RFC.3068" ?>
<?rfc include="reference.RFC.3171" ?>
<?rfc include="reference.RFC.3927" ?>
<?rfc include="reference.RFC.3330" ?>
<?rfc include="reference.RFC.5156" ?>
<?rfc include="reference.RFC.5226" ?>
</references>
<section title="Differences between this document and RFC 3330">
<t>
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:
</t>
<t>
- 14.0.0.0/8 is no longer set aside for assignments to the international system
of Public Data Networks <xref target="RFC1700"/>, page 181. It is now available
for allocation to RIRs in the normal way;
</t>
<t>
- 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;
</t>
<t>
- 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;
</t>
<t>
- 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;
</t>
<t>
- 191.255.0.0/16 is not reserved and is subject to future allocation by a RIR for
assignment in the normal manner; and
</t>
<t>
- 223.255.255.0/24 is not reserved and is subject to future allocation by an RIR for
assignment in the normal manner.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:05:15 |