Internet DRAFT - draft-baker-6renum-oss-renumbering
draft-baker-6renum-oss-renumbering
6renum F. Baker
Internet-Draft Cisco Systems
Intended status: Informational November 5, 2012
Expires: May 9, 2013
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 9, 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.
Baker Expires May 9, 2013 [Page 1]
Internet-Draft Renumbering by the OSS November 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Using the OSS for address and prefix management . . . . . . . . 4
2.1. What is an Operational Support System? . . . . . . . . . . 4
2.2. Implementing RFC 4192 . . . . . . . . . . . . . . . . . . . 4
2.3. Renumbering using an OSS . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Baker Expires May 9, 2013 [Page 2]
Internet-Draft Renumbering by the OSS November 2012
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.
Baker Expires May 9, 2013 [Page 3]
Internet-Draft Renumbering by the OSS November 2012
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:
o adding a new prefix to a network or a part of the network, and
o 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.
Baker Expires May 9, 2013 [Page 4]
Internet-Draft Renumbering by the OSS November 2012
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:
Baker Expires May 9, 2013 [Page 5]
Internet-Draft Renumbering by the OSS November 2012
o It is likely built on a database,
o Individual objects, such as subscriber entries, can have sets of
attributes, such as IPv4 or IPv6 addresses or prefixes,
o 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
o Add the prefix to the list
o Execute a method that configures the corresponding ipAdEntAddr,
ipAddressAddr, and ipAddressPrefixEntries in the actual router.
o 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.
Baker Expires May 9, 2013 [Page 6]
Internet-Draft Renumbering by the OSS November 2012
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
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006.
8.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
RFC 1900, February 1996.
[RFC1916] Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser,
Baker Expires May 9, 2013 [Page 7]
Internet-Draft Renumbering by the OSS November 2012
"Enterprise Renumbering: Experience and Information
Solicitation", RFC 1916, February 1996.
[RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering
Overview: Why would I want it and what is it anyway?",
RFC 2071, January 1997.
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
January 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874,
July 2000.
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894,
August 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
Requirements for Stateless Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010.
Baker Expires May 9, 2013 [Page 8]
Internet-Draft Renumbering by the OSS November 2012
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Baker Expires May 9, 2013 [Page 9]
