Automatic IPv4 to IPv6 Transition D1.2 - Network representation and pre-requisites

HAL Id: inria-00407632

https://hal.inria.fr/inria-00407632

Submitted on 27 Jul 2009

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

Automatic IPv4 to IPv6 Transition D1.2 - Network

representation and pre-requisites

Frédéric Beck, Isabelle Chrisment, Olivier Festor

To cite this version:

Frédéric Beck, Isabelle Chrisment, Olivier Festor. Automatic IPv4 to IPv6 Transition D1.2 - Network

representation and pre-requisites. [Contract] 2009, pp.28. �inria-00407632�

D1.2 - Network representation and

pre-requisites

Frederi Be k, Isabelle Chrisment, Olivier Festor

1 Introdu tion 2

2 NetworkRepresentation 3

2.1 Overview: thesimplest ase . . . 3

2.2 Network withaba kbone . . . 4

2.3 Network withLoop . . . 6

2.4 MultihomedNetwork. . . 8

2.5 MultihomingatSiteLevel . . . 11

2.5.1 2ISPsand1borderrouter . . . 11

2.5.2 2ISPsand2borderrouters . . . 11

2.5.3 DierentBorderRouter . . . 13

2.6 Network withDMZ. . . 13

2.6.1 VLAN . . . 16

3 Pre-requisites to anIPv4 to IPv6 Transition 18 3.1 Conne tiontotheIPv6World. . . 18

3.2 Network Topology . . . 18

3.3 Additional NetworkRelated Information . . . 18

3.3.1 Routers . . . 19

3.3.2 VLANs . . . 19

3.4 Constraints . . . 19

4 Possible Sour esof Information 21 4.1 Automati NetworkDis overy. . . 21

4.1.1 Hynetd . . . 22 4.1.2 Cheops-ng. . . 22 4.1.3 Netdis o . . . 22 4.1.4 Zenoss . . . 23 4.1.5 HomemadeCooking . . . 23 4.1.6 Con lusion . . . 23 4.2 Cis oWorks . . . 24

4.3 IPv4Se urityPoli y . . . 24

Over the last de ade, IPv6 has established itself as the most mature network proto ol for the future Internet. Whileitsa eptan eanddeploymentremainedsofar oftenlimitedto a ademi networks,its re entdeploymentinboth orenetworksofoperators(oftenformanagementpurposes)anditsavailability toend ustomersoflargeISPsdemonstratesitsdeploymentfromtheinsideofthenetworkleadingtothe edges.

Formanyenterprises,thetransitionremainsanissuetoday. This remainsatediousanderrorprone taskfornetworkadministrators.

Inthe ontextoftheCis oCCRIproje t,weaim atprovidingthene essaryalgorithmsandtoolsto enable this transition to be ome automati . In this report, we present the rst out omeof this work, namelyananalysis ofthetransition pro edure andamodel oftargetnetworks onwhi h ourautomati approa hwill beexperimented. Wealsopresentarstversionofaset oftransitionalgorithmsthatwill berenedthroughthestudy.

Introdu tion

IP networks are widely spread and used in many dierent appli ations and domains. Their growth ontinuesatanamazingratesustainedbyitshighpenetrationinboththeHomenetworksandthemobile markets. Althoughoftenpostponedthankstoha kslikeNAT,theexhaustionofavailableaddresses,and others aleissueslikeroutingtables explosionwillo urin anear future.

TheIPv6[1℄ was dened withabigger addressspa e(128 bits) and omes alongwith newbuilt-in servi es(address auto onguration[6℄, nativeIPSe , routesaggregation,simplied stru ture...). Itis a fa t that IPv6deploymentisslowerthanforeseen. Manyreasonsarevalid toexplain this: e onomi al, politi al, te hnologi al, and human. Despite this slow start, IPv6 is today more than ever the most maturenetworkproto olforthefutureInternet. Tofasteritsa eptan eanddeploymenthowever,ithas tooerautonomi apa itythatemergein severalre entproto olsin termsofself-xfun tions redu ing endofteneliminatingthemanintheloop. Weare onvin edthat su hfeaturesarealsorequiredforthe evolutionaryaspe tsofanIPnetwork,thetransitionfrom IPv4to IPv6beinganessentialone.

Inthisproje t,weareinterestedinthes ienti partofthete hnologi alproblemsthathighlyimpa t human a eptan e. Many network administrators are indeed relu tant to deploys IPv6 be ause, rst, theydonot knowwell theproto olitself, and theydonothavesu iently ri h algorithmi support to seamlesslymanagethetransitionfromtheirIPv4networkstoIPv6. Toaddressthisissue,weinvestigate, designandaimatimplementingatransitionframeworkwiththeobje tiveofmakingitself-managed.

AstheIPv4toIPv6transitionisavery omplexoperation,and anliterallyleadtothedeathofthe network,thereisarealneedforatransitionengineto easeandse urethenetworkadministrator'stask; theidealbeinga"one li k"transition.

This report presents the logi al representation of the network on whi h our study will be based. Wewill rstdene thisrepresentation, andthengivetherepresentationofea htopology onsidered in deliverable D1.1. Then, we will identify thepossiblesour es of information that anbe used in order to get all the information required to generate the network representation. Finally, we will give the pre-requisitestoanIPv4toIPv6transition.

Network Representation

Inthisstudy,wewillusealogi alrepresentationofthenetwork.

2.1 Overview: the simplest ase

We hoseto representthenetwork asahierar hi al,orientedgraph.

This graph has one and only one root, whi h we will all border router, and whi h is the router onne ted to the IPv6 world. The leaves of the graph are the end-users subnets, whi h we all end-networks. Theverti esbetweentherootandtheleaves anberouters,orinter- onne tionnetworks. An inter- onne tionisrepresentedbyasimplelinkifit onne tsonly2routers,butifit onne tsmorethan 2routers,itisrepresentedbyaspe i networkvertexwe allba kbone.

Thesimplest asethat anbeen ounteredisthetreetopologyofD1.1shownin gure2.1.

Figure 2.1: SimpleNetworkasaTree

This physi altopology anbesimplyreusedaslogi alrepresentationofthenetwork asitfollowsall the onstraintsdetailedpreviously,asshownin gure2.2.

As wede ided to nottakeinto a ountthe onne tionwiththe IPv6world,assumingthat this has beenalready onguredanddeployed,thisinter onne tionisnotrepresented,inordertohavetheborder routerasrootofthegraph.

Usingthis logi alrepresentation, allverti esneedto ndtheirshortestpathto theroot inorder to determine thehierar hi alrelations in thegraph. The gatewayof avertexwill be bydefault the next vertex, iffollowingthe shortestpath to the root. In the physi al topology, it means that the gateway forthenetworkLAN5 istherouterD, andthatthegatewayofthatrouteristherouterC.Inorderto determinetheshortestpath,alllinksin thegraphhavebeenassigned thesameweight,namely1.

Inthenextse tions,wewillintrodu e omplexityinthenetworktopology. Wewillusethetopologies dened in deliverableD1.1,and explain aseby ase,howthespe i ity ofea htopologyis takeninto a ountin thelogi alrepresentation.

2.2 Network with a ba kbone

As wesaid, theintermediateverti es an be routersorinter- onne tion networks. An inter- onne tion networknetwork an onne ttwoormorerouters. Inthatse ond ase,itwillberepresentedasanetwork. Wetakeasexample thephysi al network shown in gure2.3, whi h onsists in atree topologywith a ba kbone onne ting3routers.

Thelogi alrepresentationofthenetworkisshownin gure2.4.

Whenrunningthe shortestpathalgorithm on that logi alrepresentation, withall links weightsset to1,weobtainadistan eof2betweentheroutersAand Aandtheborder router,whileitissupposed to be1. Itmeansthat forthese tworouters, theirgatewayistheba kbone,andnottheborderrouter, whi hisnottheexpe tedout ome.

routerto theba kbonewillthuskeepitsweightto1,whereasthelinksgoing fromtheba kboneto the routersAandB willhaveanullweight,asshowningure2.5.

Figure2.5: Logi alRepresentationofaTreeNetworkwithaBa kboneandCorre tedWeights

Thistime,iftheshortestpathalgorithmisrun,thepre eden eisrespe tedandthe orre tpathsare determined.

Theweigthassignmentfollows4rules:

1. All linkshaveaweigthwhi h anbe0or1

2. All linksbetween2routershaveaweigth of1

3. All linksfromaroutertoanetwork (leaveorba kbone)haveaweigthof1

4. All linksfromanetworktoarouterhaveaweigthof0

Inthefollowingse tion,wewillnotmentiontheweights,but assumethat theyfollowtheserules.

2.3 Network with Loop

In the physi al topology, loops are a epted in the routing, with one subnet being onne ted to two routersatthesametime,forredundan yissuesusually. Figure2.6showssu hatopology.

In thistopology,the network LAN 2 is onne tedto twodierentrouters. The di ultyhereis to denewhi hrouterwillbetheprimaryupstreamforthesubnet, andwhi h onewillbetheba kup.

Thenetworkrepresentationgeneratedfromthistopologythusalsohasaloop,asshowningure2.7. Byfollowingtheweightsrulesdenedearlier,bothlinksfromtherouterstothenetworkhaveaweigth set to1. Theshortestpathalgorithm givestwodierentpathsfor LAN2 tothe border. The rstone with apath lengthof 2via therouter A, and the se ond oneviathe routerD with alengthof 4. By

routinginfrastru ture will be ongureda ordingly, and the routingproto ol hosenwill take areof sendingthetra totherigthrouter.

Itmaybeinterestingtobeabletodenemanuallyadierentdefaultgatewaythantheonedetermined withtheshortestpathalgorithm. Someloadtypemetri s analsobeusedtodeterminethatupstream. Todoso,wewillneedto addmoreinformationin thenetwork representation. Wewilldis ussthisin a laterse tion.

2.4 Multihomed Network

OneofthenewfeaturesbroughtbyIPv6isnetworkmultihoming,whereasamesubnet anbeaddressed withtwoormoredierentnetworkprexes. This aserepresentsoneofthe onstraintsthatthetransition algorithmwilltake. Wewilltaketheexampleofasubnetmultihomedwithtwonetworkprexes.

Asshowningure2.8,thetwoprexes anbeadvertisedbytworouters.

Figure2.8: MultihomedNetworkby2Routers

Inorderto generatethelogi alrepresentation,evenifphysi ally thenetworkis thesame,itwill be representedastwodierentlogi alnetworks,andtheloopwillthus disappearfrom thegraph,asshown ingure2.9.

Ea h networkprexadvertisedis su hseenasthenetworkitaddresseswithitsgatewaydetermined by the shortest path algorithm. However, multihoming an be in that ase oupled with redundan y, withDbeingtheba kuprouterfortheprexXandAtheonefortheprexY,asshowningure2.10. Itisthusne essarytohavethepossibilitytosele tmanuallytheupstreamforea hnetwork,otherwise Awillbesele tedasthedefaultgatewayforea hsubnet. Thiswillpermittolettheautomati designation ofAasupstreamforLAN2PrexX,and parameterDasdefaultgatewayforLAN2Prex Y.

Figure 2.11: MultihomedNetworkbythesameRouter

Inthat ase, thenetwork areon e againseenastwosubnets, butbothof themarethem arelinked onlytotherouterA,whi hwillbetheirdefaultupstream al ulatedbytheshortestpathalgorithm,as seenin gure2.12.

Figure 2.12: Logi alRepresentationofaMultihomedNetworkbythesameRouter

If redundan y is added and the networks are also onne ted to the router D, we have the same representationthanin gure2.10,butnospe i onstraintorparameterisadded,andthegatewayfor bothsubnet isdetermined bytheshortestpathalgorithm,namelyA,andD willbetheba kup.

Multihoming an also be used at the site level. It meansthat the whole site is multihomed with two dierent prexes,usually from 2ISPs dierent. Inthis se tion, wewill notdis uss the reasonsbehind sitemultihoming,buttakealook at the2possiblesituation,where wehave2ISPsonthesameborder router,ortwoborderrouters,oneperISP.

2.5.1 2 ISPs and 1 border router

In this ase, there is only one border router whi h is onne ted to twodierent IPv6 ISPs, ea h one assigningadierentprexto thesite.

Figure2.13: MultihomedSitewith1BorderRouters

Thisdoesnot hangeanythingforthesiteitself,thelogi alrepresentationofthetopologywillbethe samethatiftherewasonlyoneISPandoneprex,asshowningure2.2. Thedieren eisin that ase that thealgorithm will haveto berun twotimes onthe samelogi alrepresentation,onetime per ISP. Ea hiterationof thealgorithmwill haveitsown onstraints,andtheresultofthe rstinstan e anbe usedas onstraintforthese ond one.

2.5.2 2 ISPs and 2 border routers

Here, we still have a multihomed site with two dierent ISPs and prexes, but ea h ISP has its own dedi atedborderrouter.

Thus,wehavetwodierentlogi alrepresentationsofthenetwork,oneperISP,withthe orresponding borderrouterasrootofthe graph. Figure2.15showsthelogi alrepresentationfortheISPA, whereas gure2.16showstheonefortheISPB.

The algorithmwill beinstantiated in ea h representationwith itsown onstraints. On e again, the resultforoneISP anbeusedas onstraintfortheotherone.

It isalsopossiblethat someparts ofthesite arenotmultihomed,andbelongonlytoone ofthetwo ISP.Inthat ase,these parts ofthetopologywill notappear inthe logi alrepresentation oftheISPit doesnotbelongto.

2.5.3 Dierent Border Router

Inthis ase,theborderroutersmanagingIPv4andIPv6aredierent,asshownin gure2.17.

ItimpliesthatsomenetworkareIPv4only,whereasothersareIPv6only. Thelogi alrepresentation dedu edfromthis topologywillonlyin ludetheIPv6partsofthetopology,asseenin gure2.18.

Thismayraiseanissuewhenautomatingthe ongurationanddeploymentofIPv6. Inthissituation, theIPv6border routerandtherouterEdonothaveanIPv4address. Automation ofthe onguration pro ess requires IPv4 addresseson the omponents to ongurein order to onne tviaTelnetor SSH and pushthedata. The omponentsthatdo nothavesu h anaddresswill needmanual onguration, orthesetupoftemporaryIPv4addresses. Iftemporaryaddressesareset, itismandatorytoadapt the IPv4se uritypoli y a ordingly,toavoid reatingse urityholes. Intheother ase,the ongurationto bepushedto the omponentswillbegeneratedandtheadministratorwillonlyhavetopushitinto the devi es.

2.6 Network with DMZ

Inthis ase,thenetworkisstillrepresentedasahierar hi altree,butthenetworkisalso omposedofa DMZ,asshowningure2.19.

TheDMZisaparti ularsubnet,withspe i onstraints,intermsofse urity,addressing... Atypi al onstraintis that the DMZ does notperform addressauto onguration, but uses stati addressingor DHCPv6,orto for eagivennetworkprex ontheDMZorany othersubnet. but allthese onstraints donot impa tthe logi alrepresentation. Asshownin gure2.20,a DMZ isseenas aregularleavein thegraph.

Thislogi alrepresentationisnotsu ienttospe ifyallthe onstraintthat anbeappliedtotheDMZ. Weneedmoreinformationwhi hneedtobespe iedbyanotherwaythanthegraph. These onstraints su h aasan auto onf orDHCP ag, the prexassigned to the DMZ orthe addresses assignedto the prexes, aDMZ ag... need to be spe ied in additionto the topology, asthe subnetrequires spe i

2.6.1 VLAN

Thistime,thespe i ityis thatVLANshavebeendeployedonthenetworkasseenin gure2.21.

Figure2.21: NetworkwithVLANs

TheVLANsarespreadoverthewholenetwork,andtheaddressingplanshouldrespe tthedenition oftheseVLANs,whiletryingtorespe tasmu haspossibleprexaggregation,butthismaybeadi ult onstraint.

Inthelogi alrepresentation,ea hVLANwillbeseenasadierentlink. Butfor ongurationissues, itis importantto dierentiatethese links. Theend-pointsof thelinks representthephysi al orlogi al physi al interfa einterfa e. Wewill usethisand put labelsonthe linksto dierentiatethem asshown ingure2.22.

Theinterfa es onthe routers follow the Cis o naming onvention

< interf acetype >< slot > / <

interf aceid > . < vlanid >

Theinformationsthat arerequiredwill bedenedwhen studyingthisissuelaterduringtheproje t. Oneof the open questions remaining on ernsthe network swit hes, and iftheyneed, forthis spe i ase,tobein ludedin thenetworkrepresentation.

Pre-requisites to an IPv4 to IPv6

Transition

Inthis hapter,wewillgiveanonexhaustivesetofpre-requisitesin ordertoperformasmoothIPv4to IPv6transition. Morepre isely,wewillpresentthepre-requisitesfromthepointofviewofourtransition me hanisms. Thesepre-requisitesaretheinformationthat arerequiredto performthetransition.

3.1 Conne tion to the IPv6 World

As we already said, the onne tion to the IPv6 world will not be dis ussed in ourstudy. Manyother proje tsalreadyaddressedit,anddo umentationisavailable veryeasily.

The onne tion totheIPv6 worldisthus onsideredasapre-requisitein this study. We allit pre-requisiteevenitthisoperationonlytakespla einthefourthstepofthepro eduredetailedinthe hapter 4of D1.1.

3.2 Network Topology

This deliverable ispresentingthenetwork representationthat wewill useduring ourstudy. In hapter 2,wededu edalogi alrepresentationfrom thea tualphysi al topology.

Theknowledgeofthephysi altopologyisthusmandatory,andstandsforoneofthemostimportant pre-requisitesforatransition. Administratorsusuallyhaveagoodideaofthetopologyoftheirnetwork, but it is mandatory to review it before performing the transition, and audit all omponentsto ensure thattheyareIPv6 apable.

In hapter4,wewillshowhowinformations anbeextra tedfromtheappli ationsusually deployed onnetworks andthatwilleasethisphaseandmakeitfaster.

3.3 Additional Network Related Information

Solethetopologyinformationsare su ienttodedu e thenetworkrepresentation, but, for ertain s e-narios andin order to performthe onguration,moreinformationare needed. These information an not be set on thegraph. During the implementation phase, anotherinput will be needed, basi ally a ongurationle.

Inorder to generatethe appropriate onguration forthe network omponents, information about the routers interfa es are required. This in ludes interfa es identiersto assign IPv6 addresses, and IPv4 addressestoperformremote onguration.

Moreover,toperformtheremote onguration,wewill alsoneedavalid usernameandpasswordto onne ttotherouter.

Finally,therouteritselfmustbeidentied,to dierentiateforexampleaCis orouterandaQuagga basedrouter,inordertogeneratetheappropriate ongurationforea h devi e.

3.3.2 VLANs

VLANsare representedasdierentlogi allinks. Butmoreinformation areneeded, su hastheVLAN denition,namely its identier, andall the onstraintsthat may a ompany it, su h asagivenprex. Some parameters must be added also in the routers denition. Information about the VLANs and asso iatedinterfa esmustbeadded,espe iallybe auseofthedierentparametersandpossibilitiesoered bydevi esfromdierentmanufa turers.

Moreover,the swit hes mayneed to be in ludedin the representation, andweneed to know whi h portisassignedtowhi hVLAN.

3.4 Constraints

The logi al representation does not embed the onstraints, but only represents the topology. All the onstraints must be identied and dened before generating the onguration, and for some of them before running the addressing. These onstraints an not be spe ied in the graph, but in the same ongurationlethantheotherones.

Inthis se tionwewill presentarstset of onstraintsweidentied sofar. Wemayaddsomemore asthestudyadvan es.

Reserved metri Whendeningtheaddressingplan,wesometimesknowinadvan ethatwemayneed inthe(near)futuremore/64prexesfornetworkgrowth(mergewithanothernetwork,testbed...). Tuningthis metri onarouterin reasesthenumberof/64prexesitrequests.

Fixed /64 For a given subnet orlink in the topology, the administrator anx a hosen /64prex. Usually, this is done for some onguration issues, either lo ally for servi e dependen ies, orfor remote onne tionwith partners,but anyother reason anmotivate this hoi e. Thealgorithms willhavetointegratethis onstraintinthedenitionoftheaddressingplane,whilemakingsureto respe tprexaggregation.

Ba kbone Whenmorethantworoutersare onne tedtothesamenetwork,itis onsideredasa ba k-bone(it is just theterminology we hose in our algorithms). Theupstreamor designatedrouter forthat networkisdetermined byusingtheshortestpathtotheroot algorithm. Thisfeature an alsobetunedbyusingthefor e upstreamrouter onstraint.

Multihoming A subnet ora whole site an be multihomed. This onstraints permits to spe ify if a whole siteorjustasubnetorpartofthenetworkis. Weneedtodenehowthis onstraintwillbe representedintheDOT/XMLforthedierents enariosdened.

For e upstream router Insometopologies,whenalooporin aseofmultihomedsubnets,the admin-istratormaywanttouseadierentrootasdefaultupstreamthantheone hosenwiththeshortest pathalgorithm. This onstraintsmakesthat possible.

Router-to-router link By default, the transition engine uses /64 networks for links between two routers. A link is thus onsidered as another subnet. But this solution, if it makes easier the

beusedfortheselinks.Anotheroptionwouldbetousepoint-to-point onne tionbyusingtheLink Lo al Addressesfor example[5℄. Before integrating these me hanisms in the algorithms, wewill study them,and seehowthey anbeapplied appliedto avoidwasting/64prexesinthe ontext of our approa h. The important questionwe need to answer is: how will these solutions impa t prex aggregation? Asaggregationis onestrong requirementin ourapproa h, wedonotwantto ompromiseit. Anotherinterrogationaddressesthe linkswenamed ba kbones,wheremore than tworoutersare on erned. Somepra ti alfeedba kaboutthesolutionsusedorstudiedinreal ases wouldbeagreathelp.

Stateless/stateful addressing Bydefault,thetransitionengine onsidersthatallsubnetsuseStateless Auto onguration. However,sometimes,theadministrator maypreferastatefulme hanismwith DHCPv6. This onstraintspermitstotunethisfeature.

DMZ Innetworks,espe iallyforenterprisesorbigorganizations,aspe ialsubnet alledDMZisusedto gatherall serversandsensitiveservi es. A DMZusually impliesastateful addressingme hanism su h asDHCPv6and more omplexandstrongerse urity poli y. A subnetmarkedasDMZ in a topologyshouldbeaddressed onsequentlybythealgorithms.

NAT NATisnotalwaysusedonlyfor onne tionsharingissues,itmaybeusedtohidesomeinformation behindthis me hanism. Thetransition to IPv6must notunhidethese information, whi h means thatsomemoreseverese urityrulesneedtobeapplied. This onstraintraisesoneofthebigissues that weneedtoaddressduring thisstudy.

ExistingIPv6 addressplan Forsomereasons(redundan yorsitemultihomingforexample),anIPv6 addressingplanforadierentprexmayalreadybepresent. Thisaddressingplan,andthese urity poli y that isset forthis prex,need tobetakeninto a ountwhendening theaddressingplan and these uritypoli y forthesite. Weneedforthisto identifywhi hparts anbereusedandin what extendthispro ess anbeautomated,espe iallyforthese uritypoli y,astheneeds anbe dierent,dependingontheborder routerused andtheother onstraintsset.

Beforeintegratingall these onstraintsin the algorithms, therststepwill beto study allthe new standardsreleasedre ently, on erningtheproto ol itself(RFC4861[3℄,RFC4862[7℄, RFC4294[2℄or draft-ietf-v6ops-ipv6- pe-router-00),somerelatedme hanisms(RFC3627[4℄,RFC5072[5℄),andidentify thepossible hangesornew onstraintstheymayraise,ormodifythealgorithmsa ordingly. Constraints su hasDMZ orNAT willaddressedinparallelwithTask3asitispartofthese uritypoli y study.

Then, as a se ond step, we will begin running the algorithms on the s enarios, and adding the onstraints,in ordertoupdatethetransitionengine.

Possible Sour es of Information

ToperformtheIPv4toIPv6transition,manyinformationabouttheexistingnetworkarerequired. Most oftheseinformationalreadyappearatsomepla einthemanagementplane. Theobje tiveinthis hapter istoidentifywherewe anndasmu hofthesedataaspossibleautomati ally,andgeneratethesoftware representationofthelogi aloneproposedinthisdeliverablewithaslessmanualinterventionaspossible. Weidentiedthreemaintypesofinformation:

•

•

•

Theautomati approa h isastrong onstraintin ourstudy. In theexisting prototype,thenetwork topologyand addressingplane,alongsidewithallrequired ongurationdata, arerepresentedina om-binationoftwole,oneinDOT

1

languagerepresentingthenetworktopologyasagraph, ompleted by an XML le with all themissing data (addressingplane, ongurationof the devi es...). Filling these les isnot di ultand feasible ifthenetwork is nottoobig. Otherwise, it an be apainful and error proneoperation.

WeaimatretrievingfromtheexistingIPv4networkandmanagementplaneasmu hinformationas possible. It seemsirrealisti tothink that wewould beabletogetallthe information,somedata, su h asusernameandpasswordstomanageremotelythedevi esforexample,isimpossibletoget,be auseof se urityme hanismssu hasshadowpasswords.

Inse tion4.1,wewillgiveanon-exhaustivelistoftoolswestudied, andthe on lusionswerea hed, toproposeame hanismdis overtherequiredinformationwhileminimizethemanualinterventionofthe administrator,andlimitittosomedetailsandvalidationoftheoutput. Inse tion4.2,wewilldis ussthe intera tion betweenthetransition engineandCis oWorks, whilewewillexplain whytheIPv4 se urity poli yisalso on ernedinse tion4.3.

4.1 Automati Network Dis overy

Inthisse tion, wepresentsomeOpen Sour eorproprietarytoolsthat makepossiblenetwork topology dis overy. Thislist isnotexhaustive,and doesnotpresentallthetoolswetried. Attheend, wegivea small on lusion,wherewe omparethedierenttoolsandexplainour hoi e.

1

Hynetd 2

(Hybrid NetworkTopologyDis overy)isbasedonahybridmethodology,that ombinesa tive andpassivemeasurementstodis overnetworktopologiesatrouter level. The topologiesaredis overed starting from the IP address spa es to explore and SNMP ommunity names. After spe ifying the parameters (SNMP ommunity, IP range to s an...), the tools s ans the network with ICMP (ping, tra eroute),UDP,SNMP,ba ktra ealgorithms,seriallinkheuristi s... ThetoolalsoresolvesDNSnames, ARP tables ontheroutersviaSNMP. Asanoutput, thetoolsprodu esseveral logles(links, routers, subnets, ICMP table, aliases) and one XML le representing the topology dis overed. We were very interestedinthedistin tionbetweenrouters,subnetsandlinks,aswehadfollowedthesameterminology inthelogi alrepresentation.

Thetoolsaimsatguarantying ompleteness,a ura yande ien y. Thismeansthatthetoolsaims atdis overingtheentiretopology,withoutmakinganymistakes,whileminimizingthedis overyduration andthetra overhead.

Duringour study, wetried twoversions. The oldest one was version0.2.4, whi h wasgiving good results in term of a ura y and e ien y, but not in termsof ompleteness. Several subnets, links or routerswherenotdis overed,be auseofissueswiththeSNMP OIDs.

Theresultsarewaybetterwithversion0.2.5,whi hisabletodete tthewholetopology,withafew mistakes. Thesemistakesaremainly IPv6nodesidentiedasrouterswhereastheyaremerehosts. But by ombiningthedierentinformations(ICMPandARPtables,logles...),thesemistakes anbesolved inmost ases.

4.1.2 Cheops-ng Cheops-ng

3

isaNetworkmanagementtoolformappingandmonitoringanetwork. It hashost/network dis overyfun tionalityaswellasOSdete tionofhosts. Cheops-nghastheabilitytoprobehosts tosee what servi es they are running. On some servi es, heops-ngis a tually able to see what program is runningfor aservi eand theversionnumberofthat program. Thear hite tureof the tool relieson a ba kendagentrunningonthehost,andaGUIthat pilotsit.

Duringourtests, heops-ngdidnot work verywell, rashing often, dupli ating somehosts, andits frontendis notveryuserfriendly. Moreover,itdidnot oerabetter viewofthenetwork thanHynetd whilebeingslower.

4.1.3 Netdis o Netdis o

4

isanOpenSour eweb-basednetworkmanagementtool. Thetargetusersarelarge orporate and university networks administrators. Data is olle ted into a Postgres database using SNMP and presentedwitha lean webinterfa eusing Mason.

Conguration information and onne tion data for network devi es are retrieved via SNMP. Data isstored using aSQL databasefor s alabilityandspeed. Layer-2topologyproto olssu hasCDP and LLDPprovideautomati dis overyofthenetworktopology. Netdis ogetsallitsdata,in ludingtopology information,withSNMPpollsandDNSqueries. ItdoesnotuseCLIa essandhasnoneedforprivilege passwords.

Evenifthesupport ofCDPand LLDPandother features(lo atingahostbyMACorIP andshow the swit h port it lives at) is very interesting, its installation is painful as it has many dependen ies, and the fa ts that it is web based and that it requires a lot of manual intera tion does not meet our requirements. Itmaybeawayfortheadministratortodis oversomeinformation thatHynetd didnot nd automati ally and orre tthe proposed topologyand onguration, but it annotbe usedas the soledis overytoolwewill use.

2

http://www.grid.unina.it /sof twa re/T D/ 3

http:// heops-ng.sour ef org e.ne t/ 4

Zenoss 5

isamonitoringinfrastru turethatmanagesthe onguration,healthandperforman eof net-works, serversand appli ations through asingle, integrated software pa kage. On the opposite to the othertoolsmentionedsofar,evenifitalsoanOpenSour eappli ation,itremainsa ommer ialone.

Moreover,theuserinterfa eis on emoreawebbased,and evenifthetooloersseveral interesting features,itrequiresmorehumaninterventionthanwhatwewant. Moreover,theinstallationpro essand even the downloading part, forwhi h a registration pro ess is required, are time onsuming, while we aimatsomethingfastand easy.

On eagain,asitisthe aseforNetdis o,Zenossmaybeani esour eofadditionalinformation(even moreifitisalreadydeployedinthenetwork),but annotbeourrstsour eofinformation,andmaynot beworthinstallingonly in thes opeof thetransition and the olle tofthe information Hynetd ould notretrieveitself.

4.1.5 Homemade Cooking

After trying Hynetd version 0.2.4, we were not satised with all the tools we tested, and thought of writingourownHynetd likes riptsbyusing wellknownopensour esoftwaresu hasping, tra eroute, nmap,snmp,whi hareofteninstalledonthemanagementstationandmaybeeasilyinterfa edwiththe transitionengine.

Wemanaged toobtainthesamekindofinformation thanHynetd, anden ountered thesameissues relatedtotheSNMPOIDs. Astheyaredierent,dependingontheimplementationandevensometimes theversionsoftheframeworksorMIBs,there weremany asestotakeintoa ount.

We then thought of extending Hynetd, but as we began to look into the ode, version 0.2.5 was released,solvingmostoftheproblemsen ountered. Thus, wede idedtosti kto Hynetd,andusethese othertoolsto orre tand omplementHynetdresults.

4.1.6 Con lusion

There are a lot of open sour e software performing automati network dis overy, but most of them require a lot of human intervention, either for the dis overy itself, or to orre t the results (remove ghosts, dupli ates...). As some of them, and espe ially Hynetd in the ontext of our study and the requirementswexed, were giving onvin ingresults, we de idedto use Hynetdand other well known tools(nmap,tra eroute,ping,snmp...),thatareusuallyinstalledonthemanagementhost,to omplement ortheinformation olle ted. Thetransition enginewill beupdated a ordingly,and will integratethis automati dis overy.

However, some information will not be dis overed automati ally, su h as the username and pass-word for remote onguration. Moreover, manual intervention will always be required, for validation, or orre tion/additionof information. Todo so,other managementtoolsmaybeused, su h asNagios orArpWat h forexample. When writingthe guidelines and the nal versionof thereport on erning this automati dis overy, wewill integrate alist of tools that may help, and the type and lo ation of the on erneddata. Itmayalsobeof someinterestto onsider LinkLayerDis overyProto ol(LLDP, IEEE standard802.1AB-2005)and Cis oDis overyProto ol (CDP)proto ols, and theNetInventory

6 toolfrom Bell-Labs.

As this issueis moreanengineering problemthan aresear h hallenge, wewill notfo us onit in a rsttime. Wewill keepitasaba kgroundtask,evenifitisonlynalizedafter theendoftheproje t.

5

http://www.zenoss. om/pr odu t/n etwo rk-moni tor ing 6

Another option onsidered is to rely on a management framework su h as Cis oWorks. It is a web-based of toolsaiming at helping users manage a Cis o-based omputer network. It makes possible to get/push ongurationsonCis odevi esonanetwork,manageandmonitorvariousaspe tofthenetwork, in ludingitstopology,faultmanagement... Allinformationrelatedtotheaddressingplaneandtopologies arepresentinthisframework. However,itisstillun learhowwe ouldinterferewithit,asmanydierent optionsarepossible,andsomequestionsneedto beanswered.

Therst option would be to develop the transition engine asa plugin for Cis oWorks. That way, we wouldbenetsfrom allfeatures ofCis oWorks, in ludingthe knowledgeof thetopologyandall the ongurationparametersof thedevi es managed. Butthis raisesanissue on erningnetworks running non-Cis odevi es. Moreover,itisstillun learhowandin whatextendthispluginintegrationwouldbe realizable.

These ondoptionwouldbetouseCis oWorksasanothersour eofinformation,bytakingadvantage oftheXMLserialization oeredbytheframeworktollmissinginformation, atleastforCis odevi es. Thisrelation ouldbeextended,andthetransition ouldalsouseCis oWorkstoget/push ongurations from/tothedevi es,oeringthusmoreoptionsandabetterexibility(CLI,telnetorSSHinarsttime, maybeNet onfor anotherme hanismin thefuture withoutbig odeupdates).

Otherquestionsmayberaisedduringthestudy,whi hiswhy,toanswertheseinterrogationsandthe onesthat willappear,moreintera tionwithCis oisrequiredonthat point.

4.3 IPv4 Se urity Poli y

Finally,theIPv4Se urityPoli yisanotherimportantinformationtogatherbeforeperformingthe tran-sition. Whenadding IPv6to anetwork or apartofit, it ismandatory tonot opennewse urityholes forthat new proto ol, in order notto ompromisethewhole infrastru ture. Thus, dening aadequate se uritypoli yforIPv6isoneofthemostimportant on ernsduringatransition. Deningthisse urity requiresagoodknowledgeoftheproto olandthethreatsitisfa ing,andastudyofthese uritypoli ies thataretheori allyandpra ti allydened andused.

Butthemostimportantinformationtotakeintoa ountistheIPv4se uritypoli y. Thebestwayto ensureanadequateprote tionistoree ttheIPv4poli y intheIPv6one,whileaddingtheanswersto theIPv6onlythreats. ThismeansthatwegettheknowledgeoftheIPv4se uritypoli y,andespe ially the ACLs pla edon all rewall, not onlyat thenetworks level, but also lo ally onhost, espe ially on servers. Itisimportantthatalteredservi eforIPv4remainslteredforIPv6. This operationrequires ana uratemappingfromIPv4subnets andhosts toIPv6addresses, internally,but alsoexternally,fa lientorproviderhasa essto oneofourserversinIPv4andwewanttomapthisa ess inIPv6.

Con lusion

Inthis deliverable, wedened a logi alnetwork representationthat we will useduring this study. We alsopresented6topologiesand9s enariosonwhi hwewillfo us.

We set the basis of the study by dening the pre-requisites and the assumptions we made for a transitionfromIPv4toIPv6,anddened the ontextinwhi hwepla edourselves. Weidentiedarst set of onstraints, standingfor some spe i ities in theexisting ortheexpe ting network. Finally, we identieddierentsour esofinformationthat ouldbetakenfromtheexistingIPv4network.

Duringthenextsteps,wewillintegratealltheaspe tsand on lusions ofthisdeliverableand ofthe rsttask.

[1℄ S. Deering and R. Hinden. Internet Proto ol, Version 6 (IPv6) Spe i ation. RFC 2460 (Draft Standard),De ember1998. UpdatedbyRFC5095.

[2℄ J. Loughney. IPv6NodeRequirements. RFC 4294 (Informational), April2006. Updatedby RFC 5095.

[3℄ T.Narten,E.Nordmark,W.Simpson, andH.Soliman. NeighborDis overyforIPversion6(IPv6). RFC4861(DraftStandard),September2007.

[4℄ P.Savola.Useof/127PrexLengthBetweenRoutersConsideredHarmful.RFC3627(Informational), September2003.

[5℄ S.Varada,D.Haskins,andE.Allen.IP Version6overPPP. RFC5072(DraftStandard),September 2007.

[6℄ S. ThomsonandT.Narten. IPv6StatelessAddressAuto onguration. RFC2462(DraftStandard), De ember1998. ObsoletedbyRFC4862.

[7℄ S. Thomson,T.Narten,andT.Jinmei.IPv6StatelessAddressAuto onguration. RFC4862(Draft Standard),September2007.