comments please

Bill Manning bmanning at ISI.EDU
Tue Dec 8 09:52:48 UTC 1998

                                                         Bill Manning
                                                    November 24, 1998

            Documenting Special Use IPv4 Address Blocks
   Copyright (C) The Internet Society (1998). All Rights Reserved.

1. Status of this Memo

This draft, file name draft-manning-dsua-00.txt, is intended to become
something that might be of use to those who are interested in the
operational requirements of an IPv4 based network.  Distribution of 
this document is unlimited. Comments should be sent to the author.

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on (Africa), (Northern Europe), (Southern Europe), (Pacific Rim), (US East Coast), or (US West Coast).

This Internet-Draft expires six months from the date of publication
in the Internet Drafts directories.


This document lists the existent special use prefixes from the IPv4 space 
and provides some suggestions for operational procedures when these 
prefixes are encountered.  This document does not address IPv4 space that
is reserved for future delegation in the operational Internet.

The current list of special use prefixes:

2.1 Prefix Discussion: has a number of unique properties, many of which were built into
the protocol stacks used throughout the Internet. or the all-zeros
address has been used and is still recognized as the historical broadcast
address. This use or restriction is depricated and modern code will treat
broadcast correctly as an all-ones value within the subnet. 

Also, many stacks will allow the system administrator to encode IP addresses
of the form, with the presumption that historical, "natural" masks
apply and so this would represent a host that carries the local value of
160.57 within the /16 netblock that is in use on that media. These properties 
suggest that a prudent network manager & system admin will treat
as a special use netblock. Router and Host requirements documents and 
implementations treat this range with special use constraints. is earmarked for what is called "loopback". This construct is 
to allow a node to test/validate its IP stack.  Most software only uses
a single value from this range, for loopback purposes.  It
is treated with the same levels of restriction by router and host requirements
and implementations so it is difficult to use any other addresses within 
this block for anything other than node specific applications, generally 
bootstraping.  All in all a tremendous waste of IP space. Good thing we'll 
not likely need it. is listed as the TEST-NET. This prefix is earmarked for use in 
documentation and example code. Network operations and End System 
administrators should ensure that this prefix is not coded into systems
or routed through any infrastructure.  Since it has the appearance of a
"normal" prefix, special precautions should be taken to ensure that this
prefix is not propagated in either the Internet or any private networks
that use the IP protocols.  Often used in conjunction with
or in vendor and protocol documentation.,, are the prefixes called out
in RFC 1918. They are only for use in private networks that wish to use
the IP protocols. Network operations and End System administrators should 
ensure that these prefixes is not coded into systems or routed through any 
Internet infrastructure.  Since they have the appearance of "normal" prefixes, 
special precautions should be taken to ensure that they are not propagated 
in the Internet. has been ear-marked as the IP range to use for end node 
autoconfiguration when a DHCP server may not be found. As such, network
operations and administrators should be VERY aggressive in ensuring that
neither route advertisements nor packet forwarding should occur across
any media boundaries. This is true for the Internet as well as any
private networks that use the IP protocols. End node administrators
should be aware that some vendors will autoconfigure and add this
prefix to the nodes forwarding table. This will cause problems with
sites that run router discovery or depricated routing protocols such as

As a side note, at least one vendor has hijacked an address range for
use by its printservers. That range is and the specific
address that they use is  This is not a valid delegation
to this vendor and its use argues for reconstitution of this service
into the link-local range or configurable with site delegated space.

3. DNS considerations:

None of these address prefixes is to be used or visible on the public Internet.
In fact, some of these prefixes must not appear outside the machine. To 
encourage honesty, most of these prefixes have been mapped into the
DNS. This encourages people to ensure that when used, these prefixes are
coded with local-scope DNS and there will be no "leakage" to the 
global Internet.

4. Access Control suggestions:

In todays network, it is prudent to control access. In the case of these
special use prefixes, it is generally a good idea to filter them so they
do not propagate. After all, you don't want someone else's use of these
prefixes to taint your environment.  An example of one form of access
control is listed below:

access-list 100 deny   ip host any
access-list 100 deny   ip
access-list 100 deny   ip
access-list 100 deny   ip
access-list 100 deny   ip
access-list 100 deny   ip
access-list 100 deny   ip
access-list 100 permit ip any any

5. Security Considerations:

Use of most of these special use prefixes open up significant opportunities 
for anonymity and ambiguity. People being what they are, will hide behind 
ambiguous or nebulous identities to do things that are antisocial and 
downright hostile. It would be nice to have better authentication methods
in play than an IP address which has lost its global uniqueness.

6. References:

[DHC-IPV4-AUTOCONFIG] - R. Troll, Automaticly Choosing an IP Address 
in an Ad-Hoc IPv4 Network, Internet draft, 
draft-ietf-dhc-ipv4-autoconfig-01.txt, October 1998

[RFC1918]  Y. Rekhter, Address Allocation for Private Internets,
February 1996, RFC 1918

[RFC1122] R. Braden,  Requirements for Internet Hosts -- Communication Layers,
October 1989, RFC 1122

[RFC1812] F. Baker, Requirements for IP Version 4 Routers,
June 1995, RFC 1812

[RFC2267] P. Ferguson, D. Senie, Network Ingress Filtering: 
Defeating Denial of Service Attacks which employ IP Source Address Spoofing,
January 1998, RFC 2267

[NET-TEST] Netname: IANA, Netnumber:, Coordinator: 
Internet Assigned Numbers Authority, 1993

[LOOPBACK] Netname: LOOPBACK, Netnumber:, Coordinator:
Internet Assigned Numbers Authority, 1972

[RESERVED-1] Netname RESERVED-1, Netblock: -,
Coordinator: Internet Assigned Numbers Authority, 1972

7. Copyright Notice

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the  purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

8. Author's Address

	Bill Manning
	4676 Admiralty Way, #1001
	Marina del Rey, CA. 90292
	bmanning at


More information about the NANOG mailing list