One document matched: draft-baker-6renum-oss-renumbering-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-6renum-oss-renumbering-00"
ipr="trust200902">
<front>
<title abbrev="Renumbering by the OSS">Renumbering using an Operational
Support System</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2012" />
<area>Operations and Management</area>
<workgroup>6renum</workgroup>
<abstract>
<t>This document comments briefly on the use of an Operational Support
System to renumber all or part of a network.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>This document comments briefly on the use of an Operational Support
System to renumber all or part of a network.</t>
<t>When the question of renumbering a network, discussed previously in
<xref target="RFC1900"></xref>, <xref target="RFC1916"></xref>, <xref
target="RFC2071"></xref>, <xref target="RFC2072"></xref>, <xref
target="RFC2874"></xref>, <xref target="RFC2894"></xref>, <xref
target="RFC4076"></xref>, <xref target="RFC4192"></xref>, and <xref
target="RFC5887"></xref>, came up yet again in the IETF, the author's
comment, besides pointing to the issues raised in The <xref
target="RFC4192"></xref>, 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 <xref target="RFC0791">IPv4</xref> or <xref
target="RFC2460">IPv6</xref> 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 <xref
target="RFC4293">IP MIB</xref> 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.</t>
<t>The <xref target="RFC4192">"Procedures for Renumbering an IPv6
Network without a Flag Day"</xref> 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. <xref
target="RFC4192"></xref> 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.</t>
<t>This note does not pretend to fix the problem of human creativity. It
does, however, discuss how one might implement the procedure of <xref
target="RFC4192"></xref> in one's Operational Support System in a
reasonable way.</t>
<!--
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
-->
</section>
<section anchor="sect2"
title="Using the OSS for address and prefix management">
<t></t>
<section title="What is an Operational Support System?">
<t>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.</t>
</section>
<section title="Implementing RFC 4192">
<t>The steps considered in <xref target="RFC4192"></xref> fall broadly
into two categories: <list style="symbols">
<t>adding a new prefix to a network or a part of the network,
and</t>
<t>removing an old prefix from that network or part of a
network.</t>
</list></t>
<t>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.</t>
<t>To add a prefix to a network, one takes several steps: <list
style="numbers">
<t>Initial condition: the network and its services are operating
and supporting services with one or more prefixes.</t>
<t>Add the prefix to the routing system, including a prefix on
each LAN (and therefore a subnet), advertised in routing.</t>
<t>Add an address in the added prefix to each host in the domain;
this might be done using <xref target="RFC2131">DHCP</xref> <xref
target="RFC3315"></xref> or <xref target="RFC4862"> Stateless
Address Autoconfiguration</xref><xref target="RFC4941"></xref> by
making the new prefix a "preferred" prefix.</t>
<t>As interfaces acquire their new addresses, add resource records
to DNS enabling systems to use them.</t>
<t>Resulting condition: the network and its services are operating
and supporting services with the original set of prefix(es) plus
the new one.</t>
</list></t>
<t>To remove a prefix from a network, one takes a corresponding series
of steps: <list style="numbers">
<t>Initial condition: the network and its services are operating
and supporting services with two or more prefixes.</t>
<t>Remove resource records using the legacy prefix from DNS,
causing new accesses to services to use the prefixes not being
removed.</t>
<t>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.</t>
<t>Remove the indicated addresses from the routing domain; this
might be done using <xref target="RFC2131">DHCP</xref> <xref
target="RFC3315"></xref> or <xref target="RFC4862"> Stateless
Address Autoconfiguration</xref><xref target="RFC4941"></xref> by
making the prefix no longer be "preferred".</t>
<t>Remove the prefix from the routing system.</t>
<t>Resulting condition: the network and its services are operating
and supporting services with the remaining prefix(es).</t>
</list></t>
<t><xref target="RFC4192"></xref> 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.</t>
</section>
<section title="Renumbering using an OSS">
<t>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:<list
style="symbols">
<t>It is likely built on a database,</t>
<t>Individual objects, such as subscriber entries, can have sets
of attributes, such as IPv4 or IPv6 addresses or prefixes,</t>
<t>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.</t>
</list></t>
<t>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 <list style="symbols">
<t>Add the prefix to the list</t>
<t>Execute a method that configures the corresponding ipAdEntAddr,
ipAddressAddr, and ipAddressPrefixEntries in the actual
router.</t>
<t>Execute a method that configures each listed subscriber with an
address or prefix from the new one. <list style="symbols">
<t>This method may in turn execute a method that configures
the corresponding ipAdEntAddr, ipAddressAddr, and
ipAddressPrefixEntries in the subscriber equipment.</t>
<t>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.</t>
</list></t>
</list></t>
<t>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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>There are many potential and real security issues in network
configuration management. This note doesn't address them.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>There are many potential privacy issues in network configuration
management. This note doesn't address them.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This note developed from a conversation with Brian Carpenter and Tim
Chown.</t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">November 2012</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.4192" ?>
<?rfc include="reference.RFC.4293" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.1900" ?>
<?rfc include="reference.RFC.1916" ?>
<?rfc include="reference.RFC.2071" ?>
<?rfc include="reference.RFC.2072" ?>
<?rfc include="reference.RFC.2131" ?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.2874" ?>
<?rfc include="reference.RFC.2894" ?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.RFC.4076" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.5887" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:39:37 |