One document matched: draft-iana-rfc3330bis-03.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="full3978" docName="draft-iana-rfc3330bis-03" 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</country>

		</postal>

		<phone>+310-823-9358</phone>

		<email>michelle.cotton@icann.org</email>

		<uri>

			http://www.iana.org/

		</uri>

	</address>

</author>

<date month="June" year="2008"/>

<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.  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 Regional Internet Registries 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 5 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 re-publish the technical
 content of RFC 3330 mostly unchanged as a Best Current Practice RFC.
                
        </t>

        <t>

The terms "Specification Required", "Expert Review", "IESG Approval",
"IETF Consensus", and "Standards Action", are used in this memo to
refer to the processes described in <xref target="RFC5226"/>.  The keywords MUST,
MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT are to be interpreted as defined in <xref target="RFC2119"/>.
	</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="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 changes: 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. 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. 192.0.0.0/24 is not reserved and is 
subject to future allocation by a RIR for assignment in the normal manner. 
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>

<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="RFC1700"/>, page 4.

	</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"/>.  Addresses within this
		   block should not appear on the public Internet.

	</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 should loop back inside the host.
		   This is ordinarily implemented using only 127.0.0.1/32 for loopback,
		   but no addresses within this block should ever appear on any network
		   anywhere <xref target="RFC1700"/>, page 5.

	</t>


	<t>

		   128.0.0.0/16 - This block, corresponding to the numerically lowest 
		   of the former Class B addresses, was initially reserved by
		   the IANA.  Given the present classless nature of the IP address
		   space, the basis for the reservation no longer applies and addresses
		   in this block are subject to future allocation by a Regional 
		   Internet Registry for assignment in the normal manner.

	</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 
		   may not 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"/>.  Addresses within this
		   block should not appear on the public Internet.

	</t>



	<t>

		   192.0.2.0/24 - This block is assigned as "TEST-NET" 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.  Addresses within this block should not appear on the
		   public Internet.

	</t>


	<t>

		   192.88.99.0/24 - This block is allocated for use as 6to4 relay
		   anycast addresses, according to <xref target="RFC3068"/>.

	</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"/>.  Addresses 
		   within this block should not appear on the public Internet.

	</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>
		   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.  The "limited broadcast" destination address
		   255.255.255.255 should never be forwarded outside the local network of
		   the source.  The remainder of this space is reserved for future use.
		   <xref target="RFC1700"/>, page 4.

	</t>

</section>



<section title="Summary Table">

	<figure><artwork>

Address Block       Present Use                Reference
------------------------------------------------------------------
0.0.0.0/8           "This" Network             RFC 1700, page 4
10.0.0.0/8          Private-Use Networks       RFC 1918
127.0.0.0/8         Loopback                   RFC 1700, page 5
169.254.0.0/16      Link Local                 RFC 3927 
172.16.0.0/12       Private-Use Networks       RFC 1918
192.0.2.0/24        Test-Net
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
224.0.0.0/4         Multicast                  RFC 3171
240.0.0.0/4         Reserved for Future Use    RFC 1700, page 4


	</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
the 10.0.0.0/8 block originate within your subnet, all border 
routers should filter such packets that originate from elsewhere.  
Attacks have been mounted that depend on the unexpected use of some 
of these addresses.

		</t>

</section>



<section title="Acknowledgments">

		<t>

Many people have made comments on draft versions of this document.
The IANA would especially like to thank Scott Bradner, Randy Bush,
Leo Vegoda, and Harald Alvestrand for their constructive feedback 
and comments.

		</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" ?>
        
</references>

<references title='Informative References'>
	
	<?rfc include="reference.RFC.1174" ?>

	<?rfc include="reference.RFC.1700" ?>

	<?rfc include="reference.RFC.1918" ?>	

	<?rfc include="reference.RFC.2544" ?>

	<?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>

</back>

</rfc>


PAFTECH AB 2003-20242024-05-14 17:34:02