INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT Int. J. Network Mgmt (2009) Publshed onlne n Wley InterScence (www.nterscence.wley.com).717 Preparng network confguratons for IPv6 renumberng Damen Leroy* and Olver Bonaventure Unversté catholque de Louvan (UCL), Belgum SUMMARY The dffculty of renumberng a network.e., addng and removng an Internet Protocol (IP) prefx due to a provder change or a network merger s a real ssue for most network admnstrators. In ths paper, we propose a set of macros that can be used n confguraton fles. These allow network admnstrators to wrte generc confguratons that are ndependent of the publc IPv6 prefxes allocated to ther network. We explan how to apply our macros to key confguraton fles, namely frewall access lsts, Doman Name Servce and Dynamc Host Confguraton Protocol, and how to use ths mechansm n a full renumberng process. Copyrght 2009 John Wley & Sons, Ltd. 1. INTRODUCTION The current Internet Protocol (IPv4) was desgned n the 1970s. At that tme, IP addresses were dvded nto classes, and organsatons wllng to connect to the Internet had to obtan an address block from the Internet Assgned Numbers Authorty. In the late 1980s, class-based addresses combned wth the growth of the Internet caused two man problems [1]. Frst, the szes of class A, class B and class C addresses were too rgd. Second, projectons n the early 1990s ndcated that the 32- bt Internet address space would become an ncreasngly lmtng resource. The frst problem was solved by the ntroducton of Classless Interdoman Routng (CIDR) [1], whch supports varable-sze subnets. To face the second problem, the development of IP next generaton, now known as IPv6, began [2]. Compared to IPv4, the man beneft of IPv6 s ts 128-bt address space. From a scalablty vewpont, a key element of an addressng archtecture s how address blocks are allocated. Wth IPv4, address blocks were ntally allocated on a frst-come, frst-served bass. Two types of address blocks were the defned: Provder Independent (PI) and Provder Aggregatable (PA). PI address blocks are assgned by routng regstres to Internet servce provders (ISPs) and large customers only. PA address blocks are assgned by ISPs, from ther PA block, to smaller customers. When a PI address block s allocated to an organsaton, the organsaton can use ths address block whle beng connected to any provder. On the other hand, an organsaton that receved a PA address block from provder X cannot swtch to provder Y wthout renumberng,.e., updatng all ts IP addresses. Wth IPv6, the ntal address allocaton plans [3] were strongly n favour of manly allocatng PA address blocks to avod overloadng the Border Gateway Protocol (BGP) routng tables and, thus, to permt routng scalablty. The frst polces used by Regonal Internet Regstres (RIR) bascally assumed that IPv6 addresses would only be allocated to ISPs [4]. Today, small customers are lobbyng to force the RIRs also to allocate PI address blocks to them [5]. Ther man motvaton s that, unfortunately, practcal experence has shown that t s very dffcult for a customer network to renumber when t needs to change provder. To successfully renumber and so to avod provder lock-n, stes must ndeed be able to update all confguraton fles n whch IPv6 addresses appear. Typcal examples nclude Doman Name Servce *Correspondence to: Damen Leroy, Unverste catholque de Louvan, Place Ste Barbe 2, Louvan-la-Neuve 1348, Belgum E-mal: damen.leroy@uclouvan.be Copyrght 2009 John Wley & Sons, Ltd.
D. LEROY AND O. BONAVENTURE (DNS) confguratons, router confguratons, frewall access lsts and Dynamc Host Confguaton Protocol (DHCP) confguratons. Although ths problem had been dentfed n the md 1990s [6], the procedures that should be followed today for renumberng [7,8] requre many manual operatons and are therefore stll complex, lengthy and error prone. Besdes, t can be consdered that an IPv6 ste wll have to renumber one or several tmes durng ts exstence. Ths can be a consequence of a network growth or merger, or, as clamed earler, due to a provder change. From ths perspectve, the fact that many networks have not yet started ther transton to IPv6 can be seen as an opportunty to wrte down confguratons n such a way as to make further renumberng easer. In ths paper, we tackle the renumberng ssue by showng that t s possble to partally automate the process. To do so, we splt the problem nto an addton and removal problem and defne macros allowng confguratons to be wrtten that are ndependent of the currently avalable prefxes n the ste. Later, each tme a prefx change occurs, the actual confguraton fles are regenerated accordng to the avalable prefxes. Ths technque s manly targeted at networks that am at frequent renumberng but can be appled n a larger scope. The remander of ths paper s organsed as follows. Secton 2 explans how a network can be smply prepared once for future renumberng through several case studes. Secton 3 descrbes how, n a prepared network, a prefx can be added or removed. Fnally, Secton 4 concludes the work. 2. PREPARING CONFIGURATIONS FOR PREFIX CHANGES An IPv6 ste wshng to prepare for an easy addton or removal of ts publc prefxes has to be confgured n an approprate way. Ths confguraton s made up of two parts. Frstly, n addton to ts publc IPv6 prefx or prefxes, we propose that the ste also uses nternally a ULA (Unque Local Addresses [9]) prefx. The ULA prefx s used to provde stable IPv6 addresses at least to all nodes contanng a confguraton fle that would be affected by a prefx change (routers, servers, frewalls, mddleboxes, etc.). Most regular IPv6 hosts ether use autoconfguraton or DHCPv6 and thus do not contan confguraton fles that must be updated. These stable ULAs are of course only reachable nsde the ste. Secondly, all the confguraton fles are prepared for the changes. Bascally, we ntroduce macros nto the confguraton fles that allow automatc generaton of updated confguraton fles contanng the actual IPv6 prefxes whenever a prefx s added or removed. Actually, a renumberng event contans a perod durng whch both prefxes coexst, the new prefx beng preferred to the former one for new connectons. Once most connectons have swtched to the new prefx, the former one s removed. Networks n whch some long-lved connectons must survve the renumberng are beyond the scope of ths paper and should consder usng protocols such as Host Identty Protocol. Owng to space lmtatons, we concentrate on the confguraton of the servces that cause most problems [9,10] when an IPv6 network needs to be renumbered, namely DNS, frewalls, DHCP and Neghbour Dscovery. For each of these servces, we obtaned ISP and campus network confguraton fles from Japan, Chna and Belgum. Smlar solutons can be developed for other servces. Both IPv4 and IPv6 confguratons were used: IPv6 snce t s the target of our mechansm and IPv4 snce t large real confguratons to be obtaned that are not yet avalable n IPv6. We succeeded n rewrtng all these confguratons usng our macros and wthout changng ther semantcs. For ths purpose, we developed a toolbox called Macro based Prefx Updater (MPU), whch can be downloaded from our webste (http://nl.nfo.ucl.ac.be/ MPU). The only requrement for our soluton s that the confguraton of each servce can be generated from an ASCII fle. 2.1 Macro defntons Addng (or removng) an IPv6 prefx from the confguraton fles used by a ste s more complex than smply performng search and duplcate (or remove) n all confguraton fles. For example, DNS Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
PREPARING NETWORK CONFIGURATIONS FOR IPv6 RENUMBERING confguraton fles wll contan IPv6 addresses n both standard and reverse form. Other examples are frewalls where access lsts can contan rules that are applcable to some prefxes but not all of them. Furthermore, mult-homed stes may have dfferent polces concernng ther publc prefx allocaton. For nstance, a corporate network attached to one research and two commercal ISPs may use all prefxes nsde ts research lab whle the confguraton of ts data centres wll only use the prefxes allocated by the commercal ISPs. To cope wth these ssues, we propose flexble macros that are used to replace all prefxes n the confguraton fles. The smplest statement n our macros s wrtten as [[<expresson1> $$ <expresson2>]<separator>] Ths means that the strng between the nner square brackets has to be repeated for each prefx after havng replaced $$ by the prefx. The separator (<sep>) s placed between each repetton; typcal values for t are a colon, semcolon or a new lne. For example, [[address $$:a::1],] n a network usng the prefxes 2001:db8:1::/48 and 2001:db8:8::/48 would be converted to address 2001:db8:1:a::1,address 2001:db8:8:a::1. Besdes, some confguratons may need to apply a functon on prefxes such as DNS usng the reverse IP notaton. For ths reason, a functon can be defned as follows: [[<expr>$ [<functon_name>:]$<expr>]<sep>] For example, [[zone $reverse:$.p6.nt {...}]] can be used to defne a reverse DNS zone for each prefx of a ste. Other functons are defned later for lfetmes. MPU can easly be extended wth new functons. Fnally, we ntroduce colours permttng the dscrmnaton of prefxes to use n each macro. For ths purpose, each prefx s assocated wth one or several colours. For example, consder a network havng both research and commercal prefxes. The research prefxes are tagged wth the rd colour whle the commercal prefxes are tagged wth the comm colour. Assume that part of a confguraton fle should only be appled to research prefxes. Colours can thus be used to restrct the duplcaton of ths part only to research prefxes. For nstance, a statement startng wth [comm,rd;rd[... means that two colour sets (separated by semcolons) are defned. The frst one contans prefxes of colour rd or comm and set 2 contans the prefxes havng colour rd. Gven these sets, the statement can use the patterns $1$ and $2$ to respectvely relate to prefx set 1 or 2. As a result, the statement s frst duplcated for each prefx of set 1 replacng $1$ by the correspondng prefx, then t s done for set 2. If, at one gven moment, the network has one research prefx 2001:db8:3::/48 and one commercal prefx 2001:db8:7::/48, the followng frewall pseudo-rule can be wrtten to express that all packets from commercal or research prefx to the host wth suffx ::9 usng research prefx have to be dropped; [comm,rd;rd[f packet from $1$::/48 to $2$::9, then drop]] For the sake of smplcty, an empty colour set s equvalent to all prefxes and no colour defned between dollars s equvalent to declare set 1. In [[address $$:a::1],], t thus means that set 1 s made of all prefxes and that ths rule wll be duplcated for each prefx of set 1, $$ beng replaced by the prefx value. In the followng, we detal how macros can be appled to DNS (Secton 2.2), frewalls (Secton 2.3) and some other servces (Secton 2.4). 2.2 The Doman Name Servce (DNS) For the DNS, our case study are BIND confguraton fles. BIND server confguraton s a set of statement blocks contanng optons, a sample beng gven n Fgure 1. Addresses appear ether n a statement defnton (server and zone n Fgure 1) or wthn an opton (e.g., acl, query-source or masters). If an address appears n a statement defnton (e.g., at lne 6 n Fg. 1), the entre statement has to be duplcated for each prefx. In optons, addresses are mostly used n lsts, e.g., at lne 1 or 13 n Fgure 1. In ths Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
D. LEROY AND O. BONAVENTURE 1 acl "nternals" { 2001:db8:1::/48; fd12:3:4::/48; } 2 optons { 3 notfy no; 4 query-source address 2001:db8:1:a::d; 5 }; 6 server 2001:db8:1:7::a { request-xfr no; }; 7 vew "local" { 8 match-clents { nternals; }; 9 recurson yes; 10 zone "mydoman.net" { 11 type slave; 12 fle "db.net.mydoman"; 13 masters { 2001:db8:1::a; }; 14 }; 15 zone "1.0.0.0.8.b.d.0.1.0.0.2.p6.arpa" {... 16 }; 17 }; Fgure 1. A sample of BIND confguraton fle 1 acl "nternals" { [[$$::/48;]] fd12:3:4::/48; } 2 optons { 3 notfy no; 4 [man[query-source address $$:a::d;]] 5... 6 }; 7 [[server $$:7::a { request-xfr no; };]] 8 vew "local" { 9 match-clents { nternals; }; 10 recurson yes; 11 zone "mydoman.net" { 12 type slave; 13 fle "db.net.mydoman"; 14 masters { [man[$$::a;]] }; 15 }; 16 [[ zone "$reverse:$.p6.arpa" {... 17 }; ]] 18 }; Fgure 2. The generc verson of the BIND confguraton fle of Fgure 1 case, each address has smply to be duplcated for each prefx. However, some BIND optons requre a sngle address as a parameter: query-source[-v6], [alt-]transfer-source[-v6] and notfy-source[-v6]. These defne the source addresses that must be used for specfc operatons. A better way to deal wth t would be to rely on the host s address selecton mechansm [11] and thus not to use these optons. If for any reason they must be used, a soluton to express t wth our macros s to use a colour bound to one prefx, the preferred one. The nformaton requested and contaned n DNS reples s called a Resource Record (RR). RRs are stored n zone fles as tuples <name> [<TTL>] <type> <value>. Sample RRs are gven n Fgure 3. Zones are declared n the confguraton fle (lnes 10 16 n Fgure 1) specfyng the fles where RRs are stored. A zone s named by what t defnes,.e., the doman name for drect resoluton and the address prefx for reverse resoluton. In BIND, addresses used for a reverse zone are nverted as seen on lne 15 of Fgure 1. Usng our macros, the confguraton of Fgure 1 can be abstracted as shown n Fgure 2 to become ndependent of the global prefxes. At lne 4 of ths confguraton, t s shown how an opton takng only Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
PREPARING NETWORK CONFIGURATIONS FOR IPv6 RENUMBERING 1 ns1 IN CNAME nameserver 2 www IN AAAA fd12:3:4:a:9 3 www 7200 IN AAAA 2001:db8:1:a:9 4 7.1.b.a.3.a.d.0.c.7.b.e.7.9.d.1.c.0.0.0 IN PTR abcd.mydoman.net. 5 9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.0.0 86400 IN PTR www.mydoman.net. Fgure 3. Some sample BIND RRs one IP address can be transformed under the assumpton that the man colour s bound to one prefx. Lne 16 uses the reverse functon to transform the prefx for reverse DNS zones. A sample of drect (or reverse) RRs that can be found n zone fles s shown at lnes 2 3 (or 4 5) of Fgure 3. In drect zone fles, names are mapped to IP addresses. When a new prefx s added, the RRs have therefore to be duplcated. In reverse zone fles, RRs map an address suffx to a name. Those fles do not need to be changed when a new prefx s added. Only ther declaraton statement n the server confguraton (lnes 15 16 n Fgure 1) needs to be duplcated. RRs can also contan a TTL when they are not usng the default one (defned for the whole zone fle), for nstance 7200 and 86400 (24 hours) n Fgure 3. Ths TTL gves to the DNS clent the lfetme durng whch t can stll use ths record wthout sendng a new request, typcally a few days. When a new prefx s added, no specal care has to be taken wth ths parameter. However, when a prefx has to be removed, the RRs assocated wth ths prefx wll reman n clent caches for TTL tme. Ths ssue, brefly mentoned n some renumberng dscussons [7,8], concerns only drect RRs snce clents wll stll try to connect to hosts usng addresses that no longer belong to them. There are two opposte solutons to ths ssue. Frst, the drect RRs could be removed DNS TTL-seconds before the actual removal of the correspondng prefx. Ths can only be appled f another prefx s routable n the network. Another soluton s to set the TTL to zero TTL-seconds before prefx removal tme and then to remove the RRs at the tme of removal. Ths soluton may lead though the DNS server to receve a large number of requests durng the zero-ttl perod. Of course, a trade-off should be chosen between these two solutons. Such a trade-off could be to decrease the TTL n several steps, e.g., to dvde the startng TTL by two TTL-seconds before prefx removal, to dvde t once more by two new-ttl-seconds before prefx removal, and so on untl the TTL reaches a threshold at whch t s set to zero. In practce, n Fgure 3, the only RRs that need a change for a generc confguraton s the thrd one whch would become: 3 [[www $ttl:$ IN AAAA $$:a:9]] End-hosts may also have entres n the DNS server. If so, ther entres do not necessarly need to be updated usng our tool when a new prefx s known. Indeed, some of them may need to use a dfferent IP suffx for each prefx receved, e.g., f they are usng Cryptographcally Generated Addresses (CGA) [12] or prvacy extensons [13]. In ths case, DNS records cannot be updated by smply replacng the former prefx by the new one. Dynamc updates [14] must be used by such end-hosts to update ther own RRs. In 2000, A6 records were proposed at IETF [15] to support renumberng. They rely on address channg to obtan an IP address from a name. Each part of the address was placed n a separate RR, makng ste renumberng much easer. Unfortunately, A6 has been deprecated n favour of AAAA because of the potental overweght of the channg [16]. 2.3 Frewalls Other servces that need to be carefully updated when a network s renumbered are the frewalls and the access lsts used on routers. Intutvely, when a prefx s removed, the rules matchng the prefx (e.g., Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
D. LEROY AND O. BONAVENTURE from prefx A, drop ) must be entrely removed, whle n the case of rules excludng the prefx (e.g., not from prefx A nor prefx B, drop ), only the condtons related to the prefx must be removed. When a new prefx s added, the same prncples are appled,.e., the entre rule s duplcated f the rule matches the prefx and only the condton s duplcated f the prefx s excluded. In ths secton, we focus on frewall confguratons that can be wrtten as a lst of rules made of a conjuncton of condtons and a target (allow or deny). In practce, all commonly used frewall mplementatons ft ths model. We verfed ths on real network confguratons usng Netfler/ptables, Csco IOS access lsts and JunOS frewalls. If a frewall language allows dsjunctons, these can be easly transformed by splttng them nto two rules as shown n Table 1. Lke Cheswck et al. [17], we use a table notaton to represent frewall rules for the sake of readablty. Formally, a flterng rule can be expressed ether as rules of type (1) or type (2). In these rules, C s a condton unrelated to IP addresses and P A s a condton matchng an address or address block from prefx A. The target defnes the actons to be performed when the rule s matched; n practce common targets are allow or deny. A Ether C P target (1) or A C P target (2) If a new prefx, B, s added, rule (1) can be rewrtten as follows: A B C ( P P ) target C C P P A B target target Ths means that a rule contanng a condton that matches a prefx must be entrely duplcated for each prefx. On the other hand, rule (2) can be rewrtten as (3) A B A B C ( P P ) target C P P target (4) whch means that a rule contanng a condton excludng a prefx must have only the condton duplcated for each prefx. For nstance, consder a network ownng prefx 2001:db8:1::/48 that uses the flterng rules lsted n Table 2. 1 If ths network obtans a second prefx, 2001:db8:abc::/48, the frst fve rules would be updated as shown n Table 3. Accordng to property (3), rule 1 gves two rules: 1a and 1b. On the other hand, usng (4), rule 4 only has more condtons when a prefx s added. # Acton Source address Port Destnaton address Port 1 allow 2001:db8:1::/48 * 2001:db8:a:4::1 http 2001:db8:e::/48 2a allow 2001:db8:1::/48 * 2001:db8:a:4::1 http 2b allow 2001:db8:e::/48 * 2001:db8:a:4::1 http Table 1. In ths example, rule 1 s semantcally equvalent to rules 2a and 2b. It allows http packets from ether 2001:db8:1::/48 or 2001:db8:e::/48 prefx to a specfc IP address 1 In ths table,! ndcates a negaton. Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
PREPARING NETWORK CONFIGURATIONS FOR IPv6 RENUMBERING # Acton Source address Port Destnaton address Port 1 allow * * 2001:db8:1:a::d dns 2 allow * * 2001:db8:1:7::a dns 3 deny! 2001:db8:1:a::d dns * * &! 2001:db8:1:7::a 4 allow * *! 2001:db8:1:5::/64 ssh 5 deny * * 2001:db8:1::/48 telnet 6 allow 2001:db8:1::/48 * 2001:db8:1:a::4 smtp [...] Table 2. A sample frewall table n a network ownng the prefx 2001:db8:1::/48 1a allow * * 2001:db8:1:a::d dns 1b allow * * 2001:db8:abc:a::d dns 2a allow * * 2001:db8:1:7::a dns 2b allow * * 2001:db8:abc:7::a dns 3 deny! 2001:db8:1:a::d dns * * &! 2001:db8:abc:a::d &! 2001:db8:1:7::a &! 2001:db8:abc:7::a 4 allow * *! 2001:db8:1:5::/64 ssh &! 2001:db8:abc:5::/64 5a deny * * 2001:db8:1::/48 telnet 5b deny * * 2001:db8:abc::/48 telnet Table 3. The frst fve rules of Table 2 f a prefx (2001:db8:abc::/48) has been added to the network 6a allow 2001:db8:1::/48 * 2001:db8:1:a::4 smtp 6b allow 2001:db8:abc::/48 * 2001:db8:abc:a::4 smtp Table 4. A frst way of rewrtng rule 6 of Table 2 when a new prefx s added. It does not allow a packet to be sent from one prefx to the other 6a allow 2001:db8:1::/48 * 2001:db8:1:a::4 smtp 6b allow 2001:db8:1::/48 * 2001:db8:abc:a::4 smtp 6c allow 2001:db8:abc::/48 * 2001:db8:1:a::4 smtp 6d allow 2001:db8:abc::/48 * 2001:db8:abc:a::4 smtp Table 5. A second way of rewrtng rule 6 of Table 2 when a new prefx s added. The rule s duplcated for each prefx par The last rule (rule 6) contans several condtons related to IP address. When a prefx s added, such a rule can be converted n two ways: ether as shown n Table 4 or n Table 5. The frst conssts n duplcatng the rule consderng each prefx ndependently. It does not allow packets to be sent from one prefx to the other. The second consders each prefx par for buldng rules. In Table 5, ths allows packets to be sent from one prefx to another. If the rule target were deny, the second opton should be chosen to prevent a host from bypassng the rule by sendng packets from one prefx to the other. The choce between these two s dependent on the polcy of the network and has to be made by an admnstrator. The second soluton should be chosen unless admnstrators decde to deny cross-prefx connectons wthn the network. Both can be expressed wth our macros. Thus, usng the macro defntons descrbed earler n ths secton, the ntal frewall of Table 2 could be wrtten as Table 6 n order to make t prefx ndependent wthout changng ts semantcs. Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
D. LEROY AND O. BONAVENTURE # Acton Source address Port Destnaton address Port 1 [[allow * * $$:a::d dns]] 2 [[allow * * $$:7::a dns]] 3 deny [[! $$:a::d ]&] dns * * & [[! $$:7::a]&] 4 allow * * [[! $$:5::/64]&] ssh 5 [[deny * * $$::/48 telnet 6 [;[allow $1$::/48 * $2$:a::4 smtp]] [...] Table 6. Prefx-ndependent frewall table havng the same semantcs as that one of Table 2 In rules 3 and 4, the & (and) sgn between closng brackets s the separator. Rule 6 uses a semcolon between the openng brackets; ths expresson means that both set 1 and set 2 correspond to all prefxes. As a result, f n s the number of prefxes, ths rule s frst duplcated n tmes replacng $1$ by each prefx and then each duplcated rule s duplcated once more n tmes replacng $2$ by each prefx. 2.4 Other confguratons Both DHCP and Router Advertsements (RA) are used to permt end-hosts connected on a LAN to obtan and use IP addresses. In practce, the router runnng DHCPv6 server (DHCPs) or Router Advertsement daemon (RAd) s often the egress router of the LAN. RAd s used for stateless IPv6 address confguraton [18]. It floods on the LAN the prefxes that can be used by the end-hosts as well as ther preferred and vald lfetmes. On the other hand, DHCPv6 [19] s used as a server-based address confguraton. When t receves an address request, t reples wth one or several addresses and ther preferred and vald lfetme. The preferred lfetme s the remanng tme durng whch ths address should be preferred by the host,.e., should be used for any connecton. The vald lfetme s the tme left durng whch ths address can be used. When the vald lfetme expres, the address must stop beng used by the host. When an address s not preferred anymore but stll vald, t becomes deprecated. In ths state, t cannot be used for new connectons but can stll be used for already establshed ones. As for DNS RR, addresses or prefxes are therefore assocated wth TTLs, called lfetmes. There are two possble approaches for updatng them for RAd and DHCPs. The frst one s to apply the same procedure as for DNS,.e., updatng pror to renumberng the lfetme to a shorter one. Another method, whch does not need early schedulng, s to reduce the prefx lfetme of end-hosts pror to ts expraton. For DHCPv6 ths can be done by usng a DHCP reconfgure message that trggers the hosts to re-contact the server. For RA, t s done by sendng new prefx nformaton. However, RA specfcaton [20] defnes that, n order to avod DoS, the lfetme reducton updates of unauthentcated prefxes 2 cannot be used f there are fewer than 2 hours left. RAd and DHCPs use smlar confguraton fles. They consst of several global parameters and some confguraton blocks: one for each prefx. These blocks must be duplcated every tme a prefx s added. They contan obvously the prefx value but also the dfferent lfetmes. Besdes these servces, some other confguratons need some changes. The nterface addresses of routers and servers that use nether RA nor DHCP have to be updated. Such confguraton fles can be very dfferent from one operatng system to another. Actually, these are qute smple and smlar to DHCPs/RAd confguratons. 2 Authentcaton of RA can be done usng the SEND protocol. Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
PREPARING NETWORK CONFIGURATIONS FOR IPv6 RENUMBERING Routng protocols daemons and other strctly local protocols should local addresses [9] use as much as possble for ther communcatons. However, even f global addresses are needed, we observed that confguraton fles of most of them are very smlar to the ones we prevously dscussed n ths paper. 2.5 On the cost of preparng confguratons In pure manual renumberng of confguratons, each tme a prefx change occurs, all the confguraton fles concerned have to be updated. Wth the soluton dscussed n ths paper, the renumberng has to be prepared only once, pror to any prefx change. Later, the changes can be automated and should be error free. In fact, the confguraton fles usng macros are parsed by MPU, whch generates real confguratons contanng all the prefxes n use. The frst preparaton of the confguraton fles can be made by convertng exstng confguratons to prefx-ndependent ones, as has been done for DNS (from Fgure 1 to Fgure 2) or for frewalls (from Table 2 to Table 6). Prefx-ndependent confguratons can also be wrtten drectly from scratch when new servces are confgured. It s pretty dffcult to evaluate what s the complexty of buldng these macro-based confguratons. When they are wrtten drectly from scratch, we can assume that the addtonal cost s neglgble compared to the cost of wrtng the full confguratons. The cost of modfyng exstng confguratons seems to be farly lght. Actually, most of the process can be automated by usng pattern-matchng scrpts. In the sgnfcant and large real confguratons we examned durng our analyss on DNS, frewalls and DHCP confguratons, we observed ratos of respectvely 250/253 (98.8%), 689/750 (91,7%) and 50/50 (100%) of statements that have been automatcally transformed usng smple scrpts. For the remanng ones, we had to take a look n order to nterpret them n the rght way. 3. PREFIX ADDITION OR REMOVAL PROCEDURE Secton 2 explaned how the confguraton fles should be prepared once, for any prefx change event. Here, we dscuss how a prefx addton or removal should be performed to avod servce outage. In practce, a prefx change cannot be consdered as an nstantaneous event as dfferent servce updates must be done n a specfc order. For nstance, a new prefx should not be assgned to end-hosts whle a frewall s stll blockng ths prefx. As a result, a prefx addton or removal procedure s composed of several steps [7]. Ths s often error-prone and should not be done manually. The easest way s probably to rely on a centralsed management tool that knows whch servces are runnng on whch nodes and that s able to plan and montor the renumberng procedure. In practce, ths tool sends orders to network nodes n accordance wth the current state and montors the results. In order to perform a frst valdaton of our tool, MPU, we used confguratons we have obtaned from ISPs and campus networks. For the servces we could nstall n our lab, we deployed them n a network usng SOAP processes for trggerng the prefx changes. The servces restarted correctly and ther behavour appeared to be coherent and correct after each update. 3.1 Related work Detaled renumberng procedures have been dscussed n several IETF documents [7,8] descrbng ssues that may be rased by renumberng and exstng solutons. They descrbe constrants that are taken nto account n ths paper, but do not propose any concrete automated confguraton update mechansm. For the dstrbuton of prefx nformaton wthn a ste, dstrbuted mechansms could be used such as Router Renumberng [21] or those ncluded n full renumberng propostons [22,23]. DHCPv6 usng Prefx Delegaton [24] could also be used as a centralsed mechansm. However, these solutons do not enable transmsson of nformaton such as colours and dstrbuted ones are probably not sutable for Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
D. LEROY AND O. BONAVENTURE trggerng each parts of the update. Fnally, the montorng part has been addressed by Beck et al. usng the NetSV tool [25]. 3.2 Removng a prefx n use The removal of a prefx p s a three-step process: preparaton for the removal, deprecaton of p and defntve removal. The preparaton conssts, as explaned earler, n startng to decrease the TTL of DNS drect RRs and the lfetme of prefxes advertsed on LANs. Deprecaton corresponds to settng p as deprecated so that no host uses t any more for new connectons. Ths has to be done for RAd and DHCP confguratons as well as for statc IP confguraton on all network devces. DNS server confguratons also have to be updated not to use p for requests (e.g., va the man colour n Fgure 2). Fnally, drect RRs usng p have to be removed from the DNS. These four updates have no precedence constrants between them. The removal of all addresses related to prefx p n confguraton fles s the last step of the procedure. Before startng ths step, t must be ensured that DNS drect RRs concernng p are no longer used. In theory, applcatons should no longer use an address wth an expred TTL. In practce, some applcatons and some recursve DNS servers do not observe ths TTL at all. As a result, some addtonal tme should be allowed before startng ths last step to avod servce outage. Frst, addresses on LAN (va RAd and DHCPs) and on statcally assgned nterfaces have to be removed. As explaned n Secton 2.4, LAN updates may need to wat for some prefxed lfetme to expre on end-hosts. Once ths s done, the last removals can be performed, n any order, n DNS server confguratons, frewalls, routng protocols and reverse zone DNS records. 3.3 Addng a new prefx Addng a new prefx n a network s smpler than removng t. Frst of all, frewall, routng protocols and reverse zone DNS records must be updated to consder the new prefx. Once routng has converged, addresses related to ths prefx can be bound to statcally confgured nterfaces. The DNS server can then be confgured to use ths new prefx, followed by LAN confguraton protocols (RA and DHCP). When the prefx s used on LANs (t could take tme wth DHCP f reconfgure messages are not used to trgger the clent to request the DHCP server), drect DNS records must be updated to take the new prefx nto account. 4. CONCLUSION Many network admnstrators are concerned, or wll soon be concerned, by the dffculty of changng ther confguraton fles each tme a new IPv6 prefx s allocated to ther network. For ths reason, they lobby for obtanng provder-ndependent (PI) IPv6 prefxes. If ths were appled, t would unfortunately lead to a rsky growth of the BGP IPv6 routng tables [10]. However, the transton of networks to IPv6, requrng some confguraton rewrtng, can be seen as an opportunty to wrte confguratons n a way that makes renumberng easer. In ths paper, we proposed an approach that reles on macros to allow text-based confguraton fles to be automatcally updated upon the addton or removal of an IPv6 prefx. Our macros support prefx colourng to dscrmnate part of the confguratons based on the prefx type. We descrbed the procedure that should be followed when a prefx s added or removed. A prototype was mplemented n Python and appled to real network confguratons. The man advantage of our approach s that t can be appled qute easly on a network, wthout requrng large changes n confguratons or n the deployed servces. Our further work s to contnue our technque wth a management tool for renumberng, thus buldng an all-n-one toolbox. Fnally, the opposte approach n whch servces are aware of the prefx changes should be consdered and analysed n comparson wth the one proposed n ths paper. Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
PREPARING NETWORK CONFIGURATIONS FOR IPv6 RENUMBERING ACKNOWLEDGEMENTS We would lke to thank Maoke Chen, Hong Dan, Kenj Masu, Bruno Delcourt and Alan Fontane for ther help n collectng confguraton fles. Damen Leroy was supported by a grant from Fonds pour la formaton à la Recherche dans l Industre et dans l Agrculture (FRIA), rue d Egmont 5, 1000 Brussels, Belgum. REFERENCES 1. Fuller V, L T, Yu J, Varadhan K. Classless nter-doman routng (CIDR): an address assgnment and aggregaton strategy. RFC 1519 (obsoleted by RFC 4632), Internet Engneerng Task Force, September 1993. 2. Bradner S, Mankn A. The recommendaton for the IP next generaton protocol. RFC 1752, Internet Engneerng Task Force, January 1995. 3. Rekhter Y, L T. An archtecture for IPv6 Uncast address allocaton. RFC 1887, Internet Engneerng Task Force, December 1995. 4. APNIC, ARIN, RIPE NCC. IPv6 address allocaton and assgnment polcy: rpe-421, November 2007. http:// www.rpe.net/rpe/docs/pv6polcy.html [29 December, 2008]. 5. Palet J. Provder ndependent (PI) IPv6 assgnments for end user organsatons. RIPE Polcy Proposal 2006 01, http://www.rpe.net/rpe/polces/proposals/2006 01.html [29 December 2008]. 6. Carpenter B, Rekhter Y, Renumberng needs work. RFC 1900, Internet Engneerng Task Force, February 1996. 7. Baker F, Lear E, Droms R. Procedures for renumberng an IPv6 network wthout a flag day. RFC 4192, Internet Engneerng Task Force, September 2005. 8. Chown T, Ford A, Venaas S. Thngs to thnk about when renumberng an IPv6 network. Internet draft (work n progress) draft-chown-v6ops-renumber-thnkabout-05, Internet Engneerng Task Force, September 2006. 9. Hnden R, Haberman B. Unque local IPv6 Uncast addresses. RFC 4193, Internet Engneerng Task Force, October 2005. 10. Meyer D, Zhang L, Fall K. Report from the IAB Workshop on Routng and Addressng. RFC 4984, Internet Engneerng Task Force, September 2007. 11. Draves R. Default address selecton for Internet Protocol verson 6 (IPv6). RFC 3484, Internet Engneerng Task Force, February 2003. 12. Aura T. Cryptographcally Generated Addresses (CGA). RFC 3972, Internet Engneerng Task Force, March 2005. 13. Narten T, Draves R, Krshnan S. Prvacy extensons for stateless address autoconfguraton n IPv6. RFC 4941, Internet Engneerng Task Force, September 2007. 14. Vxe P, Thomson S, Rekhter Y, Bound J. Dynamc updates n the doman name system (DNS update). RFC 2136, Internet Engneerng Task Force, Aprl 1997. 15. Crawford M, Hutema C. DNS extensons to support IPv6 address aggregaton and renumberng. RFC 2874, Internet Engneerng Task Force, July 2000. 16. Austen R. Tradeoffs n doman name system (DNS) support for nternet protocol verson 6 (IPv6). RFC 3364, Internet Engneerng Task Force, August 2002. 17. Cheswck WR, Bellovn SM, Rubn AD. Frewalls and Internet Securty: Repellng the Wly Hacker. Addson-Wesley Longman: Boston, MA, 2003. 18. Narten T, Nordmark E, Smpson W, Solman H. Neghbor dscovery for IP verson 6 (IPv6). RFC 4861, Internet Engneerng Task Force, September 2007. 19. Droms R, Bound J, Volz B, Lemon T, Perkns C, Carney M. Dynamc host confguraton protocol for IPv6 (DHCPv6). RFC 3315, Internet Engneerng Task Force, July 2003. 20. Thomson S, Narten T, Jnme T. IPv6 stateless address autoconfguraton. RFC 4862, Internet Engneerng Task Force, September 2007. 21. Crawford M. Router renumberng for IPv6. RFC 2894, Internet Engneerng Task Force, August 2000. 22. Chelus G, Fleury E, Toutan L. No Admnstraton Protocol (NAP) for IPv6 router auto-confguraton. Internatonal Journal of Internet Protocol Technology 2005; 101 108. 23. Leroy D, and Bonaventure O. A secure mechansm for address block allocaton and dstrbuton. In Proceedngs of IFIP Networkng, May 2008. Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)
D. LEROY AND O. BONAVENTURE 24. Troan O, Droms R. IPv6 prefx optons for Dynamc Host Confguraton Protocol (DHCP) verson 6. RFC 3633, Internet Engneerng Task Force, December 2003. 25. Beck F, Chrsment I, Festor O. A montorng approach for safe IPv6 renumberng. In Proceedngs of the Internatonal Mult-Conference on Computng n Global Informaton Technology (ICCGI), August 2006. AUTHORS BIOGRAPHIES Damen Leroy s currently a PhD student n the IP Networkng Lab at Unversté catholque de Louvan (UCL) n Belgum. In 2006, he receved the Alcatel Bell MSc Thess Award for hs master s thess on frewalls. Hs current research topcs are about IPv6 addressng,wf roamng and network securty. Olver Bonaventure s currently a professor n the Department of Computng Scence and Engneerng at Unversté catholque de Louvan (UCL), Belgum. From 1998 to 2002 he was a professor at the Facultés Unverstares Notre- Dame de la Pax, Namur, Belgum. Before that, he receved a PhD degree from the Unversty of Lège and spent one year at the Alcatel Corporate Research Centre n Antwerp. He s on the edtoral board of IEEE Network Magazne and IEEE/ACM Transactons on Networkng. He receved the Wernaers and Alcatel przes awarded by the Belgan Natonal Fund for Scentfc Research n 2001. Hs current research nterests nclude ntra- and nterdoman routng, traffc engneerng and network securty. Copyrght 2009 John Wley & Sons, Ltd. Int. J. Network Mgmt (2009)