Configuration and evolution of the management plane during ...

steambeanSoftware and s/w Development

Jun 30, 2012 (5 years and 4 months ago)

508 views

ISSN 0249-0803
apport

t echni que
Th
`
eme COM
INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE
Configuration and evolution of the management
plane during and after an IPv6 renumbering
operation
Fr´ed´eric Beck —Olivier Festor
N

????
April 2005
Unit´e de recherche INRIA Lorraine
LORIA,Technopˆole de Nancy-Brabois,Campus scientifique,
615,rue du Jardin Botanique,BP 101,54602 Villers-L`es-Nancy (France)
T´el´ephone:+33 3 83 59 30 00 —T´el´ecopie:+33 3 83 27 83 19
Configuration and evolution of the management plane
during and after an IPv6 renumbering operation
Fr´ed´eric Beck,Olivier Festor
Th`eme COM — Syst`emes communicants
Projet MADYNES
Rapport technique n

????— April 2005 — 40 pages
Abstract:While renumbering is one of the very useful features of IPv6,its impact on the
various planes of a network has not been investigated in depth so far.In this report,we
present the results we obtained in investigating the impact of renumbering on the manage-
ment plane of IPv6 networks.

Key-words:IPv6,renumbering,management,monitoring,network

This work has been done as part of the IST 6net project
Configuration et ´evolution du plan de management
pendant et apr`es une op´eration de renum´erotage IPv6
R´esum´e:Alors que le renum´erotage d’un r´eseau est l’une des fonctionnalit´es les plus
utiles dans IPv6,son impact sur les diff´erents plans d’un r´eseau n’a pas encore fait l’objet
d’investigations pouss´ees.Dans ce rapport,nous pr´esentons les r´esultats issus de nos inves-
tigations sur l’´evaluation de l’impact d’un renum´erotage sur le plan de supervision dans les
r´eseaux IPv6.

Mots-cl´es:IPv6,renum´erotage,management,supervision,r´eseau

Ces travaux ont ´et´e effectu´es dans le cadre du projet 6net IST
IPv6 renumbering & the management plane 3
Contents
1 Introduction 5
2 IPv6 renumbering 5
2.1 IPv6 Overview...................................5
2.2 Address Autoconfiguration............................6
2.2.1 Link Local Address.............................7
2.2.2 StateLess Address Autoconfiguration...................8
2.2.3 Stateful Address AutoConfiguration...................8
2.3 Network Renumbering...............................9
2.3.1 Triggers...................................9
2.3.2 Requirements for the end-user......................9
2.3.3 Keys of a renumbering...........................10
2.3.4 Special cases................................10
2.3.5 Procedure..................................11
2.3.6 Things to keep in mind when renumbering an IPv6 network......13
3 Network management 14
3.1 Overview......................................14
3.2 Supervision Tools..................................14
3.2.1 Net-SNMP.................................15
3.2.2 MRTG....................................16
3.2.3 Nagios....................................17
3.2.4 NTop....................................19
4 Impact of renumbering on the management plane 20
4.1 Objectives......................................20
4.2 Scenarios......................................21
4.3 Testbed.......................................22
4.4 Renumbering with a prefix which has the same length.............26
4.4.1 NetSNMP..................................27
4.4.2 MRTG....................................27
4.4.3 Nagios....................................29
4.4.4 NTop....................................32
4.5 Renumbering with a prefix which has not the same length...........34
5 Guidelines 34
5.1 How to restore the management plane?.....................34
5.2 How to prevent service outage?..........................35
5.3 How to implement the tools in order to avoid troubles?............36
RT n

0123456789
4 Frederic Beck & Olivier Festor
List of Figures
1 IPv4 and IPv6 packet headers...........................6
2 Link Local Address Generation Algorithm....................7
3 Example of a graphic generated with MRTG..................17
4 Nagios WEB interface:Host state information.................19
5 Nagios WEB interface:Services details for a host...............19
6 Ntop WEB interface:the hosts section.....................20
7 The testbed in a stable situation.........................23
8 MRTG Graph for the old address.........................28
9 MRTG Graph for the new address........................28
10 MRTG Graph when using the script.......................30
11 NTop in a stable configuration..........................33
12 NTop after several renumberings.........................33
INRIA
IPv6 renumbering & the management plane 5
1 Introduction
Over the last ten years,IPv6 [7] has been the focus of many research and developments,but
as the need of a management plane for IP networks has only appeared with the explosion of
the internet during the nineties,it is only in the last few years that the management plane
has been studied in depth for this protocol.
The first concerns in this context were the representation of IPv6 addresses in SMI (Struc-
ture of Management Information) and SNMP evolutions [12],transition mechanisms [11],
IPv4 [19]/IPv6 [3] cohabitation and the porting and migration of existing management tools.
While many advances have been made in the provision of robust tools for monitoring
and configuring IPv6 networks,the impact of advanced built-in services in IPv6 on the
management plane has not been evaluated yet.
In this report,we focus on the study of one of these services,namely IPv6 network
renumbering,and especially the impact of this procedure on the management plane.Before
taking a look at our study itself,we present IPv6 generalities,the renumbering procedure,
and the applications of the management plane which are used within our experiments.Once
the context is introduced,we describe the testbed and the scenarios used,and the results
and conclusions made.Finally,by basing us on these,we give general guidelines on how to
renumber an IPv6 network while a management plane is set up.
2 IPv6 renumbering
2.1 IPv6 Overview
Internet constantly evolved since the first days of Arpanet,the origin of the first packet
switched networks in the middle of the seventies.However,its growth since 1992,and the
first commercial offers,brought a certain number of major problems such as the explosion
of the routing tables and the saturation of the address space.
Some temporary solutions have been used,such as the Network Address Translation
(NAT [20]) which uses a private addressing space to reduce the number of addresses used by
a site or network,or Classless Internet Domain Routing (CIDR [10]) for the routing part.
The version 6 of the IP protocol,IPv6 (originally known as IPng for IP Next Generation),
has thus been developed in order to correct the problems encountered with IPv4.
To begin with,the addressing space is much larger,growing from 32 bits to 128 bits
which should permit to address all the desired devices without using mechanisms like NAT
(which isn’t recommended for use with IPv6),and the routing table space explosion has
been solved with the aggregated addressing scheme.
As shown in figure 1,the protocol’s header has been simplified,and the field Next Header
permits easily to add options or protocol extensions.
With IPv6,new functionalities are available,such as the Address Autoconfiguration (see
section 2.2),the field Flow Label which facilitates the Quality of Service (QoS),security
RT n

0123456789
6 Frederic Beck & Olivier Festor
Figure 1:IPv4 and IPv6 packet headers
(data integrity and authentification) - whereas these two points are considered as an ap-
plication matter in IPv4,source routing and a built-in multicast which is more efficiently
routed.
As of today,more than 100 RFCs deal with IPv6,describing either built-in mechanisms
or guiding principles,such as the Addressing Architecture [13],or new protocols/extensions
born with IPv6 or transposed from IPv4.
The most known of these protocols or extensions are:
• the Neighbor Discovery (NS [18]) protocol which makes possible for hosts which are
sharing the last 24 bits of their MAC address on the same physical support to discover
their mutual presence,to find these neighbors’ layer 2 addresses and to locate the
routing equipments thanks to use the use on specific multicast adresses.
• DHCPv6 [8] (see section 2.2.3) and SLAAC [22] (see section 2.2.2) which are the main
actors of the address autoconfiguration.
• Mobile IPv6 (MIPv6 [15]) which allows mobile nodes to change their IPv6 network in
a transparent way for the upper layers without losing the connectivity.
• IPsec (IP Security [16]) which permits the protected exchange of IP level packets,
thanks to the encryption of IP data or header.
• Routing Protocols extended to support IPv6:RIPng [17],OSPFng [2]...
• SMI and SNMP extensions [12,5,6]
2.2 Address Autoconfiguration
One of the main features provided by IPv6 is the address autoconfiguration capability which
offers a built-in mechanism for a host to determine its IPv6 addresses.
INRIA
IPv6 renumbering & the management plane 7
IPv6 defines in its addressing architecture [13] the notion of scope which describe the
validity of an IPv6 address.The IPv6 Address Autoconfiguration is composed of two steps:
first,a host determines its Link Local Address (LLAsee section 2.2.1),after what it performs
SLAAC (see section 2.2.2) or SAAC (see section 2.2.3) to generate a Global or Site Address.
2.2.1 Link Local Address
This is the first step in Address Autoconfiguration,in which a device creates its LLA which
will permit,thanks to the use of defined multicast addresses,to discover the routers,DHCP
servers and communicate with them.
This operation is completely automatic and independent from any network equipment
such as a router (it is performed on the host itself).
As we can see in figure 2,this address is computed by adding the FE80::/10 prefix to
the interface identifier’s 64 bits derived from the MAC Address.
Figure 2:Link Local Address Generation Algorithm
At this stage,a host uses Duplicate Address Detection (DAD [22]) to verify the unique-
ness of its LLA by sending a Neighbor Solicitation (NS) message,using the Neighbor Discov-
ery protocol,to the solicited multicast address FF02::1:FFXX:XXXX,where ”XX:XXXX”
are the 24 last bits of the interface’s EUI-64 [14].It then listens for a Neighbor Adver-
tisement (NA) in response that indicates that another device is already using a link-local
address with the same 24 last bits;if the LLA and the addresses of the hosts which have
responded are equal,either a new address must be generated,or autoconfiguration fails and
another method must be employed.
RT n

0123456789
8 Frederic Beck & Olivier Festor
Assuming the uniqueness test passes successfully,the device assigns the link-local ad-
dress to its IP interface.This address can be used for communication on the local network,
but not on the Internet (since link-local addresses are not routed).
Now,the host must use either SLAAC or SAAC to pursue its configuration.
2.2.2 StateLess Address Autoconfiguration
This method uses the Router Advertisement (RA) sent by routers to all the nodes on the
same link using the defined multicast address FF02::1.These messages are sent periodically
by all routers,but hosts can trigger this event by sending a Router Solicitation (RS) to all
the routers (FF02::2).
First of all,a flag in the RA received will tell the host if it should use SLAAC or SAAC
(in this case the message contains the DHCPv6 server’s address) to configure itself.
If SLAAC is the recommended one,the prefix(es) to use is(are) included in the RA,
and the host can configure his address(es) by adding the announced prefix(es) to the in-
terface’s 64 bit identifier,in the same way that it was done for the LLA.In the example
used in figure 2,if the prefix 2001:660:4501:1::/64 is announced,the host will compute
2001:660:4501:1:211:11ff:fe4d:8200 as global address.
The router doesn’t keep any information on the hosts’ state or addresses,it only an-
nounces a prefix and lets them take care of everything.
2.2.3 Stateful Address AutoConfiguration
SAAC differs from SLAAC from the management of addressing:a DHCPv6 server is
in charge of giving and managing the hosts’ addresses.It keeps information about the
used addresses,and the same mechanisms as in IPv4 are available (options personalisation,
filtering,address assignement based on MAC addresses...).
The procedure is as follows:
1.after setting up a LLA,a host which has to configure itself using SAAC sends a message
DHCP Solicit to the defined multicast address All
DHCP
Relay
Agents
and
Servers
(FF02::1:2) to find the DHCP capable servers.
2.the servers answer with a DHCP Advertise.
3.after receiving these advertisements,the host elects one of the servers which has re-
sponded and sends him a DHCP Request.
4.the server sends a DHCP Reply with the assigned address.
The host can then assign the address contained in this last message to its IP interface.
Dynamic Updates to DNS [23] can be used by DHCP to maintain up-to-date the corre-
sponding DNS entries.
INRIA
IPv6 renumbering & the management plane 9
2.3 Network Renumbering
Renumbering an IPv6 network consists in changing the prefix of this network.In this section,
we will explain the causes of such an operation,the problems it generates,and how this is
performed concretely.This can be done with a planned service outage,called a flag-day,
or without such a flag-day as explained in section 2.3.5 which is considered as the default
procedure.
Several investigations are already taking place on this topic,and 2 Internet drafts have
been published on this topic recently.The first one acts as a reminder for all the things
which are important when the renumbering of a network is performed [21],the second one
describes the different steps of a renumbering procedure [9].These are our main references.
2.3.1 Triggers
A renumbering can be triggered by many different causes,the main ones being:
• the uplink prefix changes,mostly because of the migration to a new provider or a
change in its topology,a transition to IPv6 (from a 6to4 architecture for example),
or a Dial on Demand connection,in which the allocated prefix may change at each
connection.
• a network merge (after the merge of two organisations or companies for example) or
growth.
• a change in the internal topology.
• network mobility with Nemo [?] or for wireless networks.
Some of these are dependent fromthe network administrator which can control themand
plan their occurence,others aren’t and are the most critical ones.As a network renumbering
can lead to service outages (for a rather long period,depending on the services and how the
renumbering has been prepared),there are some points to keep in mind when performing
such an action (see section 2.3.6).
Moreover,the frequency of these events is very variable,and can complicate the task of
the administrator.Indeed,when using a Dial on Demand connection,the prefix can change
at each connection and thus trigger a renumbering at each connection whereas a migration
to a new provider shouldn’t happen too often.
It is very important,before doing a renumbering,to identify the cause and if possible
the moment when it will occur in order to make the needed preparations in order to prevent
as many problems as possible.
2.3.2 Requirements for the end-user
Renumbering a network must imply as less disruptions for the users as possible.The best
case would be that they do not notice anything,i.e.that it is completely transparent for
them.
RT n

0123456789
10 Frederic Beck & Olivier Festor
To minimize the potential embarrassment and disruption,it is necessary to take into
account the sessions in progress at the time of the operation and their survivability.We
have chosen to differentiate these sessions by using their duration,which permits us to emit
certain predictions as for their behavior after a renumbering:
• short-term sessions (such as HTTP):if the DNS entries and caches are updated,no
impact is expected.
• medium-term sessions (SSH for example):usually,they will need to be restarted to
take in account the changes in network addresses.
• long-termsessions (such as NFS):these sessions can last several months,and generally
make only one DNS resolution at the beginning and keep the result in a cache,thus
they need to be reconfigured and restarted (the best would be to do so during the
transition phase as seen in section 2.3.5).
2.3.3 Keys of a renumbering
Before performing the renumbering of a network,the network administrator has to prepare
certain points and check the availability of some functionalities and mechanisms.
To begin with,the hosts have to be able to use several addresses on the same interface
(multihoming).
Then,the network administrator must be prepared to perform the renumbering of all
the routers,either manually or thanks to the use of a defined ICMPv6 [4] message sent to
the all
routers address (FF05::2 or FF02::2).As it is shown in section 2.3.5,this operation
goes with the set up in the ingress routers of the filtering for the new prefix.
Moreover,there will always be a transition period when performing a renumbering where
the old and the new prefixes will both be present and working on the network.A good
compromise should be found to define this period’s duration,because if it is too short,the
network administrator won’t be able to ensure the migration of all services or the problems
correction (which could imply service outage after the transition),but as this situations
implies an overcost in terms of money and resources,it is better it does not last too long.
This means that,if it is possible to plan the day and time the renumbering will occur,
there is a need to adjust the prefixes’ lifetimes in RAs,DHCP leases,DNS entries validity
in caches...
2.3.4 Special cases
Mobility
In the case of the use of MIPv6 [15],it is possible to distinguish different renumbering
scenarios:
• renumbering of the visited network:it is the same than changing the network when
moving,the Mobile Node (MN) gets a new care-of address and informs its Home Agent
(HA) with MIPv6 mechanisms.
INRIA
IPv6 renumbering & the management plane 11
• the Home Network renumbers while the MN is in a visited network and registered:
MIPv6 has built-in mechanisms which permits thanks to ICMPv6 messages called Mo-
bile Prefix Solicitation and Mobile Prefix Advertisement to update the HA’s address.
• Home Network renumbering when the MN isn’t registered:the MN must run again
the HA discovering procedure.
Network Address Translation (NAT)
Although NAT isn’t recommended for use with IPv6,it has been mentioned as a possible
solution to avoid renumbering a whole network:only the edge router is renumbered,the
hosts’ addresses don’t change and this edge router uses NAT.
It could have been a good solution to avoid some problems linked to the renumbering
and make it easier,but this procedure has been abandoned as NAT is being avoided with
IPv6.
2.3.5 Procedure
As it has already been said,there are two possible procedures for renumbering an IPv6
network:
• using a Flag Day,which means a planned transition with service outage.
• without using a Flag Day [9].
The second way is the preferred one which we will describe below.
Step 1:Preconditions
Before renumbering a network,we must be in a stable and working situation with an existing
prefix which we will call the old prefix.
Moreover,IPv6 hosts must be configured to perform Address AutoConfiguration and be
able to use multiple addresses on the same interface (multihoming).
Step 2:Preparations
The first step is to obtain the new prefix and new reverse zone fromthe delegating authority.
Then,before any device or service reconfiguration,each link must be assigned a sub-prefix
from the new prefix.
Once this is done,DNS and DHCP servers must be reconfigured.New DNS entries are
added for the new prefix,and the TTL of the entries are updated so that the hosts must
carry out more regular requests and not keep out-of-date data in their cache.DHCP leases
must also be adapted to ensure addresses update.This operations can be done either at
”old lease” seconds before the renumbering (so that when the renumbering occurs,hosts
have already taken in account the new leases) or use a message DHCP RECONFIGURE to
trigger the update when the renumbering begins.
RT n

0123456789
12 Frederic Beck & Olivier Festor
Step 3:Configuring switches and routers for the new prefix
Whereas the existing routing architecture remains,we have to set up a parallel routing
architecture for the new prefix.
This means that all the routers and switches must be configured (addresses and routes)
according to the new prefix whereas as it doesn’t appear in RA (unless hosts would perform
SLAAC and the network isn’t ready yet to forward the data).
A very important point here,is that as soon as the routing architecture for the new prefix
is set up,it is vulnerable against attacks in the places where the new prefix is operational,
which is why filtering should be added in the ingress and egress access lists.
Once we are sure that all network services (DNS,DHCP...),firewalling rules,routing
infrastructure are operational,the prefix is advertised outside the network.
At the end of this phase,the whole network architecture is working for both prefixes.
Step 4:Hosts Addressing
The new prefix is advertised inside the network (included in RAs) which triggers the hosts’
addressing update,either by using SLAAC or SAAC.
It is important to update both DNS and reverse-DNS entries with the new addresses,
for example by using Dynamic DNS.
Step 5:Stable use of either prefix
Once the network has been configured with the new prefix and has had sufficient time to
stabilize,it becomes a stable platform with two addresses configured on each host,and two
non-link-local addresses are available for their use,one for the old prefix and one for the
new.The prefix with the longest preferred lifetime specified is used by default,but both
can be used efficiently.
This is a stable configuration where the network is multihomed.
Step 6:Transition from the old to the new prefix
When the new prefix has been fully integrated into the network,there is no need anymore to
keep the old prefix which is considered and advertised as obsolete:all lifetimes and TTLs
are set to 0 in RA and DHCP configuration.
As services are or become available through the newprefix,references to these services are
updated to use the new prefix (DNS resolutions updated in cache,DHCP reconfiguration...).
Each host chooses the right time for himto make the transition.We must be very careful
with DNS caches and hard-coded addresses in programs or configurations which aren’t valid
anymore.This means that as soon as the old prefix is announced as obsolete,it shouldn’t
be used anymore by the hosts (the address remains on the interface,but the applications
and the systems shouldn’t use it anymore to communicate with others).
INRIA
IPv6 renumbering & the management plane 13
When renumbering a server (DNS,DHCP,NTP...),we must keep in mind that users are
using this service and wait until all hosts use the new prefix for their requests before making
the transition.
Step 7:Old prefix removed
When all dependencies to the old prefix have been cleared,it can be removed from the
routing architecture,the RA (it isn’t announced anymore inside and outside the network)
or DHCP configuration,the DNS and reverse-DNS entries...
All the TTL and lifetimes for the new prefix are set to their default values.
When the timer associated to the old prefix’s address on hosts’ network interfaces has
expired (depending on the lifetime announced earlier),this address is suppressed from the
interfaces,and only the one corresponding to the new prefix remains.
Step 8:Postcondition
This is equivalent to the first state,but using the new prefix.
2.3.6 Things to keep in mind when renumbering an IPv6 network
When renumbering an IPv6 network,it is important to be attentive with certain points:
• manually configured hosts and devices do not perform address Autoconfiguration,the
network administrator must take care himself of the addressing with the new prefix.
• in lots of programs and applications,addresses are ”hard coded” in their configuration,
they need a manual update for these to keep working.
• in the same way,these addresses are present in routers,firewalls and switches and need
a manual update.
• some applications determine their local address at the start up and do not update this
information,and then need to be restarted when the local address changes.
Moreover,DNS is one of the main problems.
From the softwares’ point of view,problems can occur if they only resolve once and then
keep the result in a local cache for further use:the address resolved isn’t valid anymore and
the application doesn’t work anymore unless it makes a new resolution or it is restarted.It
is possible to avoid most of these problems (at least for applications which use the system’s
DNS cache) by setting shorter lifetimes for DNS entries in cache before the renumbering (as
said in section 2.3.5).
On the administrator’s side,it is important to keep in mind that updating these entries
takes some time and that the update of the secondary DNS servers takes even more time
RT n

0123456789
14 Frederic Beck & Olivier Festor
before the resolution works fine everywhere,so that he avoids service outage.
As a new prefix appears on the network,security problems appear as well.
When the routing architecture for the new prefix is being set up,the network parts were
the routing is working is vulnerable to attacks.To protect them,the first thing to do before
setting up this architecture is to update the ingress and egress access lists by including rules
for the new prefix,and,of course,not advertise this prefix outside the network before that
!This raises another problem:it is necessary,so that the renumbering proceeds correctly
if taking the assumption that this operation is triggered by the provider,that the network
administrator is well informed before the procedure takes place,in order to have enough
time to make the needed preparations,and especially for security matters.
Other security faults or service outage can appear because of a host’s or equipment’s
misconfiguration.To avoid this,it is important to check all hard coded addresses (as said in
the first point of this section),and use a transition period that is sufficiently long to detect
and correct these problems.Usually,modifications are done using a remote control on the
hosts,with SSH for example,that’s why having someone ”on site” with a physical access to
the hosts is preferred,in case of crash after an error in a configuration.
3 Network management
3.1 Overview
The management plane is used to ensure the quality of a network and its services through
automatic and remote monitoring and control operations.
Once it is set up and works fine,it allows the network administrator to monitor each
host,device or service on his network and to be informed of many problems without having
to leave its station,and more efficiently than with a physical check.
The alerts or problem detection can integrate a first level of diagnostic,and the use of
some tools or protocols makes possible to manage these devices at the same time they are
supervised.
3.2 Supervision Tools
Many different kinds of supervision/management tools are available today.Some of them
are used to collect statistics on the traffic of a network or hosts and thanks to them identify
possible problems.Some others are used to check the availability or configuration of hosts
or services.
These softwares are built differently.For example,a tool which will make statistics on
a network runs on a single host,sets the interface in promiscuous mode and captures the
traffic,whereas an application which checks the availability of hosts or services will run
on the monitoring stations and make requests on the host/service monitored to check it,
and finally some tools run on both the monitoring and the monitored station,the first one
INRIA
IPv6 renumbering & the management plane 15
retrieving information on the second one which can send alerts when a problem occurs.
In this section,we will present the four tools we deployed and tested and explain how to
configure them so that they work with IPv6 (the reference used is our testbed,see section
4.3).
3.2.1 Net-SNMP
Presentation
The Simple Network Management Protocol (SNMP [1]) is a widely used protocol for moni-
toring the health and welfare of network equipment (eg.routers),computer equipment and
even devices like Universal Power Supplies.Net-SNMP (http://www.net-snmp.org/) is
a suite of applications used to implement SNMP v1,SNMP v2c and SNMP v3 using both
IPv4 and IPv6.
The suite includes:
• an extensible agent for responding to SNMP queries for management information (sn-
mpd).This includes built-in support for a wide range of MIBinformation modules,and
can be extended using dynamically loaded modules,external scripts and commands.
• a daemon application for receiving SNMP notifications (snmptrapd).
• command-line applications to retrieve information from an SNMP-capable device (sn-
mpget,snmpgetnext,snmpwalk,snmptable,snmpdelta),manipulate configuration in-
formation on an SNMP-capable device (snmpset)...
• a graphical MIB browser (tkmib),using Tk/perl.
• a library for developing new SNMP applications,with both C and perl APIs.
Net-SNMP queries can be considered as short-term sessions as a new connection is made
to the daemon each time an operation GET or SET is made.
Configuration
Net-SNMP configuration to enable IPv6 support needs two steps.
Firstly,we must specify to the snmpd daemon to listen for IPv6 requests.This is done
by modifying the SNMPDOPTS variable in the file/etc/default/snmpd as follows:
SNMPDOPTS=’-Lsd -Lf/dev/null -p/var/run/snmpd.pid udp6:161’
Then,the daemon’s configuration itself must be modified (/etc/snmp/snmpd.conf ) to
allow access to the MIBs by creating a community and set its access rights:
RT n

0123456789
16 Frederic Beck & Olivier Festor
#sec.name source community
com2sec6 readonly6 default mycommunityv6
[...]
####
#Second,map the security names into group names:
#sec.model sec.name
group myv6group v2c readonly6
group myv6group v1 readonly6
group myv6group usm readonly6
[...]
####
#Finally,grant the 2 groups access to the 1 view with different
#write permissions:
#context sec.model sec.level match read write notif
access myv6group""any noauth exact all none none
The daemon is now configured to respond to IPv6 requests for the community mycommu-
nityv6.By replacing the attribute default by a network address,it is possible to forbid the
access to all hosts which are not in this range.
Unfortunately,for the moment (version 5.1.2),only the IPV6-MIB is available,the TCP
and UDP tables (IPV6-TCP-MIB and IPV6-UDP-MIB) for example are not supported yet.
To check the data in the IPV6-MIB,a host may use the following command:
% snmpwalk -v 2c -c mycommunityv6 udp6:[2001:660:4501:1:211:11ff:fe4d:8200] mib-2.55
IPV6-MIB::ipv6Forwarding.0 = INTEGER:notForwarding(2)
IPV6-MIB::ipv6DefaultHopLimit.0 = INTEGER:64
IPV6-MIB::ipv6Interfaces.0 = Gauge32:2
IPV6-MIB::ipv6IfDescr.1 = STRING:lo
IPV6-MIB::ipv6IfDescr.3 = STRING:eth0
IPV6-MIB::ipv6IfLowerLayer.1 = OID:SNMPv2-SMI::zeroDotZero
IPV6-MIB::ipv6IfLowerLayer.3 = OID:SNMPv2-SMI::zeroDotZero
IPV6-MIB::ipv6IfEffectiveMtu.1 = Gauge32:16436 octets
IPV6-MIB::ipv6IfEffectiveMtu.3 = Gauge32:1500 octets
IPV6-MIB::ipv6IfPhysicalAddress.1 = STRING:
IPV6-MIB::ipv6IfPhysicalAddress.3 = STRING:0:11:11:4d:82:0
IPV6-MIB::ipv6IfAdminStatus.1 = INTEGER:up(1)
IPV6-MIB::ipv6IfAdminStatus.3 = INTEGER:up(1)
IPV6-MIB::ipv6IfOperStatus.1 = INTEGER:up(1)
IPV6-MIB::ipv6IfOperStatus.3 = INTEGER:up(1)
3.2.2 MRTG
Presentation
The Multi Router Traffic Grapher (MRTG- http://people.ee.ethz.ch/

oetiker/webtools/
mrtg/) is a tool used to monitor the traffic load on network links.It generates HTML pages
containing graphical images representing the informations queried periodically on the mon-
itored hosts thanks to the SNMP protocol.Such a graphic is shown in figure 3.
MRTG does support SNMP over IPv6 and is widely used to monitor the traffic on
network links,CPU usage,and other host and network parameters.
INRIA
IPv6 renumbering & the management plane 17
Figure 3:Example of a graphic generated with MRTG
As MRTG uses SNMP,it also belongs to the short-term sessions category.
Configuration
MRTG’s configuration is simplified by the tool cfgmaker which permits to generate the
configuration file automatically thanks to the parameters given.These parameters are the
SNMP community,the host’s address and MRTG specific options.
The addresses can be either IPv4 or IPv6 addresses given with their usual notation.
However,to enable IPv6 support,the option –enable-ipv6 must be specified,which requires
the installation of the libraries libsocket6-perl and libio-socket-inet6-perl.
If we say that the configuration of the SNMP daemon in section 3.2.1 has been made
on the host luffy with an IPv6 address 2001:660:4501:1:211:11ff:fe4d:8200,the command
cfgmaker will be used as follows:
cfgmaker --enable-ipv6 --global ’WorkDir:/var/www/mrtg’
--global ’Options[_]:bits,growright’ --output/root/mrtg/luffy.cfg
mycommunityv6@[2001:660:4501:1:211:11ff:fe4d:8200]:161
Then,the configuration file for use for MRTG to monitor this host is available,and can
be used with the mrtg/root/mrtg/luffy.cfg command.This call has to be done periodically
to maintain the statistics up-to-date,for example by using a crontab entry:
*/5 * * * * mrtg/root/mrtg/mrtg.cfg >/dev/null 2>&1
3.2.3 Nagios
Presentation
Nagios (http://www.nagios.org/) is a host and service monitor designed to inform net-
work administrators of problems before clients,end-users or managers do.The monitoring
daemon runs intermittent checks on hosts and services specified using external ”plugins”
which return status information to Nagios.When problems are encountered,the daemon
can send notifications out to administrative contacts in a variety of different ways (email,
RT n

0123456789
18 Frederic Beck & Olivier Festor
instant message,SMS,etc.).Current status information,historical logs,and reports can all
be accessed via a web browser.
As the checks are done thanks to external plugins called periodically,Nagios’ checks can
be considered as short-term sessions.
Configuration
A set of ”official” plugins is available,but Nagios gives the possibility to the network admin-
istrator to write his own plugins simply by editing the file/etc/nagios/checkcommands.cfg,
for example to check the availability of an IPv6 WEB server:
define command {
command_name check_apache
command_line/usr/lib/nagios/plugins/check_http -6 -I $HOSTADDRESS$
}
Hosts’ configuration is the same for IPv4 and IPv6 addresses and is done in the file
/etc/nagios/hosts.cfg as follows:
define host{
use generic-host
host_name luffy
alias luffy.loria.fr
address 2001:660:4501:1:211:11ff:fe4d:8200
check_command check-host-alive
max_check_attempts 20
notification_interval 60
notification_period 24x7
notification_options d,u,r
}
Once the host is defined,corresponding checks must be defined.This is done by creating
entries in the file/etc/nagios/services.cfg,for example for the command we defined earlier:
define service{
use generic-service;Name of service template to use
host_name luffy
service_description Apache
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups linux-admins
notification_interval 120
notification_period 24x7
notification_options w,u,c,r
check_command check_apache
}
In addition to the alarms sent by mail or others,it is possible to check at every moment
the state of the supervised hosts and schedule the checks thanks to a WEB interface (see
figure 4 and 5).
INRIA
IPv6 renumbering & the management plane 19
Figure 4:Nagios WEB interface:Host state information
Figure 5:Nagios WEB interface:Services details for a host
3.2.4 NTop
Presentation
Ntop (http://www.ntop.org/) is a network traffic probe that shows the network usage,
similar to what the popular top Unix command does and is based on libpcap.Ntop users
RT n

0123456789
20 Frederic Beck & Olivier Festor
can use a web browser (figure 6) to navigate through Ntop (that acts as a web server) traffic
information and get a dump of the network status.In the latter case,ntop can be seen as
a simple RMON-like agent with an embedded web interface.
Figure 6:Ntop WEB interface:the hosts section
The use of a web interface,limited configuration and administration via the web interface
and reduced CPU and memory usage (they vary according to network size and traffic) make
ntop easy to use and suitable for monitoring various kind of networks.
Ntop is a daemon running on a host,and can be then qualified as a long-term sessions.
Configuration
Ntop’s configuration is really simple.There is only one file to modify,/var/lib/ntop/init.cfg
in which the user owning the process and the interfaces to monitor must be specified:
USER="ntop"
INTERFACES="eth0"
There is no specific configuration to make Ntop support IPv6,it is built-in:Ntop deter-
mines the local IPv4 and IPv6 addresses at the start up,set the interfaces in promiscuous
mode,captures the traffic,sorts it and makes statistics.However,we specified that the built-
in HTTP server should answer only to IPv6 queries by modifying the file/etc/default/ntop
and the GETOPT variable as follows:
GETOPT="--ipv6"
4 Impact of renumbering on the management plane
4.1 Objectives
Once the management plane is set up and works fine,it allows the network administrator
to monitor each node on his network and be informed of many problems.One of the main
INRIA
IPv6 renumbering & the management plane 21
advantages of IPv6 is the Address AutoConfiguration,which permits quite easily to renum-
ber an IPv6 network.But what happens to the management plane during and after this
operation?
The following questions were raised when thinking about the impact of renumbering on
the management plane:
• What happens to the management plane after and during a renumbering?
• Do the deployed management applications still work?Which applications will work,
and which won’t?
• What actions are required to solve the problems?
We aimat providing guidelines on howto renumber a network if management/supervision
applications are deployed,in which we explain what are the required actions,before,during
and after the renumbering in order to avoid having applications crashing or service outage.
Moreover,for some applications,after renumbering,there could be problems related to
data continuity (the past statistics and/or data collected may be corrupted or simply lost).
We offer scripts and develop (if needed) service extensions for the applications deployed in
our testbed (described in section 4.3) in order to overcome these problems.
Finally,based on the conclusions which we will draw from the study of the deployed
tools,we will give generic guidelines on how to renumber a network with a management
plane set up,while trying to maintain it stable.To begin with,we will tackle the problem
from the point of view of a network administrator and focus on the tools’ configuration.
Then we will take the point of view of a software developer and think on how to design
applications to avoid some problems (see section 5).
4.2 Scenarios
To identify all possible problems,we needed the most complete scenario.Therefore,we did
deploy the following architectures:
• a non-renumbered host monitors renumbered hosts.
• a renumbered host monitors non-renumbered hosts.
• a renumbered host monitors renumbered hosts.
The case were two non-renumbered hosts renumber each other is of no interest here,as
it is the most common usage.
RT n

0123456789
22 Frederic Beck & Olivier Festor
In addition of these different supervision architectures,we used different kinds of tools
configuration.
Traditionally,the hosts’ global address in configuration files is used.As our network is
multihomed (see testbed in section 4.3),we used the two available global addresses when
possible.
In addition,when hosts in the same network (namely the renumbered network) supervise
each other,we used the LLA,which is defined as unique and which still remains unchanged
after a renumbering.
Moreover,we set up a DNS server and used the DNS names of the hosts for the moni-
toring.
Finally,the monitoring hosts do monitor ALL monitored stations,which includes that
they monitor themselves,by using all the precedent addresses and in addition the localhost
address,[::1].
Thus,we obtain an environment in which all the possible cases are present,at the level
of the architecture of supervision or at the level of the tools configuration.
Once the management plane was set up according to these assumptions,we did proceed
on the experimentations.
At the beginning,we only renumbered a simple network,with one prefix once,then
several times,in order to draw a first set of results which were used as bases thereafter.
Then,the network became multihomed and we used the same procedure to confirm the
first results.
Each time a new version of a tool was released,we made again all the tests,so that we
did not miss a correction of one or more of the conclusions we made.
First,our experimentation was done while moving from a given prefix to a prefix with
the same length (actually from a 64 bits long prefix to a 64 bit long prefix).
After that,we will to make all these tests again when moving from a prefix to a longer
or shorter one.
4.3 Testbed
Initially very simple (1 router,1 network and prefix,1 host),our testbed evolved according
to the experimentations we made.
In the end,we obtained the architecture in figure 7,which shows our testbed in a stable
configuration.
The testbed is fully based on free and open source software.
All nodes are running a Debian GNU/Linux distribution on a 2.6.10 kernel with USAGI
IPv6 stack (www.linux-ipv6.org/),and all of them are monitored stations whereas the two
PC-routers are the only ones which aren’t working as monitoring stations.This means all
INRIA
IPv6 renumbering & the management plane 23
Figure 7:The testbed in a stable situation
the stations do run a Net-SNMP daemon,a Ntop daemon (to call them monitored stations
is,in fact,an langage abuse;we understand by this expression that they do not have a
centralized application monitoring hosts and services such as Nagios),and various monitored
services (an Apache HTTP server,a SSH server).
The non-renumbered station,luffy,is in LORIA’s IPv6 network.This is why its global
address remains the same (unless this network renumbers too of course).For this rea-
son,we set up the DNS server for the renumbered network on this host by using the
Berkeley Internet Name Domain (BIND) version 9 server.The domain name chosen is
ipv6.renumbering.loria.fr.As we already said,this host runs Ntop and NetSNMP daemons,
and it uses MRTGand Nagios to monitor all monitored stations and their associated services.
Our PC-routers,asterix and treize,use NetFilter to forward IPv6 packets to the core
network and radvd to send Router Advertisements (RA) and answer to Router Solicitations
(RS) on the renumbered network.These two will be the main actors in our renumbering sce-
narios by following the procedure described in section 2.3.5.The first tests were done while
following scrupulously this procedure,but after,as we were making successive renumbering,
we skipped some steps.
As said in the previous sections,the transition period’s length depends on the prefixes’
lifetimes announced.In the same way,before announcing the new prefix,the routing and
RT n

0123456789
24 Frederic Beck & Olivier Festor
firewalling architecture must be set,and the DNS entries have to be added,in order to avoid
service outage.
For convenience issues,we circumvented these problems,by setting an appropriate con-
figuration.Actually,since we renumber our test network with a high frequency,the lifetime
of our prefixes is 6 minutes and the preferred lifetime is 3 minutes.Concerning the DNS,
we set the TTL to low values,in order to trigger frequent updates:
• refresh every 2 minutes,
• retry every minute,
• expiry after 6 minutes,
• minimum of 3 minutes.
We used a script on the DNS server to update the entries (we could have set up a
Dynamic DNS architecture,but as we have only a few stations,we limited ourselves to this
solution),and added permanently the reverse DNS files.
In production network,such lifetimes and TTL shouldn’t be used,but these values permit
us not to wait too long before arriving in the situation which is interesting for us,the 8th
step,when the operation is completed.As these hosts are manually configured,they do not
perform Address Autoconfiguration.We included the address update in the script used to
perform the renumbering:
root@treize:~/multiple_renumbering
% cat renumbering_aaaa_to_bbbb.conf
#!/bin/bash
#Step 1:adding support for new prefix on router
echo"Step 1:adding support for new prefix on router"
ifconfig eth1 add 2001:660:4501:bbbb:250:daff:fedc:8ebb/64
route -A inet6 add 2001:660:4501:bbbb::/64 dev eth1 metric 1
#Step 2:advertise new prefixe
echo"Step 2:Advertising new prefix"
cp/root/multiple_renumbering/radvd_aaaa_bbbb.conf/etc/radvd.conf
/etc/init.d/radvd restart
sleep 30
#Step 3:Advertise the old prefix as obsolete
echo"Step 3:Advertise the old prefix as obsolete"
cp/root/multiple_renumbering/radvd_old_aaaa_new_bbbb.conf/etc/radvd.conf
/etc/init.d/radvd restart
sleep 30
#Step 4:suppress old prefix
echo"Step 4:suppress old prefix"
ifconfig eth1 del 2001:660:4501:aaaa:250:daff:fedc:8ebb/64
route -A inet6 del 2001:660:4501:aaaa::/64 dev eth1 metric 1
route -A inet6 del 2001:660:4501:aaaa::/64 dev eth1 metric 256
cp/root/multiple_renumbering/radvd_bbbb.conf/etc/radvd.conf
/etc/init.d/radvd restart
#Step 5:multiple_renumbering done
INRIA
IPv6 renumbering & the management plane 25
echo"Renumbering done."
ifconfig eth1
route --inet6
One can note that the transition period length is short (we could have waited at least a
duration equivalent to the prefix lifetime or DNS TTL),but as we are aiming at studying
the management plane after the renumbering,the transition has been shortened.
As our network only intends at being used for our tests,and how the routing proto-
cols work while renumbering isn’t in the scope of our study,we don’t have any routing
protocol working on these routers.The hosts in the renumbered network set their routes
automatically thanks to Address Autoconfiguration,the previous script updates routes on
the routers,and static routes are permanently set on the non-renumbered host.The traffic
from the renumbered network is forwarded thanks to Netfilter and the following scripts.
The script to start and stop the forwarding,ipv6
fw.sh:
#!/bin/bash
#
#IPv4 firewalling rules start/stop script
start()
{
echo"Setting up eth1 interface and setting up route:"
ifconfig eth1 up
ifconfig eth1 add 2001:660:4501:aaaa:250:daff:fedc:8ebb/64
route -A inet6 add 2001:660:4501:aaaa::/64 dev eth1 metric 1
echo"Starting IPv6 FW:"
modprobe ip6_tables
/root/firewalling/netfilter_ipv6.sh
echo"Starting Router Advertising Daemon:"
mv/root/renumbering/radvd_aaaa.conf/etc/radvd.conf
radvd
}
stop()
{
echo"Stopping IPv6 FW:"
/root/firewalling/netfilter_flush_ipv6.sh
echo"Stopping Router Advertising Daemon:"
killall radvd
echo"Shutting down eth 1:"
ifconfig eth1 down
}
case"$1"in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
RT n

0123456789
26 Frederic Beck & Olivier Festor
status)
echo"###ip6tables rules:"
/sbin/ip6tables -L
echo""
echo"###radvd running?"
ps axf | grep radvd
;;
*)
echo"Usage:ipv6_fw {start|stop|restart|status}"
esac
exit
The script containing the rules,netfilter
ipv6.sh:
#!/bin/bash
#check support
[!-f/proc/net/ip6_tables_names ] && echo"Current kernel doesn’t support ip6tables firewalling (IPv6)"
#enable forwarding
echo"1">/proc/sys/net/ipv6/conf/all/forwarding
ip6tables -F
ip6tables -t mangle -F
ip6tables -X
ip6tables -A INPUT -i lo -p ipv6 -j ACCEPT
ip6tables -A OUTPUT -o lo -p ipv6 -j ACCEPT
#rules
ip6tables -A INPUT -i eth0 -p ipv6 -j ACCEPT
ip6tables -A INPUT -i eth1 -p ipv6 -j ACCEPT
ip6tables -A OUTPUT -o eth0 -p ipv6 -j ACCEPT
ip6tables -A OUTPUT -o eth1 -p ipv6 -j ACCEPT
ip6tables -A FORWARD -i eth0 -o eth1 -p ipv6 -j ACCEPT
ip6tables -A FORWARD -i eth1 -o eth0 -p ipv6 -j ACCEPT
As we do not advertise the prefixes from the renumbered network outside this network,
we don’t take care of firewalling rules to protect it fromattacks,but in a production network
this has to be done.
These two PC-routers are running a Net-SNMP daemon,ntop,Apache and a SSH server
so that they act as monitored stations.
Finally,azenar and aria,the two hosts in the renumbered network are at the same
time monitoring and monitored station,thus running a Net-SNMP daemon,Ntop,MRTG,
Nagios and various services (Apache HTTP server,SSH server...).
These hosts are configured to use SLAAC for Address Autoconfiguration.
4.4 Renumbering with a prefix which has the same length
In this section,we present the results obtained fromour tests when renumbering the network
from an old prefix with a length of 64 bits to a new one with the same length.
INRIA
IPv6 renumbering & the management plane 27
4.4.1 NetSNMP
As said in section 3.2.1 presenting Net-SNMP,it uses two entities,the daemon running on
the monitored host,and the tools allowing the administrator to retrieve or modify informa-
tions by interacting with the daemon thanks to SNMP messages.
We configured the snmpd daemon so that it accepts connections from any host,without
making any filtering,thanks to the option default in the access definition.Thus,when
trying to modify (SNMP set) or retrieve (SNMP get or walk) informations,as long as these
operations are done on the new address,the daemon answers without restarting it.
But if a network address appears in the access definition,whatever the host is (renum-
bered or not),if this network address depends on the old prefix which isn’t in use anymore,
the connections are refused,the configuration must be updated and the daemon restarted.
All versions of SNMP work,and the user access control brought with SNMPv3,the
agent’s User-based Security Module (USM),is also working,as the user’s identification is
independent from the host’s address.
From the client point of view,SNMP SET/GET/WALK do work fine when using LLA,
and DNS as long as the entries are up-to-date.
However,it’s a pity that the TCP and UDP tables (IPV6-TCP-MIB and IPV6-UDP-
MIB) aren’t supported yet.Only the basic IPV6-MIB is working,which doesnt give any
information on TCP connections.Thus,we cannot follow the evolution of the global ad-
dresses during the renumbering and verify that the old one isn’t used anymore with SNMP.
4.4.2 MRTG
MRTG uses Net-SNMP to retrieve informations about configured hosts thanks to SNMP
GET messages and creates HTML indexes containing graphics generated with rrd tools.
Therefore,we can expect to have the same conclusions as for the client part of Net-SNMP,
and it is the case.Actually,whether we use the localhost address,the DNS or the link lo-
cal one,the renumbering does not affect MRTGwhich will always be able to update the data.
When using the host’s global address,if this one has changed,it has to be updated,
either by running again the cfgmaker tool or by editing manually the configuration file.
MRTG uses an external WEB server to display the HTML indexes generated.In our
case,the Apache2 WEB server was used.
As with a standard configuration (without any address declaration in the configuration
files),Apache is still operational after a renumbering without restarting the service,as long
as it is queried on the new address.
RT n

0123456789
28 Frederic Beck & Olivier Festor
Thus,MRTG indexes are still available after a renumbering without any intervention.
When browsing the directory containing these indexes (http://￿hostnameoraddress￿
/mrtg/),one can see all files (graphics generated,HTML indexes...) and can access them.
These files’ names,indexes and graphics,are prefixed with the host’s address.That’s
why,after renumbering and reconfiguring MRTG,new files are created when data are re-
trieved,prefixed with the new address,and all the past statistics are lost.For the same
host,we have then each file in two version,one per address,as shown in figures 8 and 9.
Figure 8:MRTG Graph for the old
address
Figure 9:MRTG Graph for the new
address
This is annoying,not only because data continuity isn’t assured,but also because the
number of files doubles,and it becomes hard and painful for the network administrator to
browse these files and find the host he is interested in.
Moreover,manually reconfiguring all the files can become a long and boring operation.
For all these reasons,we wrote a script making all the necessary reconfigurations.
Of course,this script isn’t the ”ultimate solution”,because it is depending on each mon-
itoring station’s,but it can be used as a reference and be adapted to every administrator’s
needs and architecture,but its first goal is to prove that data continuity can be assured after
the renumbering.
This script is quite simple,using only the sed (StreamEDitor) and mv (MoVe) commands
:
% cat mrtg_continuity.sh
#!/bin/bash
#
#MRTG Continuity after renumbering script
#
#Usage:./mrtg_continuity.sh <old_prefix> <new_prefix> <MRTG_config_files>
#The script takes 3 parameters
if [ $#-ne 3 ]
then
echo
echo"Usage:$0 <old_prefix> <new_prefix> <MRTG_config_files>"
exit 0
fi
#Step 1:rename files
echo"Step 1:renaming files in/var/www/mrtg"
INRIA
IPv6 renumbering & the management plane 29
for file in ‘ls/var/www/mrtg/*$1*‘
do
new=‘echo $file | sed s/$1/$2/g‘
mv ${file} $new
done
#Step 2:edit HTML file
echo"Step 2:replacing old file names in HTML files"
for file in ‘ls/var/www/mrtg/*$2*.html‘
do
sed s/$1/$2/g $file > $file\_modified
mv $file\_modified $file
done
#Step 3:edit configuration file
echo"Step 3:replacing old prefix by the new one in configuration files"
for file in ‘ls $3/*.cfg‘
do
sed s/$1/$2/g $file > $file\_modified
mv $file\_modified $file
done
exit 0
As we can see,this script takes care of updating the configuration files (while taking
for assumption that they all are in the same directory),renaming the indexes and graphics
filenames in/var/www/mrtg/,and updates these indexes according to these changes.It
takes as parameters the old prefix,the new one and the directory in which the configuration
files can be found.
If we take for hypothesis that we renumber our network fromthe prefix 2001:660:4501:aaaa::/64
to 2001:660:4501:bbbb::/64,and that all MRTG’s configuration files are in the directory
/root/mrtg/,we have to launch the script with the command line./mrtg
continuity.sh
2001:660:4501:aaaa::/64 2001:660:4501:bbbb::/64/root/mrtg.
Such an execution enables the merge of the two graphic from figures 8 and 9 into one
and only one,as shown in figure 10,so that we are able to ensure data continuity and keep
the same number of files.
Moreover,if one has set up additional HTML indexes in/var/www/mrtg/to display
differently the graphics by using an index instead of directory listing,this script can take
care of updating them simply by removing *$2* in step 2.
But one can note that when using DNS addresses,as the DNS name of the host given
when creating the configuration is used as identifier for the files,data continuity is assured,
as long as only the address changes during a renumbering procedure.
4.4.3 Nagios
Nagios is composed of two entities,namely the Nagios daemon and the plugins.The dae-
mons runs periodical tests on hosts or services by using the external plugins.This implies
RT n

0123456789
30 Frederic Beck & Olivier Festor
Figure 10:MRTG Graph when using the script
that a configuration modification,such as the addition or modification of a test or host
requires to restart the daemon for these to be taken in account.This behavior is different
from MRTG where the program is called each time the informations are updated,without
having a daemon running,which allows to modify the configuration between each call with-
out restarting the service.
Nagios integrates a WEB interface which allows the administrator to check the ser-
vices/hosts status and schedule the verifications.This interface is displayed by using an
external WEB server,Apache2 in our testbed.The availability of this interface after a
renumbering depends from this server.As Apache2 configured basically answers to queries
on the new address after a renumbering,this WEB interface is still working after the net-
work renumbering.
Nagios’ plugins do work when a host is monitoring itself by using its localhost address,
independently from the eventual changes on the interfaces’ addressing,which is why it still
works after a renumbering.
In the same way,these plugins can use the DNS address for a host.And as a new
address resolution is made each time the plugins is used (no address caching mechanism is
present),after a renumbering,if the DNS entries are up-to-date with the addressing,the
hosts/services are monitored on their new address without any reconfiguration or service
restart.
When using the Link Local Address,some plugins do work and some do not.Actu-
ally,most of them aren’t working.In our configuration,for each host,we check 5 services
with their associated plugins:check
ping,check
http,check
tcp,check
snmp and check
ssh.
Only one of these plugins does work with the LLA,the plugin check
snmp.As the LLA
doesn’t change after or during the renumbering of a network,this plugin is always functional.
When using global addresses,after a renumbering,these addresses aren’t valid any-
more and then the checks for the corresponding hosts aren’t working anymore.These ad-
dresses have to be updated in the configuration,each time they appear.Usually,the files
INRIA
IPv6 renumbering & the management plane 31
/etc/nagios/hosts.cfg and/etc/nagios/services.cfg are concerned,the first one because it is
the one holding the hosts’ definition,and thus their addresses,the second one can contains
also ”hard coded” addresses for some plugins.
Once the needed modifications have been made in the configuration,Nagios must be
restarted so that these configuration files are readed again and the modifications taken in
account.
Contrary to MRTG,Nagios doesn’t use the address as a key for data and status storage,
but the hostname defined in the file/etc/nagios/hosts.cfg.As long as this name doesn’t
change,modifying any other host parameter (address,checks...) and restarting the service
doesn’t affect in any manner the data continuity,there is no interruption in the historic.
After a renumbering,the only changes which are necessary concern the global addresses
which have changed,after what Nagios must be restarted.
Once again,if we have many hosts to monitor,it becomes painful to make all the updates
”by hand”,which is why we wrote a script similar than the one for MRTG to automatically
make these updates,which are then faster and easier to make.
It takes the same parameters as the previous one,and is simpler:
#!/bin/bash
#
#Nagios Continuity after renumbering script
#
#Usage:./nagios_continuity.sh <old_prefix> <new_prefix> <nagios_config_dir>
#The script takes 3 parameters
if [ $#-ne 3 ]
then
echo
echo"Usage:$0 <old_prefix> <new_prefix> <nagios_config_dir>"
exit 0
fi
echo"Step 1:Updating hosts adresses in $3/*.cfg"
for file in ‘ls $3/*.cfg‘
do
sed s/$1/$2/g $file > $file\_modified
mv $file\_modified $file
done
echo"Step 2:restarting nagios"
/etc/init.d/nagios restart
exit 0
If we take the same example as in the previous section,this script would be called with
./nagios
continuity.sh 2001:660:4501:aaaa::/64 2001:660:4501:bbbb::/64/etc/nagios.
RT n

0123456789
32 Frederic Beck & Olivier Festor
4.4.4 NTop
As it is the case for MRTG and Nagios,Ntop has a WEB interface for consulting the
statistics and make basic service administration,but whereas MRTG and Nagios use an
external WEB server (Apache2 in our testbed),Ntop has its own built-in HTTP server
listening on TCP port 3000.
Therefore,after a renumbering,the availability of this interface depends from Ntop it-
self.As Apache does,after a renumbering,the interface is available on renumbered hosts if
queried on the new address,without any reconfiguration or service restart.
When starting up,Ntop determines the local addresses and stores them.If these ad-
dresses change,after a renumbering for example,these are not updated,and the old and
obsolete ones remain,unless the service is restarted.
But when restarting the service,all the previously collected informations and statistics
are lost.
Nevertheless,even if the local addresses are modified after a renumbering,the statistics
are still updated without having to restart Ntop.Actually,this wasn’t working with previous
versions of Ntop,but after notifying the bug to the developers’ mailing list,this was corrected
in the current version (since end january 2005 and version 3.0-5).
This behavior seems logical,because since Ntop uses the pcap library (Packet CAPture
- http://sourceforge.net/projects/libpcap/),it should be independent from the local
addresses,as libpcap works on the interface level.
When a DNS server is present,Ntop makes the name resolution and identifies the hosts
thanks to this information.But when the hosts’ addresses change,even if the DNS entries
are updated accordingly,each time a new address appears,it is considered as a new host:
after renumbering,from the prefix 2001:660:4501:aaaa::/64 to 2001:660:4501:bbbb::/64,if
the host aria.ipv6.renumbering.loria.fr has the address 2001:660:4501:aaaa:201:2ff:fee3:608a
before the renumbering,and 2001:660:4501:bbbb:201:2ff:fee3:608a after,we’ll have two en-
tries,for the host aria.ipv6.renumbering.loria.fr with these two addresses.
In the same way,when the network is multihomed with the prefixes 2001:660:4501:aaaa::/64
and 2001:660:4501:dead::/64,all hosts multihomed with these two prefixes will appear only
once,whatever the address used is.But when renumbering the network,each new address
will be considered as a new host.
Figure 11 shows NTop hosts’ statistics in a stable situation with a multihomed network.
One can notice that only one entry is present for each host,whatever the address used is,
i.e.whatever the prefix used is,NTop aggregates the statistics.
In figure 12,one can see the same statistics,in a stable situation on the same host,but
after 7 renumberings.Whereas only one entry per host was present in figure 11,we can see
that 7 new entries have appeared and that only the entries standing for the current addresses
is being updated,the old ones are frozen.
INRIA
IPv6 renumbering & the management plane 33
Figure 11:NTop in a stable configuration
Figure 12:NTop after several renumberings
RT n

0123456789
34 Frederic Beck & Olivier Festor
4.5 Renumbering with a prefix which has not the same length
The next step we performed in our tests was to take a look at how the management would
behave if the renumbering was processed with a prefix with a different length,and especially
a prefix which could cause routes aggregation.
We imagined a scenario where two networks would merge and use after that a larger pre-
fix,including the two old ones (passing from2001:660:4501:aaaa::/64 and 2001:660:4501:aaab::/64
to 2001:660:4501:aaa::/63).
But,before modifying our testbed,we tried to simply renumber the existing one from
2001:660:4501:aaaa::/64 to 2001:660:4501:aaa::/63,and we realized it wasn’t working.
When looking at the system logs,we found messages like:IPv6 addrconf:prefix with
wrong length 63.
In order to understand what was happening,we checked this behavior in IPv6 specifica-
tions,namely the RFC 2460 [7] and 2462 [22].
We found our explication in the second one.
When performing SLAAC,the hosts form their site or global address by adding their 64
bits interface identifier to the prefix announced in the RA.
But the total length of the resulting address has to be 128 bits,with implies that
prefix
length +interface
identifier = 64
As the interface identifier is 64 bits long,the prefix length MUST be 64 bits.
5 Guidelines
Resulting fromour experimentations,we were able to establish guidelines on how to perform
a renumbering when having a management plane set up.
5.1 How to restore the management plane?
It is difficult to give general rules on how to repair the management plane after a renumber-
ing.Indeed,each tool is different,and the manipulations needed to restore them are specific
to each one of them.
Concerning the tools we deployed on our testbed,the best guidelines we could give are
the results given in section 4.4,where one can see the problems we encountered and how we
managed to correct them.
In a more general way,we can remind some of the points from section 2.3.6 which are
important here.
INRIA
IPv6 renumbering & the management plane 35
Firstly,it is vital to modify all ”hard coded” addresses in configuration files or in the
applications themselves.This can be a long,boring and painful operation if there are many
monitored hosts and/or services,which is why it is better to spend some time to write a
script to performthese operations automatically,by taking as a references the ones we wrote
for Nagios or MRTG in section 4.4.If applications determine or bind the local address at
the start up,they may need a restart,either to update this information or be functional
again.
Another point to keep in mind and which could cause the death of the management
plane is the DNS.
From the network point of view,entries have to be updated as described in section 2.3.5
and TTL/lifetimes adapted,unless applications (not only from the management plane but
all applications and services on the network) won’t be functional.
When taking a look at the applications themselves,design problems can be brought up
after a renumbering.Actually,it depends on how they were implemented.If the application
makes only one DNS resolution at the start up or the first time it is used,and keeps the result
in a cache for later use,it will cause problems,because the application may not be using the
right address,and may need to be restarted in order to take in account the modifications.
If the application makes periodical checks (or in the best case sytematic resolutions),in the
worst case,the interruption will last until the next resolution,but the service will not need
to be restarted to work (depends in fact from the DNS TTL/lifetimes).
This means that,by knowing the DNS lifetime,we are able to detect a cached reso-
lution which could lead to a service restart.After the DNS servers update,if at least a
duration equivalent to this lifetime has passed,all applications and services should have
made a new resolution and update their local cache,and thus should work by using the
new address which is the only one valid at that time.If an application isn’t working,we
can deduce that it did not make any new resolution,and that it only makes a single reso-
lution at its startup,which implies that it undergoes a restart to take in account the changes.
Finally,the nature of the application itself has a consequence on the actions triggered.
If the applications runs as a daemon (Nagios for example),a single modification of the
configuration implies that the daemon is restarted to take in account the modifications,
whereas an application which is run at each check (such as MRTG) doesn’t need to.
5.2 How to prevent service outage?
The first and most important condition to prevent problems when renumbering a network
is to know exactly WHEN it will occur.If the renumbering just happens without anybody
knowing it,no preparations can be made and it’s likely that not only the management plane
but the whole network will crash.
By knowing precisely what a renumbering is and what it implies,the administrator will
be able to avoid shooting himself in the foot by letting problems,which shouldn’t interfere
RT n

0123456789
36 Frederic Beck & Olivier Festor
with the management plane,complicate even more the situation (DNS update related prob-
lems,security issues...).
Moreover,the network administrator MUST know his management plane,which implies
the tools,their configuration and how they work.
If he does,he will be able to prevent some of the problems we have highlighted (miscon-
figuration,service restarting...).If he has one or more of the applications we deployed and
tested,it will be even easier.
Thus,the administrator will be able to identify each point which could be troublesome
:he will know where ”hard coded” addresses are,which daemons or applications may need
a restart etc...
Then,he will have the possibility to prepare scripts to perform the required actions or
prepare the right configuration files and simply copy them instead of the old ones at the
right time.
Even if the network administrator knows the applications he deployed and how they
behave,like for every modification made on a production network,it is preferable to test the
renumbering on a test network,on which the same services and applications will have been
deployed,prior to effective deployment.There,the network administrator will be able to
identify clearly the problems he will encounter,and envisage and test the actions which will
be necessary to himfor the restoration of its network and more particularly of its supervision
plane.
It is the best way for him to prepare the scripts he will use during the transition step,to
shorten this period.He will have everything in his hands so that he will know how to react
toward the situation.
Finally,it is possible to avoid some reconfiguration problems by centralizing the updates
at one point:the DNS.But this implies that the applications do work with DNS names
instead of addresses,that the resolution is made periodically,and that the entries are up-
to-date.
5.3 How to implement the tools in order to avoid troubles?
Software developers can avoid some problems by adapting the design of applications to the
problems encountered while renumbering a network.
One can note that no problem showed up for data continuity when using a defined
hostname to identify the hosts with Nagios,whereas we had troubles with MRTG using the
address.
This brings up an old questions which has already been discussed lots of times:should
we use a defined hostname or the address to identify a host in an application?
As shown in our experimentations,using a defined hostname as a key for sorting data
and statistics is the best solution in this case to ensure data continuity,as no modification
INRIA
IPv6 renumbering & the management plane 37
of this key is required to keep updating the same entries.
If an application is using DNS resolution,the main error to avoid is resolving only once
and keeping the result in a cache,because when doing so,after a renumbering,the resolution
made is false,and the application won’t be able to work anymore.
The more often the resolutions are made,the best it is,which implies that making a
systematic one each time the DNS name is used ensures to always use the right address (by
making the hypothesis that the DNS entries are up-to-date).
But this isn’t feasible for every applications.If an application uses frequently the DNS
addresses,it will cost too much time and resources to make a resolution at each time.
For these applications,DNS resolution can be cached,but lifetimes should be added so
that updates are done periodically (these lifetimes should be dynamic by using the values
announced by the DNS server in replies).
Moreover,before concluding that a host or service is down because there is an error when
sending a request on the cached address,a new DNS resolution has to be done to ensure
that there is no problem linked to an old resolution.If the error still remains after that,the
adapted conclusions can be made.
Another problemtriggered by the use of DNS is the DNS server’s address.If this address
changes during the renumbering,this information MUST be updated in the host’s config-
uration (in file/etc/resolv.conf ) in order for the host to make the resolutions.Since DNS
primitive in applications use this file to make the request to the right server,the applications
should not need to be restarted.
Finally,”hard coded” addresses should systematically be avoided in applications.
This implies that sockets shouldn’t be binded on local addresses determined at start up,
it is preferred to use the macro in6addr
any standing for the address::.
By doing so,we can avoid rebuilding or restarting applications when the local address
changes.
RT n

0123456789
38 Frederic Beck & Olivier Festor
Conclusion
Renumbering an IPv6 network can be a painful adventure,as it can cause the entire network
to break down,and imply a long period of service outage and countless problems.Even
if the management plane is broken after such an operation,if the administrator knows its
configuration and is able to be prepared at manually reconfiguring the applications deployed,
and as most of the problems are well known,the supervision plane can easily and quickly
be operational again.
By doing these experimentations,we highlighted a lack in management applications:
there is no application whose role is to supervise a renumbering.
The next step of our study will be to develop such an application,which will permit to
supervise a renumbering,detect the eventual problems in hosts’ addressing and make some
diagnostics on the monitored hosts concerning the applications they are running and which
could encounter problems after the renumbering is performed.
INRIA
IPv6 renumbering & the management plane 39
References
[1] J.Case,R.Mundy,D.Partain,and B.Stewart.Introduction to Version 3 of the
Internet-standard Network Management Framework.RFC 2570 (Informational),April
1999.Obsoleted by RFC 3410.
[2] R.Coltun,D.Ferguson,and J.Moy.OSPF for IPv6.RFC 2740 (Proposed Standard),
December 1999.
[3] A.Conta and S.Deering.Generic Packet Tunneling in IPv6 Specification.RFC 2473
(Proposed Standard),December 1998.
[4] A.Conta and S.Deering.Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification.RFC 2463 (Draft Standard),December 1998.
[5] M.Daniele.IP Version 6 Management Information Base for the Transmission Control
Protocol.RFC 2452 (Proposed Standard),December 1998.Obsoleted by RFC 4022.
[6] M.Daniele.IP Version 6 Management Information Base for the User Datagram Pro-
tocol.RFC 2454 (Historic),December 1998.Obsoleted by RFC 4113.
[7] S.Deering and R.Hinden.Internet Protocol,Version 6 (IPv6) Specification.RFC 2460
(Draft Standard),December 1998.
[8] R.Droms,J.Bound,B.Volz,T.Lemon,C.Perkins,and M.Carney.Dynamic Host
Configuration Protocol for IPv6 (DHCPv6).RFC3315 (Proposed Standard),July 2003.
[9] E.Lear F.Baker and R.Droms.Procedures for renumbering an IPv6 network without
a flag day - draft-ietf-v6ops-renumbering-procedure-03,November 2004.
[10] V.Fuller,T.Li,J.Yu,and K.Varadhan.Classless Inter-Domain Routing (CIDR):
an Address Assignment and Aggregation Strategy.RFC 1519 (Proposed Standard),
September 1993.
[11] R.Gilligan and E.Nordmark.Transition Mechanisms for IPv6 Hosts and Routers.
RFC 2893 (Proposed Standard),August 2000.
[12] D.Haskin and S.Onishi.Management Information Base for IP Version 6:Textual
Conventions and General Group.RFC 2465 (Proposed Standard),December 1998.
[13] R.Hinden and S.Deering.IP Version 6 Addressing Architecture.RFC 2373 (Proposed
Standard),July 1998.Obsoleted by RFC 3513.
[14] IEEE.Guidelines for 64-bits global identifier (EUI-64) registration authority -
http://standards.ieee.org/db/oui/tutorials/eui64.html,March 1997.
[15] D.Johnson,C.Perkins,and J.Arkko.Mobility Support in IPv6.RFC 3775 (Proposed
Standard),June 2004.
RT n

0123456789
40 Frederic Beck & Olivier Festor
[16] S.Kent and R.Atkinson.Security Architecture for the Internet Protocol.RFC 2401
(Proposed Standard),November 1998.Updated by RFC 3168.
[17] G.Malkin and R.Minnear.RIPng for IPv6.RFC 2080 (Proposed Standard),January
1997.
[18] T.Narten,E.Nordmark,and W.Simpson.Neighbor Discovery for IP Version 6 (IPv6).
RFC 2461 (Draft Standard),December 1998.
[19] J.Postel.Internet Protocol.RFC 791 (Standard),September 1981.Updated by RFC
1349.
[20] P.Srisuresh and K.Egevang.Traditional IP Network Address Translator (Traditional
NAT).RFC 3022 (Informational),January 2001.
[21] M.Thompson T.Chown and A.Ford.Things to think about when renumbering an
IPv6 network - draft-chown-v6ops-renumbering-thinkabout-00,October 2004.
[22] S.Thomson and T.Narten.IPv6 Stateless Address Autoconfiguration.RFC 2462
(Draft Standard),December 1998.
[23] P.Vixie,S.Thomson,Y.Rekhter,and J.Bound.Dynamic Updates in the Domain
Name System (DNS UPDATE).RFC 2136 (Proposed Standard),April 1997.Updated
by RFCs 3007,4033,4034,4035.
INRIA
Unit´e de recherche INRIA Lorraine
LORIA,Technopˆole de Nancy-Brabois - Campus scientifique
615,rue du Jardin Botanique - BP 101 - 54602 Villers-l`es-Nancy Cedex (France)
Unit
´
e de recherche INRIA Futurs:Parc Club Orsay Universit
´
e - ZAC des Vignes
4,rue Jacques Monod - 91893 ORSAY Cedex (France)
Unit´e de recherche INRIA Rennes:IRISA,Campus universitaire de Beaulieu - 35042 Rennes Cedex (France)
Unit´e de recherche INRIA Rhˆone-Alpes:655,avenue de l’Europe - 38334 Montbonnot Saint-Ismier (France)
Unit´e de recherche INRIA Rocquencourt:Domaine de Voluceau - Rocquencourt - BP 105 - 78153 Le Chesnay Cedex (France)
Unit´e de recherche INRIA Sophia Antipolis:2004,route des Lucioles - BP 93 - 06902 Sophia Antipolis Cedex (France)
´
Editeur
INRIA - Domaine de Voluceau - Rocquencourt,BP 105 - 78153 Le Chesnay Cedex (France)
http://www.inria.fr
ISSN 0249-0803