[apops] dsau-02

  • To: <ops@ISI.EDU>
  • Subject: [apops] dsau-02
  • From: Bill Manning <bmanning@ISI.EDU>
  • Date: Mon, 17 Apr 2000 08:21:43 -0700 (PDT)
  • Cc: bmanning@ISI.EDU
  • Sender: owner-apops@lists.apnic.net
    • 
      a bit late but here is #2
      	----------------------------------------------------
      INTERNET-DRAFT
      draft-manning-dsua-02.txt
                                                               Bill Manning
                                                                        ISI
                                                              17 April 2000 
      
                    
                  Documenting Special Use IPv4 Address Blocks
      		that have been registered with IANA
      
      
      1. Status of this Memo
      
      This draft, file name draft-manning-dsua-02.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 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.
      
      2. PREAMBLE:
      
      This document lists the existent special use prefixes from the IPv4 space 
      that have been registered with the IANA 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:
      
      	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
      	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 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 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.
      
      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.  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.
      
      As a side note, 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 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. 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 designation, 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 7.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] - R. Troll, Automatically Choosing an IP Address 
      in an Ad-Hoc IPv4 Network, Internet draft, 
      draft-ietf-dhc-ipv4-autoconfig-04.txt, October 1998
      
      [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
      
      [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
      	USC/ISI
      	4676 Admiralty Way, #1001
      	Marina del Rey, CA. 90292
      	USA
      	bmanning at isi dot edu
      	310.822.1511      
      -- 
      "When in doubt, Twirl..."  -anon
      *             APOPS: Asia Pacific Operations Forum              *
      * To unsubscribe: send "unsubscribe" to apops-request at apnic dot net *