Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330 90292 Marina del Rey United States +310-823-9358 michelle.cotton@icann.org http://www.iana.org/

special addresses ipv4 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.

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 . 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. On an ongoing basis, the IANA has been designated by the IETF to make assignments in support of the Internet Standards Process . Section 5 of this 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 , which it obsoletes; its primary purpose is to re-publish the technical content of RFC 3330 mostly unchanged as a Best Current Practice RFC. 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 . The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in .

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, .

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 , 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; - 223.255.255.0/24 is not reserved and is subject to future allocation by an RIR for assignment in the normal manner.

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 , page 30. 10.0.0.0/8 - This block is set aside for use in private networks. Its intended use is documented in . Addresses within this block should not appear on the public Internet and can be used without any coordination with IANA or an Internet registry. 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 , page 31. 169.254.0.0/16 - This is the "link local" block. As described in , 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 . Addresses within this block should not appear on the public Internet and 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. 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 and can be used without any coordination with IANA or an Internet registry. 192.88.99.0/24 - This block is allocated for use as 6to4 relay anycast addresses, according to . 192.168.0.0/16 - This block is set aside for use in private networks. Its intended use is documented in . Addresses within this block should not appear on the public Internet and 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. 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. 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 . 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. , page 2.

Address Block Present Use Reference ------------------------------------------------------------------ 0.0.0.0/8 "This" Network RFC 1122, page 30 10.0.0.0/8 Private-Use Networks RFC 1918 127.0.0.0/8 Loopback RFC 1122, page 31 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 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 1112, page 2

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" . Among other things, 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 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 . 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 , the IANA will also make necessary experimental assignments of IPv4 addresses, also in consultation with the Regional Internet Registries.

This document describes the IANA's past and current practices and does not create any new requirements for assignments or allocations by the IANA.

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.

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

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. Stanford University, Computer Science Department

Stanford CA 94305-2140 US +1 415 723 9427 deering@PESCADERO.STANFORD.EDU

University of Southern California (USC)/ Information Sciences Institute (ISI)

4676 Admiralty Way Marina del Rey CA 90292-6695 US +1 213 822 1511 Braden@ISI.EDU

Corporation for National Research Initiatives (CNRI)

1895 Preston White Drive Suite 100 Reston VA 22091 US +1 703 620 8990 vcerf@nri.reston.va.us

USC/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90292-6695 US +1 310 822 1511 jkrey@isi.edu

USC/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90292-6695 US +1 310 822 1511 postel@isi.edu

Cisco systems

170 West Tasman Drive San Jose CA 95134-1706 US +1 914 528 0090 +1 408 526 4952 yakov@cisco.com

Chrysler Corporation

25999 Lawrence Ave Center Line MI 48015 US +1 810 758 8212 +1 810 758 8173 rgm3@is.chrysler.com

RIPE Network Coordination Centre

Kruislaan 409 Amsterdam 1098 SJ NL +31 20 5925065 +31 20 5925090 Daniel.Karrenberg@ripe.net

RIPE Network Coordination Centre

Kruislaan 409 Amsterdam 1098 SJ NL +31 20 5925065 +31 20 5925090 GeertJan.deGroot@ripe.net

Silicon Graphics, Inc.

2011 N. Shoreline Blvd. Mail Stop 15-730 Mountain View CA 94043-1389 US +1 415 960 1980 +1 415 961 9584 lear@sgi.com

Harvard University

1350 Mass. Ave Room 813 Cambridge MA 02138 US +1 617 495 3864 +1 617 496 8500 sob@harvard.edu

NetScout Systems

4 Westford Tech Park Drive Westford MA 01886 US +1 978 614 4116 +1 978 614 4004 mcquaidj@netscout.com

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing. This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community. This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." [STANDARDS TRACK] This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.</t><t> IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS TRACK] IANA This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets. It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. This memo provides information for the Internet community. Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.