(User) Environmental Impact of Renumbering

[Howard Berkowitz <[e-mail]>]

We have been having a lively discussion of the implications 
of various addressing and routing schemes.  The list 
discussion, however, is appropriate for experts in routing 
and addressing.  Many of the details are relevant to the 
[political incorrectness warning] "core," "DFZ," or other 
area essential to the proper organization of the global 
Internet, but of little concern to user organizations that 
connect to it.

A large and growing number of Internet users, however, have 
simple connectivity.  They may simply have registered 
addresses and no active Internet connectivity, or a simple 
single-homed static route to a local ISP.  These users 
rarely have routng experts, but they need to plan for the 
future.  Their procurement and deployment resources often 
are less than even a small ISP, so they need to be thinking 
now about changes they will need to make in the near and 
moderate term.

I have tried, in this note, to identify a strategy that 
helps small users put the infrastructure in place to deal 
reasonably with address changes, even though we cannot now 
describe the exact scope of the changes.  We do know, 
however, that at least some change will be needed.  I encourage comment, 
but please remember that this note is intended to help the
simple user case, not the small or large provider.  I hope that
it will provide reality testing for minimizing the impact of 
renumbering proposals.

I suggest, therefore, that a document is needed for user 
planning.  Perhaps this is a BCP; perhaps there needs to be 
a new class of practice Informational RFC for those not 
conerned with the details of Internet architecture.

I have not written a formal I-D before, and welcome guidance 
on the best way to get this proposed document into the 
formal stream of information.

Howard

-------------

Network Working Group                          H. Berkowitz
                                          PSC International

       Best Planning Practices:
       Impact of Evolution in Internet Addressing


STATUS OF THIS MEMO


     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.  Internet Drafts may be updated, replaced,
or obsoleted by   other documents at any time.  It is not
appropriate to use Internet   Drafts as reference material
or to cite them other than as a  ``working draft'' or ``work
in progress.''

     Please check the 1id-abstracts.txt listing contained in
the   internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net,   nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the  current status of any Internet
Draft.

2.  OVERVIEW

     This note offers planning guidance to user 
organizations that may need to use Internet Protocol (IP) 
addreses, and wish to minimize the impact of ongoing 
developments in the internal addressing and routing 
architecture of the global Internet.  It is intended
for publication as a Best Current Practices official IETF
document.

     Recent technical design documents are concerned with 
evolution in the use of Internet addresses in the overall 
Internet architecture.  Controversial technical issues are 
involved, but a common theme is that "public" addresses may 
be subject to change as the operational environment changes.  

     Various schemes, such as "metro-based" or "provider-
based" addressing are being discussed, with the primary 
emphasis of these discussions being the detailed "core" 
router changes needed to make them real. Much less attention 
has been paid to the specific changes that "edge" users will 
need to make to support ANY means of renumbering.

     Customer efforts will vary depending on the connection 
strategy used by their provider.  Some providers completely 
control the router at the customer site that connect that 
site to the Internet, while others give significant 
operational responsibility to the user.  This document 
emphasizes the changes that renumbering will incur primarily 
on the customer boxes "beyond" the provider gateway.  It 
deals to a lesser extent with configuration changes in that 
gateway.

     Again, this document deals with planning for the user 
with simple connectivity needs.  Such users numerically are 
a large portion of Internet Protocol users, even though they 
may not offer the greatest technical challenge.  Such users 
have attributes including:

     --- Single point of attachment to the Internet
         (i.e., not multihomed)
     --- Do not exchange BGP with ISP
     --- Do not provide Internet transit services
         (i.e., true user organizations, not small
          ISP's).

     The key to minimize the user impact of potential 
changes in Internet addressing methods is to minimize the 
number of places in the user network where "hard-coded" 
addresses are stored. There are a few principal places where 
hard-coded addresses are used in common practice:

     1.  Workstations learning their own addresses
     2.  Workstations learning the address of servers
     3.  Servers learning their own address

These are not the only requirements for addresses, but 
solving these requirements will handle the bulk of work.   
Other potential places where changes are needed include:

     4.  Router interfaces
     5.  Network management
     
     Sections below deal with techniques for each of these 
categories of need.

     An important distinction is whether the user 
applications need a "public" or a "private" address.  
RFC1597 introduces the idea of public vs. private.  Public 
addresses are part of the global IP routing system, and may 
change as routing technology and operations change.  Prudent 
users should plan for such change.

     The key to minimizing user impact is for user 
organizations to understand their requirements for "public" 
addresses in the global addressing system.  If public 
addresses are needed, then Best Current Practice suggests 
that user network managers take immediate steps to mimimize 
the effects of likely address changes on their 
organizations. 

     Requirements for renumbering are controversial among 
Internet architects.  Nevertheless, it is sufficiently 
likely that user network design should proactively 
provide mechanisms for mimimizing the effects of 
renumbering. 

     Users need to identify the impact of renumbering on 
their environments.  It is a practical reality that some 
users will have thousands of hosts with "hard-coded" IP 
addresses.   Not all of these hosts, however, need to be 
renumbered if external numbering conventions change.


3.  REQUIREMENTS ANALYSIS

Two documents define various functional requirements for 
Internet connectivity.   RFC1597 discusses classes of 
applications that can use "private" address space.
RFC1775 discusses user-oriented perspectives as to what it 
means to be "on" the Internet.  The first RFC emphasizes 
address requirements, while the second is consciously at a 
higher level of abstraction, dealing with applications 
rather than addressing.

    1597 focuses on hosts that need IP addresses that are 
not connected to the Internet, while RFC1775 deals in part 
with determining if an IP address is needed at all.
 
     Another working document, draft-ietf-idr-autosys-guide-
03.txt, deals with the question of when a user needs to 
participates in the complexities of Internet exterior 
routing.

     Private addresses can be "hard-wired" into 
workstations, routers, and servers.  This is "real-world" 
but not desirable.

     Building on the RFC1775 and RFC1597 categories, we have 
a set of IP usage categories that might be used for an user 
inventory:

Class  IP Address    Address  "On the         Typical        
                                Internet
         Needed      Source     Category       Usage
  
  1    Public         Local or      Full      Public
                      LAN server              server     
      
  2    Temp.public    Local or    Client      Client
			    LAN server              for public
                                              applications
                                              (LAN based)

  3    Temp.public    Local or    Client      Client
			    Dial server	          for public
                                              applications
                                              (Telecommuter)

  4    Private        Firewall    Client       IP appl.
                                               via firewall
 
  5    No             ---         Mediated    Non-IP
                                              terminal

  6    No             ---         Messaging   Non-IP 
                                              terminal

  7    Private        Lccal       Not on      Private LAN
                      fixed or                IP client
                      temporary

  8    Private        Local       Not on      Private dial
                      fixed or                IP client
                      temporary    

  9    Private        Local fixed Not on      Embedded 
                                              system

 10    Private        Local       Not on      Private router


4.  ADDRESS SOURCES

Several sources of addressing are available to these need 
categories.  Applicable sources differ on whether an IP host 
needs its own address or needs some other host's address.

4.1  OWN ADDRESS

Hosts in Classes 1 and 2 should obtain IP addresses from 
BOOTP/DHCP hosts with a block of public addresses.  
Typically, Class 1 hosts will obtain a fixed address at 
initialization time, or obtain an address from a pool only 
if the Class 1 host can register the acquired address in 
DNS.   Users will find that Class 1 hosts are likely to have 
locally configured IP addresses.

Class 3 hosts will be similar to Class 2, although the 
source of the address is more likely to be PPP negotiation 
than Class 2.  Many current accesses of this type use a 
fixed address defined by their provider.  

This may be fairly transparent if the provider registers the 
provider-furnished addresses in a provider-operated DNS data 
base that is publically available.

4.2  SERVER ADDRESSES

     Legacy clients may have hard-coded server addresses, 
which is undesirable if renumbering is a possibiity.  The 
preferred approach is to have clients request the current 
addresss of a server from an appropriate directory service, 
typically DNS.  For some high-performance transaction 
processing, the directory may be the portmapper service.

    Special user routing considerations may apply if the 
directory service is not on the same medium as the client.  
Arbitrary DNS queries often are sent as UDP/IP broadcasts, 
which do not propagate beyond the local router interface.    

    On initialization, servers should obtain addresses from 
appropriate servers, much as do Class 1 and 2 user hosts.  
 
4.3  END HOST-ROUTER INTERACTIONS

    There are two main ways in which end hosts interact with 
routers.  In the first, the "default gateway" method, end 
hosts are hard-coded with the address of a specific router 
IP address.  This address is assumed to be on the same 
medium as the end host.

    The second major method is "proxy ARP," in which the end 
host broadcasts a MAC-level request for a MAC address for 
the destination.  If the desired host is on the same medium 
as the requesting host, the destination answers directly.  
Otherwise, a router containing a route to the destination 
host's subnet will answer as if it is the desired host.

    Hard-coded default router addresses should be avoided.  
End hosts should issue ARP requests when attempting to 
determine the medum address associated with an arbitrary 
destination. 
 
    In general, routers should have proxy ARP enabled.  
Exceptions may exist for extensions that provided fault 
tolerance with a "virtual address."


4.4  ADDRESSES IN ROUTERS

    Current technology generally will require manual 
reconfiguration of router addresses when addresses change.  
If router configurations are stored as text files, 
appropriate substitution tools can change prefixes.

    Routers will need addresses for external public 
connectivity, and for connectivity to internal machines with 
public addresses.  If the enterprise uses both public and 
private addresses, it is desirable that the router filter 
private addresses both from and to the external Internet.

    Routers will need to be configured with the IP addresses 
of DNS, BOOTP/DHCP, and other servers that clients may 
address with broadcasts.

    It may be appropriate to define these services by name 
in the DNS.  If the router can act as a DNS clent and route 
to a name, router-specific renumbering is reuced.  
Otherwise, it may be possible to write configuration scripts 
using names, which are run through a preprocessor that looks 
up names in the DNS database.

4.5  BASTIONS AND NETWORK ADDRESS TRANSLATORS

    Bastion host components of firewalls may map between 
public and private addresses, or between public "protected" 
and public "unprotected" addresses. 

    In general, if the user has deployed a component that 
has address mapping capability, use of private address space 
within the protected environment should be encouraged.

    For configurations to remain in the range of simplicity 
covered by this document, the address translating devices 
should be at the single point of attachment from the user to 
the Internet.

5.  NETWORK MANAGEMENT


5.1  BASIC CONNECTIVITY TOOLS


    Basic connectivity tools such as ping and traceroute 
have specific IP address arguents.  It will be necessary to 
learn assigned addresses to use them.

    Since these tend to be used for ad hoc troubleshooting 
by trained networking personnel, persistent IDs are probably 
not needed.  People that use these tools should be able to 
understand the process of address assignment, and should be 
able to manually discover assigned addresses.


5.2  SNMP MANAGEMENT

    Use of SNMP tools in an environment in which addresses 
change is more complex than using simple connectivity tools.  
In principle, instances of MIB object can be identified by 
systemID strings rather than IP addresses.  In practice, 
managed objcts are accessed by IP address, and long-term 
statistics are frequently indexed by IP address.

    Alternative mapping mechanisms will be needed for 
meaningful long-term statistical tracking.  It may be 
appropriate to log renumbering events and correlate them to 
the times that SNMP samples are taken.


6.  SECURITY CONSIDERATIONS

    This document does not explicitly address security 
considerations.  Incorrectly implemented renumbering can 
cause parts of a network to be unreachable, resulting in 
denial of service.  Other renumbering areas can lead to 
inappropriate exposure of data to disclosure or alteration.


7.  AUTHOR'S ADDRESS


Howard C. Berkowitz
PSC International
PO Box 6897
Arlington VA 22206

Voice [phone]
Fax   [phone]

[e-mail]