Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
IPv6 STANDARDS AND RFCs
whAT PRoFIleS CAN Do
2
MANAgeMeNT SuMMARySince the early days of the Internet, the Internet Protocol Version 4 (IPv4) has been used to transfer digital data. Today this protocol is widely used in internal networks of agencies and organizations, as well as in provider networks across the globe. The Internet and all the networks using IPv4 today have to face a profound technological change because it is inevitable for all networks to support the successor IPv6 in the foreseeable future.
There are two key answers to the frequently asked question about the essential factors driving the Transition to IPv6:
• Thereisahugetransitionpressurecausedbythescarcityofnew,stillunusedIPv4 addresses today (already in Asia, very soon worldwide).
• TheworldfacesanincreasingdemandofIPaddressesfornetworkedsmallandlarge devices,fromsensorstosmartphonestowashingmachinesthatneedtocommu- nicateoverIPnetworks.ByrunningoutofIPv4addressesthesituationbecomes even worse.
BothfactorstogethermassivelyacceleratethetransitiontoIPv6,foremostinthecoreoftheInternet,andwithinnewdevices.Inthefuture,manydeviceswillonlyhaveanIPv6addressrather than an IPv4 address and can only be contacted by this IP address. Therefore, a transitiontoIPv6assuresnotonlytheavailabilityofasufficientnumberofIPaddresses,butalso the accessibility of one’s services for the future without being dependent on a provider.
TheIPv6profileforthepublicadministrationdescribedinthisdocumentsupportstheevaluation of existing devices andprocurement processes. The definition of necessary /mandatory,useful/recommendedandoptionalfeaturesofIPv6devicesenablesthede-tailedspecificationofselectioncriteria.Requirementscanbespecifiedintermsofdeviceroles (router, firewall…) and usage contexts (stationary,mobile…), simplifying theassessment of the fulfilment. Theprofiles canalsobe used toassess existingdevices,concerningtheirusabilityinIPv6environments.Allprofiledocuments focusparticularlyon theneedsandcharacteristicsofgovernmentaladministrations(e.g.,existingnetworksandsecurityrequirements),thuscreatingthebasisforatargetedandstructuredstartintothetransitiontoIPv6forthepublicadministration.
Forfurtherdetaileddescriptions,havealookatthedocumentationpublishedbytheGEN6project on the web page www.gen6-project.eu.
3
STANDARDS AND RFCs
TheprotocolsconcerningtheglobalInternetarewrittenasStandardsdocuments(STDs)andRequestforCommentsdocuments(RFCs)bytheInternetEngineeringTaskForce(IETF).Roughly200ofthosedocumentsareconcernedwiththedefinitionandoperationofIPv6,includingadoptionsofrelatedprotocols(e.g. ICMP->ICMPv6),sothataninteroperationwith IPv6ispossible, as it is with IPv4.
Informative RFCs
RFCdocumentsaredividedintodifferentcategories:
• StandardsTrack(ProposedStandard,DraftStandardorStandard) • Informational • BestCurrentPractice(BCP) • Experimental
Therefore,onecouldexpect thatall relevant information foran IPv6profilearecontainedwithin the standards documents, and that BCP documents only contain things likerecommendationsfornetworkanddeviceconfiguration.Inpractice,thebordersbetweenthedocumenttypesarenotthatclear.
The reasons for this is the process by which standardization in the IeTF works: New topics (forexamplesomesecuritymechanism)mightbediscussedbydifferentworkinggroups,andtackledwithdifferentapproaches.Thiswide-spreadinterestandtheparticipationofdifferentgroups till the final version of an RFC have a high influence on the final result.
ItisthisbroadconsensusprocessduringthewritingofanRFCdocument,whichleadstorelevant,practicallyusableprotocoldefinitions in theRFCstandards,butalsosometimesto(still)opendetailquestionsandanot-so-harddifferentiationbetweenthedifferenttypes(STD,BCP…)ofRFCdocuments.
whoever is in charge to plan a transition to IPv6 will find a lot of guidelines in the internet butatacertainpointintimewhenitgettothebitsandbytesyouhavetodealwiththeRFCs.Over200documentstoreadandtosearchfortheinformationyouneedforyourproject.That’swhereprofileswillhelpyoutoidentifytherightinformationandparameterstogetitup and running.
4
PRoFIleS? – PRoFIleS!Theprofiledocument for thepublicadministrationprovidessupport for theprocurementofIPv6-capablehardwareandsoftwarecomponents.Toreachthisgoalitspecifies,whichIPv6standardshavetobesupportedbyanetworkeddeviceorsystem,inordertofulfilitsdutiesinanIPv6environment.
ItisveryimportantthatIPv6willbeintroducedintonetworkenvironmentsacross-the-board,becauseoftheIPv4addressshortage.ThismeansthateverynewpurchaseofnetworkeddevicesorsoftwaremusttakeIPv6capabilitiesintoaccounttoguaranteealevelofreadinessforthefuture–optimallyevenforanenvironmentwhereIPv4isnotavailableanymoreatall.
The adoption of IPv6 can be done in different ways:
• Basedonanexistingnetworkinfrastructure,IPv6canbeaddedtoIPv4inparts orwholeofthenetwork(e.g.acompanies’Intranet).UsingIPv4andIPv6 togetherinasinglenetworkiscalled“dual-stack”approach.
• Innewlycreatednetworks(orsubnets)withclearlydefinedtasksandusecases,one canconsidertorunIPv6inanIPv6-onlyconfiguration.Forthistowork,allcomponents (hardware,software(OS,applications))mustbeabletorunwithoutanyIPv4available.
• ThedetailedanalysisofthescenariosstandsatthestartofbuildinganIPv6- capablenetwork,regardlessofwhetherthenetworkisbasedonexistingcomponentsor created out of new acquisitions. Based on this, it needs to be defined, which network functions should be used (e.g. stateless autoconfiguration). Thedefinitionofscenariosandderivedfunctionsisanimportantprecondition forapplyingtheprofiledocuments.Theydetermine,whichsectionsoftheprofile have to be taken into account for the planned network, and in effect, which features areoptional,recommendedormandatory.
Theprofileshouldbeseenasakindofchecklisttodeterminethesetofrequirementsthatareimportantforthetargetednetwork.Thissetcanthenlaterbeusedasinputtothefunctionalspecificationdocumenttobeusedinprocurement.ItisnotappropriatetojustrefertotheIPv6profileina“must-be-fulfilled”manner;itismerelyabasistolookuptheconcretesetofrequirements.
5
Alternatively,suchasetofrequirementscanbeusedtoquerydetailedfeedbackfromnetworkequipmentvendorsabouttheapplicabilityoftheirdevicesfortheplannedIPv6network,basedonalistingofrelevantIPv6standards(requestforcomments,RFC).Inbothcases,youcanusetheprofileasabasisforcommunicationbetweenvendorsandcustomersaboutdetailedtechnicalrequirements,intheformofrelevantIPv6standards(requestforcomments,RFCs)andassociatedrequire¬mentlevels.Additionally,wepointoutthatthecombinationoftechnicalsystemsinanetworkwhichalldofulfiltheIPv6profiledoesnotnecessarilyleadtoafullyfunctioningnetworksetup–thefulfilmentoftheprofilerequirementsishoweveranecessaryminimalrequirementforsuccessfulinteroperation.
Note that the concrete configuration of the systems is not part of the IPv6profile. Thiseffectivelymeansthatsettingupthenetworkedsystemsinausefulandcompatiblewayisaseparateproject,afterprocuringsystemswhichhavealltherequiredfeaturesimplemented.Inpractice,evensystemswhicharecompatibleonpaperanddosupportalltherequiredfeatures,mayexperienceinteroperabilityissues,duetoslightdifferencesinIPv6implemen-tations.Therefore,dedicatedinteroperability labtestsarerecommended, toseesystemsbehaviour in practice.
exISTINg PRoFIleS FoR IPv6ExistingIPv6profilesusuallydescribemandatory/recommended/optionalrequirementsforIPv6-enableddevicesorimplementations,basedonSTDandRFCdocuments.Theremaybeadditionaltechnicalrequirementsinanygivenusecase,forexampledependingonspecificquality-orsecurity-relatedrequirements.Useof theprofiles(andconformancetoanyoneofthem)isonlyonesteptowardspracticalinteroperability,asitdependsalsoontheactualdevices’configuration,andpossiblyalsovendor(in)-compatibilities.
6
RequIReMeNTS FoR IPv6INICTEqUIPMENT(RIPE-554)The Réseaux IP européens Network Coordination Centre (RIPe NCC) supports the technical coordinationof Internet infrastructureswithin Europe. In this frame¬work the IPv6workinggrouphasdeveloped„RequirementsforIPv6inICTEquipment“.TheserequirementshavebeendocumentedinNovember2010in“ripe-501”[ripe-501].AsofJune2012anupdatedversionofthisdocumentisavailablein“ripe-554”[ripe-554].
Theripe-554document–andspecificallytherequirementsdocumentedtherein–canbeseenasasupportingcollectionofbestpracticesforthepublicsectorandcommercialcompaniesalike.
Ripe-554 identifies the essential devices classes: Switches (for end users or enterprises),routers,endsystems, securitydevices (classifiedaseitherpacketfilters,application layergateways,orintrusiondetectionsystems),CPErouters,mobiledevices,andloadbalancers.ForeachclassitidentifiesmandatorilyandoptimallyimplementedRFCs.Duringprocurement,devicesshouldbepreferredthatimplementamajorityoftheoptionalrequirements,inadditiontoallthemandatoryones,ofcourse.
Ripe-554isrelativelycoarseinitscharacterizationofthedifferentRFCs,asitdoesnotdifferentiatebetweentherequirementsforindependentfeaturesinsidesingleRFCdocuments.
7
DePARTMeNT oF DeFeNSe uNIFIeD CAPABIlITIeS RequIReMeNTS 2008, ChANge 2 (uCR 2008, ChANge 2)
Thisdocument,which isactually fromDecember2010,describesquitecomprehensivelyamultitudeofrequirementsonIPv6devicesandimplementationsforprocurementbytheUnitedStatesDepartmentofDefense(DoD).Subchapter5.3.5ofitdocumentstherequirementsrelatedtoIPv6.Anintegralcomponentofthedocumentisthe“DoDIPv6StandardProfilesforIPv6CapableProductsversion5.0”,fromJuly2010.
Thedocumentcontainsadetaileddeviceclassification,anditidentifiesmandatory,recommended,andoptionalfeaturesbasedontheclassificationofdevicesintosimpleendsystem/simpleserver,router,securitydevice(packetfilter,applicationlayergateway),switch,andendsystem(orspecific application).
ThedocumentnotonlyliststherequiredRFCsthemselves,butalsolistsdemandsonspecificfunctions,and preferences on how given features should be used.
8
IPv6 ReADy logo PRogRAM oF The IPv6 FoRuMThe vendor-driven IPv6 Ready Logo Program [IPv6Ready] of the IPv6 forum encompassesspecificationsforconformitytestsandinter¬operabilitytestsforIPv6andrelatedprotocols:
The IPv6 base protocol (including SlAAC , ICMP , addressing architecture, explicit congestion notification (eCN), Neighbor Discovery (ND) and Path MTu Discovery)
• IPsecandIKEv24
• MulticastListenerDiscovery,Version2 • SNMPMIBs5
• MobileIPv6andNEMO6 • DHCPv67
• SIP8
ForthispurposetheIPv6forumprovidestestsuitesforautomatedprocessing.Asuccessfulpassingof such test suite authorizes a vendor to assign the IPv6 Ready logo to the tested devices series. There exist dedicated IPv6 test centres, which provide running of the test suite as a service. however, the IPv6Readylogocanalsobeawardedbythevendoritselfbysigningadeclarationofconformity,i.e.stating that a devices series has passed the IPv6 Ready tests successfully.
Thosetestsare–onpurpose–verydetailedandcomprehensive.Theytakeintoconsiderationthetargetedroleofthesystemundertest,andsometimesgointodetailuptocheckingsinglemessagesandmessageexchangesbetweendevices.OntheotherhandthenumberofreferredRFCs in the IPv6Ready tests is relativelysmall (36compared tomore than200 inother IPv6profiles). The IPv6 Ready tests include only checks that can be verified using a standardized externalinterfaceofthesystemundertest.Internalvariables,suchasinternalrouterstatesarenotchecked.ThismeansthatpassingtheIPv6Readytestsdoesnotautomaticallyimplyafullycorrectimplementationofarequiredfeature.
we note especially that network protection functions, as provided by packet filters and application layer gateways, are not captured by the IPv6 Ready tests as these functions are notformallystandardizedinSTDandRFCdocuments.
1Stateless Address Autoconfiguration 2 Internet Control Message Protocol 3 Maximum Transfer Unit 4 Internet Key Exchange
5 Management Information Base 6 Network Mobility 7 Dynamic Host Configuration Protocol 8 Session Initiation Protocol
9
A PRoFIle FoR IPv6 IN The u.S. goVeRNMeNTThisdocument[NIST_USGv6],inversion1.0fromSeptember2008,hasbeendevelopedby the National Institute of Standards and Technology (NIST), an organization related to the USministryoftrade.Thedocumentdividesnetworkeddevicesintoendsystems,routers,andsecuritydevices(packetfilter,application-layergateway,andintrusiondetection/prevention devices).
Thenetwork-related featuresarecategorizedby it into12groups:Base features, routing,service quality, transition between IPv4 and IPv6, link-specific features, addressing,IPsec-relatedfeatures,networkmanagement,multicast,mobilitysupport,applicationlevelrequirements,andspecialrequirementsbysecuritydevices.
Thedocumentgoesintomuchdetailconcerningthedevices’intendedusageenvironment(use cases), and the relations between different features, based on the defining RFC documents. This approach results in aquite complexdocument, becausemany featuresare required only conditionally, in dependence of others. Features are divided into mandatoryandoptionalones.Itdoesnotvalueorprioritizetheoptionalfeatures,however.ThedocumentspecifiesforeachfeaturewhichRFCsmustbeimplementedinordertofulfilthe desired functionality.
In its goals, the [NIST_USGv6] document comes closest to our IPv6 profile document.Unfortunately,due to itsage, some importantpartsof [NIST_USGv6]arenot up-to-dateanymore,sothatthereaderoftenneedstocheckforupdatedornewerRFCdocuments,tofindthelatestdefinitions,whenassessingit.Uptothebeginningof2013nonewerversionof[NIST_USGv6]hasbeenreleased.
10
guIDelINeS FoR The SeCuRe DePloyMeNT oF IPv6ThisNISTdocument[NIST_119],fromDecember2010,ismostofallanIPv6tutorial,butwithaspecificfocusonIPv6securityissues.ItespeciallyinformsthereaderaboutthoseIPv6secu-rity risks, which have not yet been finally solved (e.g. IP first hop security issues in Intranets).
IPv6 NoDe RequIReMeNTSRFC6434(“IPv6NodeRequirements”)[RFC6434],fromDecember2011,isanupdateonRFC4294(publishedApril2006).ItisforemostaninformalsummaryandreferenceofallthefundamentalIPv6RFCs,theirmainfeatures,andtherelevancethereof.
Thedocumentdividesnetworkeddevices intonodes, routers,andend systems.Unfor-tunately, the documentdoesnot regard transit systems (suchas securitydeviceswithoutdedicatedroutingfunctionality)asaseparateclass,asalltheprofiledocumentsmentionedbefore do.
SomeRFCsof the“informational” typearealso referredbyourprofilematrixdocument,asthesesometimesaretheoneswhichspecifyrelevantparametersforpracticaluseofaprotocol.InanycaseitcanbebeneficialtoreadtheinformationalRFCsinyourareaofinterest too. In theremainderof thissectionwehighlight important“overviewtype”RFCsthatarerelevantforworkingwithourIPv6documentsandIP6ingeneral.
11
The geN6 PRoFIle BASeD oN The geRMAN IPv6 PRoFIleTheevaluationofexisting IPv6profilesshowed that theseprofiledocumentsdo indeednotrepresentcompetingdefinitions,butrepresentcomplementaryapproaches,showingIPv6aspectsofcomponentsfromdifferentpointsofviewandwiththeirmainemphasisondifferentIPv6issues.
Allconsideredprofiledocuments relate to relevantstandardsdocuments (request forcomments,RFC)andlistfeaturesfromthesestandardsfordifferentclassesofdevicesandindifferentre-quirement levels. In thisway, theprofiles recommendwhichRFCs (allorparts thereof)aremandated,recommended,oroptional,givenaspecificdevice,networkenvironment,andusecase.
Theexistingprofilesdifferintheirterminologyregardingrequirementlevel,aswellintheirdepth–whereoneprofilemaymandateacompleteRFC,anothermaypickspecificfeaturesfromthatRFConly.Inourcomparisonandconsolidationworkwehavealignedthedatafromtheotherprofilesasbestaspossible,andhaveexplaineddifferenceswhereneeded,tomotivateourrecommendation.
ThewrittenresultsofourworkonIPv6profilesconsistsofasetofspreadsheetsthatdocumentthereferredstandards,theirrecommendsrequirementslevels,andthecomparisontotheotherprofiledocuments.Where the naming schemeof recommendation levels does differ betweenprofiledocuments,itissuggestedtohaveamoredetailedlookintothedefinitionofthem,especiallywhen there is a need to work with one of the other profiles as well.
AsthedevelopmentaroundIPv6isstillveryactive,andmanynewRFCsrelatedtoIPv6arestillpublishedeachyear,ourrecommendationswilldevelopinfuturerevisionsoftheprofiledocu-ments,too.Theseupcomingstandards,pluspracticalexperiencesofnetworkequipmentvendorsandusersmandateupdatingourdocumentsinthefuture.
TheGEN6profilematrixhasbeenstructuredalong two“dimensions” tomake itoptimallyaccessibletothereader.Thesedimensionsare: • deviceclassesand • functionalcategories.
12
Thedifferentdeviceclassesaredescribedonaseparatetablesheet.Therecommendationsperfunctionalcategorythemselvesarestructuredhierarchicallyoneachsheet.Inordertoavoidredundancies in thedescriptions,wefirstdefine the“IPv6node”as thebasis forallotherIPv6-enableddevices.ThesheetsforallotherdeviceclassedthenonlydefinetherequirementswhichareneededinadditiontoIPv6node.Astheprofileistargetedinitiallytowardsthenetworksanddevicesorthepublicadministration,thissethadtobeextended,leadingtothesetdepictedinfigure1.The“whitenodes”inFigure1areforstructuringonly,theydonotrepresentaseparatetablesheetintheprofilematrix.
Node
End system Router Security devices
Packet filter
Applica�on layer gateway
VPN crypto-gateway
Infrastructure server
DNS, DHCP, SNMP
Management Enterprise switch
Figure 1: Hierarchy of Device Classes
13
These classes represent a generic instance of this class. The Node sheet as the basis defines all requirementswhichaffecteachIPv6-capabledevice.Aconcretedevicemayindeedimplementthefeaturesofmorethanonedeviceclass.TakeforexampleacurrentSOHODSLgateway–itusuallyimplementsfunctionsfromthedeviceclassesrouter,packetfilter,DNS/DHCPserver,andpossiblyotherinfrastructureserversaswell.Therefore,tocollectallrequirementsforagivendevice,multipletable sheets have to be taken into consideration (cf. Figure 2).
Securitydevices(inthepublicadministration)playaspecialrole:EventhoughtheyarebasedonNodeaswell,theirpracticalimplementationmayinfactdeviatefromsome“MUST”typerecom-mendationsfromthenodesheet,ifthisisafunctionalnecessityfortheiroperation.Thefollowingfigureshowsthesetupforhomerouterandinternetaccesspoint.MainfeaturearefromtheNODEdeviceandadditionalrequirementsarefromotherdeviceclassestodescribetheIPv6capabilitiesof such a device.
Figure 2: Complex Device Example Based on the SOHO Router Use Case
Sec
urity
Dev
ices
Infra
stru
ctur
ese
rver
SOHO gateway device(DSL, router, packet fi lter,...) Router
End system
Packet fi lter
Application LayerGateway
VPN Crypto-Gateway
DNS server
DHCP server
Management
Node
14
how To ReAD The PRoFIle MATRIxThefollowingparagraphsdocumentsomeexamplesonhowtoreadourprofilematrixdo-cument.Forabettercomprehensionwehaveincludedheresomeexcerpts(snippets)fromtheactualprofilematrixdocument.Thesesnippetscanbeeasilyfoundintheprofilematrixdocument.Thefollowingexamplesshowsomeaspectsofitsuse:
In thisexample the last linegivesadditionaldetail information,related to thespecificfeature.Eachusedfeatureorfunctionwhichisreferredinourprofilematrix,willhaveassignedarecommendationlevel.IfsinglefeaturesfromanRFCareexplicitlylistedinourprofilematrix,then(inrare)casestheymayshowarequirementlevelthatdiffersfromtheonegivenintheRFCitself.Also,ourdocumentsometimesassignsrequirementlevelstoafeaturewhichdidnotshowanyrequirementlevelintheRFCdocumentatall.
The second example shows requirements from within the profile matrix which were notspecifiedbyanRFCdocumentinitially.Thisisusuallythecaseinourdocumentwhentherequirementsareofamoreabstractlevel,andrepresentarequirementnotrepresentedbyasingleRFCdocument.Inthisexampleweshowtherequirementtohavedevicesconfigurable(remotely)viaIPv4aswellasIPv6.Thecommentfieldgivesadditionalinformation,here,underwhichconditionsthisspecificrecommendationisrelevant.
Figure 3: Profile Example #1 – Feature / Function and Requirement Level
Figure 4: Profile Example #2 – Feature / Function without a Related RFC
15
IPv6 AND SoFTwAReUsingthepreviouslydefineddevicesprofilesfornetworkeddevicesusingIPv6,wemainlyensuredconnectivityandinteroperabilityonthenetworklayer(layer3),seethefollowingfigure:
The figure shows our proposed reference architecture for use in public administrationnetworks;wedescribemoredetailsaboutthisarchitecturein[IPv6_Transition].Thisreferencearchitecturefiguredepictsthelogicalendtoendcommunicationbetweencertainapplications.Asshown,theuseofsuchanapplicationcanaffectacommunicationpathcoveringtheworkplace PC, local networks, administrativeWANnetworks for couplingadministrations, anddatacentreequipmentontheserverside.Thus,runningandmaintainingsuchanapplicationdependsonmultiplerelateddevices,networks,andsoftwareinstallations.
Thefollowingsectionsanalysethesedependenciesinmoredetail.Thechapterconcludeswiththedescriptionofapracticalprocessforasystematicapproachtocheckthesedependencies.
Figure 5: Testbed Connectivity on the Network Layer
16
COMPONENT-INTERNALREqUIREMENTSForthissectionassumethatthegoalofmakingadeviceworkinanIPv6-capableenvironmentistorunitineitheranIPv4/IPv6dual-stackoranIPv6-onlynetworkenvironment.Foradevice(runninganetworkedsoftware)toworkinsuchanenvironmentitneedstosupportatleastthebaserequirementsdocumentedinourIPv6hardwareprofile.
Followingthis,eachapplicationcomponent toworkwithanIPv6-enablednetworkhas tosupportasetofbaserequirementsaswell:
• SettingupofoutgoingIPv6connections • AcceptingofincomingIPv6connections • HandlingofIPv6addressesforDNSnameresolution
Dependingontheconcreteapplication,additionalrequirementsmayapply,forexample:
• If an application uses IP addresses not only for network connections, then the respectivefunctions(e.g.forlogging,useinsessionmanagement,ordatabase entries)mustalsobeIPv6-capable.
• Whereduringtransitionsomefunctionalelementsoftheapplication(e.g.DNS nameresolution)stillrelyonIPv4beingavailabletoo(whichisfinefordual-stack environments),westronglyrecommendtochecktheapplicationinanIPv6-only environmentaswell,tobeawareofits(non-)functioninginanenvironmentthat completelylacksIPv4.
• WheresoftwareisavailableinsourcecodeformandisdeemedtobeIPv6-capable, ithastobeassuredthatuponcompilationtheIPv6-supportisalsocompiledin (usuallybysettingcompiletimeparameterssuchas“--enableipv6”).
17
DePeNDeNCIeS FRoM oTheR (exTeRNAl) CoMPoNeNTS
Following the previous chapter, we can now have a look at dependencies of a software applicationonfurthercomponentsandonsystemsinits(network)environment.Thefollowingfigureshowsclassesofdependentsystemsforaninspectedcomponent,e.g.anapplication:
Eachclassstandsforasetofoneormoreconcretecomponents.Therefore,wecanrefinethemintothe(non-complete)listofgroupedcomponents.ApplicationArchitectureseparatesdifferentclienttypessuchasthinandfatclients;SupportingSoftwareisaboutgenericservi-ceslikeweb-orprintservers,directoryservicesordatabasemanagementsoftware.Interme-diateSystemsarecomponentssuchasfirewalls,VPNserversorapplicationlayergateways,and the class Network Infrastructure contains basic services such as DNS, DhCP or bind. ForbeingIPv6-ready,adual-stackedapplicationhastoensurethatallthesedependenciesfulfilltheIPv6requirementsinordertoworkproperly.
Figure 6: Application Dependencies and External Components
18
wheRe To FIND ADDITIoNAl INFoRMATIoN
Due to long-grown structures, the public administration already uses a broad portfolioofproducts,and indifferentstatesofmaturity. It is therefore recommended toupdateallexisting systems to the latest stable release of softwareand firmwarebefore starting themigration.CurrentinformationonthestateofIPv6supportofwell-knownICTsolutionscane.g. be found here:
http://ipv6int.net/systems/index.htmlhttp://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systemshttp://en.wikipedia.org/wiki/Comparison_of_IPv6_application_supporthttp://www.deepspace6.net/docs/ipv6_status_page_apps.html
Document References for related ICT profile documents:
[IPv6_Transition] BVA,„IPv6MigrationsleitfadenfürdieöffentlicheVerwaltung“ /“IPv6TransitionGuideforthePublicAdministration“,onlineat http://www.ipv6.bva.bund.de
[IPv6Ready] IPv6ReadyLogoProgram,https://www.ipv6ready.org/
[NIST_119] NIST,“GuidelinesfortheSecureDeploymentofIPv6“,December2010.
[NIST_USGv6] NIST,„AProfileforIPv6intheU.S.Government–Version1.0“,NIST SpecialPublication500-267,July2008, http://www-x.antd.nist.gov/usgv6/docs/usgv6-v1.pdf
[ripe-501] JanŽorž,SanderSteffann,„RequirementsForIPv6inICTEquipment“, RIPENCC,ripe-501,Nov2010,http://www.ripe.net/ripe/docs/ripe-501
[ripe-554] MerikeKäo,JanŽorž,SanderSteffann,„RequirementsforIPv6in ICTEquipment“,RIPENCC,ripe-554,onlineathttp://www.ripe.net/ ripe/docs/current-ripe-documents/ripe-554
19
[UCR08_2] DepartmentofDefense,„UnifiedCapabilitiesRequirements2008, Change2(UCR2008,Change2)“,December2010 ChangestoUCR2008,Change2,Section5.3.5,IPv6Requirements, onlineathttp://www.disa.mil/ Services/NetworkServices/UCCO/~/media/Files/DISA/Services/ UCCO/UCR2008-Change-2/07UCR08Chg2Section535.pdf
[UCR08_3] DepartmentofDefense,„UnifiedCapabilitiesRequirements2008, Change3(UCR2008,Change3)“,September2011,onlineat http://www.disa.mil/ServicesNetwork-Services/UCCO/~/media/ Files/DISA/Services/UCCO/UCR2008-Change- 3/01_UCR08_Chg3_Sections_1-4.pdf
DISClAIMeRTheGEN6project(number261584)isco-fundedbytheEuropeanCommissionundertheICTPolicySupportProgramme(PSP)aspartoftheCompetitivenessandInnovationframeworkProgramme(CIP).ThisdocumentcontainsmaterialthatisthecopyrightofcertainGEN6partnersandtheEC,andthatmaybeshared,reproducedorcopied“asis”,followingtheCreative Commons “Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND3.0)licence.Consequently, youare free to share (copy,distribute, transmit) thiswork,but youneed torespect theattribution(respectingtheprojectandauthorsnames,organizations, logosandincluding theprojectweb siteURL “http://www.gen6-project.eu”)anduse thedocumentfornon-commercialpurposesonly,andwithoutanyalteration, transformationorbuildingderivatives upon this work.
TheinformationhereindoesnotnecessarilyexpresstheopinionoftheEC.TheECandthedocument authorsare not responsible for any use thatmight bemadeof dataappearinghereinandeffects that result fromdoingso.TheGEN6partnersdonotwarrant that theinformationcontainedhereiniscapableofuse,orthatuseoftheinformationisfreefromrisk,andsodonotacceptliabilityforanydirectnorindirectlossordamagesufferedbyanypersonusingthisinformation.
This booklet is powered by
This work was part-supported by the European Commission as part of the project“Governments Enabledwith IPv6” - GEN6.GEN6 is about stimulating EU-widedeploymentofIPv6bymeansofbestpracticesandguidelinesinexistingeGovernmentinfrastructures.
Authors:CarstenSchmoll(FraunhoferFOKUS,Germany)UweHolzmann-Kaiser(FraunhoferFOKUS,Germany)CarlosGómezMuñoz(MINHAP,Spain)
Contact:To get in contact with the geN6 project or the partners please contact us in:[email protected]
Layout by Citkomm, all photographs © 2014 by fotolia.com
ThisbookletispartofaseriesofinformationonIPv6transitionineGovernment.Seewww.gen6-project.eu/publications/booklets/forfurtheravailablebooklets.Booklets already published:
-GovernmentmotivationforIPv6transition-Smartcommunicationsolutionsinemergencysituations-IPv6Applicationintheroaddomain-IPv6AddressPlanningandTransition-RequirementAnalysisforeGovernmentServiceswithIPv6
CopyrightofcertainGEN6partnersandtheEC.Shared,reproducedorcopied“asis”,followingtheCreativeCommons“Attribution-NonCommercial-NoDerivs3.0Unported(CCBY-NC-ND3.0)licence.