Renumbering using an Operational Support System
draft-baker-6renum-oss-renumbering-00

Abstract

This document comments briefly on the use of an Operational Support System to renumber all or part of a network.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

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."

This Internet-Draft will expire on May 09, 2013.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Using the OSS for address and prefix management
• 2.1. What is an Operational Support System?
• 2.2. Implementing RFC 4192
• 2.3. Renumbering using an OSS
• 3. IANA Considerations
• 4. Security Considerations
• 5. Privacy Considerations
• 6. Acknowledgements
• 7. Change Log
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Introduction

This document comments briefly on the use of an Operational Support System to renumber all or part of a network.

When the question of renumbering a network, discussed previously in [RFC1900], [RFC1916], [RFC2071], [RFC2072], [RFC2874], [RFC2894], [RFC4076], [RFC4192], and [RFC5887], came up yet again in the IETF, the author's comment, besides pointing to the issues raised in The [RFC4192], was to comment that renumbering is a special case of numbering; what we really need to figure out is how to manage addresses and prefixes in an IPv4 [RFC0791] or IPv6 [RFC2460] network. This includes how to allocate them, how to assign them, how to recover or remove them, and how to change them, in a way that supports the service being offered. The IP MIB [RFC4293] provides at least three information elements, ipAdEntAddr, ipAddressAddr, and the ipAddressPrefixEntry, that can be used to read or set the address or prefix in use on an interface. Naively, the tools exist to add, change, or delete an address or prefix from an interface in IPv4 or IPv6 given a network management system using SNMP or Netconf that can manipulate them.

The "Procedures for Renumbering an IPv6 Network without a Flag Day" [RFC4192] started from an honest question on the part of its authors. The authors asserted that a procedure could be written (and proceeded to write one) to renumber a network without a flag day. The essential element required to maintain service during the change is to never actually change an address or prefix; instead, one adds a new address or prefix, ensures that it is useful in naming and routing, and only then removes the old. Fully believing that competent operators could figure this out, the authors then asked a number of operators: "what are we missing?" What we were missing, in short, was human ignorance, laziness, and misplaced creativity; we assumed that given tools with which to manage a network, people would use them. People in fact take dramatic shortcuts like manually configuring addresses in places that don't really call for that, neglecting to look up names, and ignoring lifetimes on data, with the result that a reasonable operational change can be ineffective. [RFC4192] was then updated to point to the many and wondrous ways in which people not only shoot themselves in the foot, but, taking careful aim, shoot their toes off individually.

This note does not pretend to fix the problem of human creativity. It does, however, discuss how one might implement the procedure of [RFC4192] in one's Operational Support System in a reasonable way.

2. Using the OSS for address and prefix management

2.1. What is an Operational Support System?

An Operational Support System, or OSS, is a software system that supports the operation of a network. It often includes one or more databases storing information about subscribers, employees, billing history, service history, equipment, interconnections, contracts, and configurations. It often has broad simplifications that enable one to operate a business. In a residential broadband network, for example, it will not attempt to describe each subscriber as having a separate contract; it will instead describe several classes of contracts, and for each subscriber indicate what type of contract they have. It will likely not have the exact configuration of each piece of equipment in the network; what it will have are methods to create that configuration from its databases (which may, of course, be cached), and methods to make specific changes to configurations when appropriate.

2.2. Implementing RFC 4192

The steps considered in [RFC4192] fall broadly into two categories:

• adding a new prefix to a network or a part of the network, and
• removing an old prefix from that network or part of a network.

The steps are taken in succession: one adds a new prefix, and then removes an old one; if they care conducted at the same time, a variety of failure modes can set in. It is possible, of course to divide the network into regions and renumber them individually, but in each region the renumbering is done by adding and subsequently dropping. The interval between the major phases is also arbitrarily long: one might add a prefix, wait a year, during which one uses multiple prefixes, and then remove one of them.

To add a prefix to a network, one takes several steps:

1. Initial condition: the network and its services are operating and supporting services with one or more prefixes.
2. Add the prefix to the routing system, including a prefix on each LAN (and therefore a subnet), advertised in routing.
3. Add an address in the added prefix to each host in the domain; this might be done using DHCP [RFC2131] [RFC3315] or Stateless Address Autoconfiguration [RFC4862][RFC4941] by making the new prefix a "preferred" prefix.
4. As interfaces acquire their new addresses, add resource records to DNS enabling systems to use them.
5. Resulting condition: the network and its services are operating and supporting services with the original set of prefix(es) plus the new one.

To remove a prefix from a network, one takes a corresponding series of steps:

1. Initial condition: the network and its services are operating and supporting services with two or more prefixes.
2. Remove resource records using the legacy prefix from DNS, causing new accesses to services to use the prefixes not being removed.
3. Wait until the lifetime advertised in DNS expires and normal access using the legacy addresses to complete; hosts may continue using cached information for that interval.
4. Remove the indicated addresses from the routing domain; this might be done using DHCP [RFC2131] [RFC3315] or Stateless Address Autoconfiguration [RFC4862][RFC4941] by making the prefix no longer be "preferred".
5. Remove the prefix from the routing system.
6. Resulting condition: the network and its services are operating and supporting services with the remaining prefix(es).

[RFC4192] recommends delays in between the various steps comparable to at least the lifetimes of information currently in use; hosts should not generate addresses that the routing system cannot support, DNS should not advertise addresses that the routing system cannot route to or which do not have hosts instantiating them, and the administration needs to enable a service to use an address until that address's advertised lifetime has expired. It also recommends testing; the fact that one has removed an address from DNS and the lifetime has expired does not imply that every session started within the lifetime has ended. The next procedural step should only be taken when there is no reasonable expectation that the information remains in use legitimately.

2.3. Renumbering using an OSS

It is hard to generalize about OSS's, as they are generally custom-built to support a specific business or kind of business. However, a few assumptions may hold reasonably generally:

• It is likely built on a database,
• Individual objects, such as subscriber entries, can have sets of attributes, such as IPv4 or IPv6 addresses or prefixes,
• The database provides methods that can observe a change to an object's attributes and perform related changes, and send messages to systems as needed.

For example, in a residential broadband network, the database might know that a set of customers are attached to the same interface on a given router, and as a result know that they should be configured with an address or prefix within each of a set of addresses or prefixes. The database will contain an object that corresponds to the router's interface and has a set of attributes including a set of subscribers, a set of IPv4 prefixes, and a set of IPv6 prefixes. The database method that adds a prefix to the set of prefixes on a router's interface will

• Add the prefix to the list
• Execute a method that configures the corresponding ipAdEntAddr, ipAddressAddr, and ipAddressPrefixEntries in the actual router.
• Execute a method that configures each listed subscriber with an address or prefix from the new one.
  • This method may in turn execute a method that configures the corresponding ipAdEntAddr, ipAddressAddr, and ipAddressPrefixEntries in the subscriber equipment.
  • If it elects to let DHCP do the configuration, at some point later the subscriber will ask the DHCP server to execute a similar method that populates information elements in the DHCP response.

One could imagine further hierarchy: On operator might divide his network up into regions that use a specified prefix, such as in OSPF Areas, and have a method that recursively uses the method just described to add a prefix to each LAN interface in the area. That would be useful if the operator simply wants to add a prefix. If the operator additionally wants to reorganize his area, such as subdividing it into smaller areas or combining or dividing subnets, that will likely be at least in part a manual procedure.

3. IANA Considerations

This memo asks the IANA for no new parameters.

4. Security Considerations

There are many potential and real security issues in network configuration management. This note doesn't address them.

5. Privacy Considerations

There are many potential privacy issues in network configuration management. This note doesn't address them.

6. Acknowledgements

This note developed from a conversation with Brian Carpenter and Tim Chown.

7. Change Log

Initial Version:

November 2012

8. References

8.1. Normative References

8.2. Informative References

Author's Address