from end hosts that do not understand it. These do involve protocol
mechanisms as workarounds, but the fundamental problem is hosts'
understanding of arbitrary prefix lengths.
A key mechanism is proxy ARP [Carpenter]. The basic mechanism of
using proxy ARP in prefix-based renumbering is to have the hosts
issue an ARP whenever they want to communicate with a destination.
If the destination is actually on the same subnet, it will respond
directly to the ARP. If the destination is not, the router will
respond as if it were the destination, and the originating host will
send the datagram to the router. Once the datagram is in the router,
the VLSM-aware router can forward it.
Many end hosts, however, will only issue an ARP if they conclude the
destination is on their own subnet. All other traffic is sent to a
hard-coded default router address. In such cases, workarounds may be
needed to force the host to ARP for all destinations.
One workaround involves a deliberate misconfiguration of hosts.
Hosts that only understand default routers also are apt only to
understand classful addressing. If the host is told its major (i.e.,
classful) network is not subnetted, even though the address plan
actually is subnetted, this will often persuade it to ARP to all
destinations.
This also works for hosts that do not understand subnetting at all.
An example will serve for both levels of host understanding. Assume
the enterprise uses 172.31.0.0/16 as its major address, which is in
the Class B format. This is actually subnetted with eight bits of
subnetting -- 172.31.0.0/24. Individual hosts unaware of VLSM,
however, either infer Class B from the address value, or are told
that the subnet mask in effect is 255.255.0.0.
Yet another approach that helps hosts find routers is to run passive
RIP on the hosts, so that they hear routing updates. They assume any
host that issues routing updates must be a router, so traffic for
non- local destinations can be forwarded there. While RIPv1 does not
support arbitrary prefixes, the router(s) issuing the routing updates
may have additional capabilities that let them correctly forward such
traffic. The priority, therefore, is to get the non-local routers to
a router that understands the overall routing structure, and passive
RIP may be a viable way to do this.
It may be appropriate to cut over on a site-by-site basis [Lear]. In
such an approach, some sites have VLSM-aware hosts but others do not.
As long as the routing structure supports VLSM, workarounds can be
applied where needed.
6.1.2 MAC Address Interactions
While it is uncommon now for a router to acquire any of its interface
addresses as a DHCP client, this may become more common. When a
router so acquires addresses, care must be taken that the MAC address
presented to the DHCP server is in fact unique.
Modern routers usually support protocol architectures besides IP.
Some of these architectures, notably DECnet, Banyan VINES, Xerox
Network Services, and IPX, may modify MAC addresses of routers such
that a given MAC address appears on more than one interface. While
this is normally not a problem, it could cause difficulties when the
MAC address is assumed to be unique.
Other situations occur when the same MAC address can appear on more
than one interface. There are high-availability IBM options which
establish primary and backup instances of the same MAC address on
different physical interfaces of 37x5 communications controllers.
Some end hosts running protocol stacks other than IP, notably DECnet,
may change their MAC address from the globally assigned built-in
address.
6.2 Dynamic
Dynamic protocol mechanisms that to some extent depend on IP
addresses may be affected by router renumbering. These include
mechanisms that assign or resolve addresses (e.g., DHCP, DNS),
mechanisms that use IP addresses for identification (e.g., SNMP),
security and authentication mechanisms, etc. The listed mechanisms
are apt to have configuration files that will be affected by
renumbering.
Another area of dynamic behavior that can be affected is caching.
Application servers, directory functions such as DNS, etc., may cache
IP addresses. When the router is renumbered, these servers may point
to old addresses. Certain proxy server functions may reside on
routers, and the router may need to be restarted to reset the cache.
The endpoints of TCP tunnels terminating on routers may be internally
identified by address/port pairs at each end. If the address
changes, even if the port remains the same, the tunnel is likely to
need to be reestablished.
7. Tools and Methods for Renumbering
The function of a renumbering tool can be realized either as manual
procedures as well as software. This section deals with functionality
of hypothetical yet general renumbering tools rather than their
implementation.
General caveat: tools should know whether the environment supports
classless addressing. If it does not, newly generated addresses
should be checked to see they do not fall into the all-zeroes or
all-ones subnet values.
7.1 Search Mechanisms
Tools will be needed to search configuration files and other
databases to identify addresses and names that will be affected by
reorganization. This search should be based on the address inventory
described above.
Especially when searching for names, common search tools using
regular expressions (e.g., grep) may be very useful. Some additional
search tools may be needed. One would convert dotted decimal search
arguments to binary and only then makes the comparison.
The comparison may need to be done under the constraint of a mask.
Such a comparator would also be relevant as the second phase that
looks for ipAddress and other relevant strings in MIBs.
7.2 Address Modification
The general mechanism for address modification is substitution of an
arbitrary number of bits in an address. In the simplest cases, there
is a one-to-one correspondence between old and new bit positions.
Especially when address modification is manual, it should be
remembered that the affected bits can be obscured by dotted decimal
notation. Work in, or at least consider, binary notation to assure
accuracy.
Several basic functions can be defined:
zerobits(position,length):
clear <length> bits starting at <position>
orbits(position,length,newbits)
OR the bit string <newbits> of <length> starting at <position>
In these examples, the index [j] is used to identify entries in the
address inventory database for existing addresses, while [k]
identifies new addresses.
Remember that these tools operate at a bit level, so the new address
will have to be converted back into dotted decimal, MIB ASN.1, or
other notation before it can be replaced into configuration files.
7.2.1 Prefix Change, No Change in Length
If the entire new prefix has the same number of bits as the old
external part, requiring no change to subnetting, the router part of
renumbering may be fairly simple. If the router configurations are
available in machine-readable form, as text files or parsable SNMP
data, it is a relatively simple task to define a tool to examine IP
addresses in the configuration, identify those beginning with the old
prefix, and substitute the new prefix bit-by-bit.
for each address[j],
zerobits(0,PrefixLength[j])
orbits(0,PrefixLength[j],NewPrefix[j])
Note that the host part is unaffected. Both subnet specifications
(e.g., for route advertisements) and specific host references will be
changed correctly in this simple case.
7.2.2 highOrderPart change
Matters are slightly more complex when the change applies only to the
externally-controlled part of the prefix, as might be the case when
an organization changes ISPs and renumbers into the ISP's address
space, without changing the internal subnet structure.
The substitution process is much as the previous case, except only
the high-order bits change:
for each address,
zerobits(0,highOrderPartLength[j])
orbits(0,highOrderPartLength,newHighOrderPart[k])
7.2.3 lowOrderPart change
Organizations might renumber only the lowOrderPart (i.e., the subnet
field) of their address space. This might be done to clean up an
address space into contiguous blocks prior to introducing a routing
system that aggregates addresses, such as OSPF.
for each address[j],
zerobits(highOrderPartLength[j],lowOrderPartLength[j])
orbits(highOrderPartLength[j],
lowOrderPartLength[j],newLowOrderPart[k])
7.2.4 lowOrderPart change, Change in lowOrderPart length
When the length of the subnet field changes in all or part of the
address space, things become significantly more complex. A fairly
simple case arises when the host field is consistently too long, at
least in the affected subnets. This is common, for example, when
address space is being recovered in an existing Class B network with
8 bits of subnetting. Certain /24 bit prefixes are being extended to
/30 and reallocated to point-to-point real or virtual (e.g., DLCI)
media.
for each address [j]
if address is affected by renumbering
if newLowOrderPartLength[k] > oldLowOrderPartLength[j]
then
zerobits(highOrderPartLength[k],newLowOrderPartLength[k])
orbits(highOrderPartLength[k],newLowOrderPart[k])
end
7.2.5 highOrderPart change, Change in highOrderPart length
When the length of the high-order part changes, but it is desired to
keep the existing subnet structure, constraints apply. The situation
is fairly simple if the new high-order part is shorter than the
existing high order part.
If the new high-order part is longer than the old high order part,
constraints are more complex. The key is to see if any of the <k>
most significant bits of the oldHighOrderPart, which overlap the <k>
least significant bits of the newHighOrderPart, are nonzero. If no
bits are nonzero, it may be simply to overlay the new prefix bits.
7.3 Naming
It is worthwhile to distinguish that a router's use of a DNS name
does not necessarily mean that name is defined in a name server.
Routers often contain static address to name mappings local to the
router, so both the DNS zone files and the router configurations will
need to be checked.
What we first want to do is generate a list of name/address mappings,
the mapping mechanism for each instance (e.g., static entry in
configuration file, RR in our zone's DNS, RR in a zone file outside
ours), the definition statement (or equivalent if the routers are
configured with SNMP), and current IP address. We then want to
compare the addresses in this list to the list defined earlier of
prefixes affected by renumbering. The intersection of these lists
define where we need to make changes.
Note that the explicit definition statement, or at leasts its
variables, should be kept. In the real world, static IP address
mappings in hosts may not have been maintained as systematically as
are RR records in a DNS server. It is entirely possible that
different host mapping entries for the same name point to different
addresses.
7.3.1 DNS Tools
The DNS itself can both delay and and speed router renumbering.
Caches in DNS servers both inside and outside the organization may
have sufficient persistence that a "flag day" cutover is not
practical if worldwide connectivity is to be kept. DNS can help,
however, make a period of old and new address coexistence work.
If, for example, a given router interface may have a coexisting new
and old address, it can be appropriate to introduce the new address
as a CNAME alias for the new address.
DNS RR statements can end with a semicolon, indicating the rest of
the line is a comment. This can be used as the basis of tools to
renumber DNS names for router addresses, by putting a comment (e.g.,
";newaddr") at the end of the CNAME statements for the new addresses.
At an appropriate time, a script could generate a new zone file in
which the new addresses become the primary definitions on A records,
and the old addresses could become appropriately commented CNAME
records. At a later time, these commented CNAME entries could be
removed.
Care should be taken to assure that PTR reverse mapping entries are
defined for new addresses, because some router vendor tools depend on
reverse mapping.
7.3.2 Related name tools
Especially on UNIX and othe that do routing, there may be static name
definitions. Such definitions are probably harder to keep maintained
than entries in the DNS, simply because they are more widely
distributed.
Several tools are available to generate more maintainable entries. A
perl script called h2n converts host tables into zone data files that
can be added to the DNS server. It is available as
ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z.
Another tool, makezones, is part of the current BIND distribution,
and can also be obtained from
ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones
See the DNS Resources Directory at http://www.dns.net/dnsrd.
8. Router Identifiers
Configuration commands in this category assign IP addresses to
physical or virtual interfaces on a single router. They also include
commands that assign IP-address-related information to the router
"box" itself, and commands which involve the router's interaction
with neighbors below the full routing level (e.g., default gateways,
ARP).
Routers may have other unique identifiers, such as DNS names used for
the set of addresses on the "box," or SNMP systemID strings.
8.1. Global Router Identification
Traditional IP routers do not have unique identifiers, but rather are
treated as collections of IP addresses associated with their
interfaces. Some protocol mechanisms, notably OSPF and BGP, need an
address for the router itself, typically to establish tunnel
endpoints between peer routers. Other applications include
"unnumbered interfaces" used to conserve address space for serial
media, a practice discussed further below.
In the illustration below, the 10.1.0.0/16 address space is used for
global identifiers. A TCP tunnel runs from 10.1.0.1 to 10.1.0.2, but
its traffic is load-shared among the two real links, 172.31.1.0 and
172.31.2.0.
172.31.4.1/24 172.31.5.1/24
| |
| |
+-------------------------------------+
| Router 1 |
| |
| 10.1.0.1/16 |
| # |
+-------------------#-----------------+
| 172.31.1.1/24 # | 172.31.2.1/24
| # |
| # |
| # |
| # |
| # |
| # |
| 172.31.1.2/24 # | 172.31.2.2/24
+-------------------#-----------------+
| Router 2 |
| |
| 10.1.0.2/16 |
| |
+-------------------------------------+
| |
| |
172.31.5.1/24 172.31.6.1/24
A common practice to provide router identifiers is using the "highest
IP address" on the router as an identifier for the "box." Many
implementations have a default mechanism to establish the router ID,
which may be the highest configured address, or the highest active
address.
Typical applications of a global router ID may not require it be a
"real" IP address that is advertised through the routing domain, but
is simply a 32-bit identifier local to each router. When this is the
case, this identifier can come from the RFC1918 private address
space rather than the enterprise's registered address space.
Allowing default selection of the router ID can be unstable and is
not recommended. Most implementations have a means of declaring a
pseudo-IP address for the router itself as opposed to any of its
ports.
Changes to this pseudo-address may have implications for DNS. Even
if this is not a real address, A and PTR resource records may have
been set up for it, so diagnostics can display names rather than
addresses.
Another potential DNS implication is that a CNAME may have been
established for the entire set of interface addresses on a router.
This allows testing, telnet, etc., to the router via any reachable
path.
8.2 Interface Address
Interface addresses are perhaps the most basic place to begin router
renumbering. Interface configuration will require an IP address, and
usually a subnet mask or prefix length. Some implementations may not
have a subnet mask in the existing configuration, because they use a
"default mask" based on a classful assumption about the address. Be
aware of possible needs for explicit specification of a subnet mask
or other prefix length specification when none previously was
specified. This will be especially common on older host-based
routers.
Multiple IP addresses, in different subnets, can be assigned to the
same interface. This is often a valuable technique in renumbering,
because the router interface can be configured to respond to both the
new and old addresses.
Caution is necessary, however, in using multiple subnet addresses on
the same interface. OSPF and IS-IS implementations may not advertise
the additional addresses, or may constrain their advertisement so all
must be in the same area.
When this method is used to make the interface respond to new and old
addresses, and the renumbering process is complete, care must be
taken in removing the old addresses. Some router implementations
have special meaning to the order of address declarations on an
interface. It is highly likely that routers, or at least the
interface, must be restarted after an address is removed.
8.3 Unnumbered Interfaces
As mentioned previously, several conventions have been used to avoid
wasting subnet space on serial links. One mechanism is to implement
proprietary "half-router" schemes, in which the unnumbered link
between router pairs is treated as an "internal bus" creating a
"virtual router," such that the scope of the unnumbered interface is
limited to the pair of routers.
| +------------+ +------------+ |
| | | | | |
| e0 | |s0 s0 | | |
|-------------| R1 |................| R2 |-------|
| 192.168.1.1 | 10.1.0.1/16| | 10.1.0.2/16| |
| /24 | | | | |
| +------------+ +------------+
In the above example, software in routers R1 and R2 automatically
forward every packet received on serial interface S0 to Ethernet
interface E0. They forward every packet on e0 to their local S0.
Neither S0 has an IP address. R1 has the router ID 10.1.0.1/16 and
R2 has 10.1.0.2/16.
It is thus impossible to send a specific ping to the S0 interfaces,
making it difficult to test whether a connectivity problem is due to
S0 or E0. Some management is possible as long as at least one IP
address on the router (e.g., E0) is reachable, since this will permit
SNMP connectivity to the router. Once the router is reachable with
SNMP, the unnumbered interface can be queried through the MIB
ifTable.
Another approach is to use the global router identifier as a pseudo-
address for every unnumbered interface on a router. In the above
example, R1 would use 10.1.0.1 as its identifier. This provides an
address to be used for such functions as the IP Route Recording
option, and for providing a next-hop-address for routes.
The second approach is cleaner, but still can create operational
difficulties. If there are multiple unnumbered interfaces on a
router, which one (if any) should/will respond to a ping? Other
network management mechanisms do not work cleanly with unnumbered
interface.
As part of a renumbering effort, the need for unnumbered interfaces
should be examined. If the renumbering process moves the domain to
classless addressing, then serial links can be given addresses with a
/30 prefix, which will waste a minimum of address space.
For dedicated or virtual dedicated point-to-point links within an
organization, another alternative to unnumbered operation is using
RFC1918 private address space. Inter-router links rarely need to be
accessed from the Internet unless explicitly used for exterior
routing. External traceroutes will also fail reverse DNS lookup.
If unnumbered interfaces are kept, and the router-ID convention is
used, it will probably be more stable to rely on an explicitly
configured router ID rather than a default from a numbered interface
address.
The situation becomes even more awkward if it is desired to use
unnumbered interfaces over NBMA services such as Frame Relay. OSPF,
for example, uses the IP address of numbered interfaces as a unique
identifier for that interface. Since unnumbered interfaces do not
have their own unique address, OSPF has not obvious way to identify
these interfaces. A physical index (e.g., ifTable) could be used,
but would have to be extended to have an entry for each logical entry
(i.e., VC) multiplexed onto the physical interface.
8.4 Address Resolution
While mapping of IP addresses to LAN MAC addresses is usually done
automatically by the router software, there will be cases where
special mappings may be needed. For example, the MAC address used by
router interfaces may be locally administered (i.e., set manually),
rather than relying on the burnt-in hardware address. It may be part
of a proprietary method that dynamically assigns MAC addresses to
interfaces. In such cases, an IP address may be part of the MAC
address configuration statements and will need to be changed.
Manual mapping to medium addresses will usually be needed for NBMA
and switched media. When renumbering IP addresses, statements that
map the IP address to frame relay DLCIs, X.121 addresses, SMDS and
ATM addresses, telephone numbers, etc., will need to be changed to
the new address. Local requirements may require a period of parallel
operation, where the old and new IP addresses map to the same medium
address.
8.5 Broadcast Handling
RFC1812 specifies that router interfaces MUST NOT forward limited
broadcasts (i.e., to the all-ones destination address,
255.255.255.255). It is common, however, to have circumstances where
a LAN segment is populated only by clients that communicate with key
servers (e.g., DNS or DHCP) by sending limited broadcasts. Router
interfaces can cope with this situation by translating the limited
broadcast address to a directed broadcast address or a specific host
address, which is legitimate to forward.
When limited address translation is done for serverless segments, and
the new target address is renumbered, the translation rule must be
reconfigured on every interface to a serverless segment. Be sure to
recognize that a given segment might have a server from the
perspective of one service (e.g., DHCP), but could be serverless for
other services (e.g., NFS or DNS).
8.6 Dynamic Addressing Support
Routers can participate in dynamic addressing with RARP, DHCP, BOOTP,
or PPP. In a renumbering effort, several kinds of changes may made
to be made on routers participating in dynamic addressing.
If the router acts as a server for dynamic address assignment, the
addresses it assigns will need to be renumbered. These might be
specific addresses associated with MAC addresses or dialup ports, or
could be a pool of addresses. Pools of addresses may be seen in pure
IP environments, or in multiprotocol situations such as Apple MacIP.
If the router does not assign addresses, it may be responsible for
forwarding address assignment requests to the appropriate server(s).
If this is the case, there may be hard-coded references to the IP
addresses of these servers, which may need to be changed as part of
renumbering.
9. Filtering and Access Control
Routers may implement mechanisms to filter packets based on criteria
other than next hop destination. Such mechanisms often are
implemented differently for unicast packets (the most common case) or
for multicast packets (including routing updates). Filtering rules
may contain source and/or destination IP addresses that will need to
change as part of a renumbering effort.
Filtering can be done to implement security policies or to control
traffic. In either case, extreme care must be taken in changing the
rules, to avoid leakage of sensitive information. denial of access
to legitimate users, or network congestion.
Routers may implement logging of filtering events, typically denial
of access. If logging is implemented, logging servers to which log
events are sent preferably should be identified by DNS name. If the
logging server is referenced by IP address, its address may need to
change during renumbering. Care should be taken that critical
auditing data is not lost during the address change.
9.1 Static Access Control Mechanisms
Router filters typically contain some number of include/exclude rules
that define which packets to include in forwarding and which to
exclude. These rules typically contain an address argument and some
indication of the prefix length. This length indication could be a
count, a subnet mask, or some other mask.
When renumbering, the address argument clearly has to change. It can
be more subtle if the prefix length changes, because the length
specification in the rule must change as well. Needs for such changes
may be hard to recognize, because they apply to ranges of addresses
that might be at a level of aggregation above the explicit
renumbering operation.
RFC1812 requires that address-based filtering allow arbitrary prefix
lengths, but some hosts and routers might only allow classful
prefixes.
9.2 Special Firewall Considerations
Routers are critical components of firewall systems.
Architecturally, two router functions are described in firewall
models, the external screening router between the outside and the
"demilitarized zone (DMZ)," and the internal screening router between
the inside and the "perimeter network." Between these two networks
is the bastion host, in which reside various non-routing isolation
and authentication functions, beyond the scope of this document.
One relevant aspect of the bastion host, however, is that it may do
address translation or higher-layer mappings between differnt address
spaces. If the "outside" address space (i.e., visible to the
Internet) changes, this will mean that the outside screening router
will need configuration changes. Since the outside screening router
may be under the control of the ISP rather than the entrerprise,
administrative coordination will be needed.
DMZ +--------+ Peri-
|---| Public | meter
+-----------+ | | Hosts | | +-----------+
From | External | | +--------+ |---| Internal |
Internet...| Screening |---| +--------+ | | Screening |
| Router | |---| Bastion|------| | Router |....To
+-----------+ | | Host | | +-----------+ Internal
| +--------+ | +-----------+ Network
| +--------+ |---| Dialup |
|---| Split | | | Access |
| | DNS | | | Server |
| +--------+ | +-----------+
External screening routers typically have inbound access lists that
block unauthorized traffic from the Internet, and outbound access
lists that permit access only to DMZ servers and the bastion host.
The inbound filters commonly block the Private Address Space, as well
as address space from the enterprise's internal network. If the
internal network address changes, the inbound filters clearly will
need to change.
If DMZ host addresses change, the corresponding outbound filters from
the external screening host also will need to change. Internal
screening routers permit access from the internal network to selected
servers on the perimeter network, as well as to the bastion host
itself. If the enterprise uses private address space internally,
renumbering may not affect this router.
Another component of a firewall system is the "split DNS" server,
which provides address mapping in relation to the globally visible
parts of the
9.3 Dynamic Access Control Mechanisms
Certain access control services, such as RADIUS and TACACS+, may
insert dynamically assigned access rules into router configurations.
For example, a RADIUS database "contains a list of requirements which
must be met to allow access for the user. This always includes
verification of the password, but can also specify the client(s) or
port(s) to which the user is allowed access. [Rigney]."
Configuration information dynamically communicated to the router may
be in the form of filtering rules. Effectively, this authentication
database becomes an extension of the router configuration database.
Both these databases may need to change as part of a renumbering
effort.
Another dynamic configuration issue arises when "stateful packet
screening" on bastion hosts or routers is used to provide security
for UDP-based services, or simply for IP. In such services, when an
authorized packet leaves the local environment to go into an
untrusted address space, a temporary filtering rule is established on
the interface on which the response to this packet is expected. The
rule typically has a lifetime of a single packet response. If these
rules are defined in a database outside of the router, the rule
database again is an extension of router configuration that must be
part of the renumbering effort.
10. Interior Routing
This section deals with routing inside an enterprise, which generally
follows, ignoring default routes, the rules:
1. Does a single potential route exist to a destination?
If so, use it.
2. Is there more than one potential path to a destination?
If so, use the path with the lowest end-to-end metric.
3. Are there multiple paths with equal lowest cost to the
destination? If so, consider load balancing.
Most enterprises do not directly participate in global Internet
routing mechanisms, the details of which are of concern to their
service providers. The next section deals with those more complex
exterior mechanisms.
10.1 Static Routes
During renumbering, the destination and/or next hop address of static
routes may need to change. It may be necessary to restart routers or
explicitly clear a routing table entry to force the changed static
route to take effect.
10.2 RIP (Version 1 unless otherwise specified)
The Routing Information Protocol (RIP) has long been with us, as one
of the first interior routing protocols. It still does that job in
small networks, and also has been used for assorted functions that
are not strictly part of interior routing. In this discussion, we
will first deal with pure interior routing applications.
In a renumbering effort that involves classless addressing, RIPv1 may
not be able to cope with the new addressing scheme. Officially, this
protocol is Historic and should be avoided in new routing plans.
Where legacy support requirements dictate it be retained, it is
worthwhile to try to limit RIPv1 in "stub" parts of the network.
Vendor-specific mechanisms may be available to interface RIPv1 to a
classless environment.
As part of planning renumbering, strong consideration should be given
to moving to RIPv2, OSPF, or other classless routing protocols as the
primary means of interior routing. Doing so, however, may not remove
the need to run RIP in certain parts of the enterprise.
RIP is widely implemented on hosts, where it may be used as a method
of router discovery, or for load-balancing and fault tolerance when
multiple routers are on a subnet. In these applications, RIP need
not be the only routing protocol in the domain; RIP may be present
only on stub subnets. Destination information from more capable
routing protocols may be translated into RIP updates. While it is
generally reasonable to minimize or remove RIP as part of a
renumbering effort, be careful not to disable the ability of hosts to
locate routers.
RIP is also used as a quasi-exterior routing mechanism between some
customers and their ISPs, as a means simpler than BGP for the
customer to announce routes to the provider.
10.3 OSPF
OSPF has several sensitivities to renumbering beyond those of simpler
routing protocols. If router IDs are assigned to be part of the
registered address space, they may need to be changed as part of the
renumbering effort. It may be appropriate to use RFC1918 private
address space for router IDs, as long as these can be looked up in a
DNS server within the domain.
Summarization rules are likely to be affected by renumbering,
especially if area boundaries change.
Special addressing techniques, such as unnumbered interfaces and
physical interfaces with IP addresses in multiple subnets, may not be
transparent to OSPF. Care should be exercised in their use, and
their use definitely should be limited to intra-area scope.
If part of the renumbering motivation is the introduction of NBMA
services, there can be numerous impacts on OSPF. Generally, the best
way to minimize impact is to use separate subnets for each VC. By
doing so, different OSPF costs can be assigned to different VCs,
designated router configuration is not needed, etc.
10.4 IS-IS
IP prefixes are usually associated with IS-IS area definitions. If
IP prefixes change, there may be a corresponding change in area
definitions.
10.5 IGRP and Enhanced IGRP
When a change from IGRP to enhanced IGRP is part of a renumbering
effort, the need to disable IGRP automatic route summarization needs
to be considered. This is likely if classless addressing is being
implemented.
Also be aware of the nuances of automatic redistribution between IGRP
and EIGRP. The "autonomous system number," which need not be a true
AS number but simply identifies a set of cooperating routers, must be
the same on the IGRP and EIGRP processes for automatic redistribution
to occur.
11. Exterior Routing
Exterior routes may be defined statically. If dynamic routing is
involved, such routes are learned primarily from BGP. RIP is not
infrequently used to allow ISPs to learn dynamically of new customer
routes, although there are security concerns in such an approach.
IGRP and EIGRP can be used to advertise external routes.
Renumbering that affects BGP-speaking routers can be complex, because
it can require changes not only in the BGP routers of the local
Autonomous System, but also require changes in routers of other AS
and in routing registries. This will require careful administrative
coordination.
If for no other reason than documentation, consider use of a routing
policy notation [RIPE-181++] [RPSL] to describe exterior routing
policies
11.1 Routing Registries/Routing Databases
Organizations who participate in exterior routing usually will have
routing information not only in their routers, but in databases
operated by registries or higher-level service providers (e.g., the
Routing Arbiter).
If an ISP whose previous address space came from a different provider
either renumbers into a different provider's address space, or gains
a recognized block of its own, there may be administrative
requirements to return the previously allocated addresses. These
include changes in IN-ADDR.ARPA delegation, SWIP databases, etc., and
need to be coordinated with the specific registries and providers
involved. Not all registries and providers have the same policies.
If the enterprise is a registered Autonomous System and renumbers
into a different address space, route objects with old prefixes in
routing registries need to be deleted and route objects with new
prefixes need to be added.
11.2 BGP--Own Organization
IP addressing information can be hard-coded in several aspects of a
BGP speaker. These include:
1. Router ID
2. Peer router IP addresses
3. Advertised prefix lists
4. Route filtering rules
Some tools exist [RtConfig] for generating policy configuration part
of BGP router configuration statements from the policies specified in
RIPE-181 or RPSL.
11.3 BGP--Other AS
Other autonomous systems, including nonadjacent ones, can contain
direct or indirect (e.g., aggregated) references to the above routing
information. Tools exist that can do preliminary checking of
connectivity to given external destinations [RADB].
12. Network Management
This section is intended to deal with those parts of network
management that are intimately associated with routers, rather than a
general discussion of renumbering and network management.
Methods used for managing routers include telnets to virtual console
ports, SNMP, and TFTP. Network management scripts may contain hard-
coded references to IP addresses supporting these services. In
general, try to convert script references to IP addresses to DNS
names.
A critical and complex problem will be converting SNMP databases,
which are usually organized by IP address.
12.1 Configuration Management
Names and addresses of servers that participate in configuration
management may need to change, as well as the contents of the
configurations they provide. TFTP servers are commonly used here, as
may be SNMP managers.
12.2 Name Resolution/Directory Services
During renumbering, it will probably be useful to assign DNS names to
interfaces, virtual interfaces, and router IDs of routers. Remember
that it is perfectly acceptable to identify internal interfaces with
RFC1597/RFC1918 private addresses, as long as firewalling or other
filtering prevent these addresses to be propagated outside the
enterprise.
If dynamic addressing is used, dynamic DNS should be considered.
Since this is under development, it may be appropriate to consider
proprietary means to learn what addresses have been assigned
dynamically, so they can be pinged or otherwise managed.
Also remember that some name resolution may be done by static tables
that are part of router configurations. Changing the DNS entries,
and even restarting the routers, will not change these.
12.3 Fault Management
Abnormal condition indications can be sent to several places that may
have hard-coded IP addresses, such as SNMP trap servers, syslogd
servers, etc.
It should be remembered that large bursts of transient errors may be
caused as part of address cutover in renumbering. Be aware that
these bursts might overrun the capacity of logging files, and
conceivably cause loss of auditing information. Consider enlarging
files or otherwise protecting them during cutover.
12.4 Performance Management
Performance information can be recorded in routers themselves, and
retrieved by network management scripts. Other performance
information may be sent to syslogd, or be kept in SNMP data bases.
Load-generating scripts used for performance testing may contain
hard-coded IP addresses. Look carefully for scripts that contain
executable code for generating ranges of test addresses. Such
scripts may, at first examination, not appear to contain explicit IP
addresses. They may, for example, contain a "seed" address used with
an incrementing loop.
12.5 Accounting Management
Accounting records may be sent periodically to syslogd or as SNMP
traps. Alternatively, the SNMP manager or other management
applications may periodically poll accounting information in routers,
and thus contain hard-coded IP addresses.
12.6 Security Management
Security management includes logging, authentication, filtering, and
access control. Routers can have hard-coded references to servers
for any of these functions.
In addition, routers commonly will contain filters containing
security-related rules. These rules are apt to need explicit
recoding, since they tend to operate on a bit level.
Some authentication servers and filtering mechanisms may dynamically
update router filters.
12.7 Time Service
Hard-coded references to NTP servers should be changed to DNS when
possible, and renumbered otherwise.
13. IP and Protocol Encapsulation
IP packets can be routed to provide connectivity for non-IP
protocols, or for IP traffic with addresses not consistent with the
active routing environment. Such encapsulating functions usually
have a tunneling model, where an end-to-end connection between two
"passenger" protocol addresses is mapped to a pair of endpoint IP
addresses. Generic Route Encapsulation is a representative means of
such tunneling [RFC1701, RFC1702].
13.1 Present
Renumbering of the primary IP environment often does not mean that
passenger protocol addresses need to change. In fact, such protocol
encapsulation for IP traffic may be a very viable method for handling
legacy systems that cannot easily be renumbered. For this legacy
case, the legacy IP addresses can be tunneled over the renumbered
routing environment.
Also note that IP may be a passenger protocol over non-IP systems
using IPX, AppleTalk, etc.
13.2 Future
Tunneling mechanisms are fundamental for the planned transition of
IPv4 to IPv6. As part of an IPv4 renumbering effort, it may be
worthwhile to reserve some address space for future IPv6 tunnels.
While there are clear and immediate needs for IPv4 renumbering, there
may be cases where IPv4 renumbering can be deferred for some months
or years. If the effort is deferred, it may be prudent at that time
to consider if available IPv6 implementations or tunneling mechanisms
form viable alternatives to IPv4 renumbering. It might be
appropriate to renumber certain parts of the existing IPv4 space
directly into the IPv6 space. Tools for this purpose are
experimental at the time this document was written.
14. Security Considerations
Routers are critical parts of firewalls, and are otherwise used for
security enforcement. Configuration errors made during renumbering
can expose systems to malicious intruders, or deny service to
authorized users. The most critical area of concern is that filters
are configured properly for old and new address, but other numbers
also can impact security, such as pointers to authentication,
logging, and DNS servers.
During a renumbering operation, it may be appropriate to introduce
authentication mechanisms for routing updates.
15. Planning and Implementing the Renumbering
Much of the effort in renumbering will be on platforms other than
routers. Nevertheless, routers are a key part of any renumbering
effort.
Step 1--Inventory of affected addresses and names.
Step 2--Design any needed topological changes. If temporary address
space, network address translators, etc., are needed, obtain
them.
Step 3--Install and test changes to make the network more
renumbering-friendly. These include making maximum use of
default routes and summarization, while minimizing address-
based references to servers.
Step 4--Plan the actual renumbering. Should it be phased or total?
Can it be done in a series of stub network renumberings,
possibly with secondary addresses on core routers? Is NAT
appropriate? If so, how is it to be used?
What is your plan of retreat if major problems develop?
Make a distinction between problems in the routing system
and unforeseen problems in hosts affected by renumbering.
Step 5--Take final backups.
Step 6--Cut over addresses and names, or begin coexistence.
Make needed DNS and firewall changes.
Restart routers and servers as appropriate.
Clear caches as appropriate.
Remember static name definitions in routers may not be affected
by DNS changes.
Coordinate changes with affected external organizations (e.g.,
ISPs, business partners, routing registries)
Step 6--Document what isn't already documented. Make notes to help
the person who next needs to renumber. Share experience with
the PIER working group or other appropriate organizations.
15.1 Applying Changes
Renumbering changes should be introduced with care into operational
networks. For changes to take effect, it is likely that at least
interfaces and probably routers will have to be restarted. The
sequence in which changes are applied must be carefully thought out,
to avoid loss of connectivity, routing loops, etc., while the
renumbering is in process.
See case studies presented to the PIER Working Group for examples of
operational renumbering experience. Organizations that have
undergone renumbering have had to pay careful attention to informing
users of possible outages, coordinating changes among multiple sites,
etc. It will be an organization-specific decision whether router
renumbering can be implemented incrementally or must be done in a
major "flag day" conversion.
Before making significant changes, TAKE BACKUPS FIRST of all router
configuration files, DNS zone files, and other information that
documents your present environment.
15.2 Configuration Control
Operationally, an important part of renumbering and continued
numbering maintenance is not to rely on local router interfaces,
either command language interpreter, menu-based, or graphic, for the
more sophisticated aspects of configuration, but to do primary
configuration (and changes) on an appropriate workstation. On a
workstation or other general-purpose computer, configuration files
can be edited, listed, processed with macro processors and other
tools, etc. Source code control tools can be used on the router
configuration files.
Once the configuration file is defined for a router, mechanisms for
loading it vary with the specific router implementation. In general,
these will include a file transfer using FTP or TFTP into a
configuration file on the router, SNMP SET commands, or logging in to
the router as a remote console and using a terminal emulator to
upload the new configuration under the router's interactive
configuration mode. Original acquisition of legacy configuration
files is the inverse of this process.
15.3 Avoiding Instability
Routing processes tend towards instability when they suddenly need to
handle very large numbers of updates, as might occur if a "flag day"
cutover is not carefully planned. A general guideline is to make
changes in only one part of a routing hierarchy at a time.
Routing system design should be hierarchical in all but the smallest
domains. While OSPF and IS-IS have explicit area-based hierarchical
models, hierarchical principles can be used with most implementations
of modern routing protocols. Hierarchy can be imposed on a protocol
such as RIPv2 or EIGRP by judicious use of route aggregation, routing
advertisement filtering, etc.
Respecting a hierarchical model during renumbering means such things
as renumbering a "stub" part of the routing domain and letting that
part stabilize before changing other parts. Alternatively, it may be
reasonable to add new numbers to the backbone, allowing it to
converge, renumbering stubs, and then removing old numbers from the
backbone. Obviously, these guidelines are most practical when there
is a distinct old and new address space without overlaps. If a block
of addresses must simply be reassigned, some loss of service must be
expected.
16. Acknowledgments
Thanks to Jim Bound, Paul Ferguson, Geert Jan de Groot, Roger Fajman,
Matt Holdrege, Dorian Kim, Walt Lazear, Eliot Lear, Will Leland, and
Bill Manning for advice and comments.
17. References
[