INTERNET-DRAFT draft-manning-dsua-08.txt Bill Manning 26 May 2002 Documenting Special Use IPv4 Address Blocks that have been registered with IANA/RIR 1. Status of this Memo This draft, file name draft-manning-dsua-09.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. It does not specify an Internet standard of any kind. Distribution of this document is unlimited. Comments should be sent to the author. It is instructive to note that ICANN has been asked to work with the author in the creation and maintaince of of a docuement of this nature. They have declined and have created a similar document of their own accord. Attribution has not been given for this prior work in their document but is given to others. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) Bill Manning (2002). All Rights Reserved. 2. PREAMBLE: This document lists most of the existent special use prefixes from the IPv4 space that have been registered with the IANA and now RIRs and provides some suggestions for operational procedures when these prefixes are encountered. This document does not address IPv4 space that is not registered with the IANA/RIRs for special use or address space that is reserved for future delegation in the operational Internet. Notice is given to prefixes that manufacturers have co-opted. The current list of special use prefixes: 0.0.0.0/8 127.0.0.0/8 192.0.2.0/24 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 192.175.48.0/24: RFC-1918 nameservers. 192.42.172.0/24: NeXT-Default: 192.18.0.0/15 RFC 2455 (NOT IANA, but Harvard, for BMWG) 192.88.99.0/24 RFC 3068 all D/E space 2.1 Prefix Discussion: 0.0.0.0/8 has a number of unique properties, many of which were built into the protocol stacks used throughout the Internet. 0.0.0.0/32 or the all-zeros address has been used and is still recognized as the historical broadcast address. This use or restriction is deprecated and modern code will treat broadcast correctly as an all-ones value within the subnet. It is fairly common practice to use 0.0.0.0 to encode the idea of "default". Also, many stacks will allow the system administrator to encode IP addresses of the form 0.0.160.57, with the presumption that historical, "natural" masks apply and so this would represent a host that carries the local value of x.x.160.57 within the /16 net-block that is in use on that media. These properties suggest that a prudent network manager & system admin will treat 0.0.0.0/8 as a special use net-block. Router and Host requirements documents and implementations treat this range with special use constraints. 127.0.0.0/8 is earmarked for what is called "loop-back". This construct is to allow a node to test/validate its IP stack. Most software only uses a single value from this range, 127.0.0.1/32 for loop-back 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 bootstrapping. All in all a tremendous waste of IP space. Good thing we'll not likely need it. 192.0.2.0/24 is listed as the NET TEST. 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 example.com or example.net in vendor and protocol documentation. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 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 applications do not use these ranges as source or destination addresses for any packets that traverse the 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. 169.254.0.0/16 has been ear-marked as the IP range to use for end node auto-configuration 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 auto-configure and add this prefix to the nodes forwarding table. This will cause problems with sites that run router discovery or deprecated routing protocols such as RIP. 192.175.48.0/24: RFC 1918 nameservers: The prefix used for nameservers in the public, operational Internet that are authoritative for RFC 1918 address space. Without these servers, the load on the root nameservers would be substantially higher. These servers are needed because network operators are not complying with the guidance in RFC 1918. 192.42.172.0/24: NeXT-Default: Legecy use for autoconfig of NeXT machines, e.g. Cubes, Slabs, PC's and even some NeXTstep-sparcs. Some older Apple OS may use this. Current Apple OS (Mac OS X) does -NOT- use this space. 198.18.0.0/15: from RFC-2544: C.2.2 Protocol Addresses Two sets of addresses must be defined: first the addresses assigned to the router ports, and second the address that are to be used in the frames themselves and in the routing updates. The network addresses 192.18.0.0 through 198.19.255.255 are have been assigned to the BMWG by the IANA for this purpose. This assignment was made to minimize the chance of conflict in case a testing device were to be accidentally connected to part of the Internet. 192.88.99.0/24: from RFC 3068: 2.3 6to4 Relay anycast prefix An IPv4 address prefix used to advertise an IPv4 route to an available 6to4 Relay Router, as defined in this memo. The value of this prefix is 192.88.99.0/24 Class D & E space. These are parts of the IPv4 space that retain some context of class-fullness. They are used for identification of multicast and a range left unspecified. Multicast is perfectly legal and has valid public uses but some care is required in understanding its appropriate use. The "E" space is still unspecified and so should be avoided. This extract from RFC 1166 covers these ranges. The fourth type of address, class D, is used as a multicast address [13]. The four highest-order bits are set to 1-1-1-0. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0| multicast address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class D Address Note: No addresses are allowed with the four highest-order bits set to 1-1-1-1. These addresses, called "class E", are reserved. Vendor Co-Opts: As an operationalnote, at least one vendor has hijacked an address range for use by its printservers. That range is 192.0.0.0/24 and the specific address that they use is 192.0.0.192/32. This is not a valid delegation to this vendor and its use argues for re-constitution of this service into the link-local range or configurable with site delegated space. 3. DNS considerations: None of these address prefixes, save multicast, 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 to authoritative servers in the DNS at the request of the IANA. 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. All of these address classes should be invalid as source addresses (except where negotiated in advance), and very few should be permitted as destination addresses (Multicast for example, should be permitted as a destination, just not as a source). An example of one form of access control is listed below: ... access-list 100 deny ip host 0.0.0.0 any access-list 100 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 100 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 100 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 access-list 100 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 100 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 100 deny ip 169.254.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 100 deny ip 240.0.0.0 15.255.255.255 any 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] draft-ietf-zeroconf-ipv4-linklocal-04.txt [RFC1918] Y. Rekhter et.al., Address Allocation for Private Internets, February 1996, RFC 1918 [RFC1122] R. Braden, Requirements for Internet Hosts -- Communication Layers, October 1989, RFC 1122 [RFC1166] S.Kirkpatrick et.al, INTERNET NUMBERS, July 1990, RFC 1166 [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 [RFC3068] C. Huitema, An Anycast Prefix for 6to4 Relay Routers, June 2001, RFC 3068 [NET-TEST] Netname: IANA, Netnumber: 192.0.2.0, Coordinator: Internet Assigned Numbers Authority, 1993 [LOOPBACK] Netname: LOOPBACK, Netnumber: 127.0.0.0, Coordinator: Internet Assigned Numbers Authority, 1972 [RESERVED-1] Netname RESERVED-1, Netblock: 0.0.0.0 - 0.255.255.255, Coordinator: Internet Assigned Numbers Authority, 1972 8. Author's Address Bill Manning PO Box 12317 Marina del Rey, CA. 90295 9. Full Copyright Statement Copyright (C) Bill Manning (2002). All Rights Reserved. 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. The limited permissions granted above are perpetual and will not be revoked by Bill Manning or his successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.