_Leistungsbeschreibung_VV1_Anlage 1_Migrationsleitfaden v4.1.pdf

[Seite 1]

Migrationsleitfaden für die Umsetzung von IPv6-Migrationseinzelprojekten

der Behörden und Organisationen des Bundes

– IPv6-Programm des Bundes –

Dezember2025

[Seite 2]

IPv6-ProgrammdesBundes

Adressatenkreis

DerMigrationsleitfadenrichtetsichvornehmlichandieMitarbeitendenundProjektleitungenindenMig- rationseinzelprojektenderBehördenundOrganisationendesBundes.

DieserLeitfadenistfüreineAnwendunginderDurchführungallerIPv6-Migrationsprojektegeeignet–un- abhängigvonderProjekt-oderBehördengröße.

Die vom IPv6-Programm bereitgestellten IPv6-Coaches nutzen den Migrationsleitfaden in den von ihnen unterstütztenMigrationseinzelprojekten.

Version4.1 2

[Seite 3]

IPv6-ProgrammdesBundes

Struktur

Änderungshistorie

Version4.1 3

[Seite 4]

IPv6-ProgrammdesBundes

Inhaltsverzeichnis

1 Einführung...............................................................................................................................................8

2 Grundlagen..............................................................................................................................................9

2.1 Programmgrundsätze....................................................................................................................9

2.2 GrundlegendeEmpfehlungenfürMigrationseinzelprojekte........................................................9

2.2.1 AgilesVorgehensmodell...........................................................................................................9

2.2.2 GesamthafteMigrationmitAnwendungsfokus.....................................................................10

2.2.3 VeränderungsaspektundMitarbeitereinbeziehung..............................................................11

2.2.4 Keimzellen-Vorgehen.............................................................................................................11

2.2.5 Keimzellen-Migration.............................................................................................................12

2.3 ArchitekturrichtliniedesBundes.................................................................................................13

2.4 Dual-StackversusIPv6-OnlyundIPv4-Bestandsschutz...............................................................14

2.4.1 IPv4-Bestandsschutz...............................................................................................................16

2.4.2 GatewaysundÜbersetzungstechnologien.............................................................................17

2.4.3 IPv6undRoutingprotokolle....................................................................................................18

2.5 BenutzerdefinierterIPv6-Grundschutzbaustein.........................................................................19

3 EmpfohlenesMigrationsvorgehensmodell...........................................................................................23

3.1 GrobeIst-Aufnahme....................................................................................................................25

3.2 Keimzellen-Identifikation............................................................................................................27

3.2.1 NetzwerkalsStartpunkt.........................................................................................................28

3.2.2 AnwendungenalsStartpunkt.................................................................................................30

3.2.3 RouterundSwitchesalsStartpunkt.......................................................................................33

3.2.4 SicherheitskomponentenalsStartpunkt................................................................................34

3.3 AgilesVorgehensmodell..............................................................................................................35

3.3.1 KontinuierlicheIdentifikation.................................................................................................39

3.3.2 KontinuierlicheErprobung.....................................................................................................50

3.3.3 KontinuierlicheUmsetzung....................................................................................................55

3.3.4 KontinuierlichesLernen..........................................................................................................75

3.3.5 ErneuteDurchläufe................................................................................................................89

3.3.6 GrenzendesagilenVorgehensmodells..................................................................................90

3.4 Wasserfall-Vorgehen...................................................................................................................92

4 OrganisatorischeRahmenbedingungen................................................................................................94

4.1 Projektsponsor............................................................................................................................94

4.2 Technik-Team..............................................................................................................................94

4.3 Cross-funktionaleSub-Teams.....................................................................................................95

4.4 Migrationsprojektleitung............................................................................................................96

4.5 AnsprechpersonenfürorganisatorischeThemenderIPv6-Migration.......................................97

Version4.1 4

[Seite 5]

IPv6-ProgrammdesBundes

4.6 ExemplarischesProjektorganigrammfüreinMigrationseinzelprojekt......................................98

5 Exkurs:AdressvergabeschemaBund2.0undGrundlagenderVerwaltungvonIPv6-Präfixen...........102

5.1 Vergabeschema.........................................................................................................................102

5.2 Aggregationsbereiche...............................................................................................................103

5.3 BeantragungvonAdressen.......................................................................................................104

5.4 GrundlagenderVerwaltungvonIPv6-PräfixeneinerBehördeoderOrganisationdesBundes105

5.4.1 TypenvonNetzwerkanschlüssen.........................................................................................107

5.4.2 VergabeinnerhalbderBehördeoderOrganisationdesBundes..........................................107

6 Exkurs:ProgrammeigeneIPv6-Testlabore..........................................................................................108

6.1 VirtuellesTestlabor...................................................................................................................109

6.2 PhysischesTestlabor.................................................................................................................110

6.3 TestlaborfürKommunikations-IT.............................................................................................111

7 Exkurs:IT-SicherheitundDatenschutzmitIPv6..................................................................................114

7.1 AspektederIT-Sicherheit..........................................................................................................114

7.1.1 TechnischeAspektederIT-Sicherheit..................................................................................115

7.1.2 OrganisatorischeAspektederIT-Sicherheit.........................................................................120

7.2 DatenschutzbeiderEinführungvonIPv6.................................................................................122

8 Worst-undBest-Practice-Beispiele.....................................................................................................124

9 Anhang................................................................................................................................................127

9.1 Checkliste„GrobeIst-Aufnahme“.............................................................................................127

9.2 PlanungstemplatezurPlanungderMigrationseinzelprojekte..................................................127

9.2.1 Aktivitäten............................................................................................................................127

9.2.2 Kanban..................................................................................................................................127

9.2.3 Einstellungen........................................................................................................................127

9.2.4 ListeallerAktivitäten............................................................................................................128

9.3 Bewertungsmatrix,inkl.Ausschlusskriterien,zurKlassifizierungvonKeimzellen-Kandidaten 130

9.4 Kommunikationsplanungstemplate..........................................................................................130

9.4.1 KommunikationsplanungstemplateBehörden.....................................................................130

9.4.2 NotwendigeAktivitäten........................................................................................................130

9.4.3 Einstellungen........................................................................................................................131

9.4.4 ÜberblickZiele......................................................................................................................131

9.4.5 ÜberblickProgrammmaßnahmen........................................................................................131

9.5 Wirtschaftlichkeitsbetrachtung(WiBe).....................................................................................131

9.5.1 WiBeKW...............................................................................................................................132

9.5.2 TemplateWiBeKW...............................................................................................................132

Version4.1 5

[Seite 6]

IPv6-ProgrammdesBundes

Abbildungsverzeichnis

Abbildung1:ModellzurVerdeutlichungderArchitekturbereiche...............................................................13 Abbildung2:AgilesMigrationsvorgehenanhandvonKeimzellenundInkrementen...................................23 Abbildung3:AgilesVorgehensmodellfüreinMigrationseinzelprojekt........................................................36 Abbildung4:WeltweiteIP-Adressvergabe-Hierarchie..................................................................................47 Abbildung5:LIR/Sub-LIRStruktur...............................................................................................................47 Abbildung6:ÜbersichtdesProjektdashboards(mitBeispieldaten)............................................................79 Abbildung7:ÜbersichtdesBenchmarkingDashboards(mitBeispieldaten)................................................80 Abbildung8:ÜbersichtdesRessortansicht-Dashboards(mitBeispieldaten)...............................................80 Abbildung9:WissensmanagementdesIPv6-Programms.............................................................................86 Abbildung10:„SolutionTrain“füreinbehördlichesMigrationsprojekt......................................................96 Abbildung11:ExemplarischesOrganigrammeinesMigrationseinzelprojekts.............................................98 Abbildung 12: Exemplarisches OrganigrammeinesMigrationseinzelprojektsin Anlehnung an die Modelle ausSAFe........................................................................................................................................................99 Abbildung13:Grundstrukturder/28-Adressbereiche...............................................................................103 Abbildung14:BeispielhafteNetzwerkkonfigurationinEVE-NG.................................................................109 Abbildung15:AufbaudesphysischenTestlabors.......................................................................................110 Abbildung16:AufbaudesTestlaborsfürKommunikations-IT....................................................................112 Abbildung17:Dual-Stack–Beispiel-AufbauimLaborfürKommunikations-IT..........................................113

Version4.1 6

[Seite 7]

IPv6-ProgrammdesBundes

Tabellenverzeichnis

Tabelle1:AusgewählteGefährdungendesIPv6-Grundschutzbausteins(HZD)inKorrelationmitKapitelndes Migrationsleitfadens.....................................................................................................................................22 Tabelle2:ExemplarischeTagesordnungfüreinenKick-offeinesMigrationseinzelprojektes......................25 Tabelle3:KorrelationDevOpsnachSAFeundimMigrationsleitfaden........................................................36 Tabelle4:ÜbersichtüberdieIDsfürAktivitätenimagilenVorgehensmodell.............................................39 Tabelle5:Aktivitätenketteinitiale,grobeIst-Aufnahme..............................................................................43 Tabelle6:AktivitätenketteinitialeKeimzellen-Identifikation.......................................................................46 Tabelle7:AktivitätenketteinitialePlanung..................................................................................................50 Tabelle8:AktivitätenketteinitialeVorbereitungderKeimzellen-MigrationenundWiederholungen.........52 Tabelle9:AktivitätenketteersteKeimzellen-Migrationen...........................................................................54 Tabelle10:AktivitätenketteWiederholungdererstenKeimzellen-Migrationen.........................................55 Tabelle11:AktivitätenketteinitialeKonfigurationenvonInkrementen......................................................64 Tabelle12:AktivitätenketteTests.................................................................................................................71 Tabelle13:AktivitätenketteInbetriebnahme...............................................................................................75 Tabelle14:ÜbersichtDatenerhebungsbedarffürProjekt-MonitoringimELISA-Controlling-Tool...............79 Tabelle15:AktivitätenketteProjekt-Monitoring..........................................................................................82 Tabelle16:AktivitätenketteinitialeDokumentation....................................................................................85 Tabelle17:AktivitätenketteErfahrungsaustausch.......................................................................................88 Tabelle18:ZusätzlicheAktivitätenfürerneuteDurchläufedurchdieAktivitätenketten............................90 Tabelle19:AbstimmungsformateinderProjektorganisation....................................................................101 Tabelle20:Sub-LIRBundIPv6-Adressbereiche...........................................................................................102 Tabelle21:ÜbersichtüberdieAnzahlvon/48-und/64-NetzwerkeningroßenPräfixen.........................102 Tabelle22:GrenzenfürgrößerePräfixe.....................................................................................................103 Tabelle23:Vergabeder/44-und/48-PräfixefürBehördenmitnormalemAdressbedarf........................103 Tabelle24:GrundabschnittederAdressbereichsschemata........................................................................104 Tabelle25:Netzanschlussde.gov...............................................................................................................104 Tabelle26:Netzanschlussde.non-gov........................................................................................................105 Tabelle27:ListeallerEinzelaktivitäten.......................................................................................................129

Version4.1 7

[Seite 8]

IPv6-ProgrammdesBundes

1 Einführung

DasIPv6-ProgrammdesBundes(nachfolgendkurzIPv6-Programm)unterstütztdieBehördenundOrgani- sationendesBundesbeiderDurchführungderMigrationseinzelprojekteinÜbereinstimmungmitdemBe- schluss2020/13derKonferenzderIT-Beauftragten(KoITB),heuteCIO-Board,undder„UmsetzungderIPv6- ZielefürWAN-NetzedesBundessowiefürdieüber ‚VerbundeneNetzeimIVÖV‘angebundenenRechen- zentrenimEinklangmitderNetzstrategie2030“inUmsetzungdesIT-Rats-Beschlusses2020/141.Zudem unterstütztdasProgrammdieRealisierungder VorgabeTV-09„Kommunikation“(ID:V-9036-R05)derAr- chitekturrichtliniefürdieITdesBundes(Version6.2.1,Stand2025)2.

ZieldesIPv6-ProgrammsdesBundesistes,dieUmstellungvonIPv4aufIPv6indergesamtenBundesver- waltungzentralzukoordinieren,denErfolgderUmstellungsicherzustellenundinspezifischenThemenfel- dernzuunterstützen.DafürorganisiertdasIPv6-ProgrammeineReihevonUnterstützungsmaßnahmen,zu denenauchdieserMigrationsleitfadengehört.

DasZielderMigrationseinzelprojektebestehtdarin,diegesamteIT,dieineinerBehördeoderOrganisation desBundesimEinsatzist(nichtnurdasNetzwerk),aufIPv6zumigrieren.HierzugehörensowohlimEinsatz befindlicheHard-undSoftwarealsauchdazugehörigeProzesse,Dokumentationundweiterenichttechni- sche Elemente mit Bezug zum IT-Betrieb. Dies wird nachfolgend auch „gesamthafte IPv6-Migration“ ge- nannt.

DerMigrationsleitfadenrichtetsichvornehmlichandieMitarbeitendenundProjektleitungenindenMig- rationseinzelprojekten derBehörden und Organisationen des Bundes. Dieser Leitfaden ist für eine An- wendunginderDurchführungallerIPv6-Migrationsprojektegeeignet–unabhängigvonderProjekt-oder Behördengröße.DievomIPv6-ProgrammbereitgestelltenIPv6-CoachesnutzendenMigrationsleitfaden indenvonihnenunterstütztenMigrationseinzelprojekten.

DieserMigrationsleitfadenbasiertaufdem„IPv6MigrationsleitfadenfürdieöffentlicheVerwaltung“(Ver- sion1.2,August2017).ImUnterschiedzudieserVersionausdemJahr2017legtdervorliegendeMigrati- onsleitfaden den Schwerpunkt auf Hilfestellungen und Empfehlungen zum Vorgehen einer behördlichen IPv6-MigrationundwenigeraufdieErläuterungtechnischerAspektevonIPv6imVergleichzuIPv4undvon IPv6-Migrationen.

DasIPv6-ProgrammstelltfürdieErläuterungtechnischerInhaltedasvirtuelleNachschlagewerk„IPv6-Wiki“ innerhalbderKommunikations-undInteraktionsplattformdesProgrammszurVerfügung.3

Hinweis:AlleindiesemMigrationsleitfadenaufgeführtenRFCs4,inFußnotenverlinkt,findensichauchim Bereich„Referenzen&Ressourcen“desIPv6-WikisaufderKommunikations-undInteraktionsplattformdes IPv6-Programms.

1Siehedafür:https://www.bdbos.bund.de/DE/Aufgaben/IPv6/ipv6programm_node.html;zuletztaufgerufen am11.11.2025 2https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/digitaler-wandel/architekturen-stan- dard/ArchRL.pdf;zuletztaufgerufenam11.11.2025 3KontaktaufnahmezumIPv6-ProgrammdesBundesbitteMailanPostfachipv6-programm@bdbos.bund.de oderhttps://www.bdbos.bund.de/DE/Service/Kontakt_IPv6/kontaktIPv6_node.html;zuletztaufgerufenam 11.11.2025 4RFC:RequestforComments.„DieRFC-Reihe(ISSN2070-1721)enthälttechnischeundorganisatorischeDoku- mentezumInternet,darunterSpezifikationenundRichtliniendokumente,dievonfünfGremienerstelltwurden: derInternetEngineeringTask Force(IETF), derInternetResearchTaskForce(IRTF),demInternetArchitecture Board(IAB),IndependentSubmissionsundEditorial.“(Beschreibungübersetztvonhttps://www.rfc-editor.org/; zuletztaufgerufenam11.11.2025)

Version4.1 8

[Seite 9]

IPv6-ProgrammdesBundes

2 Grundlagen

DasIPv6-ProgrammbietetdenBehördenundOrganisationen„HilfezurSelbsthilfe“an,indemesumfang- reicheUnterstützungsmaßnahmenbereitstellt,diedieMigrationseinzelprojektederBehördenundOrgani- sationenentlastensollen,u.a.dieprogrammeigenenTestlaboreoderdasWissensmanagement.Erfahrun- gen,dieineinerBehördeoderOrganisationdesBundesgesammeltwurden,sollenüberdasWissensma- nagementdesProgrammsundüberweitereVeranstaltungsformatezurVernetzungausgetauschtwerden. DadurchkanneineBehördeoderOrganisationWissenzuIPv6indereigenenOrganisationaufbauen.Mit der durch das IPv6-Programm bereitgestellten Kommunikations- und Interaktionsplattform kann dieses WissenvorallemdurchNutzungdesIPv6-WikisalsdigitalesNachschlagewerkweitervertieftwerden.Die Projektberichte,dievonMigrationseinzelprojektenimBest-Practice-RepositoryundweiterenFormatender Plattform bereitgestellt werden können, lassen sich dazu verwenden, die behördlichen IPv6-Migrationen besserzuplanenundvorzubereitenundsollendabeiunterstützen,Problemeschnellerzuerkennenundzu lösen.DabeigehtdasProgrammdavonaus,dasseinzelneMigrationsschritteindenBehördeninanaloger Weiseausgestaltetwerdenkönnen.DamitdieserErfahrungsaustauschfunktioniert,istesratsam,dassein- zelneSchritteindenMigrationseinzelprojekteninvergleichbareroderähnlicherWeisegeplantunddurch- geführtwerden.DerMigrationsleitfadensolldazubeitragen,eineVergleichbarkeitinderVorbereitungund DurchführungvonMigrationseinzelprojektenherzustellen.

2.1 Programmgrundsätze

DasIPv6-ProgrammfolgtdenProgrammgrundsätzen:

• TransparenzinderUmsetzung:VorallemhinsichtlichderPlanungderjeweiligenIPv6-Migrationender BehördenundOrganisationendesBundeswirdeinhohesMaßanTransparenzfüralleBeteiligtenum- gesetzt. Dazu gehören bspw. gemeinsame Planungs-Workshops. Darüber hinaus wird ein Anforde- rungsmanagementumgesetzt,dasesdenBeteiligtenermöglichensoll,individuelleBedarfezuadres- sieren,dievonübergreifendemInteressesindundbspw.eineÜberarbeitungderbereitgestelltenUn- terlageninitiieren. • Partizipative Zusammenarbeit: Die Einbindung aller Projektbeteiligten dient als Basis für eine moti- vierteZusammenarbeit.Gefördertwirdvorallemein„Community-Ansatz“inderZusammenarbeit,der esermöglicht,dassdiebeteiligtenBehördenundOrganisationendesBundes„inkoordinierterSelbst- organisation“ Erfahrungen und Informationen austauschen und so gemeinsam die IPv6-Migrationen sichergestaltenkönnen. • NutzerorientierteSteuerung:DerBegriffdesNutzendenumfasstimMigrationsprogrammalleUmset- zungspartnerindenOrganisationenundBehörden.Eine nutzerorientierteSteuerungistdurchAgilität und intensive Zusammenarbeit geprägt. Um diese Zusammenarbeit zu fördern, wird ein Wissensma- nagement,gestütztdurcheinedigitalePlattform,etabliert.

2.2 GrundlegendeEmpfehlungenfürMigrationseinzelprojekte

DieseProgrammgrundsätzedefinierenauchdienachfolgenden,grundlegendenEmpfehlungenfürdieVor- bereitungundDurchführungeinesMigrationseinzelprojektes.

2.2.1 AgilesVorgehensmodell

Version4.1 9

[Seite 10]

IPv6-ProgrammdesBundes

EinagilesVorgehensmodellbietetdieGrundlage,diebehördlichenIPv6-MigrationeninkleinereTeilberei- che(nachfolgend„Keimzellen“und„Inkremente“genannt,s.dazuauchu.a.Kapitel3.2)zugliedern.Au- ßerdemermöglichtdiesesVorgehensmodell,Teilbereichevorzuziehen,solltenProblemeauftretenunddie MigrationinsStockengeraten.DamitkannkontinuierlichanderIPv6-Migrationweitergearbeitetundein Projektstoppvermiedenwerden.

InderFachliteraturgibtesvieleunterschiedlicheVorgehensmodellefüreineIPv6-Migration.Diepraktische Erfahrung zeigt, dass sich die behördlichen Rahmenbedingungen teilweise stark voneinander unterschei- den.BeisehrgroßenBehörden,mitvielenLiegenschaftenundselbstbetriebenenWAN-Netzen,kannu.U. ein„Wasserfallvorgehen“nichtoptimalsein.DienacheinanderdurchgeführtenProjektphasen(Ist-Analyse, Soll-Migrationsplanung,Migrationsdurchführung,AbnahmetestsundAbschluss)könnenggf.solangeZeit in Anspruchnehmen, dass die Informationenaus der Ist-Analyse zum Zeitpunkt der Migrationsdurchfüh- rungbereitsveraltetsind.InAusnahmefällen,z.B.beieinerkleinerenBehörde,dienursehrwenigeigene ITbetreibt,kannein„Wasserfallmodell“angewendetwerden.

EskannauchkeinstrengagilesVorgehensmodell,bspw.nachScrum,empfohlenwerden,daessichbeim Migrationseinzelprojekt nicht um eine Softwareentwicklung handelt. Zudem verfügen die Behörden zum Teilübereigene,bewährteVorgehensmodelle,diesieregelmäßigeinsetzen.

Elemente von agilen Vorgehensmodellen sollten in den Migrationseinzelprojekten zur Anwendung kom- men,umdieRisikeneinesWasserfallmodellsauszugleichen.DieserGrundsatzhatauchAuswirkungenauf dieVergabederzugewiesenenIPv6-AdressenaneingesetzteKonfigurationselemente5(Engl.:Configuration item, abgekürzt „CI“). Anstatt die Zuweisung von IPv6-Adressen bis zum letzten Konfigurationselement durchzuplanen,empfiehltdieserMigrationsleitfaden,zunächsteinegrobePlanungmitFokusaufdieNetz- werke vorzunehmen.Nachfolgendsollte eine VergabevonIPv6-Adressen entsprechenddemMigrations- fortschrittnachBedarferfolgen.

2.2.2 GesamthafteMigrationmitAnwendungsfokus

IPv6istkeinreinesNetzwerkthema.DementsprechendisteineIPv6-MigrationeinerBehördeauchnichtauf das Netzwerk beschränkt. Netzwerke und Subnetze sollen im Fokus der Planung stehen; aber Endgeräte undweitereKonfigurationselementesindebensowichtig.

IPv6istauchnichtnureinHardwarethema.MithinisteineIPv6-MigrationeinerBehördenichtaufdieein- gesetzten Hardwarekomponenten beschränkt. Hardware dient dem Betrieb von Anwendungen. Anwen- dungenstellenAnforderungenandieKonfigurationdereingesetztenKonfigurationselemente.Erfolgteine reineIPv6-Hardwaremigration,kanndasRisikoeintreten,dassdieAnforderungenderMitarbeitenden,die mitdiesenAnwendungentagtäglicharbeitenmüssen,nichtmehradäquatumgesetztwerden.

5Definitions.https://csrc.nist.gov/glossary/term/configuration_item;zuletztaufgerufenam10.11.2025

Version4.1 10

[Seite 11]

IPv6-ProgrammdesBundes

EineIPv6-MigrationsolltealleeingesetztenKonfigurationselementeeinerBehördeumfassen.Nurmiteiner solchengesamthaftenIPv6-MigrationkönnendieVorteilevonIPv6erschlossenundSicherheitsrisikenver- miedenwerden.DabeimusseinegesamthafteIPv6-Migrationweder„ineinemRutsch“nochalsIPv6-Only (einKonfigurationselementkannnurnochmitIPv6adressiertwerden)gestaltetwerden.

2.2.3 VeränderungsaspektundMitarbeitereinbeziehung

IneinegesamthafteIPv6-MigrationwerdenalleArbeitsbereichederMitarbeitendeneinerBehördeeinbe- zogen.DiesumfasstalleElemente,dieüberNetzwerkekommunizieren,bspw.auchdieTelefonie,dieVide- okonferenzsysteme oder die Zeiterfassungstools. Während der IPv6-Migration können Risiken und Prob- lemeentstehen,diedieMitarbeitendenspüren,wennbspw.eineAnwendungplötzlichnichtmehrdasge- wohnteAntwortzeitverhaltenzeigt.ZudemstellteinMigrationseinzelprojektvorallemfürdieIT-Abteilung und deren Mitarbeitende eine Herausforderung undBelastung dar.Gleichzeitig bietet aber eine gesamt- hafteIPv6-MigrationvieleneueChancenfüreinemoderneIT-AusstattungundKommunikationsinfrastruk- turineinerBehörde.

DementsprechendisteinMigrationseinzelprojektauchimmereinVeränderungsprojekt.

2.2.4 Keimzellen-Vorgehen

ImKerndesKeimzellen-Vorgehenssteht,dassinderRegelkeinegesamthafteMigration„ineinemRutsch“ geplantwerdensollte.

ImerstenSchrittwirdvielmehreinegrobeIst-AufnahmedereingesetztenKonfigurationselementedurch- geführt (siehe Kapitel 3.1). Auf Basis dieser groben Ist-Aufnahme begibt sich das Projektteam auf

Version4.1 11

[Seite 12]

IPv6-ProgrammdesBundes

KandidatensuchefürMigrations-Keimzellen(sieheKapitel3.3.1.2).GeeigneteMigrations-Keimzellen-Kan- didatensind:

• Kandidaten mit akutem Handlungsbedarf (bspw. Umstellung des VPN-Zugangs, dringend benötigte Hardware-oderSoftwareupgradesoderdieBehebungvonSicherheitslücken) • KandidatenmitwenigRisiko(bspw.eineDatenbankverbindungzwischenServern) • KandidatenimVerantwortungsbereichvoninteressiertenFreiwilligen • Kandidaten,diedenAufbauderInfrastrukturenvorantreiben(bspw.NetzwerkeimBackbonederBe- hördemitNetzwerkkomponenten,dieseitvielenJahrenIPv6-fähigsind).

BeidieserAuswahldergeeignetenKeimzellen-Kandidatengilteszubeachten:

• EssolltenmöglichstkleineMigrations-Keimzellenausgewähltwerden,sonstkonterkariertesdieses Vorgehensmodell.VoneinerAnwendungausgehendistesaberbeiderAuswahlderkleinenKeimzelle wichtig,dieAufgaben(unddamitauchAufwände),diedazuindenInfrastrukturenanfallen,nichtaußer Achtzulassen,sondernmiteinzurechnen.EsgiltderGrundsatz:„Zukleingibtesnicht!“.Selbstbeider MigrationeinereinzelnenTCP-VerbindungzwischenzweiGerätenimgleichenSubnetzalsallererster KeimzellekönnenindenInfrastrukturenvieleAufgabenanfallen. • KeinKonfigurationselementsolltemehrfachalsKeimzelleidentifiziertwerden.Wennein„Standard“- Webserver im Migrationseinzelprojekt schon einmal von IPv4 auf IPv6 migriert wurde, dann sollten nichtdieweitereninderBehördeeingesetztenStandard-WebserveralsweitereKeimzellenidentifiziert werden.VielmehrsolltendieErgebnisseundErfahrungenderMigrationdeserstenStandard-Webser- verssoaufbereitetwerden,dassdiesefüralleweiterenMigrationendiesesKonfigurationselementsals Standardvorgabeverwendet werden können.Auf Basisdieser ersten Keimzelle wird nachfolgendein IPv6-Roll-out-PlanfürdieseGruppeanKonfigurationselementenentworfen.ImnachfolgendenMigra- tionsleitfadenwirddiesesVorgehenselementauchWiederholunggenannt. • EssolltensovieleKeimzellenidentifiziertundmigriertwerden,wiedasTeambraucht,umeinMigrati- onseinzelprojektsicherdurchführenzukönnen.InÜbereinstimmungmitderKomplexitätderbehörd- lichen IT-Infrastruktur sollten so viele Keimzellen definiert werden, wie die IT-Abteilung braucht, um SicherheithinsichtlichderIPv6-Migrationen–auchimBetrieb–zugewinnen.DurchdieMultiplikation der Ergebnisse der Migrations-Keimzellen und das Teilen der Migrationserfahrungen (der guten, um diesezukopieren;derschlechten,umdiesezuvermeiden)wirdIPv6ineinemMigrationseinzelprojekt zumSelbstläufer.SämtlicheErfahrungenausdenKeimzellen-Migrationenkönnennutzbringendfürdie IPv6-MigrationenweitererInkrementederbehördlichenIT-Landschafteingesetztwerden.

2.2.5 Keimzellen-Migration

Ein Migrationseinzelprojekt kann sich nicht nur auf die ausgewählten Migrations-Keimzellen und deren Wiederholungenfokussieren,umdieITgesamthaftnachIPv6zumigrieren.Eswird(teilweisegroße)Berei- che der IT in einer Behörde und Organisation des Bundes geben, für die nach der groben Ist-Aufnahme keineMigrations-Keimzellenidentifiziertwerden.DieKonfigurationselementeindiesenBereichenmüssen auchmigriertwerden,umdieBeschlüssedesCIO-Boards(sieheKapitel1)unddieVorgabenderArchitek- turrichtlinie(siehenachfolgendesKapitel2.3)einzuhalten.DieseBereichewerdenimempfohlenen,agilen VorgehensmodellInkrementegenannt,vergleichbarmitInkrementeninderSoftwareentwicklungodermit

Version4.1 12

[Seite 13]

IPv6-ProgrammdesBundes

einem „SolutionTrain“ nachdemScaledAgile Framework (SAFe)6.Inkremente sindmehrereKonfigurati- onselemente, die über Schnittstellen miteinander verbunden sind, und gemeinsam in einem Migrations- schritt auf IPv6 umgestellt werden. Im Migrationsleitfaden wird empfohlen, mit Inkrement-Migrationen dannzubeginnen,wenneinigeKeimzellen-Migrationenerfolgreichdurchgeführtwurden.DieErfahrungen ausdiesenMigrationensolltenandieMitarbeitendendesMigrationseinzelprojektsweitergeleitetwerden, diefürnochnichtmigrierteBereichederIT,v.a.dieInkremente,verantwortlichsind.

IndergrobenIst-Aufnahme(sieheKapitel3.1)wirddiebehördlicheITinGänzeanalysiertundinKeimzellen undInkrementefürdieIPv6-Migrationunterteilt.ImMigrationsplanfüreinMigrationseinzelprojekt(siehe Kapitel3.3.1.3)werdendieidentifiziertenKeimzellenundInkrementeineineReihenfolgegebracht,wobei ein hoher GradanParallelisierung möglich ist.Entsprechend desempfohlenen agilen Vorgehenswerden grobeIst-AufnahmeundMigrationsplankontinuierlichangepasst(vergleichbarmiteinemBacklog-Refine- mentinScrumoderinSAFe).DasZieleinesMigrationseinzelprojekts,dieITeinerBehördeoderOrganisa- tiondesBundesvollständigundunterBeachtungderinderArchitekturrichtliniedesBundesbeschriebenen MigrationspfadeaufIPv6umzustellen,wirddurchdasagileVorgehenunterstütztundnichteingeschränkt.

2.3 ArchitekturrichtliniedesBundes

DieArchitekturrichtliniedesBundes(Version6.2.1,2025)istinzweifacherHinsichtfürdasIPv6-Programm vonbesondererBedeutung:Zumeinenistdas„MetamodellderRahmenarchitekturIT-SteuerungBund“ein OrientierungsrahmenfürdasProgrammunddieMigrationseinzelprojekte.

Abbildung1:ModellzurVerdeutlichungderArchitekturbereiche7

DieindiesemMetamodelldokumentiertenArchitekturbereiche,v.a.aufder„thematischenEbene“,sind dieGrundlagedafür,voneinergesamthaftenIPv6-Migrationauszugehen,diealleKonfigurationselemente einer Behörde oder Organisation einschließt. Auch „Informationssicherheit, Datenschutz und Geheim- schutz“spielenindenMigrationseinzelprojekteneinegroßeRolle,daeineMigrationvonIPv4aufIPv6neue technischeMöglichkeitenbietet,bekannteAngriffsszenarienzubeheben,aberauchneueAngriffsszenarien mitsichbringt.

ZumanderenfindetsichinderArchitekturrichtliniedieVorgabeTV-09„Kommunikation“(ID:V-9036-R05, S.60ff.). Darin wird ausgeführt: „Die Kommunikation muss vollständig über IPv6 funktionsfähig sein“ (S. 60),ergänztumdenHinweis:„DieImplikationenderflächendeckendenEinführungvonIPv6sindaufgrund der vielfachen Abhängigkeiten sehr groß und werden dramatisch größer, je länger dessen Einführung

.6https://framework.scaledagile.com/solution-train/;zuletztaufgerufenam11.11.2025 7AbbildungangelehntandieArchitekturrichtliniefürdieITdesBundes(Version1.0vom13.06.2019),Ab- schnitt,„Abbildung4:„AusdemMetamodellderRahmenarchitekturIT-SteuerungBundentwickeltesModell zurVerdeutlichungderArchitekturbereiche“.Quelle:KoITB-Beschluss2019/7, https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/cio-bund/steuerung-it-bund/beschlu- esse_cio-board_KoITB/2019_7_Beschluss_Konferenz_IT_Beauftragte.pdf;zuletztaufgerufenam11.11.2025

Version4.1 13

[Seite 14]

IPv6-ProgrammdesBundes

hinausgezögertwird“(S.61).DieserUmstandmotivierteinezeitnaheUmsetzungderIPv6-Migrationenso- wohl in den zentralen bereitgestellten Netzen und Diensten sowie auch in den einzelnen Behörden und OrganisationendesBundes.

WieobenindenGrundlagenbeschrieben,sollenIPv6-MigrationenIT-Systeme,VerfahrenundInfrastruktu- rengesamthaftumfassen.DabeilässtdieArchitekturrichtliniediedreiMigrationswegezu:„IPv6-Only“v.a. fürNetzbereicheundihreAnwendung,dieweitgehendautarksindundIPv4dortnichtbenötigtwird;„IPv4- /IPv6-Dual-Stack“fürdentechnischenÜbergangdort,woderparalleleEinsatzvonIPv4undIPv6unabding- baristundder„IPv4-Bestandsschutz“in„IT-Konzepten,inkl.Sicherheitskonzepten“,„IT-Hardwarekompo- nenten“ und „IT-Softwarekomponenten (insbesondere Einzelentwicklungen – Fachverfahren für Behör- den)“als„notwendigeLösung“dort,woIPv4trotzdesstandardmäßigenEinsatzesvonIPv6bedarfsweise erhaltenbleibenmuss(S.61).

MitdemIPv6-ProgrammwirddieseVorgabederArchitekturrichtliniedesBundesumgesetzt.

„Die Architekturrichtlinie hilft dabei Architekturentscheidungen systematisch, nachvollziehbar und trans- parentzutreffen…“(S.1),soeinesdererklärtenZieledesDokuments.DieserMigrationsleitfadensolleben- fallsdabeiunterstützen,Architekturentscheidungen,dieimZugeeinerIPv6-Migrationerforderlichwerden, zutreffen.DassdieseErforderlichkeiteintrifft,hatvorallemmitdenneuenEigenschaftenvonIPv6zutun, dieaufdieGesamtarchitektur(Enterprise-Architektur)einerBehördeausstrahlen.

2.4 Dual-StackversusIPv6-OnlyundIPv4-Bestandsschutz

Umeine IT-InfrastrukturfürdenÜbergangsbetrieb Dual-Stack-tauglichzumachen,gibt esmehrere Mög- lichkeiten. Vorhandene CIskönnen durchUpgrade oder Austausch Dual-Stack-tauglich gemacht oder um IPv6-CIsdergleichenFunktionsklasse(z.B.Router)ergänztwerden.Eswirdempfohlen,Dual-Stackeinzu- führen,umeinemöglichstdeckungsgleicheStrukturderIPv4-undIPv6-NetzeaufzubauenunddieKomple- xitätderInfrastrukturinGrenzenzuhalten.

Dual-StackermöglichtesGerätenundNetzwerken,sowohlIPv4-alsauchIPv6-Konnektivitätgleichzeitigzu unterstützen.DiesisteinAnsatz,umältereSystemeundNetzwerke,dienochaufIPv4basieren,gleichzeitig mitneuenGerätenundNetzwerkenbasierendaufIPv6parallelzubetreiben.DurchdieVerwendungvon Dual-StackkönnensowohlIPv4-alsauchIPv6-Gerätemiteinanderkommunizieren.FürdieerfolgreicheMig- rationunddenanschließendenstörungsfreienBetriebistesunerlässlich, dassdasneueDesign derInfra- strukturkomponentenineinemTestlaborverifiziertwird.ZusätzlichmüssenLasttestsdurchgeführtwerden, diesicherstellen,dassdaszuerwartendeDatenvolumenauchübertragenwerdenkann.Dasgiltinsbeson- derefürKonfigurationselemente,dieimDual-Stack-Betrieblaufensollen.Beispielsweisebenötigtdannein RouterzweiRoutingtabellen,waswiederumeinehöhereAuslastungdesArbeitsspeichersbedeutet.

IPv6-Dual-StackhateinigewichtigeVor-undNachteile:

• Interoperabilität:DurchdieUnterstützungvonDual-Stackkönnen sowohlIPv4- alsauchIPv6-Geräte problemlosnebeneinanderexistieren.ZurKommunikationuntereinandermusseinIPv6-Gateway ge- nutztwerden.

Version4.1 14

[Seite 15]

IPv6-ProgrammdesBundes

• Übergangszeit:WährendderÜbergangsphasevonIPv4zuIPv6ermöglichtDual-Stackeineschrittweise Migration,ohnedassallevorhandenenSystemesofortaufIPv6umgestelltwerdenmüssen.Hierzuist allerdingseinerhöhterAufwand–u.a.einIPv6-/IPv4-Gateway–notwendig,umzwischendenProto- kollenzuübersetzen. • Wirtschaftlichkeit:WennimEinsatzbefindlicheKonfigurationselementebereitseineIPv6-Dual-Stack- Fähigkeitaufweisen,dannkannesausGründendesInvestitionsschutzeserforderlichsein,diesebiszu einergeplantenNeubeschaffungweiterzubetreiben.BeieinerNeubeschaffungsolltedanngeprüftwer- den,obdieKonfigurationselementeübereineIPv6-Only-Fähigkeitverfügen. • Zukunftssicherheit:DaIPv6dielangfristigeLösungfürdieAdressierungimInternetdarstellt,gewähr- leistet die Implementierung von Dual-Stack, dass Netzwerke für zukünftige Anforderungen gerüstet sind.DerNachteildieserLösungliegtdarin,dassIPv4füralleSystemevollständigverfügbarbleibtund somitdieMotivationfüreineIPv6-MigrationgeringeristalsbeimIPv6-Only-Vorgehen. • Konfiguration:IneinemDual-Stack-NetzwerkbenötigenGerätesowohleineIPv4-alsaucheineIPv6- Adresse, umsicherzustellen,dasssie mitbeidenProtokollen kommunizierenkönnen.Diese Tatsache macht die Konfiguration der zu migrierenden Systeme komplexer, bietet im Gegenzug allerdings die Möglichkeiteiner„sanften“Migration. • RoutingundInfrastruktur:Netzwerk-Routerund-InfrastrukturmüssenebenfallsDual-Stackunterstüt- zen,umdenDatenverkehrzwischenIPv4-undIPv6-Gerätenordnungsgemäßzuleiten.Auchhieristin derÜbergangsphasemiterhöhtemKonfigurationsaufwandzurechnen.

IPv6-Only-Konfigurationselemente können andere Systeme aus dem IPv4-Netz über ein IPv4-/IPv6-Gate- wayerreichen.DieMigrationzuIPv6-OnlybringtimVergleichzuDual-StackmehrereVorteilemitsich,ins- besondereinBezugaufkünftigeSkalierbarkeit,VereinfachungdesNetzwerkmanagementsundSicherheit. DiessindeinigederwichtigstenVorteile:

• Adressraum: IPv6 bietet einen erheblich größeren Adressraum im Vergleichzu IPv4. Dies ermöglicht die Unterstützung einer wachsenden Anzahl von Geräten und Diensten ohne die Notwendigkeit für komplexeNAT-Lösungen8,wiesieinIPv4-Netzwerkenhäufigverwendetwerden.DiesfördertdieSka- lierbarkeitunddasWachstumdesNetzwerks. • Vereinfachtes Netzwerkmanagement: Mit einem reinen IPv6-Netzwerk entfällt die Notwendigkeit, IPv4-Adressenzu verwalten unddie Komplexität vonDual-Stack-Konfigurationenzubewältigen.Dies vereinfacht das Netzwerkmanagement erheblich, da eine einzige Adressierungstechnologie genutzt werdenkann. • Verbesserte Leistungsfähigkeit im Netzwerk: In einem IPv6-Only-Netzwerk entfallen die Overhead- Kosten (sowohl der zeitliche Aufwand der Mitarbeiter für die Pflege als auch die tatsächlichen

8NAT:„NetworkAddressTranslation“–eintechnischesHilfsmittel,welchesdemAdressmangelunterIPv4ent- gegenwirkensoll.Hierbeiverwendenbspw.mehrereHostsineinemNetzsegmentmitunterschiedlichenprivaten IPv4-AdressendiegleicheöffentlicheIPv4-AdressefürnachaußengerichteteKommunikation.

Version4.1 15

[Seite 16]

IPv6-ProgrammdesBundes

monetärenKostenfürdieAufrechterhaltungderIPv4-Infrastruktur)fürdieVerwaltungvonDual-Stack unddieÜbersetzungvonIPv4zuIPv6undumgekehrt.DieskannzueinerverbessertenLeistungführen, insbesonderebeiVerbindungenzwischenGerätenundDiensten,dienativeIPv6unterstützen. • Zukünftige Kompatibilität: IPv6 ist die zukünftige Standardtechnologie für das Internet, da der IPv4- Adressraumbereitsweitgehenderschöpftist.DurchdieMigrationzuIPv6-OnlykönnendieEntwicklun- gendesInternetsnutzbringendeingesetztwerden. • Sicherheitsvorteile:IPv6bieteteinigeSicherheitsverbesserungenimVergleichzuIPv4,wieu.a.Privacy Extensions. Netzwerkweit und aufallenEndgeräten nur einen IP-Stackzu verwalten, macht eseinfa- cher,gegenSicherheitslückenzupatchen,alsbeideStacksimNetzwerkweiterzubetreiben.Allerdings bringtIPv6auchneueHerausforderungenfürdieIT-Sicherheitmitsich(sieheKapitel0). • EinfachereKonfiguration:IneinemIPv6-Only-NetzwerkentfalleneinigederHerausforderungenimZu- sammenhangmitderKonfigurationvonDual-Stack,wiebspw.dierichtigeZuordnungvonIPv4-Adres- senunddieVerwaltungvonNAT-Regeln.AuchderBetriebdes„IPv4-to-IPv6-Gateways“entfälltlang- fristigkomplett.

2.4.1 IPv4-Bestandsschutz

In der Informationstechnologie bedeutet der Begriff „Bestandsschutz“, bereits vorhandene Systeme, An- wendungenoderTechnologienweiterhinzuunterstützenundzunutzen,auchwennneuereVersionenoder Alternativenverfügbarsind.Bestandsschutzwirdoftangewendet,umStabilität,KompatibilitätundKonti- nuität in IT-Systemen sicherzustellen, während gleichzeitig Veränderungen oder Migrationen minimiert werden.InderöffentlichenVerwaltungistderBestandsschutzaucheinwichtigesElementderWirtschaft- lichkeitunddesInvestitionsschutzes.

DieArchitekturrichtliniedesBundeshatinderVorgabeTV-09„Kommunikation“denIPv4-Bestandsschutz fürIPv6-Migrationenfestgeschrieben.

EinigewichtigeAspektedesBestandsschutzesimZusammenhangmitderIPv6-Migrationwerdennachfol- genderörtert.

• NutzungbestehenderSysteme:BehördenkönnenbestehendeIT-Systeme,AnwendungenoderInfra- strukturen ausGründen der Kontinuität undKosteneffizienz weiterhin nutzen,auchwennes moder- nereoderaktualisierteLösungengibt.ImRahmenderIPv6-Migrationbedeutetdies,dassbestehende Systeme langfristig ander Kommunikation mit anderenSystemen zunehmendeingeschränkt agieren können.DieIPv6-Migrationwirdzwangsläufig–besondersimKontextderneuenIPv6-Features–diese Systemeisolieren. • VermeidungvonStörungen:DurchdieAufrechterhaltungdesBestandsschutzeskönnenBehördenUn- terbrechungen,diemitderMigrationaufneueTechnologienverbundenseinkönnen,vermeiden.Dies istbesonderswichtig,umdenreibungslosenBetriebvongeschäftskritischenProzessenzugewährleis- ten. Dieser Vorteil besteht allerdings nur zeitlich begrenzt, denn mit der fortschreitenden IPv6-

Version4.1 16

[Seite 17]

IPv6-ProgrammdesBundes

Migration sind langfristig Probleme in der Kommunikation mit den bereits auf IPv6 umgestellten CIs unausweichlich. • Kompatibilität:IneinigenFällenkönnenältereSystemeoderAnwendungenaufspezifischeWeisekon- figuriertoderangepasstsein.DerBestandsschutzermöglichtes,dieseKonfigurationenbeizubehalten und sicherzustellen, dass bestimmte Funktionen oder Workflows weiterhin ordnungsgemäß funktio- nieren. Langfristig sind auch für diese Systeme oder Anwendungen Umstellungen auf IPv6 sinnvoll, wenndieseamMarkterhältlichsind. • VerfügbarkeitamMarkt:AuchwennsichIPv6amMarktimmerweiterdurchsetzt,sogibtesKonfigu- rationselemente,dienochkeineIPv6-Fähigkeitbesitzen.EinIPv4-Bestandsschutzkannalsoauchdann erforderlichsein,wennauchmiteinerErsatzbeschaffungnochkeineIPv6-FähigkeitfüreinKonfigurati- onselementerworbenwerdenkann. • Investitionsschutz:BehördenundOrganisationen,diebeträchtlicheInvestitioneninbestehendeTech- nologiengetätigthaben,müssen nachdemGebotdeswirtschaftlichenHandelnsdenWert dieserIn- vestitionenschützenunddie Nutzungsdauer dieser Technologienverlängern.Hierbei müssen die zu- grundeliegenden Wirtschaftlichkeitsbetrachtungen fortgeschrieben werden, danachdenpraktischen ErfahrungenderBetriebeinzelner„IPv4-Inseln“mitfortschreitenderIPv6-Migrationimmerkomplexer undteurerwird. • Risikoreduzierung:DieEinführungneuerTechnologienoderSystemekannmitUnsicherheitenundRi- siken verbunden sein. Der Bestandsschutz kann dazu beitragen, diese Risiken zu minimieren, indem bewährte undvertraute Lösungen beibehalten werden.Dadie Lösung„IPv4“ zwar bewährt undver- traut,jedochlangfristignichtzukunftsfähigist,istdasRisikodesBestandsschutzesmitdemRisikoder Migrationabzuwägen.Eskannsinnvollsein,dieMigrationbestimmterKonfigurationselementezeitlich nachhintenzuverlagern.Dieskannmitdemempfohlenen,agilenVorgehenimZugeder Keimzellen- Migrationenfestgestelltwerden.ZudemerlaubtdiesesVorgehen,dieEinschätzungdesIPv4-Bestands- schutzes im Verlauf des Migrationseinzelprojektes zu revidieren, wenn neue Erkenntnisse vorliegen oderdurchdenBestandsschutzneue,zusätzlicheRisikenaufdieBehördezukommen. • MigrationinkontrolliertenSchritten:DerIPv4-BestandsschutzermöglichteineschrittweiseMigration, wodurchdieBehördenundOrganisationendesBundesdieMöglichkeithaben,neueTechnologienauf stabileundkontrollierteWeisezuübernehmen.

2.4.2 GatewaysundÜbersetzungstechnologien

WenneinIPv6-SystemmiteinemIPv4-Systemkommunizierenmöchte,sendetesdieDatenpaketegemäß demIPv6-Protokoll.DasIPv6-/IPv4-GatewayempfängtdiesePakete,übersetztsieindasIPv4-Formatund leitetsiedannandasIPv4-Systemweiter.UmgekehrtübersetztdasGatewayIPv4-PaketeindasIPv6-For- mat,wennsieanIPv6-Systemegesendetwerden.HieristeineArt„NAT“notwendig,daeinIPv4-Endgerät keineIPv6-Adressenkenntbzw.adressierenkann.

Version4.1 17

[Seite 18]

IPv6-ProgrammdesBundes

• IPv4-/IPv6-Gateway: Um die Kommunikation zwischen IPv6-Konfigurationselmenten und IPv4-Konfi- gurationselementenzuermöglichen,wirdeinsogenanntesIPv6-/IPv4-Gatewaybenötigt.DiesesGate- waywirdauchalsDual-Stack-Gatewaybezeichnet,daessowohlIPv6-alsauchIPv4-Konnektivitätbietet unddieKommunikationzwischendenbeidenProtokollenermöglicht. • Adressübersetzung:DaIPv6-AdressenandersstrukturiertsindalsIPv4-Adressen,müssenimGateway ÜbersetzungsmechanismenfürAdressenimplementiertwerden,damitdieKommunikationnahtloser- folgen kann.Prinzipiell ist ein Teildesneuen IPv6-Bereiches reserviert undstellt den„alten“ Bereich derIPv4Adressendar.ImRFC5156„Special-UseIPv6Addresses“9werdendieIPv4-Adressenmitdem Präfix::FFFF:0:0/96indenIPv6-Bereichübertragen. • Protokollübersetzung: Da IPv6 und IPv4 einige Unterschiede in den Protokollmerkmalen aufweisen, mussdasGatewayauchinderLagesein,dieseUnterschiedezuhandhaben,umeinekorrekteKommu- nikationzugewährleisten.AlsBeispiel seihier eine unterschiedlicheBehandlungvonQoS (Quality of Service)genanntoderauchFunktionenwiediemittlerweilesehrfreiverwendbarenundprogrammier- barenIPv6-Extension-Headers.

Esistwichtigzubeachten,dassdieVerwendungeinesGatewaysfürdieKommunikationzwischenIPv6-und IPv4-Systemen als vorübergehende Lösungwährenddes ÜbergangsvonIPv4zu IPv6 dienen sollte. Lang- fristigmussdasZieljedochsein, alleSysteme auf IPv6umzustellen, umdie langfristigen Vorteile unddie ZukunftssicherheitvonIPv6zunutzen.

2.4.3 IPv6undRoutingprotokolle

WährendstatischesRoutingfürIPv6analogzuIPv4eingerichtetwerdenkann,ergebensichfürdiedynami- schenRoutingprotokolleinIPv6(RIPng,EIGRP,OSPFv3,IS-IS,BGP)einigeÄnderungen:

ZwischenAutonomenSystemenwirddasBorderGatewayProtocol(BGP)mitdenMultiprotocolExtensions eingesetzt.

AlsInteriorGatewayProtocolstehenOSPFinderVersion3,IS-ISmitUnterstützungvonIPv6-TLVsundRIPng alsoffeneStandardszurVerfügung.DiemeistenHerstellerunterstützenfürIS-ISMulti-TopologyRouting, alsogleichzeitigesRoutingfürbeideAdressfamilienauchdann,wennIPv4-undIPv6-Netzesichnichtgenau überdecken.

OSPFv3 realisiert dieses in einem neuen Standard (RFC 583810) über verschiedene Instanzen für die ver- schiedenenProtokolle.EinandererWegistes,unterschiedlicheRoutingprotokollefürdiebeidenTopolo- gienzuverwenden,alsoetwaOSPFv2fürIPv4undIS-ISfürIPv6.

EskommenindenIPv6-RoutingprotokollenneueSchlüssellängenundkryptografischeVerfahrenzumEin- satz.Esempfiehltsich,folgendeTechnischeRichtliniendesBundesamtsfürSicherheitinderInformations- technik(BSI),welcheVorgabenfürSchlüssellängenvonKryptographischenVerfahrenenthalten,zubeach- ten:

• TechnischeRichtlinieBSITR-02102-1:KryptographischeVerfahren:EmpfehlungenundSchlüssellängen • TechnischeRichtlinieBSITR-02102-3:Teil3–VerwendungvonInternetProtocolSecurity(IPsec)und InternetKey

FallseinKryptokonzeptvorhandenist,solltediesesumdieseIPv6-Routingprotokolleerweitertwerden.

DerEinsatzderIPv6-Routingprotokollesolltevorhergetestetwerden.

9https://datatracker.ietf.org/doc/html/rfc5156;zuletztaufgerufenam11.11.2025 10https://datatracker.ietf.org/doc/html/rfc5838;zuletztaufgerufenam11.11.2025

Version4.1 18

[Seite 19]

IPv6-ProgrammdesBundes

2.5 BenutzerdefinierterIPv6-Grundschutzbaustein

DieHessischeZentralefürDatenverarbeitung(HZD)hat2020einenbenutzerdefiniertenIPv6-Grundschutz- baustein erarbeitet, um während der Migration Risiken durch externe Gefährdungen zu minimieren und einenstabilenIT-Betriebaufrechtzuerhalten11.DerBausteinwurdedemBSIzurVerfügunggestelltundver- öffentlicht.EristkeinBestandteildesIT-Grundschutz-Kompendiums.SeineAnwendungwirdinSicherheits- konzeptenaberempfohlen,daerdiewichtigstenAspektezuIPv6abdeckt.DerBausteinkannjenachEin- satzumfeld einmal übergreifend für den Informationsverbund modelliert oder bestimmten Zielobjekten (v.a.Anwendungen,Systeme,Netze)zugeordnetwerden.

DerIPv6-Grundschutzbausteinumfasst27identifizierteGefährdungen,denenAnforderungenzugeordnet sind,diealsGegenmaßnahmenergriffenwerdensollten.EswurdenrelevanteGefährdungenausdem IT- Grundschutz-Kompendiumbetrachtet.ZusätzlichwurdenspezifischebenutzerdefinierteGefährdungener- mittelt.

DieseVorgehenshinweisesindnachfolgend„aufeinenBlick“dargestelltundmitdenKapitelnbzw.Inhalten desLeitfadensverknüpft.

11https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Benutzerdefi- nierte_BS/BS_IPv6.html;zuletztaufgerufenam11.11.2025

Version4.1 19

[Seite 20]

IPv6-ProgrammdesBundes

Version4.1 20

[Seite 21]

IPv6-ProgrammdesBundes

Version4.1 21

[Seite 22]

IPv6-ProgrammdesBundes

Tabelle1:AusgewählteGefährdungendesIPv6-Grundschutzbausteins(HZD)inKorrelationmitKapitelndesMigrationsleit- fadens

12Sieheauchhttps://datatracker.ietf.org/doc/html/rfc4864;zuletztaufgerufenam11.11.2025

Version4.1 22

[Seite 23]

IPv6-ProgrammdesBundes

3 Empfohlenes Migrationsvorgehensmodell

Die Migration zu IPv6 ist mit Unwägbarkeiten verbunden. Die Wahrscheinlichkeit ist hoch, dass einzelne Migrationsschrittewiederholtwerdenmüssen,weilesbeiderAnpassungvonKonfigurationenzuSituatio- nengekommenist,dieAuswirkungenaufdieStabilitätdesIT-Betriebshabenkönnen.AusdiesemGrundist essinnvoll,dasProjektinvielekleineSchritte–überKeimzellenundInkrementehinweg–zuzerlegen,die einzelnbeherrschbarsind.ImDetailistdiesesVorgehenimKapitel3.3beschrieben;dienachfolgendeAb- bildungfasstdasVorgehenzusammen:

Abbildung2:AgilesMigrationsvorgehenanhandvonKeimzellenundInkrementen

Wenn in einer Keimzelle oder in einem Inkrement einHemmnis auftritt, können die anderen Keimzellen undInkremente–sofernkeinefachlich-technischeAbhängigkeitbesteht(z.B.Clientszumigrieren,bevor das Netzwerk umgestellt ist, ist kein gutes Vorgehen) – trotzdem weitergeführt werden. Darüber hinaus zeigendiepraktischenErfahrungen,dasssicheinedetaillierteundvollständigeIst-Aufnahmederzumigrie- rendenKonfigurationselementevorStartderIPv6-MigrationinderPraxisnichtbewährt hat.ImZugevon WartungenwerdenkontinuierlicheinzelneKonfigurationselementeparallelzurLaufzeitdesMigrationsein- zelprojektsausgetauscht.MiteinemAustauschändertsichauchderStatusderIPv6-Fähigkeit.Einhäufiges Hemmnisistdiefehlende,eingeschränkteodermangelhafteUnterstützungvonIPv6inBetriebssystemund Anwendungen – umkonkrete Beispiele zu nennen.Umdiese Hemmnisse zu beseitigen, sind oftmalsAb- stimmungen mit denHerstellerndereingesetztenProdukteerforderlich.Zudemkanneszu Engpässenin den Lieferketten kommen,neue oder verbesserte CIskönnen teilweise nicht so wie imMigrationseinzel- projektgeplantgeliefertwerden.AuchhieristdieAufgliederunginKeimzellenundInkrementevongroßem Nutzen,daProjekt-Ressourcen,dieaufneueCIswartenmüssen,flexibelinanderenKeimzellenundInkre- menteneingesetztwerdenkönnen.

Trotzdesempfohlenen,agilenVorgehensisteserforderlich,dassimMigrationseinzelprojektdasZiel,eine gesamthafte Migration durchzuführen, nicht aus dem Blick gerät. Gesamthafte Migration bedeutet, dass im Zuge der groben Ist-Aufnahme (siehe Kapitel 3.1) alle in der Behörde eingesetzten Konfigurationsele- menteundderenIPv6-Fähigkeiterfasstwerden.DiesmussnichtimerstenDurchlauferfolgen(sieheAbbil- dung3),sonderndieIst-AufnahmewirdentsprechenddesagilenVorgehenssukzessiveangereichert.

AufderBasisderErgebnisseder grobenIst-AufnahmeundidealerweiseunterVerwendungdesbereitge- stelltenPlanungstemplates(sieheKapitel9.2)werdenimMigrationsplanMeilensteinefürdasMigrations- einzelprojektgenannt,zuwelchenaucheinavisierterFertigstellungstermindesProjektesgehört.Voraus- setzungfür die FestlegungdiesesFertigstellungsterminist die Festlegungeiner IPv6-Migrationsquote. Da

Version4.1 23

[Seite 24]

IPv6-ProgrammdesBundes

davonauszugehenist,dassfürausgewählteKonfigurationselementeinderBehördeoderOrganisationein IPv4-Bestandsschutzdeklariertwerdenmuss,solltederFertigstellungsterminnichtmitderIPv6-Migation des„letzten“Konfigurationselements,fürdaseinIPv4-Bestandsschutzfestgelegtwurde,korreliertwerden. Zudem sollte bei der Festlegung des Fertigstellungstermins abgewogen werden, wie hoch der Anteil an IPv4-/IPv6-Dual-StackimVergleichzuIPv6-Onlyseinmussodersoll.

DieFestlegungderIPv6-MigrationsquotekannimKick-offfürdasMigrationseinzelprojekterfolgen.Indie- semKick-offsollendieindividuellen,behördlichenZielederIPv6-Migrationfestgelegtwerden.Esbietetsich dabeian,diesenKick-offumdieGrundsätzefüreineIPv6-Migration(„Soagilwiemöglichvorgehen“,„Von derAnwendungausdenken“,„Mitarbeitendeeinbeziehen“und„Migrations-Keimzellenbilden“)herumzu gestaltenundweitereFestlegungenhinsichtlichderkonkretenAusprägungdieserGrundsätzefürdasbe- hördliche Migrationseinzelprojekt zu treffen. Folgende exemplarische Tagesordnung kann im Kick-off für einMigrationseinzelprojektumgesetztwerden:

Version4.1 24

[Seite 25]

IPv6-ProgrammdesBundes

Tabelle2:ExemplarischeTagesordnungfüreinenKick-offeinesMigrationseinzelprojektes

Der Projektplan für das Migrationseinzelprojekt darf die flexibleReaktion auf Hemmnisse und Unabwäg- barkeiten nicht behindern und muss daher in regelmäßigen Intervallen angepasst werden. Die Detailpla- nungindenKeimzellenundInkrementenobliegtdenzugeordnetenTeamsunderfolgtimSinnedesemp- fohlenen,agilenVorgehensaufBasiseinesBacklogs(imPlanungstemplate,sieheKapitel9.2).DieseDetail- planungundderenkontinuierlicheFortschreibungkannmitdemBacklog-Refinementverglichenwerden.

WährendderLaufzeitdesMigrationseinzelprojekteswirdIPv6aktivweiterentwickelt–neueRFCswerden veröffentlicht, neue Generationen von Konfigurationselementen, die eine IPv6-Fähigkeit aufweisen oder aufIPv6-Onlyausgelegtsind,stehenamMarktbereit.DieNutzungneuerFähigkeitenunddieEinarbeitung vonneuen„BestPractices“undSicherheitsempfehlungenwährendderLaufzeitundauchspäterimRegel- betriebisteinwichtigerSchrittzurPflegeeinesmodernenNetzwerkes.

3.1 GrobeIst-Aufnahme

Nach dem Kick-off und den ersten Schritten in das Migrationseinzelprojekt hinein, wie bspw. eine erste VersionderProjektplanung,solleinegrobeIst-AufnahmedervorhandenenITinderBehördedurchgeführt werden.DiegrobeIst-AufnahmeliefertInformationenüberdasbestehendeIPv4-Netzwerkunddiebeste- hende IT-Landschaft sowie die IPv6-Fähigkeit der in der Behörde eingesetzten Konfigurationselemente. DadurchisteinefundierteEntscheidungsfindungüberdasindividuelleBehördenvorgehenimMigrations- einzelprojektfürdieUmstellungaufIPv6möglich.DiegewonnenenErkenntnissesinddieBasisfürdieDe- taillierung der Planung, für die Festlegung des am besten geeigneten Vorgehens in der Behörde, für die AllokationdererforderlichenRessourcensowiefürdieerforderlichenMaßnahmenzurQualitätssicherung undTests.

Version4.1 25

[Seite 26]

IPv6-ProgrammdesBundes

Die grobe Ist-Aufnahme soll einerseits Konfigurationselemente sowie andererseits Architekturvorgaben, anzuwendendeStandards,definierteAustauschformateundSchnittstellenundweiterebehördlicheIT-,Si- cherheits-undDatenschutz-Grundlagendokumenteumfassen.DarüberhinaussollenindiesergrobenIst- AufnahmedieFachdienste,Basisdienste,Querschnittsdienste,InfrastrukturdienstesowieIT-Lösungenund IT-Komponentenaufgelistetwerden.BestehendeIT-RahmendokumenteinderBehördeoderauchbeste- hendeKonfigurationsverzeichnissedereingesetzten,behördlichenITbildendieGrundlagefürdieIst-Auf- nahme und sollten im ersten Schritt ausgewertet werden. Hinzu kommen eingesetzte Anwendungen für Kryptographie, IAM (Identity and Access Management) und BCM (Business Continuity Management). Er- gänzt werden sollte, welche IPv6-Fähigkeit die erfassten Konfigurationselemente aufweisen – IPv6-Only; IPv4-/IPv6-Dual-StackoderIPv4-Only.DieseInformationistfürdieAuswahlmigrationsrelevanterKonfigu- rationselementeunddieKeimzellen-IdentifikationeineVoraussetzung.

Demempfohlenen,agilenVorgehenfolgendsolltengrobeIst-AufnahmeundKeimzellen-Identifikationals auchersteMigrationenvonidentifiziertenKeimzellenüberlappendgeplantwerden.Eszählt–demGrund- verständnis dieses Migrationsleitfadens folgend – immer der „schnelle, erste Schritt“ in eine praktische IPv6-MigrationeinesKonfigurationselements.Nachfolgendwerdendiese„schnellen“IPv6-Migrationenals Keimzellebezeichnet.VollständigparallelisiertkönnendiesePhasenineinemMigrationseinzelprojektnur dannablaufen,wenndieBehördeaufeinegrobeIst-AufnahmedereingesetztenITzurückgreifenkann.

UmdiegrobeIst-Aufnahmezustrukturieren,könnenauchweitereReferenzrahmenwerke–zusätzlichzur Architekturrichtlinie desBundes – hinzugezogen werden.DasichvieleBehördenundOrganisationen des BundesgleichzeitigindenVorbereitungenaufdiebehördlichenBKB-ProjekteundaufdasbehördlicheIPv6- Migrationseinzelprojektbefinden,istessinnvoll,eineStrukturierungsmethodezuverwenden,dieinbeiden Projekten eingesetzt werden kann – die OBASHI-Methode13. Die Anwendung der OBASHI-Methode ist in denentsprechendenLeitfädenundHandreichungenderBKBausführlichbeschriebenunddiesewerdenim programminternenBereichderKommunikations-undInteraktionsplattformdesIPv6-Programmsbereitge- stellt. Mit der Verwendung der OBASHI-Methode wird die Brücke zwischen der groben Ist-Aufnahme in einemMigrationseinzelprojektundderIst-ErhebungineinemBKB-Projektgeschlagen.

ImAnhangdiesesMigrationsleitfadensisteineChecklistezufinden,diefürdiesegrobeIst-Aufnahmever- wendetwerdenkann(sieheKapitel9.1).

IneinerkleinerenIT-LandschaftkanneinekompletteIst-AufnahmeohneweitereIterationendurchgeführt werden.

AuchhiersollenaberparallelzurIst-AufnahmedieIdentifikationvonKeimzellenundersteKeimzellen-Mig- rationenerfolgen.

13https://www.i-doit.com/blog/obashi-die-verbindung-von-geschaeftsprozessen-und-it/;zuletztaufgerufenam 11.11.2025 14CMDB:ConfigurationManagementDatabase.„GemäßITIL®handeltessichbeieinerCMDBumeineDaten- bankzurVerwaltungvonKonfigurationselementenwährendihresgesamtenLebenszyklus.DieCMDBdientzum Sammeln,Speichern,Managen,Aktualisieren,AnalysierenundzurPräsentationvonDatenallerConfiguration- ItemsundderenBeziehungen.“Aus:ManuelaundGeorgReiss(2019):PraxisbuchIT-Dokumentation.VomBe- triebshandbuchbiszumDokumentationsmanagement–DieDokumentationimGriff.München:Hanser,(3.,ak- tual.Aufl.),S.153.

Version4.1 26

[Seite 27]

IPv6-ProgrammdesBundes

CMDB und IPAM (IP Address Management) sind zentrale Teile der Dokumentation einer IT-Landschaft. Beide Werkzeuge sind sinnvoll, um Konfigurationen undIP-Adressen automatisiert zu verwalten – insbe- sondere für und während einer IPv6-Migration. Eine vollständige Dokumentation der behördlichen IT schafftÜbersichtundistdieBasisfüreineSicherheitsarchitektur.BeiNutzungbzw.derEinführungdieser WerkzeugeisteineautomatisierteErfassungderbestehendenIT-Infrastruktur,inklusivederbisherverwen- detenIP-Adressen,möglich.EsgibtsowohlkommerzielleAngebotealsauchOpen-Source-Tools,diediese Aufgabenübernehmen.DieKombinationvonCMDBundIPAMmiteinemAsset-Managementkannderbe- hördlichen IT wesentliche Vorteile im weiteren Betrieb bringen, insbesondere, wenn die IPv6-Migration aufgrundvonDual-StackundIPv4-Bestandsschutzlängerandauert.

EinweitererwichtigerAspekt,derindiegrobe Ist-Aufnahmeinkludiertwerdenmuss,istdasMonitoring. MonitoringhatverschiedeneZiele.NebenderÜberwachungderVerfügbarkeitvonDienstendientesauch derLangzeitbeobachtungderAuslastungvonRessourcen,wiez.B.NetzwerkbandbreiteoderFestplatten- auslastung.Darüberhinausistes,zusammenmiteinemzentralenSammelnvonProtokoll-(Log)-Informati- onen,einewertvolleQuellezurProblembehebung.IndergrobenIst-Aufnahmesolltefestgestelltwerden, obdasinderBehördeeingesetzte Monitoringsystem IPv6-WertevonGerätenerheben undsowohlIPv6- alsauchIPv4-Werteaggregierenkann.GibteshierEinschränkungen,istdieHerstellungderIPv6-Fähigkeit im Monitoringsystemeine ersteKeimzelle der IPv6-Migration. Zubeachten ist, dassnach der Einführung vonIPv6dasMonitoringsystembeideProtokolle(IPv4undIPv6)überwachenmuss.EinWebserverbspw. kannüberIPv4erreichbarsein,aberüberIPv6nicht.

3.2 Keimzellen-Identifikation

IstdasKeimzellen-VorgehenalsMigrationsstrategiefestgelegt,mussfolgendeFragebeantwortetwerden: VonwelcherAnwendungoderwelchemNetzwerkbereichaussollsichdieKeimzellebilden?

ImFolgendenwerdeneinigeKriterienerläutert,diebeiderAuswahlvonKeimzellenhelfensollen.

• AkuterHandlungsbedarf:EinakuterHandlungsbedarfkannbspw.imFalleinesVPN-Serversbestehen. VPNswerdendazuverwendet,sichereVerbindungenzwischenEndpunkteneinerOrganisationherzu- stellen. Dabei wird jedoch jedem dieser Endpunkte eine IP-Adresse zugewiesen. Sich auf einen IPv4- basierten VPN-Server zu verlassen, wird aufgrund der Begrenzung der verfügbaren IPv4-Adressen zu Verbindungsproblemenführen.Diesvorallem,wenneineOrganisationwächstundneueLiegenschaf- teneröffnet.ProblemesolcherArtkönnendurcheineUmstellungaufIPv6vermiedenwerden. • Einfache Konfigurationsänderungen: Heutzutage unterstützen viele Web- und DNS-Server bereits IPv6.EineUmstellungaufIPv6fürdieWeb-undDNS-Servererfordertdaheroftlediglicheinigeeinfache Konfigurationsänderungen.WenndieseÄnderungenkeinekritischenunddurchFirewallsgeschützten Dienstehosten,dannsindderenzugehörigenKeimzellenauchübersichtlichundgutisoliert.Mitdieser Art Anwendungen anzufangen, vermittelt die Sicherheit, die ersten Umstellungen schnell und

Version4.1 27

[Seite 28]

IPv6-ProgrammdesBundes

erfolgreichvorzunehmen.DadurchentstehtVertraueninnerhalbderBehördeoderOrganisationindas Migrationseinzelprojekt. • Anwendungen als Katalysatoren: Anwendungen, deren Abhängigkeiten sich vertikal über möglichst vieleNetzwerkebenenerstrecken,könntenalsKatalysatorenfürdieIPv6-EinführunginderInfrastruk- turdienen.DavonausgehendKeimzellenzubilden,schafftdasBewusstseinfürdieNotwendigkeitund Dringlichkeit,IPv6indenBackbone-nahenNetzwerkebenenumzusetzen.EshilftaußerdemdenInfra- struktur-Projekten,indemesihneneineOrientierunggibt,wasalsNächsteszutunist.BeiderAuswahl dieserAnwendungenmussallerdingsdieser„Katalysatoren-Effekt“gegendieKomplexitätderAnwen- dungabgewogenwerden.IstdieAnwendungsehrkomplex,würdeeinekomplexeKeimzelleentstehen, diewederschnellnochrisikoarmundauchnichtressourcenschonendumgesetztwerdenkönnte. • NachhaltigerKompetenzaufbauimTechnik-Team:FüreinennachhaltigenKompetenzaufbauisteine ausgewogeneRotationzwischenAnwendungenverschiedenerOrganisationsbereicheratsam.Sokönn- tenalleTeams(zurempfohlenenProjektorganisationsieheKapitel4)sukzessiveIPv6-Erfahrungensam- meln und wären dadurch in der Lage, IPv6-Migrationen nachfolgender Inkremente im Rahmen von WartungsfensternalsLinienaufgabedurchzuführen.

WeitereguteKandidatenfüreineKeimzellekönnensein:

• DasNetzwerkzurAußen-AnbindungumfassthäufigRouterundermöglichtderOrganisationdieKom- munikationmitdemInternet.AlleanderenDiensteundApplikationensindaufdieseVerbindungange- wiesen.DiesesNetzwerkwirdtypischerweiseimDual-Stack-BetriebgenutztundbietetsodurchIPv4 einebekannteundsicherePlattform. • EineDatenbankverbindungimRechenzentrumbietetsichalsKandidatfüreineKeimzellean.DieVer- bindungistisoliert,siewirdnichtvonClientsgenutztundhatkeineVerbindungindasöffentlicheIn- ternet.EineVerbindungdieserArtkannleichtüberwachtwerdenundistübersichtlichklein.

VerantwortungfüreinzelneKeimzellen-MigrationenübernehmenzunächstengagierteTeammitgliederdes Technik-Teams(sieheKapitel4.2),diewertvolleErfahrungensammelnunddieseanweitereTeammitglie- derderSub-Teams(sieheKapitel4.3)weitergeben.Mitdiesem„Keimzellen-Vorgehen“könnenskeptische KolleginnenundKollegeninderOrganisationüberzeugtundabgeholtwerden.

3.2.1 NetzwerkalsStartpunkt

DasNetzwerkbieteteineReihevonStartpunkten,dieals„Migrations-Keimzelle“indiePlanungenaufge- nommenwerdenkönnen.AuchwennIPv6keinreinesNetzwerkprojektdarstellt,istdasNetzwerkeinwich- tigerTeilderUmstellung.Eshatsichbewährt,IPv6imNetzwerkauszurollenundbisandieRoutereinzelner Netzwerksegmenteheranzuführen.EinSzenarioausMigrationsprojektensiehtvor,dassdieRouter,ande- nendieArbeitsplätzeimBüroangeschlossensind,mitIPv6ertüchtigtwerden,aberdieArbeitsplätzenoch keinIPv6bekommen.DasSub-Team(sieheKapitel4.3),dasdieClientsbetreut,kannsovondenErfahrun- genprofitierenunddieClientszueinemspäterenZeitpunktaufIPv6umstellen.DievermeintlicheBegrün- dungeinzelnerTeams,mankönneIPv6nichteinführen,weilesdasNetzwerkjanochnichthergäbe,wird so entkräftet. Die Netzwerkabteilung ihrerseitsmuss nicht auf denWunsch einer Abteilungwarten,jetzt

Version4.1 28

[Seite 29]

IPv6-ProgrammdesBundes

IPv6einführenzuwollenundkanndasProjektzügigvorantreiben.Diesträgtdazubei,dassalleAbteilungen dieNotwendigkeitundDringlichkeiterkennen,sichmitderEinführungvonIPv6zubefassen.

DerVorteildiesesStartpunktesbestehtauchdarin,dassalleMonitoring-undSicherheitseinstellungenvor- genommen werden, die es dann ermöglichen, IPv6 für weitere Inkremente zu aktivieren, wenn dieser Wunsch bspw. aus einer Fachabteilung an die Netzwerkverantwortlichen herangetragen wird. Wenn das NetzwerkalsStartpunktinnerhalbeinesMigrationseinzelprojektesausgesuchtwordenist,mussinnerhalb desNetzwerkesnochmalsentschiedenwerden,wasdieersteKeimzellebildensoll.

Version4.1 29

[Seite 30]

IPv6-ProgrammdesBundes

Bei allen Keimzellen im Netzwerk müssen die Themen Sicherheit und Monitoring berücksichtigt werden. Dafürbietetessichan,dasseineengeZusammenarbeitmitdemQuerschnittsteam(sieheKapitel4.3)im Migrationseinzelprojektstattfindet.

3.2.2 AnwendungenalsStartpunkt

EineAnwendung,odereineKomponenteeinerAnwendung,isteinmöglicherStartpunktderIPv6-Migration unddamiteineguteKeimzelle.Wieobenbereitsbeschrieben,istesauchfürAnwendungenerforderlich, alleKonfigurationselementeundderenIPv6-Fähigkeitzuerfassen.EinguterAnsatzhierfüristdieVerwen- dungdesArchitekturschaubildes,dasalleSchichtenundSchnittstellenderAnwendungabbildet.DiesesAr- chitekturschaubildsolltederDokumentationdergrobenIst-Aufnahmebeigefügtwerden.ÜberdasArchi- tekturschaubildsolltensichalleKonfigurationselementeundderenSchnittstellenidentifizierenlassen.Gibt eskeinsolchesArchitekturschaubild,könnendokumentiereGeschäftsprozessegeprüftwerden.InderRe- gelwerdeneinzelnenAktivitätenindenProzessenundProzesskettenunterstützendeIT-Systeme,alsoAn- wendungen,zugeordnet.WerdeninnerhalbeinesProzessesunterschiedlicheAnwendungendeneinzelnen Aktivitätenzugeordnet,lassensichüberdieseVerkettungmöglicheindirekteAbhängigkeitenvonAnwen- dungenerkennen,diebeiderIdentifikationvonKeimzellenberücksichtigtwerdenmüssen.

Weitere,vorbereitendeSchrittesind:DieerstepraktischePrüfung,obeineAnwendungmitIPv6betrieben werdenkann,erfolgtanderBenutzeroberfläche.WennkeineEingabefelderfürIPv6vorhandensind,istdie Unterstützung von IPv6 wahrscheinlich nicht gegeben. Zu prüfen, ob IPv6 über eine Konfigurationsdatei angeschaltetwerdenkann,istdernächsteSchrittbeiderFeststellungderIPv6-FähigkeiteinerAnwendung. BeiAnwendungen,dienurüberKonfigurationsdateienzusteuernsind,mussdieDokumentationAufschluss über möglicheIPv6-Parameter geben.Die OberflächeeinerApplikationistfürdieBedienungdurchMen- schenkonzipiertworden.EineKommunikationzwischenApplikationenerfolgtüberdieAPIs(API:Applica- tionProgrammingInterface.Programmierschnittstelle15).FürIPv6musseineAPIeineVerbindungüberIPv6 zulassen, autorisieren undauthentifizieren können.Daher ist ineinemweiterenSchritt zu prüfen, ob die APIauchmitderIPv6-Adresse(welcheamServervorabkonfiguriertwurde)ansprechbarist.Esmussauch geprüftwerden,obbeiderApplikationeineIPv6-Adresseeingetragenwerdenkann(soferndieAnwendung IP-Adressenbenötigt).UmineinemletztenVorbereitungsschrittprüfenzukönnen,obdieKommunikation mitderAPIfunktioniert,musseineandereApplikationihrerseitseineVerbindungüberIPv6zurAPIderzu migrierendenApplikationöffnen.DabeidürfenDienstewieDNSundDHCPnichtignoriertwerden.

Nicht selten sindTeile der Architektur mit Unterstützung durch Dritthersteller bzw.externe Dienstleister entstanden.Diesemüssendannmöglicherweisedurchebendieseangepasstoderneukonfiguriertwerden. Externe Dienstleister sollten rechtzeitig über die Planungen im Migrationseinzelprojekt informiert und in dasProjekteinbezogenwerden.

15Definition s. https://csrc.nist.gov/glossary/term/application_programming_interface; zuletzt aufgerufen am 11.11.2025

Version4.1 30

[Seite 31]

IPv6-ProgrammdesBundes

Version4.1 31

[Seite 32]

IPv6-ProgrammdesBundes

EineIPv4-Adresseisteinfachzudokumentieren:4mal8BitwerdenalsFormatstetseingehalten.BeiIPv6 werdenhexadezimaleWerte[0-9a-f]genutzt–keinedezimalenWertewiebeiIPv4.DieempfohleneDar- stellung ist in RFC 595216definiert. Die Buchstaben sollen klein geschrieben werden, aber die praktische Erfahrungzeigt,dasssichnichtjederHerstellerandieseVorgabehält.Allerdingswirdauchnichtzwischen Groß-undKleinschreibungunterschieden,wennesumdieBedeutungderBuchstabengeht(noncasesen- sitive). Die optische Verkürzung der Adressen (führende Null kann wegfallen, Blöcke von Nullen können durch„::“ersetztwerden–z.B.2001:db8:0000:0000:0000:0000:0000:0001darfmanals2001:db8::1op- tischverkürzen),machenesfürApplikationenschwierig,IPv6-AdresseninjedemFallrichtigzuinterpretie- ren.HiersindgründlicheTestsnotwendig,umeventuelleUnzulänglichkeitenderApplikationenzuentde- cken.ApplikationenmüsseneventuellinderLagesein,IPv6-Adressenzuspeichern.WenndieApplikation dievolleAdressemit128Bitspeichert,istzumindestklar,wielangdieAdresseundwievielSpeicherplatz vorzusehenist.BeidenKurzformenistdieFestlegungnichtmöglich.Datenbankensindaufdenbenötigten Speicherverbrauchhinzuuntersuchen,daIPv6-AdressenvielmehrSpeicherplatzbenötigenalsIPv4-Adres- sen.JedeApplikation,die eine IPv6Adresse speichert,mussinder Lage sein, alle IPv6-Adresseninvoller Längezuspeichern.

Wenn IPv6-Adressen inURLsgenutzt werden, z.B.https://[2001:db8:1:1::1234]:808017mussdie Adresse ineckigeKlammern„[]“gefasstwerden.Eswirddringendempfohlen,diesnurzumTestenundzurFehler- suchezunutzenundansonstenDNSzuverwenden.ImDNSmüssenfürServereinIPv4-undeinIPv6-Eintrag vorhanden sein, wenn der Service über beide Protokolle erreicht werden soll. Es bleibt dann dem Client

16https://datatracker.ietf.org/doc/html/rfc5952;zuletztaufgerufenam11.11.2025 17https://datatracker.ietf.org/doc/html/rfc2732;zuletztaufgerufenam11.11.2025

Version4.1 32

[Seite 33]

IPv6-ProgrammdesBundes

überlassen, welche der beiden IP-Adressen genutzt werden soll. Standardmäßig wird von allen gängigen BetriebssystemenIPv6bevorzugt.

HiereinBeispiel:

www.example.com 3600 A 192.0.2.1 www.example.com 3600 AAAA 2001:db8:0:55::1 www.ipv4.example.com 3600 A 192.0.2.1 www.ipv6.example.com 3600 AAAA 2001:db8:0:55::1

IndiesemBeispielistderDienstüberIPv4undIPv6erreichbar.ZusätzlichwurdenIPv4-OnlyundIPv6-Only Namenvergeben,umbeieinerDiagnoseoderfürdasMonitoringeinengezieltenZugriffaufdenDienstmit IPv4oderIPv6zuermöglichen.ObdieseDiagnosenameneingetragenwerdensollen,entscheidetdasAd- ministrationsteam.Wichtigist,dassdieDiagnosezugriffeimSicherheitskonzeptbetrachtetwerden.

Wenn der Client sowohleine IPv6- alsaucheine IPv4-Adresse auf die Anfragezurückbekommt, mussdie AnwendungeineEntscheidungtreffen,mitwelcherAdressedieVerbindungaufgebautwerdensoll.Dabei solltedieAnwendungaufdasBetriebssystemzurückgreifen.DieStandardreihenfolge18ist:

1. IPv6GlobalUnicast
2. IPv4
3. IPv6UniqueLocal.

BrowserbenutzeneinenMechanismusnamens„HappyEyeballs“19,beidemversuchtwird,gleichzeitigeine IPv6-undeineIPv4-Verbindungaufzubauenunddanndiebesserezunutzen.Esistwichtig,indeneinzelnen Migrationsschrittenan„HappyEyeballs“zudenken,weildurchdiesenMechanismusmöglicherweiseFehl- konfigurationenverschleiertwerden.

3.2.3 RouterundSwitchesalsStartpunkt

RouterundSwitchesstellendieBasiskomponenteneinesNetzwerkesdar.Daheristeswichtig,diese Kon- figurationselementefrühzeitigimProjektimRahmen der Ist-AufnahmezubetrachtenundalsKeimzellen frühzeitigzumigrieren.

18 Zu dieser Reihenfolge wird gegenwärtig ein RFC-Draft diskutiert, welcher dieser ändert (https://datatra- cker.ietf.org/doc/draft-ietf-6man-rfc6724-update/; zuletzt aufgerufen am 11.11.2025). Es ist wahrscheinlich, dassIPv6-AdressenjedwederArtIPv4-Adressenvorzuziehenseinwerden. 19DerAlgorithmusistspezifiziertinRFC8305(https://datatracker.ietf.org/doc/html/rfc8305;zuletztaufgerufen am11.11.2025)

Version4.1 33

[Seite 34]

IPv6-ProgrammdesBundes

3.2.4 SicherheitskomponentenalsStartpunkt

Unter dem Begriff „Sicherheitskomponenten“ sind verschiedene Hardware-Komponenten zusammenge- fasst: Paketfilter, Application-Layer-Gateways (ALG), VPN-Krypto-Gateways, Intrusion-Detection-/Preven- tion-Systeme(IDS, IPS)undLoadbalancer.Esgilt, dassdie Funktionen unddie LeistungeinerIPv6-Sicher- heitskomponentemindestensdeneneinerentsprechendenIPv4-Sicherheitskomponenteinderkonkreten Einsatzumgebungentsprechenmüssen.

Füreine„Keimzellen-Migration“eignetsichausderpraktischenErfahrungherausdieIPv6-Migrationeiner zustandsbehaftetenFirewall(statefulFirewall).SolltedieFirewallweitereFunktionenerfüllen(z.B.alsEnd- systemoderRouteraktivsein),somüssenzusätzlichdieMigrationsanforderungenderentsprechendenGe- räteklassenbetrachtetwerden.FirewallssindTransitsysteme,d.h.sieleiteneingehendeDatenpaketewei- ter,wenndiesealsunbedenklichunderlaubteingestuftwordensind.

DieSicherheitsregelnfürKeimzellenkönnennormalerweisenicht1:1vonIPv4über- nommenwerden.IPv6-Regelnwerdenersteingetragen,wenneineApplikationeine Regelbenötigt.DieAnpassungvonallgemeinenRegelnzumSchutzderFirewallund desNetzwerksvonIPv4aufIPv6sindhingegenInhaltder„Keimzellen-Migration“, Tippsfür z.B.RegelnfürExtension-Header,ICMPv6,Bogon-Netzwerke(nichtgerouteteNetz- diePraxis: werke).Hierbeimussbeachtetwerden,dasseinigeICMPv6-TypenfürdenBetrieb zwingenderforderlichsindundnichtgeblocktwerdendürfen21.

20https://datatracker.ietf.org/doc/html/rfc3954;zuletztaufgerufenam10.11.2025 21https://datatracker.ietf.org/doc/html/rfc4890;zuletztaufgerufenam11.11.2025

Version4.1 34

[Seite 35]

IPv6-ProgrammdesBundes

3.3 AgilesVorgehensmodell

DiegrobeIst-AufnahmeistdiePlanungsgrundlagefürdasMigrationseinzelprojekt,inwelcherKeimzellen, derenWiederholungen,sowie„Migrations-Inkremente“ausgewähltwerden.

DiesegrobeIst-Aufnahmemussdetailliertwerden,sodasseinegründlicheAnalysederbestehendenIPv4- IT-Landschaftmöglichist.ImagilenVorgehenerfolgtdieseDetaillierung(ebensowiediefolgendenMigra- tionsschritte)jeweilsfüreinegewählteKeimzelleundeinausgewähltesInkrement.

Version4.1 35

[Seite 36]

IPv6-ProgrammdesBundes

InAnlehnunganSAFewirddasfolgendeagileVorgehensmodellempfohlen:

Abbildung3:AgilesVorgehensmodellfüreinMigrationseinzelprojekt22

Eswurdefolgende„Übersetzung“desSAFeCDPindieWeltderIPv6-Migrationenvorgenommen:

Tabelle3:KorrelationDevOpsnachSAFeundimMigrationsleitfaden

22NachDevOps-PrinzipienundinAnlehnunganSAFe.

Version4.1 36

[Seite 37]

IPv6-ProgrammdesBundes

WichtigfürdasVerständnisdieserStrategieist,sichvorAugenzuführen,dassdieseVorgehensweisekein statischer,einmaligerProzessist,sondernimZeitverlaufmehrfachdurchlaufenwird.Somitkönnendiebe- reits vorhandenen Erfahrungen aus früheren Durchläufen genutzt werden, um kontinuierliche Verbesse- rungenbeidenMigrationenzuerzielen.JenachKeimzelleundInkrementmussdasindiesemKapitelbe- schriebeneVorgehennichtzwingendkomplettdurchlaufenwerden.Beiweiteren/späterenWiederholun- genistmöglicherweisekeineerneutedetaillierteAnalysenotwendig,daessichumweitereInstanzeneiner bereitsvorherdurchlaufenenKeimzellehandeltundsomitaufvorherigeErfahrungenundDokumentatio- nenzurückgegriffenwerdenkann.LediglichderletzteTeildesVorgehens(„Lernen“)istfüralleKeimzellen undderenWiederholungenessenziellundsolltestetigweiterverfolgtwerden.

EsgibtzweiThemen,diebeiderMehrheitderArbeitspaketeeineRollespielen:MonitoringundTesten.

FüreineerfolgreicheMigrationeinesNetzwerksistdasTestenvonHardware,SoftwareundKonfiguratio- nenvonessenziellerBedeutung.NurnachgeeignetenTestskannmithinreichenderSicherheitgewährleis- tetwerden,dasseineMigrationhinzuIPv6erfolgreichistundohneStörungendesWirkbetriebeserfolgen kann.JedeMigrationundjedeUmstellunginderITbergendasRisikoeinesMisserfolges.ZielderTestsist es,dasRisikozuminimierenunddieErfolgsaussichtenzuerhöhen.

Imempfohlenen,agilenVorgehenbeginnenTestsbereitsimArbeitspaket„Planung“,sieheKapitel3.3.1.3, da die Vorbereitung einer IPv6-Migration auch die Prüfung der grundsätzlichen Frage, ob eine Software odereineHardwaremitIPv6betriebenwerdenkann,umfasst.VorgelagerteTests,dieeigenständigdurch- geführtwerdenkönnen,müssenzeigen,obIPv6füreinKonfigurationselementlauffähigist.Flankiertdurch die programmeigenen Testlabore und das Wissensmanagement müssen diese Tests nicht von jeder Be- hörde durchgeführtwerden,wenn Migrationseinzelprojekte ihr Wissen über die getestete IPv6-Fähigkeit von CIsauf der Kommunikations- undInteraktionsplattform verfügbar machen. Die durch dasProgramm bereitgestellteTestlaborkoordinationunterstütztdieBehördenundOrganisationenbeiderDokumentation vonTestsindenprogrammeigenenTestlaboren;dasRedaktionsteamdesWissensmanagementsstehtbe- reit,umTestfälleundTestergebnisseviaInterviewaufzunehmenundzuteilen.AuchdieeingesetztenIPv6- CoachessindbeiderDokumentationvonTestsbehilflich.

Wenn eine Komponente schon im Vorfeldals nicht IPv6-tauglicheingestuft wird,eignet sie sichnicht als migrationsrelevanteKeimzelleundmusszurückgestelltwerden.

Technologien,diefüreineIPv6-Migrationerforderlichsind–unabhängigdavon,obfüreineKeimzelle,de- renWiederholungenoderdieInkremente-müssenvomIT-Teambeherrschtwerden.DafürstelltdasPro- grammBundesrahmenverträgefürSchulungenbereit,diezumeinenüberdasKaufhausdesBundesabge- rufenwerdenkönnen.ZumanderenunterstützendasProgrammmanagementunddieIPv6-Coachesbeider AuswahlgeeigneterSchulungsangebotefürdieBehördenundOrganisationendesBundesausdiesenRah- menverträgen.Wennnotwendig,solltenmindestensdieMitgliederdesTechnik-Teams(sieheKapitel4.2) dieTechnologienzusätzlichindenprogrammeigenenTestlaborenerproben.Dazukannvorallemdasvirtu- elle Testlabor genutzt werden. In diesem können unabhängig von der realen Situation in der Keimzelle, SzenarienmitdenfraglichenTechnologienerstelltundverprobtwerden.Auchdiese„Probe-Szenarien“und

Version4.1 37

[Seite 38]

IPv6-ProgrammdesBundes

TestergebnissesolltenaufderKommunikations-undInteraktionsplattformdokumentiertundgeteiltwer- den,umanderenBehördendie„Migrationsarbeit“zuerleichtern.

Wenn die notwendigen Technologien sicher beherrscht werden, kann die eigentliche Konfigurationsum- stellungvorbereitetwerden(siehedazuKapitel3.3.1.3und3.3.2.1).Istesnichtmöglich,fürdiespezifische KonfigurationsumstellungdieprogrammeigenenTestlaborezunutzen,sollteinderBehördeoderOrgani- sationeinTestlaborodereineTestumgebungaufgebautwerden,diedenNachbauderHardwareoderden Testder Softwareerlaubt.SchonbeidenTestssolltedie Inbetriebnahmesimuliertwerden, umsicherzu- stellen,dasskeineAnpassungenindeneingeübtenProzessenzurInbetriebnahmeerforderlichsind.

Wenn die TestsimTestlabor ergeben, dassdie gewählte Keimzelle zu kleinoder zugroßgewählt wurde, um schnelleine IPv6-Migration durchzuführen,lässt das agile Vorgehen denSchrittzurück in die Ist-Auf- nahme(sieheKapitel3.1und3.3.1.1)und/oderdieKeimzellen-Identifikation(sieheKapitel3.3.1.2)zu.Die Keimzelle soll ineinem Wartungsterminmigriert werden. Wenn dieKeimzelle zu groß ist, kannder War- tungsterminnichtinRuhedurchgeführtwerden.Istsiezuklein,istderWartungsterminnichtausgefülltund eswerdenzuvieleWartungsterminefürdieIPv6-Migrationbenötigt.

FallsnötigkönnenimTestlabormehrereIterationenvonTestsdurchgeführtwerden,wennderersteVer- suchnochnichtdengewünschtenErfolgerzielthat.

In Vorbereitung auf die Inbetriebnahme wird basierend auf den Testergebnissen und den ausgeführten TestpläneneinPlanentwickelt,inwelcherReihenfolgedie umgestelltenKonfigurationeneingeführtwer- den.Erneutwirdgeprüft,obesnochmalsZwischenschrittegibt,diemitTestsabgesichertwerdensollten. DieInbetriebnahmeerfolgtso,wiedieBehördeauchandereUpdateseinspieltoderneueHardwarekom- ponenteneinführt–PlanungderWartungsfenster,Zeiträume,BekanntmachungundInformationsflussun- terscheiden sich nicht von anderen Wartungen. Eine Migration ist - wie jede andere Wartung - erst mit ErstellenderDokumentationabgeschlossen.DieTestdokumentationspieltaufgrunddesagilenVorgehens hiereinewichtigeRolle,dennderErfolgderKeimzellen-Wiederholungenhängtbspw.davonab,dassFehler indenTestsnachvollziehbardokumentiertsind,umdieseinjederWiederholungzuvermeiden.Sokönnen TestpläneleichtaufdieWiederholungangepasstwerden.

DerAblaufeinesTestsfüreinInkrement(sieheKapitel3.3.3.2)istähnlichwiederfürdieKeimzelle.Test- pläne und Pläne für die Inbetriebnahme für Keimzellen können als Grundlage für die Ausarbeitung von TestplänenindenInkrement-Migrationenverwendetwerden.

Mit Bezug auf das Monitoring soll darauf hingewiesen werden, dass dieses in allen Schritten einer IPv6- Migration beachtet werden muss. Dafür sind jedoch die Prüfung und Herstellung der IPv6-Fähigkeit des Monitoringsselbsterforderlich.UmdiesineinemMigrationseinzelprojektnichtzuvergessen,sindinden nachfolgendenKapitelnBezügezumMonitoringaufgeführt.

IT-SicherheitinIPv6-MigrationenmussunterallenUmständengewahrtwerden.ZumeinenbringtIPv6eine ReihevonFunktionalitätenmit,diedieIT-Sicherheitverbessern.ZumanderensindauchneueAngriffssze- narienbekannt.ImDetailwirddasThemaIT-SicherheitundIPv6imKapitel0diskutiert.

In den nachfolgendenKapiteln werden einzelne Aktivitäten in Aktivitätenketten für die Arbeitspakete im „RadderIPv6-Migration“beschrieben.DieseAktivitätenfindensichimPlanungstemplate(imAnhang,siehe Kapitel9.2)wiederundsindmitentsprechendenIDsversehen.Tabelle4beinhaltetdieseIDsimÜberblick:

Version4.1 38

[Seite 39]

IPv6-ProgrammdesBundes

Tabelle4:ÜbersichtüberdieIDsfürAktivitätenimagilenVorgehensmodell

3.3.1 KontinuierlicheIdentifikation

MitdiesemAbschnittim„RadderIPv6-Migration“wirdempfohlen,dassimMigrationseinzelprojektkonti- nuierlichgeplantwird.DamitgehtdasVerständniseinher,dasseinebehördlicheIPv6-MigrationeineTrans- formationderbehördlichenIT-Landschaftdarstellt.DieseTransformationhateinendefiniertenStartpunkt, der in der Bündelplanung des IPv6-Programms dokumentiert ist. Die Umstellung aller Konfigurationsele- mente einer Behörde oderOrganisationdesBundeskannaber über dasgeplanteProjekt-Enddatumhin- ausreichen,weilbspw.nochkeineIPv6-fähigenKonfigurationselementeamMarktverfügbarsind.

AuchwenndiegrobeIst-Aufnahme(sieheKapitel3.1)amBeginneinesMigrationseinzelprojektesstehen soll(ersterSchrittindieMigrationhinein–ÜberblicküberdieIT-Landschaftschaffen),sosolldieseimVer- laufdesMigrationseinzelprojektesregelmäßigüberprüftwerden,daderAusbauoderdieFortentwicklung der behördlichen IT-Landschaft nicht stehenbleiben, lediglich weil ein IPv6-Migrationsprojekt gestartet wird.MitdenerstenErfahrungenwerdensichneueIdeenundRahmenbedingungenfürKeimzellenerge- ben, die migriert werden können. Bereits identifizierte Keimzellen können verworfen werden, wenn es neue Erkenntnissezu Abhängigkeiten gibt, dieEinflussauf deren IPv6-Migrationhaben.Insofernist auch die eigentliche Migrationsplanung nicht als ein starres Konstrukt zu verstehen, das zwingend umgesetzt werdenmuss.VielmehrfolgtdiePlanungauchdemagilenVorgehenundsoll–vergleichbarmitdemkonti- nuierlichenBacklog-RefinementinSAFeundScrum–imVerlaufdesMigrationseinzelprojekteskontinuier- lichüberprüftundangepasstwerden.

3.3.1.1 GrobeIst-Aufnahme

DiegrobeIst-AufnahmeistimKapitel3.1beschrieben.ImAnhang,dortimKapitel9.1,findensichChecklis- ten,umdiegrobeIst-AufnahmezustrukturierenundersteInformationenzuerfassen.

NebendererstenUntersuchungderinderBehördeeingesetztenKonfigurationselemente(Hardware-Spe- zifikationen,Netzwerk,BetriebssystemeundSoftware)sollendieverwendetenIP-AdressenundderenVer- teilung im Netzwerk analysiert werden. Es wird ermittelt, wie die IP-Adressen zugewiesen undverwaltet werden,obeinezentraleIP-AdressverwaltungexistiertundobesEngpässeoderDuplikatebeidenAdressen gibt.ZumBeispielistesdenkbar,dassinkleinerenBehördenkeinIPAM-ToolzurIP-Adressbewirtschaftung verwendetwird.IndiesemFallmüssten,fallsdieNetzenichtanderweitigdokumentiertsind,dieMigration sowiedieAdressbeplanungmanuellnachgepflegtwerden.DieIst-AufnahmekannzufünfErgebnissenfüh- ren:

DieKomponente/dasNetzwerk/dieKeimzelleist

• vollIPv6-fähigoder

Version4.1 39

[Seite 40]

IPv6-ProgrammdesBundes

• Dual-Stack-fähigoder • kannmiteinemSoftwareupgradefürIPv6ertüchtigtwerdenoder • nureinAustauschstelltdieIPv6-Fähigkeitheroder • eine Nutzung mit IPv6 ist ausgeschlossen, eine Ersatzbeschaffung ist erforderlich oder der IPv4-Be- standsschutzwirdentschieden.

DieseInformationensindentscheidendfürdieIdentifikationvonKeimzellen-Kandidaten.

FolgendesVorgehenwirdfürdiegrobeIst-Aufnahmeempfohlen,wenndieseinitialerstelltwird:

Version4.1 40

[Seite 41]

IPv6-ProgrammdesBundes

Version4.1 41

[Seite 42]

IPv6-ProgrammdesBundes

Version4.1 42

[Seite 43]

IPv6-ProgrammdesBundes

Tabelle5:Aktivitätenketteinitiale,grobeIst-Aufnahme

3.3.1.2 Keimzellen-Identifikation

PraktischeTippsundeineEinführungindieKeimzellen-IdentifikationsindimKapitel3.2beschrieben.Die Keimzellen-Identifikation kann erst auf Basis der Ergebnisse der groben Ist-Aufnahme erfolgen, d.h. hier wirdeinsequenziellerDurchlaufdurchdiesenbeidenArbeitspaketeeinesEinzelmigrationsprojektesvorge- schlagen.IndiesemArbeitspaketisteinWorkshopvorgesehen.

Im Rahmen der Keimzellen-Identifikation sollen erstmalig Kontakte zu Herstellernvon Konfigurationsele- menten,dieimRahmenderKeimzellenaufIPv6migriertwerdensollen,aufgenommenoderbestehende Kontaktevertieftwerden.DiepraktischeErfahrungzeigt,dasstrotzStudiumderveröffentlichtenRFCsim- merwiederÜberraschungenbeidenIPv6-MigrationeneinzelnerHard-undSoftwarekomponenteneintre- ten,dieeineAbstimmungmitHerstellernerforderlichmachen.

EserfolgteineBewertungderNetzwerktopologiefüreineKeimzelleodereinInkrement,beiderdiephysi- scheundlogischeStrukturdesNetzwerksanalysiertwird.DiesumfasstdieIdentifizierungderverschiede- nenNetzwerkkomponentenwieRouter,Switches,Firewalls,Sicherheitseinstellungen,Servern,möglichen ApplikationensowiederenVerbindungenundKonfigurationen.

EinweitererwichtigerAspektistdieIdentifizierungdervorhandenenNetzwerkdiensteundderenKonfigu- ration.DiesumfasstDienstewieDNS(DomainNameSystem),DHCP(DynamicHostConfigurationProtocol), NTP(NetworkTimeProtocol)undandere.Eswirdüberprüft,obdieseDiensteordnungsgemäßfunktionie- ren,obesKonflikteoderEngpässegibtundobsieIPv6-fähigsind.

ZusätzlichwerdendieaktuellenEngpässeundHerausforderungendesIPv4-Netzwerksermittelt.Dieskön- nenbeispielsweiseÜberlastungsprobleme,SicherheitslückenoderPerformance-Problemesein.DieIdenti- fizierungdieserEngpässebildetdieGrundlagefürdiePlanungundPriorisierungderUmstellungsmaßnah- menaufIPv6.

FolgendesVorgehenwirdfürdieIdentifikationvonKeimzellenempfohlen:

23https://framework.scaledagile.com/solution-train/, dort Abbildung 6 auf dieser Seite; zuletzt aufgerufen am 11.11.2025 24Hinweis:InSAFewirdderBegriffder„Iteration“anstellevon„Sprint“verwendet.IndiesemMigrationsleitfa- denwirdderBegriffder„Iteration“vermieden,damitdenKeimzellen-MigrationenundWiederholungenstreng genommenkeinZuwachsanrealisiertenFunktionenstattfindet,daessichnichtumeinenSoftwareentwicklungs- prozesshandelt.

Version4.1 43

[Seite 44]

IPv6-ProgrammdesBundes

Version4.1 44

[Seite 45]

IPv6-ProgrammdesBundes

Version4.1 45

[Seite 46]

IPv6-ProgrammdesBundes

Tabelle6:AktivitätenketteinitialeKeimzellen-Identifikation

3.3.1.3 Planung

DiePlanungsollinzweiDimensionenerfolgen:(A)aufEbenedesMigrationseinzelprojektesund(B)fürdie MigrationderKeimzelle(n)zuIPv6.

FürbeideDimensionenisteserforderlich,dienotwendigenRessourceninderBehördeoderOrganisation desBundesbereitzustellen.

Zu(A)PlanungaufEbenedesMigrationseinzelprojekts:ZurSchätzung,wievieleRessourcenfüreinMig- rationseinzelprojektbenötigtwerden,könnendiemitdiesemLeitfadenbereitgestelltenTemplatesfürdie WiBe herangezogen werden. Auch die Rollen für die Projektorganisation, die imKapitel 4 des Leitfadens beschriebensind,bieteneineAnleitungzurSchätzungderRessourcen.DerRessourcenbedarfineinemMig- rationseinzelprojektunterscheidetsichinAbhängigkeitvonderAnzahlanzumigrierendenKonfigurations- elementen und damit von der Komplexität der behördlichen IPv6-Migration. Inkleinen Migrationseinzel- projekten,bspw.inBehörden,diebereitseinBKB-ProjektdurchgeführthabenundnurnochsehrwenigIT selbstbetreiben,reichtggf.einkleinesTechnik-Team,umdiegesamteIPv6-Migrationzuorganisieren.Am anderenEndedesSpektrumsfürRessourcenbedarfestehtz.B.dasBMV,dasfürdiekomplexenIPv6-Mig- rationen der großen Anzahl der Geschäftsbereichsbehörden eine eigene (Groß-)Projektorganisation um- setzt.FürdiePlanungenaufEbenedesMigrationseinzelprojektswirdaufdasPlanungstemplateimAnhang, imKapitel9.2,verwiesen.

DieWeiterbildungdesIT-TeamsfürIPv6nimmtZeitinAnspruch,dieindenPlanun- genberücksichtigtwerdensollte.UnterschiedlicheKursefürIPv6-Schulungensindfür dieBehördenundOrganisationendesBundesimKaufhausdesBundesabrufbar.In Tippsfür Übereinstimmungmitderindividuellen,agilenPlanungeinesMigrationseinzelprojek- diePraxis: teskönnendieSchulungensukzessiveerfolgen.

Version4.1 46

[Seite 47]

IPv6-ProgrammdesBundes

Eine weitere, wichtige Planungsaktivität auf Ebene des Migrationseinzelprojekts ist die Allokation eines IPv6-AdressbereichsbeiderSub-LIRBundunddienachfolgende,grobeBeplanungdeszugewiesenenAd- ressbereichsfürdieeigeneOrganisation.

InternetadressenwerdenineinerweltweitenOrganisationanAntragstellervergeben.FürdenAdressraum, derderdeutschenVerwaltungzugewiesenwurde,istdieRIPENCCzuständig.

Abbildung4:WeltweiteIP-Adressvergabe-Hierarchie

NachZuweisungdes/23erAdressraumfürdiedeutscheVerwaltungwurdedieLIR(LocalInternetRegistry) „de.government“eingerichtet,diedenzugewiesenenIPv6-AdressrauminÜbereinstimmungmitdenRIPE- Statuten verwaltet. Die LIR „de.government“ hat nachfolgende Adressräume an Sub-LIRs vergeben, die dieseinihremAuftragverwalten.

Abbildung5:LIR/Sub-LIRStruktur

DieSub-LIRBundverwaltetdieInternetadressenfürdieBundesverwaltung–außerBMVg,BKA,BPOL,DRV, BAundfürdasGroßvorhabenKonsens.MithinistdieSub-LIRBundjeneStelle,beiderdieBehördenund OrganisationendesBundesbenötigteIPv6-Adressenbeantragenkönnen.

DasIPv6-AdressvergabeschemaBundbildetdieGrundlagefürdieAllokationeinesentsprechendenAdress- bereichs(sieheKapitel5).DieSub-LIRBundverwaltetfürdieBeantragungeinesbehördlichenIPv6-Adress- bereichsentsprechendeFormulare;aufderKommunikations-undInteraktionsplattformfindensichimBe- reich „Adressvergabe“ Ausfüllhilfen für diese Formulare. Der Adressplan für eine Behörde oder

Version4.1 47

[Seite 48]

IPv6-ProgrammdesBundes

OrganisationdesBundesbestimmtdiekonkretenIPv6-Adressen,dieineinemNetzwerkfürdieeinzelnen Konfigurationselementevergebenwerden.Erlegtauchfest,wiedieIPv6-AdresseninjedemNetzwerkseg- mentzugeteiltwerden(manuell,Autokonfiguration,DHCPv6,eineKombination).DieserAdressplansollte auf Basis der grobenIst-Aufnahme (siehe Kapitel 3.1) inder Planungsphase erarbeitet werden.AufBasis derIdentifikationvonKeimzellen(sieheKapitel3.2)kanndieserAdressplanauchfrühzeitigimVerlaufdes MigrationseinzelprojektsvalidiertundbeiBedarffortgeschriebenwerden.

EinbehördlicherIPv6-AdressplanmussindieserPhasedesMigrationseinzelprojekts nichtbiszujedemKonfigurationselement,demeineIPv6-Adressezugewiesenwer- densoll,detailliertwerden.Eshatsichbewährt,nurmaximaldieHälftederzurVerfü- gungstehendenIPv6-AdresseniminitialenEntwurfdesIPv6-Adressplanszuverge- ben.VielmehrergebensichausdemagilenVorgehenvieleErkenntnisse,dieindie AktualisierungenundFortschreibungendesAdressplanseinfließensollten.Änderun- gen,bspw.durchdieEinführungneuerTechnologien,dieEröffnungneuerLiegen- schaftenoderdieVeränderungenindenZuschnittenvonGeschäftsbereichenderMi- nisteriennacheinerWahl,könneneinfachinderFortschreibungdesIPv6-Adressplans Tippsfür berücksichtigtwerden.WennausdemAdressblockzunächstnurjedes4.oder8. diePraxis: Netzwerkvergebenwird,kanneinvollständiggenutztesNetzwerkerweitertwerden, ohnedassdieAggregierungleidet.SolltendieinReservegehaltenenNetzwerkespä- terbenötigtwerden,könnendieLückengefülltwerden.Wichtigist,dassmansogut aggregiertwiemöglich.Wennz.B.dreiGebäudeineinerLiegenschafteinerBehörde stehen,dannbekommtjedesGebäudeeinenBlockanPräfixenzugewiesen.Diese werdennichtübereinzelneNetze(beiBedarf)vergeben,wieesoftbeiIPv4üblich war.

(B)PlanungfürdieMigrationderKeimzelle(n):DadenEmpfehlungendiesesLeitfadensfolgendeineKeim- zellenureinoderwenigeKonfigurationselement(e)umfasst,sindauchdienotwendigenRessourcenbedarfe amBeginneinesauchkomplexerenMigrationseinzelprojektsnichtgroß.InjedemFallmussetwasArbeits- zeiteingeplantwerden,dademTechnik-TeambeidenerstenKeimzellen-MigrationennochdieRoutinefür eine IPv6-Umstellung fehlt. Zeitliche Risikopuffer sollten in den Planungen berücksichtigt werden. Wenn eineKeimzellealsgeeignetfüreineIPv6-Migrationidentifiziertist,kannmitderPlanungder„Keimzellen- Migration“begonnenwerden.DabeisollteneineReihevonFragenbeantwortetwerden,diedieIPv6Kon- figurationbetreffen:

• WirddieKeimzellenachderMigrationmitDual-Stacklaufen? • WirddieKeimzellenachderMigrationalsIPv6-Onlylaufen? • HatdieKeimzellenocheinenIPv4-Only-Zwilling? • WirdmitIPv6einneuesDesignangestrebt? • WieändertsichdieSicherheitsarchitekturmitIPv6?

DieseListeanFragenstellteinenerstenAnhaltspunktdarunderhebtkeinenAnspruchaufVollständigkeit. AufBasisdieserundweitererFragenliegendieGrundlageninformationenvor,umdie„Keimzellen-Migra- tion“anhandderAktivitätenketteausKapitel3.3.2.2durchzuplanen.

Zur Planung der Keimzellen-Migrationen gehört vor allem der erste Test der Konfigurationsumstellung. NuraufderBasisdieserErprobungsschrittekönnendiePlanungenbelastbarumgesetztwerden.

BeiderPlanungsollteimmeralsErstesdieKeimzelledokumentiertwerden.Danach sollteaufderKommunikations-undInteraktionsplattformüberprüftwerden,obes Tippsfür schonInformationenzudieserKeimzellegibt,diewiederverwendetwerdenkönnen. diePraxis: UpdatessolltenimmerimTestlaborgetestetwerden.Auchhiersollteaufder

Version4.1 48

[Seite 49]

IPv6-ProgrammdesBundes

Kommunikations-undInteraktionsplattformgeprüftwerden,obesTestprotokolle vongeeigneten,bereitsdurchgeführtenTestszenariengibt.

FolgendesVorgehenwirdfürdieinitialePlanungderKeimzellen-Migrationen(nichtdesgesamtenMigrati- onseinzelprojekts)empfohlen:

Version4.1 49

[Seite 50]

IPv6-ProgrammdesBundes

Tabelle7:AktivitätenketteinitialePlanung

3.3.2 KontinuierlicheErprobung

NachdergrobenIst-Aufnahmeundder„Keimzellen-Identifikation“sollendieKeimzellennunaufIPv6mig- riertwerden.DafürwerdenweitereVorarbeitenfürdieMigrationabgeschlossen,dievorallemderZuord- nung der Mitarbeitenden zu den anstehenden Aufgaben und der Information von IT-Betrieb und Helpdeskumfassen.DieKeimzellen-MigrationenunddieWiederholungensolltenaufBasisdervorherigen Planung und Vorbereitung gut durchgeführt werden können. Wichtig ist (Stichwort „Überraschungen“),

Version4.1 50

[Seite 51]

IPv6-ProgrammdesBundes

dassVorkehrungen für einenRollback zutreffen sind, sodassbeimAuftreten vonProblemen die vorhan- deneKonfigurationwiedereingespieltwerdenkann.

3.3.2.1 Vorbereitung

EntsprechenddemempfohlenenVorgehensindinderVorbereitungorganisatorischeAktivitätenverankert, diediebisherdurchgeführtenfachlichenundtechnischenAktivitätenkomplettieren.Hieristeswichtig,zu verstehen,dasssichdieGrößedesProjektteamsfürdasMigrationseinzelprojektnachderGrößedervor- handenenIT-Einheit(Team,Gruppe,Referat,Abteilung)richtet.VorallemdieAktivitäteninderVorberei- tung,aberauchdieindenKeimzellen-MigrationenundWiederholungen,könnendurcheinenMitarbeiten- denerledigtwerden.DerVorschlag,hier„Peers“/Tandemszubilden,sollzumeinenderVerbreiterungvon IPv6-ErfahrungswissenineinerBehördeoderOrganisationdienen.ZumanderenkannbeieinergroßenAn- zahlanerforderlichenWiederholungenvonKeimzellen-Migrationenparallelisiertwerden,wennmehrals einMitarbeitendersichmitderKonfigurationsumstellungbeschäftigthat.

Folgendes Vorgehen wird für die initiale Vorbereitung der Keimzellen-Migrationen und Wiederholungen empfohlen:

Version4.1 51

[Seite 52]

IPv6-ProgrammdesBundes

Tabelle8:AktivitätenketteinitialeVorbereitungderKeimzellen-MigrationenundWiederholungen

3.3.2.2 Keimzellen-Migration

VordemHintergrund,dieErfahrungendererstenKeimzellen-Migrationenfürgleichebzw.ähnlicheMigra- tionen weiterzuverwenden (Wiederholungen), ist es wichtig, dass die ersten Keimzellen-Migrationen de- tailliertdokumentiert werden.SokannlangfristigeineZeitersparnisimMigrationsprojekterzieltwerden, daeinmalumgesetzteKeimzellenals„Blaupause“fürweitereMigrationenherangezogenwerdenkönnen. Durch die Zusammenarbeit mit Herstellern werden Überraschungen in den Wiederholungen vermieden unddieIPv6-MigrationderbehördlichenITwirdsukzessivezueinemSelbstläufer.

FolgendesVorgehenwirdfüreineersteKeimzellen-Migrationempfohlen:

Version4.1 52

[Seite 53]

IPv6-ProgrammdesBundes

Version4.1 53

[Seite 54]

IPv6-ProgrammdesBundes

Tabelle9:AktivitätenketteersteKeimzellen-Migrationen

3.3.2.3 Keimzellen-Wiederholung

ImVorgehenunddennachfolgendbeschriebenenAktivitätenunterscheidensichKeimzellen-Migrationund Wiederholungennichtsubstanziellvoneinander–wasfolgerichtigist,daessichumdiegleichenKonfigura- tionsumstellungen handelt. Allerdings sollte die Ergänzung oder Anreicherung der Dokumentation nicht vergessenwerden,sodasskeineneuenDokumentationslückenentstehen.

DasStichwort„Überraschungen“sollteandieserStellenochmalsangeführtwerden.Wiederholungenkön- nen trotz der Übung und der bekannten, getesteten Konfigurationsumstellung auch in Probleme laufen, sodassRollback-RoutinenauchbeiWiederholungenvonKeimzellen-Migrationennichtvernachlässigtwer- densollten.

BeieinerKeimzellen-Wiederholungmussdaraufgeachtetwerden,dassdie„Ur“- KeimzellemitdenneuenKeimzellenweitestgehendidentischist.GibteszuvieleAb- weichungen,handeltessichumeineneue,weitereKeimzelle.ZumBeispielkannein Switch,wenndiesereineandereSoftwareversionbenutzt,inderIPv6-Migrationab- weichendreagieren.SollteeinabweichendesVerhaltenfestgestelltwerden,istein Tippsfür sofortigesRollbacknotwendigundeineFehleranalyseauchmitUnterstützungdes diePraxis: Testlaborsdurchzuführen.AufBasisderDokumentationder„Ur“-Keimzellesolltevor einerWiederholungimerstenSchrittgeprüftwerden,obessichumeine„identische“ KeimzellefürdieWiederholunghandelt,oderdocheherumeineweitere.

Version4.1 54

[Seite 55]

IPv6-ProgrammdesBundes

FolgendesVorgehenwirdfürdieWiederholungendererstenKeimzellen-Migrationenempfohlen:

Tabelle10:AktivitätenketteWiederholungdererstenKeimzellen-Migrationen

3.3.3 KontinuierlicheUmsetzung

Auf der Basis der Erfahrungen, die mit den Keimzellen-Migrationen undderen Wiederholungen gemacht wurden,kannsichdasbehördlicheProjektteamnunankomplexereIPv6-Migrationenwagen.Dafürsollten nun durch Schnittstellen miteinander verbundene Konfigurationselemente identifiziert, hinsichtlich ihrer IPv6-Fähigkeitanalysiertundausgewähltwerden.

DieumfangreichenDokumentenprüfungenunddieStrukturierungderIT,bspw.nachOBASHI,imArbeits- paket „grobe Ist-Aufnahme“ sollen nicht nur für die Keimzellen, sondern stets für die Gesamtarchitektur einerBehördeoderOrganisationerfolgen.

BeiderkontinuierlichenUmsetzungkanneszuunerwartetemVerhaltenkommen, dasinderKeimzellen-Migrationnichtaufgetretenist.Werdenz.B.mehrereSwitches

Version4.1 55

[Seite 56]

IPv6-ProgrammdesBundes

Tippsfür hintereinanderbetrieben,kannbeieinernichtausreichendgenauenKonfiguration diePraxis: aufdemeinzelnenGerätDatenverkehrstattfinden,dernichtgewolltist,wiez.B. MulticastDatenverkehr.DaskanndurchDefault-Einstellungenpassieren,dieinder normalenAnsichtderKonfigurationsdateinichtangezeigtwerden.Darumisteswich- tig,dasVerhaltenzudokumentierenundaufderKommunikations-undInteraktions- plattformnachvergleichbarenSituationenzurecherchieren.Änderungenanden Default-EinstellungensolltenstetsinAbsprachemitdemHerstellererfolgenundvor Migrationengetestetwerden.

Auch die Aktivitäten „Keimzellen-Identifikation“ und „Planung“ beinhalten Projektergebnisse, die für die PlanungundDurchführungvonInkrement-Migrationensinnvollunderforderlichsind.EineKeimzellen-Mig- rationkannergeben,dasssichdasTeambeiderAuswahlgeirrthat–mithinmussdieIPv4-/IPv6-Umstellung des bisher als Keimzelle identifizierten Konfigurationselements in einem Inkrement erfolgen. Alle bisher gemachtenErfahrungenstützendieseInkrement-Migrationab.

Die Erkenntnisse undErfahrungen, die indenKeimzellen-Migrationen gewonnenwerden, haben Einfluss auf inhaltlich-fachliche Entscheidungen der Inkrement-Migrationen. Auch die Zusammenarbeit mit den HerstellernkannzudiesemZeitpunktnochmalsgefestigtwerden.DerBedarfzurNutzungvonTestlaborka- pazitäten wird beidenInkrement-Migrationen ansteigen. Ggf. reicht dasAngebot der programmeigenen Testlaborenichtaus.SpätestenszudiesemZeitpunktisteinZugangzurKommunikations-undInteraktions- plattform des IPv6-Programms sinnvoll, denn es ist insbesondere bei späteren Bündeln möglich, dass es Informationen füreine vergleichbare Migrationskonstellationoder vergleichbare Anwendungs- undTest- fälleimIPv6-WikioderinanderenBereichenderKommunikations-undInteraktionsplattformgibt.

3.3.3.1 KonfigurationInkremente

ZumStartdiesesArbeitspaketswirdein„Lessons-Learned“-Workshopüberdievorangegangenenoderauch parallel noch stattfindenden Keimzellen-Migrationen und deren Wiederholungen empfohlen. Die Durch- führung des Workshops vermeidet die Wiederholung bekannter Fehler. Erfahrungen können geteilt und MotivationfürdieanstehendenMigrationsaufgabenkanngewonnenwerden.

ImZentrumdesArbeitspakets„KonfigurationInkremente“stehenzweiwesentlicheAufgaben:

(A)ErfassungundAnalysederIst-Situationund

(B)PlanungdesMigrationsvorgehens.

Zu(A):Inderdetaillierten Ist-Analyse solldieIPv6-FähigkeitjedesCIs, dasineinInkrementeingebunden wird,festgestelltunddurchTestsanalysiertwerden.JetztstehenauchschwierigeEntscheidungenzuggf. erforderlichen Ersatzbeschaffungen an,die unter Umständen auchdie EinbeziehungdesProjektsponsors (sieheKapitel4.1)erforderlichmachen,dafüreineErsatzbeschaffungHaushaltsmittelunddieUnterstüt- zungderVergabe-undVertragsexpertenderBehördebenötigtwerden.

Die Migrationseinzelprojekte sollten nicht dazu genutzt werden, die behördliche IT komplett auszutau- schen,umeinemodernereTechnologieausstattungzuerreichen.NichtsdestotrotzzeigtdiepraktischeEr- fahrung,dassindenBehördenundOrganisationendesBundesdurchausveralteteITimEinsatzseinkann. VeralteteITbringtinderRegelkeineIPv4-/IPv6-Dual-Stack-oderIPv6-Only-Fähigkeitenmit.DieArchitek- turrichtliniedesBundes(sieheKapitel2.3)kenntfürdiesesSzenariodenIPv4-Bestandsschutz.InInkrement- MigrationensindKonfigurationselementedurchSchnittstellenmiteinanderverbunden.VondiesenSchnitt- stellenhängtdieEntscheidungab,obeinCIindenIPv4-Bestandsschutzgenommenwerdenkann,oderob eineErsatzbeschaffungerforderlichist.VondieserEntscheidungfüreineErsatzbeschaffunghängtderMig- rationszeitplanab:SindErsatzbeschaffungenfürCIsineinemInkrementerforderlich,solltendieZeiträume

Version4.1 56

[Seite 57]

IPv6-ProgrammdesBundes

fürdieBeschaffungimMigrationsplanberücksichtigtwerdenunddasInkrementsolltezueinemspäteren Zeitpunktmigriertwerden.Auchkanngeprüftwerden,dasseineErsatzbeschaffungsichbereitsinderPla- nung befindet undentsprechende Haushaltsmittel dafür beantragt sind. Dannkanndieser geplante Zeit- raumindieMigrationsplanungaufgenommenundberücksichtigtwerden.DerVorteildiesesagilenVorge- hensmodellsbestehtdarin,dassnichtdasgesamteMigrationseinzelprojektgestopptwerdenmuss,wenn das Team die Erforderlichkeit einer oder mehrerer Ersatzbeschaffungen identifiziert hat, sondern Inkre- mente,indenenkeineErsatzbeschaffungenerforderlichsind,könnenzuerstmigriertwerden.

Nachfolgend sind einige praktische „Tipps und Tricks“ für (A) die Erfassung und Analyse der Ist-Situation und (B) die Planung der Migration für wesentliche technische Konfigurationselemente beschrieben. Es lohnt, für weitere Informationen das IPv6-Wiki auf der Kommunikations- und Interaktionsplattform des ProgrammsnachErläuterungenundInformationenzudurchsuchen.

Domain-Name-System-Server(DNS-Server):DasDomain-Name-System(DNS)istes- senziellerBestandteileinerjedenNetzwerk-Infrastruktur.Eswirddeswegenauch dringendempfohlen,DNSzunutzenundmindestenszweiautoritativeDNS-Serverzu verwenden.DNSdientzumeinenderAuflösungvonNamenzuAdressen,alsoz.B. vonwww.example.comzu93.184.216.34und2606:2800:220:1:248:1893:25c8:1946. ZumanderendientdasDNSzurAuflösungvonAdressenzuNamen(reverseDNS)also beispielsweisevon77.87.224.131zumx1.bund.de.EinträgeimDNSwerdenalsRe- cordsbezeichnet,diesekönnenverschiedenenTypenhaben.FürIPv4-Adressenwird derTypAverwendet,fürIPv6derTypAAAA.Darüberhinausgibtesnochzahlreiche weitereTypen.EsmüssenzweiArtenvonServernunterschiedenwerden:Authorita- tive-Server,welchedieDatenfüreinebestimmteDomainsverwaltenundResolver, welcheKlientendieAuflösungvonNamenermöglichenundErgebnisseauchzwi- schenspeichern(cachen).

BeiderZusammenfassungallerRecordsfüreineDomainsprichtmanimAllgemeinen voneinerZone.Dabeiistesegal,obdarunterIPv4oderIPv6alsTransportprotokoll Tippsfür verwendetwird.EinAuthoritativeDNSServerkannimmeralleRecordsausgeben,die diePraxis: derServerkennt,alsoaucheineIPv6-undIPv4-Adresse. AlleaktuellenDNS-Server-Implementierungen,egalobAuthoritativeoderResolver, solltensowohlAAAA-RecordsalsauchdenTransportperIPv6unterstützen.

ImHinblickaufdieEinführungvonDNSSECisteszwingenderforderlich,dieFunktio- nenAuthoritativeDNS-ServerundDNS-Resolvervoneinanderzutrennenundaufse- paratenServernzubetreiben.AndernfallskanneszuProblemenmitDNSSECkom- men.DiesistbeiderKonfigurationvonDNSzuberücksichtigen,wenndiesesalsIn- krementmigriertwerdensoll.25

BeiderVerwendungglobalgültigerIPv6-AdressenisteineTrennungzwischeninter- nenundexternenAdressenwichtig.Eswird–geradeimHinblickaufdieEinführung vonDNSSEC–dringenddavonabgeraten,dazuDNS-Views(oderauchSplit-DNSge- nannt)zuverwenden.DiepraktischenErfahrungenzeigen,dassDNS-ViewsdenAuf- wandfürdasTroubleshootingerhöhenunddieEinführungvonDNSSECerschweren. DieIPv6-Einführungisthierggf.eineguteChance,vorhandeneSetupszuersetzen.

25Siehe auch https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Ein- zel_PDFs_2023/06_APP_Anwendungen/APP_3_6_DNS_Server_Edition_2023.pdf; zuletzt aufgerufen am 11.11.2025.ImBSI-IT-GrundschutzfindetsichderBegriff„AdvertisingDNS-Server“anstellevon„Authoritative DNS-Server“.

Version4.1 57

[Seite 58]

IPv6-ProgrammdesBundes

DieallgemeineEmpfehlungistes,eigene(Sub-)Domainsfürinternundexternzuver- wenden.

DHCPv6:BevormitderMigrationbegonnenwerdenkann,musseinIPv6-Adresskon- zeptresp.-Adressplanvorliegen,indemdieAdress-PoolsfürIPv6festgelegtsind,aus denendieClientsversorgtwerden.DasAdresskonzeptlegtauchdiePoolgrößenfest. WenneingemeinsamerServer(HardwareundSoftware)fürDHCPv4undDHCPv6ge- nutztwird,mussderServermitDual-Stackkonfiguriertsein.BeiDHCPwirdderSer- verentwederüberIPv4oderIPv6angesprochenundbedientauchnurAnfragenin demProtokollausdenzugehörigenPools.DasunterscheidetDHCP-ServervonDNS- Servern.GegebenenfallsmussneueDHCPv6-SoftwareaufServern,Firewalls,Netz- werkgerätenetc.installiertwerden,bevormitderKonfigurationbegonnenwerden kann.DieIPv6-AdressenkönnenausdemPoolzufälligodermiteinerReservierung vergebenwerden.ImFallederReservierungistdieDUID(KennungdesIPv6-Clients) imDHCPv6-Serverzuhinterlegen.EsgibtvierverschiedeneDUID-Typen.Esistzuklä- ren,welchenTypeinClientnutzt.DiealleinigeVerwendungderMAC-Adresseals DUIDisttechnischmöglich,aberbeiIPv6unüblich.DieSteuerung,obeinHost DHCPv6nutztodernicht,wirdüberFlagsimRouter-Advertisementaufdementspre- chendenLayer-3-Gerät(Switch,Router,Firewall)gesteuert.ImGegensatzzuDHCPv4 übermitteltDHCPv6keinDefault-GatewayundauchkeinesonstigenRoutingInforma- tionen.DasDefault-GatewayerhältderHostperRouter-Advertisement.

Esistaußerdemzubeachten,dassAndroidkeinDHCPv6unterstützt.DNS-Resolver unddieSearch-DomainkönnenauchüberRouter-Advertisementsbereitgestelltwer- den.DieswirdvonallenaktuellenBetriebssystemenunterstütztundfüreinfache NetzeistkeinDHCPv6notwendig. Tippsfür diePraxis: StatefulDHCPv6:DHCPv6kanninzweiVarianteneingesetztwerden–zurAdressver- gabeundumzusätzlicheInformationenwiez.B.DNS-,NTP-oderProxy-Serverzu übermitteln.WirdDHCPv6zurAdressvergabeverwendet,sosprichtmanvonStateful DHCPv6,weilderServerhierbeispeichernmuss,welcheAdressenschonanwelchen Clientvergebensind.

StatelessDHCPv6:BeiStatelessDHCPv6wirdkeineIPv6-AdresseandenClientgesen- det.SomitmusskeineTabelleüberdievergebenenIPv6-Adressengeführtwerden undesentstehtkein„State“.DerDHCPv6-ServerliefertnurInformationenwieDNS- Server,NTP-Serveroderähnlicheaus.DaeinStateless-DHCPv6-Servernurwenige Ressourcenbenötigt,könntedieFunktionauchvonLayer-3-SwitchesoderRoutern imNetzwerkbereitgestelltwerden.IndenmeistenNetzenwirdStatelessDHCPv6 undAutokonfigurationverwendet.

DHCPv6Relay:WennderDHCPv6-ServernichtimlokalenNetzwerksteht,kannein Router(Layer-3-Switch,Firewall)alsRelaydieAnfrageaufnehmenundandeneigent- lichenServerweiterleiten.Esistzuprüfen,obdasangedachteRelayalleimNetzwerk genutztenDUIDderClientsunterstützt.

DHCPPrefixDelegation(DHCP-PD).MittelsDHCP-PDlassensicheinemanderenRou- terganzePräfixezuweisen.Dieswirdz.B.beivielenProvidernfürEndkundenge- nutzt,umIPv6-Präfixezuverteilen.InderRegelwirdhierein/56-IPv6-Adressraum vergeben.BeidiesenAnschlüssenhandeltessichinderRegelumAnschlüssefür

Version4.1 58

[Seite 59]

IPv6-ProgrammdesBundes

privateKunden.RFC9663bietetInformationenzumEinsatzvonDHCP-PDfürEndge- rätez.B.imBehörden-Netzwerk26.

DerActive-Directory-ServervonMicrosoftistderzentraleVerwaltungspunktinei- nemMicrosoft-Netzwerk.AlleClientsmüssenaufdenAD-Serverzugreifenkönnen. WährendderUmstellungaufIPv6mussderAD-ServersolangeIPv4undIPv6parallel Tippsfür unterstützen,bisderletzteIPv4-ClientdenServicenichtmehrbenötigt.DieAnmel- diePraxis: dunganADüberIPv6istheutemöglichundinderPraxiserprobt.

EinegenauelokaleUhrzeitaufdenSystemeneinerIT-Infrastrukturistwichtigfürdas korrekteFunktionierenvielerzentralerDiensteineinerBehördeoderOrganisation, wiez.B.Dateiserver,IP-RouterundSicherheitssysteme.Eswirddaherempfohlen,ei- nenlokalenZeitserverimIntranetoderRechenzentrumzubetreiben.DieserServer stelltüberNTP(NetworkTimeProtocol)Zeit-undDatumsinformationfürKlienten, ServerundAnwendungenbereit.ImZugeeinerMigrationaufIPv4-/IPv6-Dual-Stack Tippsfür mussgewährleistetwerden,dassderNTP-ServerauchüberIPv6erreichbarist.Hier- diePraxis: fürmüssendasIP-SubnetzdesNTP-Servers,derNTP-Server-HostselbstunddieSer- ver-SoftwareIPv6-tauglichseinundIPv6aktiviertwerden.Fernersindvorhandene Firewall-RegelnfürNTPzuüberprüfenund,fallsnötig,äquivalenteFirewall-Regelnfür NTP/IPv6zuerstellen.

Auf Grund des anhaltenden Trends, immer mehr technische Systeme mit IP-basierten Kommunikations- Schnittstellenauszustatten,findenvermehrtGeräteAnschlussandasIntranet/LAN,diefrüherandere,de- dizierteKommunikationswegegenutzthaben.ImZugeeinesMigrationseinzelprojektsistauchfürdieseGe- rätedieFunktionstauglichkeitzutestenundweiterhinzugewährleisten.BeispielefürsolcheSystemesind u.a.Sensor-SystemeoderHaus-undAlarmtechnik.

Nicht immer ist bei diesen Systemen ein Hersteller-Upgrade möglich, sodass ggf. sogar einige IPv4-Netz- werkenochaufsehrlangeSichtweiterbestehenmüssenundunterdenIPv4-Bestandsschutzfallen:

• LokalerundRechenzentrumsbetrieb • KonfigurationsmanagementundDeployment.

ZudenKonfigurationsmanagement-DienstengehörennebendenAnwendungen namhafterHerstellerauchdieverschiedenstenKonfigurations-Skripte,diesichim VerlaufderJahreangesammelthaben.DieseeigenerstelltenTool-Setssindoftmals nichtineinerCMDBoderanderenVerfahrenerfasstundkönnensomitleichtbeider Erfassungübersehenwerden.Diesliegtzudemauchdaran,davieleKonfigurations- Tippsfür SkriptemeistinautomatisiertenWorkflowsverwendetwerden.AufGrunddessenist diePraxis: eswichtig,beiderAnalysederIst-SituationdenBereichderIT-Administrationeben- fallsgenauzuerfassen,umauchnachderMigrationkeineStörungendurchveraltete Konfigurationseinstellungenoder-Scriptszuverursachen.

FolgendesVorgehenwirdfürdieinitialenKonfigurationenvonInkrementenempfohlen:

26https://datatracker.ietf.org/doc/rfc9663/;zuletztaufgerufenam11.11.2025

Version4.1 59

[Seite 60]

IPv6-ProgrammdesBundes

Version4.1 60

[Seite 61]

IPv6-ProgrammdesBundes

Version4.1 61

[Seite 62]

IPv6-ProgrammdesBundes

Version4.1 62

[Seite 63]

IPv6-ProgrammdesBundes

Version4.1 63

[Seite 64]

IPv6-ProgrammdesBundes

Tabelle11:AktivitätenketteinitialeKonfigurationenvonInkrementen

Version4.1 64

[Seite 65]

IPv6-ProgrammdesBundes

3.3.3.2 Tests

Inkrement-Migrationen sind komplexere Migrationsszenarien als die Keimzellen-Migrationen und deren Wiederholungen.DementsprechendsindauchdieAnwendungsfällefürTestsunddiesichdarausergeben- denTestfälle sehrvielumfangreicher undvonunterschiedlicherNatur.Vor allembeigrößerenBehörden würde der Aufbau eigener Testlabore erforderlich, in denen die produktiven Umgebungen nachgebildet werdenkönnen.InsofernistdieNutzungderprogrammeigenenTestlaboresinnvoll(sieheKapitel6).Nach- folgendsindeinigeAnwendungsfällefürTestsbeschrieben,diefürInkrement-Migrationenrelevantsind.

TestsvonNetzwerktechnologien:InTestlaborenkönnenNetzwerktechnologienineinerisoliertenUmge- bunggetestetwerden,wasv.a.demAufbauvonWissenundErfahrungendient.DafürstehenindenTest- laborenunterschiedlicheStandardnetztopologienund-technologienbereit,mitdenenNutzendedieMög- lichkeithaben,erstepraktischeErfahrungenzusammeln,ohneeinechtesNetzwerkzubeeinflussen.Zudem werden im programmeigenen IPv6-Testlabor der BDBOS Konnektivitäts-Tests angeboten, sodass die Ver- bindungenzudenNetzendesBundes(NdB)getestetwerdenkönnen.AuchdasvirtuelleTestlabordesIPv6- ProgrammsbietetdurchdieBereitstellungvonNetzwerkemulationssoftwareaufEVE-NGvielfältigeMög- lichkeiten,virtualisierteNetzwerktopologienzuerstellen,indenenverschiedeneKonfigurationenundSze- nariengetestetwerdenkönnen.

HinweisezumEintragenvonDNS-Records:Esistwichtig,dassderEintraginsDNS derletzteSchrittbeiderUmstellungeinerKomponentebzw.einesDienstesaufIPv6 oderDual-Stackist.AllemodernenBetriebssystemebevorzugenIPv6.HateinClient alsoIPv6undisteinAAAA-RecordfüreinenDienstimDNSeingetragen,sowirdder Clientversuchen,dieVerbindungperIPv6aufzubauen.IstderDienstnichtkorrekt konfiguriert,wirddiesineinemTimeoutresultieren.DassollteineinemTestfaller- probtwerden.Gleichesgilt,wennzwarderDienstkorrektkonfiguriertist,aberder Tippsfür Clientbzw.dasNetzzwischenClientundDienstnichtkorrektkonfiguriertsind.Auch diePraxis: hierfürsollteeinentsprechenderTestfallvorgesehenwerden.

BeiderSpezifikationderTestfällesolltebeachtetwerden,dassHappy-Eyeballsdazu entwickeltwurde,ProblemevordemBenutzerzuverbergen.FürTestsvonHTTP(S) solltenstetsWerkzeuge,wiez.B.curl,verwendetwerden,beidenensichsteuern lässt,obIPv6oderIPv4eingesetztwird.

TestenvonBGP:IndiesemTestfallsolldieKonfigurationvonBGP4imZusammen- hangmitIPv6geprüftwerden.HierzuwerdenexterneRoutermitzweiverschiedenen AS-Nummern(ASN)benötigt.DerRoutermitderASN65537liefertnureineDefault- Route,derRoutermitderASN94497lieferteinBGP-Full-TablemitBogons.VomAd- ministratorsolleinRoutergemäßNetzwerkplankonfiguriertwerden.

Szenario1:DerRouterwirdentsprechendNetzwerkplankonfiguriertundsollvom Tippsfür RoutermitderASN65537eineDefaultRouteperBGPerhalten.Dasgewünschte diePraxis: Testergebnisist:derRoutererhälteineDefaultRoute.

Szenario2:DerRouterwirdentsprechendNetzwerkplankonfiguriertundsollvom RoutermitderAS65538eineumfangreichereRoutingtabelleperBGPerhalten.Das gewünschteTestergebnisist:derRouterbekommteineRouting-TabelleinklusiveBo- gons.

Version4.1 65

[Seite 66]

IPv6-ProgrammdesBundes

Szenario3:ZusätzlichzuSzenario2wirdeineFilterlistegemäßIPv6-Wikikonfiguriert, umBogonszufiltern.DasgewünschteTestergebnisist:derRouterbekommteine Routing-TabelleohneBogonsgesendet.

TestenvonSoftware:SoftwarekannauchimRahmeneinerkomplexerenKeimzellegetestetwerden.Inder RegelistSoftwareaberdurchSchnittstellenindiebehördlicheGesamtarchitektureingebettetoderbedient überbehördlicheSchnittstellen.IndiesemFallwürdeeineUmstellungderSoftwareimRahmeneinerInkre- ment-Migration erfolgen. In den Testlaboren sollen Applikationen auf IPv6-Tauglichkeit geprüft werden, bevor eine Umstellung erfolgt. In der Regel erfordert die IPv6-Migration von Softwarekomponenten das EinspielenvonUpdates,dievondenHerstellernderSoftwarebereitgestelltwerden.EineerstePrüfung,ob dieUpdatesdieUmstellungaufIPv6umsetzen,erfolgtbereitsindenAktivitätenzurKonfigurationderIn- kremente(siehedasvorherigeKapitel3.3.3.1).IndiesemArbeitspaketwerdenumfangreichereTestszena- rienfürSoftwareumgesetzt,zudenenLast-undPenetrationstestsgehören.IndenTestkonzeptenfürdie programmeigenenLabore,dieaufderKommunikations-undInteraktionsplattformdesProgrammsbereit- gestelltwerden,sindAnwendungsfälleskizziert.AllerdingskanndieVielfaltderSoftwarelösungen(v.a.die FachanwendungenalsIndividualsoftware),dieindenBehördeneingesetztwerden,nichtindenprogramm- eigenenTestlaborenabgebildetwerden.InÜbereinstimmungmitdenbisherabgestimmtenAnwendungs- fällenwirdvorallemStandardsoftware,inkl.OpenSource,indenprogrammeigenenTestlaborengetestet, wieu.a.:

TestenderAdresskonfigurationaufWindows:IndiesemTestfallsollenverschiedene AdresskonfigurationsmechanismenunterWindowssowiediepassendeKonfiguration einesCiscoLayer-3-Switcheserprobtwerden.ClientundServersollensichhierbeiin unterschiedlichenNetzenbefinden.EsstehenfolgendeCIszurVerfügung:Windows ServerfürDHCPv6,CiscoLayer-3-SwitchundWindowsClient.Darüberhinauskannes sinnvollsein,einenMonitoring-PortaufdemSwitchzukonfigurierenunddenTraffic perWiresharkmitzuschneiden.

Szenario1:DerSwitchwirdgemäßNetzwerkplankonfiguriert,zusätzlichwirdnoch einRouter-AdvertisementmitDNS-ResolverundSearchDomaineingerichtet.Daser- warteteTestergebnisist:derClientkonfiguriertausdemPräfixeineAdresseundfügt diekonfiguriertenOptionenseinerKonfigurationhinzu. Tippsfür diePraxis: Szenario2:DerWindows-ServerwirdalsDHCPv6undDNS-ResolvergemäßNetzwerk- plankonfiguriert.PerDHCPv6wirdeinandererDNS-ResolververgebenalsperRouter Advertisement.BeimSwitchwird,zusätzlichzurvorhandenenKonfiguration,noch das„other-config“-Flaggesetzt.AufdemSwitchwirdeinDHCPv6-Relaykonfiguriert. DaserwarteteTestergebnisist:derClientbekommtperDHCPv6dieentsprechenden OptionenzugewiesenundderDHCPv6-ServerloggtdieAnfrage.

Szenario3:BeimSwitchwird,zusätzlichzurvorhandenenKonfigurationausSzenario 2,nochdas„managed-config“-Flaggesetzt.DaserwarteteTestergebnisist:derClient bekommtperDHCPv6dieentsprechendenOptionenundeineAdressezugewiesen undderDHCPv6-ServerloggtdieAnfrage.

TestenderUmstellungvonMediaWiki(MW)aufIPv6:FürdiesenTestfallwerdenein ClientmitWebbrowserundmin.curlsowiezweiVMsmitDebianGNU/Linuxinder Tippsfür aktuellenVersion,einWebserver(ApachealsWebserver,Dual-Stack)sowieeinDa- diePraxis: tenbankserver(MariaDB,IPv6-Only)benötigt.

Version4.1 66

[Seite 67]

IPv6-ProgrammdesBundes

DarüberhinaussindeinTLS-ZertifikatsowieDNS-Einträgeerforderlich.DerEinfach- heithalbersollte,wennmöglich,Let’sEncryptfürdasZertifikatverwendetwerden.

ImTestaufbauwerdenbeideVMsgemäßdemNetzwerkplaneingerichtet.DerWebs- ervererhälthierbeisowohleineIPv4-alsaucheineIPv6-Adresse.BeideServerwer- densokonfiguriert,dasssiekeineAdress-Autokonfigurationumsetzen.

ImDetailsindfolgendeSchrittefürdenTestaufbaudurchgeführt:

AufdemDatenbank-ServerwirdMariaDBinstalliertundeineDatenbankgemäßder AnleitungvonMediaWikiinstalliert.

Aufdemhttp-ServerwerdenApacheundPHPgemäßderAnleitungvonMediaWiki installiertundkonfiguriert.DasZertifikatwirdinstalliertundderWebserverentspre- chendkonfiguriert,siehe:https://ssl-config.mozilla.org.

MediaWikiwirdgemäßderAnleitunginstalliert.

DerTestfallfürMediaWikiumfasstdiefolgendenTestschritte:

1. KönnenWeb-undDatenbankserversichgegenseitigpingen?

2. KannderWebserveraufdenMariaDB-Serverzugreifen?

3. KannvomClientaufdenWebserverperIPv6zugegriffenwerden (Testenmitcurl)?

4. KannvomClientaufdenWebserverperIPv4zugegriffenwerden (Testenmitcurl)?

5. FunktioniertdasMediaWikiimBrowser?

6. WerdenIPv4-undIPv6-Verbindungengeloggt?

7. KannderWebserverUpdatesdurchführen(aptupdate)?

8. KannderDatenbankserverUpdatesdurchführen(aptupdate)?

Hinweis:NichtalleDebian-MirrorsunterstützenIPv6.Essolltedeb.debian.orgalsex- ternerMirroreingesetztwerden.

DieerwartetenErgebnisseumfassen:

• DieIPv6-Only-KommunikationzumDatenbank-Serverfunktioniert.

• DerWebserveristperIPv4undIPv6erreichbar.

• DieMediaWikiInstallationfunktioniert.

• DasLoggingdesWebserversfunktioniert.

• DieServerkönnenUpdatesdurchführen.

Hersteller von Netzwerkhardware und -software bieten oftmals eigene IPv6-Testlabore an, um ihre Pro- dukte potenziellenKundenvorzuführen undderen Funktionenzu demonstrieren. Im IPv6-Programmdes Bundes wurde im Jahr 2024 mit dem Format der Hersteller-Roundtables eine neue Unterstützungsmaß- nahmeetabliert.ImRahmenderHersteller-RoundtableserfolgteineengeAbstimmungmitdenHerstellern, sodass für die Behördenund OrganisationendesBundes zumeinen entsprechendeTestlaborkapazitäten reserviertwerdenkönnen.ZumanderenwerdenindenregelmäßigenRoundtable-VeranstaltungenNeuig- keitenzuIPv6-KonfigurationenvondenHerstellernberichtet.Dadurchsollesermöglichtwerden,dassdie BehördenundOrganisationenselbstProdukteindenHersteller-Testlaborentesten.Testergebnissesollen

Version4.1 67

[Seite 68]

IPv6-ProgrammdesBundes

aufderKommunikations-undInteraktionsplattformbereitgestelltwerden,sodassvergleichbareTestsnicht wiederholtwerdenmüssen.

MitBezugaufdieFachanwendungenindenBehördengibtesverschiedeneMöglichkeitenfürIPv6-Tests: HatdieBehördemiteigenemPersonaldieFachanwendungenrealisiertundbetreibtdieBehördeselbstdie Entwicklungs-undTestumgebungenfürdieAnwendungen,dannsolltenbeideUmgebungenfürdieIPv6- Umstellungvorbereitetwerden.HatdieBehördedieFachanwendungdurcheinenDienstleisterrealisieren lassen,gibtesinderRegelPflegeverträgefürdieSoftware.UnterNutzungdieserPflegeverträgekanndie UmstellungaufIPv6beauftragtwerden,wasentsprechendeTestsvordemDeploymentderIPv6-Updates einschließenmuss.BetreibtdieBehördeeigeneTestumgebungen,umvordemEinspielenvonexternreali- sierterSoftwarenochmalseigeneTests,v.a.auchIntegrationstests,durchzuführen,dannistdieseTestum- gebungandieIPv6-UmstellunganzupassenundentsprechendeIPv6-Testfällemüssendefiniertundspezi- fiziertwerden.HierunterstützenvorallemdieIPv6-CoachesbeidenVorbereitungenundderDurchführung entsprechenderAnpassungen.

Lasttests, Stabilitäts- und Performancetests für Netzwerkkomponenten: Im physischen IPv6-Testlabor (siehe Kapitel 5) können umfangreiche Lasttests von verschiedener Netzwerkhardware und -software durchgeführtwerden.HierbeilassensichzumeinenkurzfristigeLastspitzensimulieren,umdieLeistungs- grenzen und Skalierbarkeit der Geräte und Anwendungen zu ermitteln. Zum anderen können Langzeit- StresstestsüberTageoderWochenerfolgen,umdieStabilitätundPerformancederProduktevergleichend zwischen IPv6 und IPv4 zu messen. Die Ergebnisse dieser kontrollierten Tests tragen dazu bei, die Pro- dukteinstellungenundDimensionierungenfürdenspäterenEinsatzzuoptimierenundsolltenaufderKom- munikations-undInteraktionsplattformdesIPv6-Programmsbereitgestelltwerden.

SimulationvonAngriffsszenarien:IPv6bringtneueAngriffsszenarienmitsich.DieSimulationvonAngriffs- szenarien, wie beispielsweise Denial-of-Service-Angriffen (DoS-Angriffen), ist ein wesentlicher Anwen- dungsfallfürIPv6-Testlabore. DoS-Angriffe zielendarauf ab,Netzwerksystemezu überlasten undDienste unzugänglichzumachen.DurchdieSimulationsolcherAngriffeineinerkontrolliertenUmgebungkönnen SchwachstellenidentifiziertundentsprechendeGegenmaßnahmenentwickeltundgetestetwerden.Unter anderem sollten IPv6-First-Hop-Security-Mechanismen getestet werden. Diese können nicht nur gegen mutwilligeAngriffenützlichsein,sondernauchbeiProblemenmitfalschkonfiguriertenCIshelfen.Einver- sehentlichandenfalschenPortangeschlossenerDSL-Routerverursacht sowohlbeiIPv4alsauchbeiIPv6 Probleme. Mit dem Test von Angriffsszenarien gegen den falsch angeschlossenenDSL-Router kann diese Schwachstelleerkanntwerden.

ImRahmenvonNegativtestswirdderAusfallvonbestimmtenGerätenundCIssimuliert.Dabeiwerdendie Auswirkungen auf die Anwendungen, denDatenverkehrunddie Netzwerkgeräte gemessen, umdasVer- haltenbeiAusfällenundWiederherstellungenzucharakterisieren.HierzumusseinfürdasProtokollgeeig- netesMonitoringbereitsvorhandensein.

InderPraxishatessichbewährt,vorÄnderungenbereitsdasMonitoringanzupassen. SowirddieszumeinennichtvergessenundzumanderenkannesbeiderDurchfüh- Tippsfür rungvonTestsnützlichsein,dasMonitoringtemporärzuaktivierenbzw.zudeaktivie- diePraxis: ren.SoerhältmanunmittelbaresFeedbackzumErfolgeinerAnpassung.

MöglicheTestfällesind:

• Router-Ausfall:DerAusfalleineszentralenRoutersimNetzwerkwirdsimuliertunddieAuswirkungen aufdieKonnektivitätzwischendenNetzwerksegmentenwerdenanalysiert. • Switch-Ausfall:DerAusfalleinesNetzwerkswitcheswirdsimuliertunddieAuswirkungenaufdieErreich- barkeitvonangeschlossenenGerätenwerdenbewertet.

Version4.1 68

[Seite 69]

IPv6-ProgrammdesBundes

• Firewall-Ausfall:Der Ausfalleiner Firewallwird simuliert undes wirduntersucht, wie die Netzwerksi- cherheitundderDatenverkehrbeeinträchtigtwerden. • Server-Ausfall:DerAusfalleineskritischenServerswirdsimuliertunddieAuswirkungenaufdieVerfüg- barkeitvonAnwendungenundDienstenwerdenbeobachtet. • Link-Ausfall:DerAusfalleinesNetzwerkverbindungslinkszwischenzweiStandortenwirdsimuliertund dieAuswirkungenaufdieKommunikationzwischendenStandortenwerdenanalysiert. • DNS-Ausfall:DerAusfalldesDNS-Serverswirdsimuliertundeswirdbewertet,wiesichdiesaufdieNa- mensauflösungunddenZugriffaufInternetressourcenauswirkt. • Stromausfall:EinplötzlicherStromausfallineinemRechenzentrumwirdsimuliertundeswirdbeobach- tet,wiedieRedundanz-undWiederherstellungsmechanismendesNetzwerksdaraufreagieren.

DieTestsdienenderunmittelbarenVorbereitungfürdieUmsetzungderIPv6-MigrationeninderInbetrieb- nahme.MöglicheWartungsszenarienundSystemänderungennachderUmstellungaufIPv6könnendurch- gespieltsowieTestfälleundPrüfprozedurenentwickeltwerden.NachderWartungkannsoimEchtbetrieb anhanddervorbereitetenTestsüberprüftwerden,oballeswiegeplantfunktioniert.Dieerfolgreichgetes- teten Konfigurationen bieten eine optimale Grundlage für die Umsetzungsphase des Keimzellen-Vorge- hensmodells.

FolgendesVorgehenwirdfürdieTestsempfohlen:

Version4.1 69

[Seite 70]

IPv6-ProgrammdesBundes

Version4.1 70

[Seite 71]

IPv6-ProgrammdesBundes

Tabelle12:AktivitätenketteTests

3.3.3.3 Inbetriebnahme

NachdenaufgeführtenVorarbeitenindeneinzelnenArbeitspakten,wieindenAktivitätenkettenbeschrie- benundindenpraktischenTippserläutert,kanndieInbetriebnahmegeplantwerden.WährendderInbe- triebnahmesolltendieeinzelnenArbeitsschrittenacheinanderdurchlaufenwerden–dieInbetriebnahme läuft inder Regel seriell ab.Es wird davonausgegangen,dass es injeder Behörde oder Organisationdes Bundes bewährte Inbetriebnahme- und Wartungsprozesse gibt, die auch bei einer IPv6-Migration einge- setztwerden.AufdiesebewährtenProzessekannundsollsichdasMigrationsteamverlassen–IPv6ergänzt lediglichdiesebewährtenProzessesowiedieWartungs-undBetriebsdokumentationen,wiediepraktischen Projekterfahrungenzeigen.

Version4.1 71

[Seite 72]

IPv6-ProgrammdesBundes

WiebereitsindenKapitelnzudenKeimzellen-MigrationenundderenWiederholungenbeschrieben(siehe Kapitel 3.3.2.2 und 3.3.2.3), erfolgen die Inbetriebnahmen innerhalb geplanter Wartungsfenster. Dabei kannesaufgrundderkomplexerenMigrationsszenarienbeidenInkrement-Migrationenerforderlichwer- den,weitereWartungsfensterindenWartungsplanaufzunehmenoder/unddieZeiträumefürdiebereits geplanten Wartungsfenster zu erweitern, um mehr Zeit für die Problemlösung einzuräumen, bevor Roll- backsentschiedenwerdenmüssen.AmEndeeinerjedenInbetriebnahmemussüberprüftwerden,obdie neueingespieltenIPv6-KonfigurationenBestandhabenoderobeinRollbackerfolgenmuss.DieseÜberprü- fungerforderteineneueRundeanTests–dieFreigabe-oderAbnahmetests.ImUnterschiedzudeninden vorherigenKapitelnbeschriebenenTestsmüssendieseaberinderBehörde oderOrganisationoderbeim beauftragtenDienstleisterdurchgeführtwerden–nichtineinemderprogrammeigenenTestlaboreoderin einem Herstellertestlabor. Auch für die Freigabe- und Abnahmetests sollen entsprechende Testpläne er- stelltundabgearbeitetwerden.

NachAbschlussderInbetriebnahmeundderTestsfürdieErfolgskontrolleerfolgtdieAbnahmeoderFrei- gabederumgestelltenIPv6-KonfigurationenindenInkrementen.DieAbnahmeoderFreigabeumfasstdie Bewertungder Testergebnisse unddie Überprüfung, ob alle definierten Testziele erreicht wurden.Dabei wirdinsbesondereüberprüft,obdasNetzwerknachderIPv6-Migration(noch)denSicherheitsanforderun- gen entspricht, die Performance angemessen ist und die Kommunikation reibungslos funktioniert. Das Technik-Team erstellt für jedes Inkrement ein Abnahme- oder Freigabeprotokoll, das die Ergebnisse der Abnahme dokumentiert.DiesesProtokoll dient alsGrundlage für die Entscheidungzur Freigabe der mig- riertenInkrementefürdenproduktivenEinsatz.

HinweisezuEinträgeninsDNS:NachdemdieIPv6-AdressefüreinenDienstinsDNS eingetragenwurde,isterneutzutesten,obderDienstfunktioniertundnichtinein Tippsfür Timeoutläuft.Hierbeiistauchwichtig,anHappy-Eyeballszudenken,dadiesmögli- diePraxis: cheVerbindungsproblemeverschleiert.

Während der Inbetriebnahme sollte ein Augenmerk auf das Monitoring gelegt werden: Das Monitoring liefert aus Langzeitbeobachtungen wichtige Informationen zur Betriebsstabilität nach einer IPv6-Mig- rataion.Wennmöglichsollten z.B.aufSwitchesundRouternIPv4 undIPv6 getrenntvoneinander proto- kolliertwerden,wennDual-StackimEinsatzist.ImMonitoringentstehendreiWerte,dieüberdenZeitver- laufausgewertetwerdenkönnen:IPv4,IPv6undbeidezusammenaggregiert.Dadurch,dassmehrWerte überwachtwerden,steigtderRessourcenbedarf(RAM,CPU,Disk)desMonitoringsystemsan.Gleichzeitig können aber Optimierungenfür die Kapazitätsplanungabgeleitetwerden.Diese Auswertunghistorischer Datenkannbspw.durchdasBetriebsteamineineRetrospektiveeingebrachtwerden.

DieInkrement-MigrationensolltendurchRetrospektiven(Retros)abgeschlossenwerden.DieseRetrosdie- nen der erneuten Identifikation von Lessons Learned, der Vorbereitung auf das „kontinuierliche Lernen“ undvorallemderEntscheidung,welcheErfahrungen,BerichteundErkenntnissedieBehördeoderOrgani- sationaufderKommunikations-undInteraktionsplattformdesIPv6-Programmsteilenkann.DieRetrokann verglichenwerdenmiteiner„Iteration-Retrospektive“inSAFe27,dieindernachfolgendenAktivitätenkette beschriebenwird.

27https://framework.scaledagile.com/iteration-retrospective/;zuletztaufgerufenam11.11.2025

Version4.1 72

[Seite 73]

IPv6-ProgrammdesBundes

Version4.1 73

[Seite 74]

IPv6-ProgrammdesBundes

Version4.1 74

[Seite 75]

IPv6-ProgrammdesBundes

Tabelle13:AktivitätenketteInbetriebnahme

3.3.4 KontinuierlichesLernen

DasIPv6-Programmbasiertauf„HilfezurSelbsthilfe“–esstelltdenüberbehördlichenErfahrungsaustausch in den Mittelpunkt. Diesen zu nutzen, minimiert Risiken im Migrationseinzelprojekt und spart Aufwände mitBezugaufdieDurchführungvonTests(indenKeimzellen-MigrationenundderenWiederholungenso- wiedenInkrement-Migrationen).Ggf.könnensogarSachkosteneingespartwerden,weilErsatzbeschaffun- genvermiedenwerdenkönnen.TeildesErfahrungsaustauschszuwerden,bedeutetimGegenzugOffenheit fürTippsundHinweiseimMigrationseinzelprojektzuzulassen.

„Kontinuierlich“istdasLerneninzweifacherDimension:ZumeinendurchläufteinMigrationseinzelprojekt mehrfachdas„RadderMigration“(sieheAbbildung3).MitjedemDurchlaufwerdenneueErfahrungenund Erkenntnissegesammelt,dieimProjektteamundaufderKommunikations-undInteraktionsplattformdes IPv6-Programms geteilt werden sollten. Zum anderen folgt dieser Migrationsleitfaden dem Verständnis, dasseineIPv6-MigrationeineTransformationderbehördlichenIT-Landschaftdarstellt,dieeinenlängeren Zeitraum in Anspruch nehmen kann als in der Bündelplanung des IPv6-Programms dokumentiert und im Projektplan des Migrationseinzelprojektes ausgeführt. Das bedeutet, dass auch nach dem Erreichen der Migrationsquote undder BeendigungdesMigrationseinzelprojektes„der Blick“ aufdie Kommunikations- undInteraktionsplattformlohnt,umweitereBestPracticeskennenzulernen,diefürdieIPv6-Migrationvon jenenCIsangewendetwerdenkönnen,dienochunterIPv4betriebenwerden.

EingebettetindieAktivitätenkettenfindensichdieReview-MeetingsfürdieKeimzellen-Migrationensowie die Retrospektive für die Inkrement-Migrationen. Aus beiden Formaten lassen sich wichtige Lessons Learnedableiten,die–sofernmöglich–aufderKommunikations-undInteraktionsplattformdesIPv6-Pro- grammsmitanderengeteiltwerdenkönnen.

In kleineren Behörden, in denen bspw. nur drei oder vier Mitarbeitende den IT-Betrieb aufrechterhalten unddieanstehendenIPv6-Migrationendurchführensollen,sinddiegenanntenFormateTeildernormalen Abstimmungen –eswird einfacheine Teamabstimmung, die esregelmäßiggibt, für dasThema„Lessons Learned“reserviert.GeradefürkleinereMigrationsteamsisteineregeNutzungdesWissensmanagements sinnvoll, weil sie dort Unterstützung erhalten, die den Teams, die die IPv6-Migration auf dastägliche Ar- beitspensumaufsatteln,ZeitundAufwandspart.FragenkönnenimForumoderdenCommunitiesofPrac- ticederKommunikations-undInteraktionsplattformgestelltunddiskutiertwerden.

HierbeikommtesnunaufjedeneinzelnenMitarbeitendenindenMigrationsteams–Dienstleistereinge- schlossen–an:WennniemandseineErfahrungenimaufderKommunikations-undInteraktionsplattform- teilt,wirddieserelativleerbleiben.DieRedaktiondesIPv6-ProgrammsbietethiervieleFormate,umauf- wandssparendLessonsLearnedaufzunehmen.DieIPv6-CoachessinddieersteAnlaufstellefürFragenund werdendiesealsPower-UserderKommunikations-undInteraktionsplattformkontinuierlichbeantworten. DieNutzungderKommunikations-undInteraktionsplattformunddesIPv6-Wikis–quasivomerstenTagan

Version4.1 75

[Seite 76]

IPv6-ProgrammdesBundes

–kanndieMitarbeitendeneinesMigrationseinzelprojektesmotivieren,ihreErfahrungenmitanderenaus- zutauschen.ZunächstkönnendieMitarbeitendeneinesMigrationseinzelprojektesals„Wissenskonsumen- ten“aufderKommunikations-undInteraktionsplattformagieren–spezifischetechnischeFragenimIPv6- Wiki suchen und entsprechende Artikel lesen oder bspw. mit dem BSI in einer „Community of Practice“ überdieerforderlichenAnpassungenindenSicherheitskonzeptendiskutieren.MitfortschreitendenIPv6- MigrationenvonKeimzellenundInkrementenundunterstützt durchdieRedaktionunddieIPv6-Coaches könnendieMitarbeitendenihreErfahrungenbereitstellen–imSinnevon„NehmenundGeben“vonWis- sen.DieBereitstellungvonErfahrungeninanonymisierterFormistinAbstimmungmitdemRedaktionsteam ebenfallsmöglich.

EingesetzteDienstleisterverfügenübervielWissenundumfangreicheErfahrungen.EskannderFalleintre- ten,dassdieDienstleisterauswirtschaftlichenInteressenherausdiesesWissenunddieErfahrungennicht teilenwollen.Zumeinenistessinnvoll,indenindividuellenBeauftragungenentsprechendePassagenzum Know-how-Transfer vorzusehen. Zumanderen könnendie Dienstleister damit motiviert werden, dass sie sich über eine Beteiligung am Wissensmanagement auch für Folgebeauftragungen bewerben – denndas IPv6-ProgrammselbstisteinLangläuferunddieindividuellenMigrationseinzelprojektesindTransformati- onenderbehördlichenIT-Landschaften,indenenExpertenimmerwiederbenötigtwerden,wenneinsich bisherimIPv4-BestandsschutzbefindlichesCIdurcheinneuesProduktersetztwerdensoll,dasübereine IPv6-Fähigkeitverfügt.

3.3.4.1 Projekt-Monitoring

Hinweis:UnterProjekt-MonitoringindiesemMigrationsleitfadenistdasControllingundBenchmarking imMigrationseinzelprojektzuverstehen,nichtdasMonitoringvonKonfigurationselementen.

BeimControllingderMigrationseinzelprojektegibteszweiBesonderheiten:ZumeinenfolgtdieserMigra- tionsleitfadendemVerständnis,dassessichbeiderUmstellungaufIPv6umeineTransformationderbe- hördlichen IT handelt. Dieser Transformation ist mit der Zuordnung in die Bündelplanung ein „Start-Zeit- fenster“ zugewiesen worden. Auch wenn davon auszugehen ist, dass einige Migrationseinzelprojekte in- nerhalbeinesBündelzeitraumsbegonnenundabgeschlossenwerdenkönnen,sokanndieTransformation derbehördlichenITaufIPv6auchlängeralszweiJahreandauern.ZumanderenbedingtdasagileVorgehen, dasseinigeKennzahlen,wiedieAnzahlderzumigrierendenKonfigurationselemente,sichhinsichtlichder PlanzahlenüberdieZeitverändernwerden.

DasIPv6-ProgrammbietetmitELISAeinControlling-Toolan,inwelchemwesentlicheControlling-Datenfür einMigrationseinzelprojekterfasstwerdenkönnen.MitdenverrechnetenKennzahlenausdenControlling- Daten im ELISA-Tool kann ein Projekt-Monitoring umgesetzt werden. Das ELISA-Tool hat berücksichtigt, dasssichPlanzahleninfolgedesagilenVorgehensüberdieLaufzeiteinesMigrationseinzelprojekteshinweg verändernkönnen.

DieNutzungdesELISA-Controlling-Toolsist andievereinbarteBündelplanungdesProgrammsgekoppelt, d.h.mitEintrittindaszugewieseneBündelkanndasProjekt-MonitoringimELISA-Toolerfolgen.

DieDatenerhebungerfolgtquartalsweiseanhandvonfünfControlling-Dimensionen:

• Fortschrittscontrolling • Meilensteincontrolling • Risikocontrolling • Ressourcencontrollingund • Kommunikationsmanagement

Version4.1 76

[Seite 77]

IPv6-ProgrammdesBundes

FolgendeControlling-DatensollenfüreinMigrationseinzelprojekterfasstwerden:

Version4.1 77

[Seite 78]

IPv6-ProgrammdesBundes

Version4.1 78

[Seite 79]

IPv6-ProgrammdesBundes

Tabelle14:ÜbersichtDatenerhebungsbedarffürProjekt-MonitoringimELISA-Controlling-Tool

ZusätzlichzudiesenKennzahlen,dieimELISA-Toolerfasstwerden,musseineKontrolleüberdieverausgab- ten Haushaltsmittel durch das Projektcontrolling erfolgen. Im ELISA-Tool werden nur die Gesamtbeträge der angemeldeten und der bewilligten Haushaltsmittel erfasst. Im Migrationseinzelprojekt selbst, unter- stützt durch die behördlichen Haushälter, müssen die Mittelabflüsse nachverfolgt werden. In der Regel greift dieMigrationsprojektleitunghier auf die bewährten Dokumentations-Werkzeuge derBehörde,wie Excel-Tabellen, zurück. Damit erfolgt das Controlling des verausgabten Projektbudgets, welches auch bei FortschreibungenderWirtschaftlichkeitsbetrachtungfürdasMigrationseinzelprojektbenötigtwird.

DasFortschrittscontrollingimELISA-ToolerfolgtüberdieMeilensteinumsetzung(sieheoben).ImMigrati- onseinzelprojekt kann unter Verwendungder Daten zur „Anzahlzu migrierende CIs“ und„Anzahlbereits migrierterCIs“monatlichdieMigrationsquoteermitteltundmitderfestgelegtenZiel-Migrationsquotever- glichenwerden.MitdiesemVergleichkannderFortschrittderbehördlichenIPv6-Migrationgemessenwer- den.

Das ELISA-Tool bietet darüber hinaus Dashboards an, die Auswertungen und Zusammenfassungen von Kennzahlenanzeigen,diedenMigrationseinzelprojektendasBenchmarkingmitanderenProjektenermög- lichen soll. Dieses Benchmarking ist ein wichtiger Bestandteil desProjekt-Monitorings. Es unterstützt die „HilfezurSelbsthilfe“unddamitauchdasagileVorgehen.

Es stehen für das Projekt-Monitoring auf Ebene eines Migrationseinzelprojektes das „Projektdashboard“ unddas„Benchmarking-Dashboard“zurVerfügung.

Abbildung6:ÜbersichtdesProjektdashboards(mitBeispieldaten)

Version4.1 79

[Seite 80]

IPv6-ProgrammdesBundes

Abbildung7:ÜbersichtdesBenchmarkingDashboards(mitBeispieldaten)

DieRessortansprechpartnerhabenzusätzlichnochZugriffaufein„Ressortansicht-Dashboard“,inwelchem dieMigrationseinzelprojekteeinesRessortsmitAuswertungendargestelltsind.

Abbildung8:ÜbersichtdesRessortansicht-Dashboards(mitBeispieldaten)

InderKombinationvonerfasstenControlling-DatenunddervisualisiertenDarstellungderdarausverrech- netenKennzahlenindenDashboardsverfügen dieMigrationseinzelprojekte sowohlüber ausreichendIn- formationenzurSteuerungderanstehendenMigrationenalsauchzurVernetzungmitanderenBehörden undOrganisationen,dieggf.Herausforderungen schnelleraufgelösthaben.Zudemkönnen Inputsfürdie ErstellungvonWirtschaftlichkeitsbetrachtungenfürdieMigrationseinzelprojektegewonnenwerden.

Alle visualisiertenKennzahleninnerhalbder Dashboardskönnen auchalsExcel- (.xlsx) oder als CSV-Datei (.csv)exportiertwerden.ZudemkönnendieerfasstenControlling-DatenalsWord-Berichtheruntergeladen

Version4.1 80

[Seite 81]

IPv6-ProgrammdesBundes

werden.DiessolldieBerichterstattungzumMigrationseinzelprojektinnerhalbeinerBehörde,v.a.zurBe- hördenleitung,erleichtern.

DieBündelplanungdesIPv6-ProgrammsdesBundesmarkiertdieZeitfensterfüreinenStartderMigrations- einzelprojekte. Das bedeutet, dass nicht jedes Migrationseinzelprojekt zur gleichen Zeit startet und Con- trolling-Datenerfasstwerdenkönnen.

FolgendesVorgehenwirdfürdasProjekt-Monitoringempfohlen:

Version4.1 81

[Seite 82]

IPv6-ProgrammdesBundes

Tabelle15:AktivitätenketteProjekt-Monitoring

3.3.4.2 Dokumentation

EntsprechenddemagilenVorgehensmodellistdieDokumentation„vonSchritteins“imMigrationseinzel- projektzuerstellen undsukzessivemit jedemMigrationsschrittundjedem Durchlauf durchdas„Radder Migration“anzureichern.NachAbschlussderInbetriebnahmemussdieDokumentationdermigriertenKon- figurationselemente vervollständigt werden. Keine Inbetriebnahme oder Umstellung ist abgeschlossen ohnevollständigeDokumentation.

Zu den wichtigsten Dokumenten im Bereich der Inbetriebnahme gehören die Betriebskonzepte. Im Zuge derIPv6-MigrationmussauchdasIT-Betriebskonzeptüberprüftundangepasstwerden.

DieskannsowohlvoralsauchparallelzurMigrationzuIPv6erfolgen,abhängigvonverschiedenenFaktoren, wiez.B.demUmfangderAnpassungen,denvorhandenenRessourcenundderKomplexitätderMigration. Beikleinen Behörden ist esratsam,dasBetriebskonzept imVoraus anzupassen,umsicherzustellen, dass dienotwendigenÄnderungenundAnpassungenrechtzeitigumgesetztwerdenkönnen.ImFalle mittlerer undgroßerBehördenundentsprechendkomplexenMigrationseinzelprojektenistessinnvoll,dasBetriebs- konzeptparallelzurMigrationanzupassen.Diesermöglichtes,praktischeErfahrungenwährendderMigra- tionzusammelnundaufBasisdieserErfahrungenAnpassungenvorzunehmen.Entsprechenddesempfoh- lenen, agilen Vorgehens soll das Betriebskonzept während des Migrationseinzelprojektes kontinuierlich überprüftundangepasstwerden,umaufauftretendeProblemeoderHerausforderungenzureagieren.

BestehendeBetriebskonzeptemüssennichtersetztwerdendurcheinneues.Auf- grunddesparallelenBetriebsvonIPv4undIPv6ineinerBehörde(IPv4-Bestands- schutzundIPv4-/IPv6-Dual-Stack)istessinnvoll,IPv6-KapitelindasbestehendeBe- Tippsfür triebskonzeptaufzunehmen.UmdieHandhabbarkeitdessofortgeschriebenenBe- diePraxis: triebskonzepteszuverbessern,istdeutlichzukennzeichnen,obessichumeinKapitel der„altenIPv4-Welt“odereinIPv6-Kapitelhandelt.

Version4.1 82

[Seite 83]

IPv6-ProgrammdesBundes

AbhängigvondendokumentiertenKonfigurationenimBetriebskonzeptmüssenverschiedeneKapiteldes IT-BetriebskonzeptsumIPv6erweitertoderergänztwerden,u.a.diefolgenden:

• Netzwerkarchitektur: Die Netzwerkarchitektur muss aktualisiert werden, um IPv6 zu unterstützen. DiesumfasstdieAktualisierungvonNetzwerkkomponentenwieRoutern,Switches,FirewallsundLoad- Balancern,umIPv6-Konnektivitätzuermöglichen. • Adressraumplanung: Mit IPv6 steht ein großer Adressraum zur Verfügung. Die Adressraumplanung muss überarbeitet werden, um die effiziente Nutzung von IPv6-Adressen zu gewährleisten und eine ausreichendeAnzahlvonAdressenfürzukünftigesWachstumundneueDienstebereitzustellen.Sollte imZugederIPv6-MigrationeinIPAM-Tooleingeführtwerden,musseinentsprechendesHandbuchzur NutzungdesneuenWerkzeugsfürAdressraumplanungzusätzlichzumBetriebskonzepterstelltwerden. • Protokollunterstützung:DasIT-Betriebskonzeptsolltesicherstellen,dassalleNetzwerkprotokolleund Dienste, die in der IT-Infrastruktur eingesetzt werden, IPv6 unterstützen. Dies umfasst DNS (Domain Name System), DHCP (Dynamic Host Configuration Protocol), NTP (Network Time Protocol), SNMP (SimpleNetworkManagementProtocol)undandereProtokolle. • Sicherheit und Zugriffskontrolle: Die Sicherheitsmechanismen und Zugriffskontrollen müssen an die IPv6-Umgebung angepasst werden. Dies beinhaltet die Konfiguration von Firewalls, Intrusion-Detec- tion-Systemen (IDS) und Intrusion-Prevention-Systemen (IPS), um IPv6-Datenverkehr zu überwachen undzuschützen. • Anwendungsunterstützung:DieAnpassungenundUpdatesfürIPv6indenSoftwarelösungenderBe- hördekönnenEinflussaufdieAdministrationderSoftwarehaben.DiesistimBetriebskonzeptzudoku- mentieren.

EinweitererwichtigerBereich,indemIPv6-Inhalteergänztwerdenmüssen,istdasDisaster-Recovery-Kon- zept. Disaster-Recovery-Konzepte und die dazugehörigen Mechanismen sowie Automatismen sind sehr spezifischfürdiejeweiligeIT-Umgebung.DasüberdasMigrationseinzelprojekterworbeneWissenzuIPv6 isteinewichtigeVoraussetzungzurAnpassungdiesesKonzepts.

EinimmerwiederauftretendesProblembeiderAnpassungvonDisaster-Recovery-Konzeptenist,dasssie nicht kontinuierlich mit Bezug auf vorgenommene Änderungen oder Erweiterungen aktualisiert werden. Dasempfohlene,agileVorgehenermöglicht es,diesesKonzept nicht nur hinsichtlichderIPv6-Umstellun- gen,sondernauchdarüberhinausgehendzuergänzen.EinandererAspekt,derbeiderAnpassungderKon- zepte eine zentrale Rolle spielt, ist, dass manche der Recovery-Schritte nur einzelne Konfigurationsele- mente betreffen, andere aber übergreifend auf die in der Behörde eingesetzte IT wirken. Deshalb ist es sinnvoll,dieübergreifendenDisaster-Management-undRecovery-Themengebündeltzubetrachten.Hier- fürbietetsicheineigenesSub-Teaman(sieheKapitel4.3),dasineinemAgile-Release-Trainzusammenar- beitet.DiesesTeamübernimmtnichtnurdieAnpassungdesKonzeptes,sondernformuliertAnwendungs- undTestfällefürDisaster-undRecovery-Szenarien.

BeimSichtendesexistierendenDisaster-undRecovery-KonzeptesmussdasSub-TeamzunächstdieFrage beantworten, anwelchen Stellen undinwelcherPhaseder Disaster-Recovery-ProzessvonIPv6 abhängig ist.AuffolgendeKapitelimvorhandenenDisaster-Recovery-KonzeptsolldabeiderSchwerpunktgelegtwer- den,umdiesezentraleFragebeantwortenzukönnen:

• Essenzielle Infrastrukturen: Unter „essenzielle Infrastrukturen“ sind Konfigurationselemente zu ver- stehen, die benötigt werden, damit alle weiteren CIs wiederhergestellt werdenkönnen. Typische CIs sind der Netzwerk-Backbone, DNS, Active Directory, NTP, Dokumentations-Server, Provisionierungs- undOrchestrierungssysteme.DieseInfrastrukturenwerdensowohlinKeimzellen(sieheKapitel3.3.2.2) alsauchalsInkremente(sieheKapitel3.3.3.3)migriert.AnpassungenimKonzept,ebensowieentspre- chendeTests,müssenvondererstenKeimzellean,mitdereinKonfigurationselementeiner„essenzi- ellenInfrastruktur“migriertwird,erfolgen.

Version4.1 83

[Seite 84]

IPv6-ProgrammdesBundes

• Out-of-Band-Management-Netze (OOB-Netze): Für OOB-Netzen muss entschieden werden, wann in welchen Bereichen auf IPv6 umgestellt wird. OOB-Netze werden oftmals als Dual-Stack konfiguriert. „Großflächiges"Dual-StackbringtimDisaster-Recovery-FalleinezusätzlicheKomplexitätmit,diev.a. manuelleSchritteimRecovery-Prozesserzwingt,wasdieRecoveryinsgesamtunnötiglangwierigund fehleranfälliggestaltet. • Backup-Server: Backup-Server müssen zuverlässig wiederhergestellt werden können, da sie eine Vo- raussetzungfürdieWiederherstellungweitererCIssind.AuchBackup-ServerkönnenalsKeimzellemi- griertwerden;diefrüheEinbindungdesRecovery-Sub-Teamsstelltsicher,dassdasKonzeptangepasst wird. • DNS:WeilinsbesondereDNSzuBeginnderRecoverynichtunbedingtzurVerfügungsteht,müssenhier teilweise literale IPv6-Adressen statt DNS-Namen benutzt werden. Im fortgeschriebenen Disaster- Recovery-Konzeptsolltevorgesehenwerden,dassDNSmöglichstschnellwiederinBetriebgenommen wird,umdieAbhängigkeitvondiesenliteralenAdressenzuminimieren.WennDNSfrühzeitigwieder- hergestelltwird,könnenauchfrühzeitigDNS-Namenvergebenwerden.AuspraktischerErfahrungher- ausistbekannt,dassdieseinesubstanzielleAnpassungdesRecovery-Konzeptesbedeutenkann.Inei- nerAbstimmungmitdemTechnik-Team(sieheKapitel4.2)mussdiesesVorgehengemeinsamentschie- denwerden.EntsprechendeTestsmüssenfrühzeitig–inderPhasePlanung,sieheKapitel3.3.1.3–vom Sub-Teamgeplant,beschriebenunddurchgeführtwerden. • NTP:DieZeitsynchronisation(typischerweise perNTP)wird benötigt, umzuverhindern,dassneuere Datendurchältereüberschriebenwerden.

TippfehlerinmanuelleingegebenenIPv6-Adressensindv.a.beiRecovery-Prozessen einProblem,dasinderPraxisbekanntist.TatsächlichkommenTippfehlerbeiderEin- gabevonIPv6-AdresseauchohneZeitdruck,derineinerDisaster-Recovery-Situation unvermeidlichist,oftgenugvor.DieFokussierungaufdasunmittelbarNotwendigein einerRecovery-Situation,wiederWiederherstellungeinerNetzwerkverbindungzwi- schenBackup-ServernunddenBackup-Clients,diewiederhergestelltwerdensollen, Tippsfür minimiertdiesesFehlerrisiko.AutomatisierungindenRecovery-Prozessen,wiedie diePraxis: automatischeWiederherstellungderNetzwerkkonfigurationenausdemBackup,inkl. derIPv6-Adressen,unterstützt,dasswenigerRecovery-Schrittemanuellumgesetzt werdenmüssen.DieWiederaufnahmedesBetriebseinzelnerAnwendungenistdem- gegenüberbeiderAnpassungdesDisaster-Recovery-Konzeptsnormalerweisevon IPv6nichtbetroffen.

Gemeinsam mit dem Technik-Team muss das Recovery-Sub-Team die Entscheidungen für den IPv4-Be- standsschutz überprüfen, denn die fortgesetzte Nutzung von IPv4 für ausgewählte CIs oder Netze, wie bspw.dasIntraneteinerOrganisation,habenEinflussaufDisaster-Recovery-Prozesse.ZumeinenwirdIPv4 zunehmendstöranfälliger,d.h.zeitweiligeAusfällewerdeninZukunftzunehmen.Zumanderenschränken InternetServiceProvider(ISPs)undTransitServiceProvider(TSPs)stetigdieNutzungvonIPv4ein.BeiAus- fällen,bspw.infolgevonCyberangriffen,greifenISPsundTSPszuNotlösungen,umIPv4miteingeschränkter Funktionalitätbereitzustellen.DieseNotlösungenkönnendieNutzungvonIPv4-CIsineinerBehördeoder OrganisationdesBundeseinschränken.

Neben diesen Konzepten soll die Testdokumentation so aufbereitet werden, dass diese umfangreich auf derKommunikations-undInteraktionsplattformdesIPv6-Programmsbereitgestelltwerdenkann.Dasspart denanderenMigrationseinzelprojektenZeitundAufwand,wennsiebereitsdurchgeführteTestfälle,diezu identifiziertenbehördlichenAnwendungsfällenpassen,nichtneuentwickelnoderggfs.auchwiederholen müssen.

Version4.1 84

[Seite 85]

IPv6-ProgrammdesBundes

Zudemistessinnvoll,eineProjektdokumentationzuführen.IndiesersollendiePlanungsdokumentesowie die Ergebnisse der Lessons-Learned-Abstimmungen, der ReviewsundRetrospektiven aufgeführtwerden. AuchinBezugaufdieseDokumentationsollgeprüftwerden,welcheBerichteoderProtokollealsErlebnis- berichteimBest-Practice-RepositoryderKommunikations-undInteraktionsplattformdesIPv6-Programms bereitgestelltwerdenkönnen.

FolgendesVorgehenwirdfürdieinitialeDokumentationsämtlicherKonfigurationsschritteimRahmenvon MigrationenvonKeimzellen,derenWiederholungenundvonInkrementenempfohlen:

Tabelle16:AktivitätenketteinitialeDokumentation

3.3.4.3 Erfahrungsaustausch

Gesammelte Erfahrungen werdenin denbeschriebenen Abstimmungsformaten ausgetauscht und in den aufgeführten Dokumentationen beschrieben. Das dient nicht nur dem überbehördlichen Erfahrungsaus- tausch im IPv6-Wissensmanagement. Im empfohlenen, agilen Vorgehensmodell ist der Erfahrungs-

Version4.1 85

[Seite 86]

IPv6-ProgrammdesBundes

austausch eine zwingende Voraussetzung für die Wiederholungen der Keimzellen-Migrationen sowie für diePlanungundDurchführungderInkrement-Migrationen.

EinweiteresSub-Team(sieheKapitel4.3)oderzumindesteinTeammitglieddesTechnik-TeamssieheKapi- tel 4.2) sollte verantwortlich sein für diesen projektinternen Erfahrungsaustausch. Die in der Tabelle 27 gelistetenAbstimmungsformatesollenstetseinenTagesordnungspunktzumErfahrungsaustauschenthal- ten, wenn dieses nicht, wie der „Lessons-Learned-Workshop“ im Arbeitspaket Konfiguration Inkremente (sieheKapitel3.3.3.1),dediziertdemErfahrungsaustauschdient.

Der projektinterne Erfahrungsaustausch ist auch eine Brücke für den programmweiten Erfahrungsaus- tausch.DasverantwortlicheSub-TeamoderdasverantwortlicheTeammitgliedsolldieErgebnissedespro- jektinternenErfahrungsaustauschskontinuierlichbewerten,obbspw.TestfälleundTestergebnisseoderEr- fahrungsberichte, z.B. zu Keimzellen-Migrationen, für das Wissensmanagement des IPv6-Programms ge- eignetsindoderobnochAnpassungen,wiebspw.Anonymisierungen,vorgenommenwerdensollen.Sub- Team oder Teammitglied beziehen das Redaktionsteam des Wissensmanagements ein, wenn es um die Aufbereitunggeht,umAufwandaufSeitenderBehördezuminimieren.

JedeBehördeoderOrganisationerhältimprogramminternenBereich(SharePoint)eineneigenenBereich. In diesemBereichkönnen die Ergebnisse des projektinternenErfahrungsaustauschs (ebenso wie weitere Unterlagen)abgelegtundbearbeitetwerden.SobalddieseErgebnissedesprojektinternenErfahrungsaus- tauschsgeprüftundbeiBedarfzurBereitstellungfürdasProgrammüberarbeitetsind,könnendiesedurch dasRedaktionsteamdesWissensmanagementsindasBest-Practice-RepositoryderKommunikations-und Interaktionsplattformhochgeladenwerden.

DasWissensmanagementderKommunikations-undInteraktionsplattform(Confluence)bietetumfangrei- cheMöglichkeitenfürdenErfahrungsaustausch,wieindernachfolgendenAbbildungdargestellt:

Abbildung9:WissensmanagementdesIPv6-Programms

DerFunktionsumfangdesWissensmanagementsistaufderPlattformanverschiedenenStellen,u.a.auch inErklärvideos,erläutert.

DasIPv6-Wiki,alsvirtuellesNachschlagewerkfürdenThemenbereichIPv6,istindieKommunikations-und Interaktionsplattformeingebettet,d.h.esgibtdafürkeinengesondertenZugang.

DasIPv6-ProgrammstellteinRedaktionsteambereit,dasdieBehördenundOrganisationenbeiderBereit- stellungvonWissenfürdenprogrammweitenErfahrungsaustauschunterstützt.DasRedaktionsteamsteht fürAustauschformatebereit,indenenbspw.ErfahrungsberichtevondenTeamsderMigrationseinzelpro- jekteaufgenommenwerden,sodassdasTeamdiesenichtselbstschreibenmuss.

Version4.1 86

[Seite 87]

IPv6-ProgrammdesBundes

DieindividuelleBeteiligungamprogrammweitenErfahrungsaustauscherfordertnureinenZugangzurKom- munikations- und Interaktionsplattform. Der Zugang kann per E-Mail (ipv6-programm@bdbos.bund.de) oderaufderProgramm-WebseiteüberdasKontaktformular28beantragtwerden.BeiexternenDienstleis- tern,diedieMigrationseinzelprojekteunterstützen,istzusätzlichdieAngabedesAnsprechpartnersaufSei- tendesAuftraggeberserforderlich.

FolgendesVorgehenwirdfürdeninitialenErfahrungsaustauschempfohlen:

28 https://www.bdbos.bund.de/DE/Service/Kontakt_IPv6/kontaktIPv6_node.html; zuletzt aufgerufen am 11.11.2025

Version4.1 87

[Seite 88]

IPv6-ProgrammdesBundes

Tabelle17:AktivitätenketteErfahrungsaustausch

Version4.1 88

[Seite 89]

IPv6-ProgrammdesBundes

3.3.5 ErneuteDurchläufe

DieerneutenDurchläufedurchdas„RadderMigration“(sieheAbbildung3)fürdieKeimzellen-Migrationen und die Inkrement-Migrationen entsprechend des agilen Vorgehens gleichen sich prinzipiell. Im Unter- schiedzurSoftwareentwicklungwirdmiteinemerneutenDurchlaufkeinweitererFunktionsumfangzuei- nerAnwendunghinzugefügt.VielmehrwerdenneueKonfigurationselementederbehördlichenGesamtar- chitekturmigriertundsukzessivefülltsichdie„IPv6-Landkarte“derITineinerBehördeoderOrganisation desBundes.AuchwennsichdieAktivitäten indiesenerneuten Durchläufen gleichen,sogibtesdennoch Unterschiede,dieindernachfolgendenTabelleerläutertsind.DienachfolgendenAktivitätensollenbeiei- nemerneutenDurchlaufindieAktivitätenkettenausTabelle5bisTabelle13sowieTabelle15,Tabelle16 undTabelle17aufgenommenwerden.

Version4.1 89

[Seite 90]

IPv6-ProgrammdesBundes

Tabelle18:ZusätzlicheAktivitätenfürerneuteDurchläufedurchdieAktivitätenketten

3.3.6 GrenzendesagilenVorgehensmodells

Auchwenn dieser Migrationsleitfaden einagilesVorgehensmodellempfiehlt, sokann eine Behörde oder OrganisationdesBundesunterUmständendiesesnichtumsetzen.

BekannteGründedafürsind:(a)unvorhergesehenetechnischeHerausforderungen,(b)unzureichendeRes- sourcen oder (c) unerwartete Änderungen der Anforderungen an die IPv6-Migration, bspw. vom Pro- jektsponsor(sieheKapitel4.1).

Zu(a)unvorhergesehenetechnischeHerausforderungengehörenv.a.folgende:

• Anwendungen, deren Einsatz unverzichtbar ist, könnennicht rechtzeitigaufIPv6 umgestellt werden. DieseAnwendungenmüssenauchüberdiegeplanteLaufzeitdesMigrationseinzelprojektesweiterhin überIPv4kommunizieren.DamitfallendieseAnwendungensowohlalsKeimzellealsauchalsTeileines InkrementsoderalsInkrementaus.DieIPv6-MigrationdieserAnwendungkannggf.erstnachderakti- ven Phase des Technik-Teams (siehe Kapitel 4.2) geplant werden. Für eine Migration außerhalb des Migrationseinzelprojektes kann ein Wasserfall-Vorgehen oder ein iterativ-inkrementelles Vorgehen umgesetzt werden. Da bereits viele Konfigurationselemente der Behörde oder Organisation zum

Version4.1 90

[Seite 91]

IPv6-ProgrammdesBundes

ZeitpunktderMigrationsplanungfürdieseAnwendungmigriertwordensind,gibtesvielIPv6-Wissen inderBehördeselbst.ZudemistdieKommunikations-undInteraktionsplattformdesIPv6-Programms mitvielenErfahrungenbefüllt.DerwesentlicheAspektdesagilenVorgehensmodells,sukzessiveWis- sen zu IPv6 in die Organisation zu tragen, trägt nicht mehr. Darüber hinaus haben die Hersteller der Anwendung(entwederdieProduktherstellerbeiStandardsoftwareoderdieDienstleister,diedieSoft- warerealisierthaben)dieAnforderungzurHerstellungderIPv6-FähigkeitderAnwendungbereitsvor einigerZeiterhaltenundsichaufdieIPv6-Umstellungvorbereitet.Mitwesentlichen„Überraschungen“ hinsichtlichderIPv6-Fähigkeitistalsonichtzurechnen.UnterUmständengibtesbereitseinIPv6-Test- laborbeimHerstellerfürdieAnwendung,diedieBehördenutzenkann.Insofernist einschrittweises Umstellen–vonderPlanungüberdieIst-AufnahmezurFestlegungdesMigrationsszenarios,derschritt- weisen oder iterativen oder inkrementellen Migration bis zu den Tests und der Inbetriebnahme mit FreigabeoderAbnahmedurchaussinnvoll. • ImZugedesKeimzellen-Vorgehenswirdfestgestellt,dasseinzusetzendeKonfigurationselementevon DrittherstellernIPv6nichtvollständigoderfehlerhaftumsetzen.Diesesführteinerseitsdazu,dassdie IPv6-MigrationenfürdieseCIszurückgestelltwerdenmuss.AndererseitsmusseineAnpassungderMig- rationsplanungerfolgen,sodassdieIPv6-UmstellungallerweiterenCIsderBehördeoderOrganisation „flexibelumdieseKomponentenherum“(„Workarounds“)erfolgenkann.FürdieseKonfigurationsele- mente,derenIPv6-Fähigkeitzwartheoretischbesteht,praktischaberzuerheblichenProblemenführt, kanngleichfallseinWasserfall-Vorgeheneingesetztwerden.Organisatorischwirdempfohlen,dassein eigenesSub-Team(einAgileRelease Train) für diese CIsgebildetwird.Eine IPv6-Migrationeinessol- chenKonfigurationselementskanndannwiederSchrittfürSchritterfolgen.Rollback-Kriterienundeine Rollback-Strategie sollten aber gemeinsam mit dem Technik-Team(siehe Kapitel 4.2) festgelegt wer- den,sodassdieIPv6-Migrationder„problembehafteten“CIszukeinenStörungenimIT-BetriebderBe- hördeführt.

UnzureichendeRessourcen(b) können dazu führen, dasssichPlanungsprämissen ändernunddievorher ausgearbeiteteMigrationsplanungauchmit(agilen)Anpassungennichtumgesetztwerdenkann:

• GeplanteHaushaltsmittelfürErsatzbeschaffungenkönnennichtbewilligtwerden.Wirdindergroben Ist-Aufnahmefestgestellt,dassdieIPv6-FähigkeitfüreinigeCIsnichtgegebenist,kanngeprüftwerden, ob eine Ersatzbeschaffung durchgeführt werden soll. Dies kann der Fall sein, wenn die eingesetzten KonfigurationselementebereitssehrlangeimBetriebsindunddurcheineneueProduktgenerationer- setztwerdensollen.GleichfallskanneineErsatzbeschaffungsinnvollsein,wenneinKonfigurationsele- mentinnerhalbeinesInkrementseinesowichtigeKomponentedarstellt,dassnurmitdiesemCIeine IPv6-Migration des Inkrements stattfindenkann. In Vorbereitung aufeine Ersatzbeschaffung werden zuerwartendeKostenkalkuliert,inderzuerstellendenWiBeberücksichtigtundimHaushaltbeantragt. WerdendieHaushaltsmittelnichtbewilligt,kanninderRegeldieErsatzbeschaffungnichtdurchgeführt werden.IndiesemFallkanneserforderlichwerden, dasVorgehen nachdenKeimzellen-Migrationen für einige Inkremente umzustellen und Schritt für Schritt vorzugehen. Zum einen kann dadurch Zeit gewonnen werden, bis die Haushaltsmittel bewilligt werden, da mit diesem schrittweisen Vorgehen sichdieMigrationszeiträumeverlängern.ZumanderenkönnenAlternativenzurgeplantenIPv6-Migra- tiondetailliertergeprüftwerden. • DieIPv6-MigrationseinzelprojektesollenparallelzudenVorbereitungen(Welle3und4)oderauchzur Durchführung(Welle1und2)derBKBdurchgeführtwerden.DiesbelastetdieMitarbeitendeninden IT-ReferatenundAbteilungenderBehördenundOrganisationendesBundeszusätzlich.Engpässekön- nenentstehen,wenndieTeamsnochweitereAufgaben,wiebspw.dieEinführungeinerneuenAnwen- dung,übernehmenmüssen.AuchKrankheitsausfälleoderunbesetzteStellenindenIT-Referatenkön- nendazuführen,dasskeinausreichendesTeamfürdasMigrationseinzelprojektzurVerfügungsteht. DasempfohleneagileVorgehensmodellermöglichteinerseits,Migrationszeiträumezuentzerren.Zum anderenabererfordertdasVorgehenZeit,umdasWissenundKnow-howzuteilen.Solltenerhebliche Ressourcenengpässe im Team auftreten, kann geprüft werden, ob zunächst eine vollständige Ist-

Version4.1 91

[Seite 92]

IPv6-ProgrammdesBundes

Aufnahmedurchgeführtwird.BasierenddaraufkannderMigrationsplaninÜbereinstimmungmitden zurVerfügungstehendenRessourcenausgearbeitetwerden.

Unerwartete Änderungen der Anforderungen an die IPv6-Migration (c) können auftreten, wenn bspw. mehrKonfigurationselementealsgeplantTeilderBKBwerdensollenundsichdieBehördeinderWelle3 oder 4 befindet. Änderungen können auch eintreten, wenn ein Konfigurationselement, für das z.B. der IPv4-Bestandsschutzentschiedenwurde,kaputtgehtundersetztwerdenmuss.InderRegelbringteinneu gekauftesKonfigurationselementeine IPv6-Fähigkeit mit.IndiesemFallkanneserforderlichwerden,die Keimzellen-MigrationenzuunterbrechenundeineInkrement-Migrationvorzuziehen.

Unabhängigdavon,dassdasempfohlene,agileVorgehenbeibesonderenProjektsituationenaufdenPrüf- standgestelltwird,solltestetsversuchtwerden,soflexibelwiemöglichanIPv6-Migrationenheranzugehen. Das trifft vor allem auf komplexe IT-Landschaften zu. Hier zuerst für einen langen Zeitraum eine Ist-Auf- nahmedurchzuführen,ohneparallelmitdenerstenKeimzellen-Migrationenzubeginnen,erhöhtdieRisi- kenbeiderUmsetzungderIPv6-Migrationsszenarien.

3.4 Wasserfall-Vorgehen

Im Wasserfallmodell werden die einzelnen Schritte in einem Projekt linear der Reihe nach abgearbeitet. JederSchrittbasiertaufdenErgebnissendesvorherigenSchrittes;allegeplantenSchritteineinemProjekt- Vorgangmüssenvollständigabgeschlossensein,bevordernächsteSchrittineinemneuenProjekt-Vorgang gestartetwird.JedemSchrittwerdeneindefinierterStartzeitpunktundeinedefinierteDauerzugewiesen.

InderSoftwareentwicklungwerden,diesemModellfolgend,zunächstdieAnforderungenerhobenundspe- zifiziert.NachfolgendwirdeinRealisierungsentwurferstelltundfreigegebenoderabgenommen,aufdessen Basis dann die Entwicklung der Software stattfindet. Sind die geplanten Fertigstellungsmeilensteine der Softwareentwicklungerreicht,wirdgetestetundaufBasisderTestseineFreigabeoderAbnahmederSoft- wareerteilt.DieSoftwarewirdnachfolgendinBetriebgenommenundgewartetEineVerzögerungineinem derSchrittekannzuVerzögerungenimgesamtenProjektführen,wenndiegeplantenProjektschrittesich aufdemkritischenPfaddesProjektsbefinden.

DasWasserfallmodellisteinerprobtesundheutenocheingesetztesModellderSoftwareentwicklung,wes- wegendieAnwendungfüreineIPv6-Migrationgeprüftwurde.MitBezugaufIPv6-Migrationenbestehtder größteSchwachpunktdesWasserfallmodellsimstriktsequenziellenVorgehenindenProjektschrittenund -phasen. Angewendet auf ein Migrationseinzelprojekt würde zunächst die Phase der Ist-Aufnahme kom- plettdurchlaufenwerden.EntwederimZugederIst-AufnahmeoderamEndedieserPhasewürdedieIPv6- FähigkeitdererhobenenKonfigurationselementefestgestelltundeinMigrationsplanfüralleerhobenenCIs entworfen,derbspw.„Core-to-edge“alsMigrationspfaddefiniert.Dieserwirddannvonentsprechenden GremienindenMigrationseinzelprojektenfreigegebenoderabgenommen.AufBasisdieserFreigabeoder AbnahmeerfolgtdieIPv6-Migration–SchrittfürSchritt,vonKonfigurationselementzuKonfigurationsele- ment.TestsfindenalsletztePhaseineinemMigrationseinzelprojektstatt.

MittlerweilegibtesAnpassungen,diedasModellzuhybridenVorgehensmodellenmititerativenund/oder inkrementellenDurchläufenweiterentwickeln.

Im iterativen Vorgehensmodell wird ein Projektschritt so oft durchlaufen, bis das von den Stakeholdern gewünschteProjektzielerreichtwerdenkann,bevordernächsteProjektschrittbeginnt.InderRegelwird mit jeder Iteration der Funktionsumfang der zu realisierenden Software angereichert. Damit lassen sich ÄnderungendurchgeänderteRahmenbedingungenzeitnahundeinfacherindeneinzelnenProjektschritten berücksichtigen.BeidenIPv6-MigrationenkönnendieKeimzellen-MigrationenmiteinemiterativenVorge- henverglichenwerden.AllerdingserfolgtbeidenWiederholungender Keimzellen-MigrationenkeineAn- reicherungdesFunktionsumfangs.VielmehrwirddasErfahrungswissenzuIPv6ineinerBehördeoderOr- ganisationdesBundesmitdemempfohlenen,agilenVorgehensmodellangereichert.

Version4.1 92

[Seite 93]

IPv6-ProgrammdesBundes

BeiminkrementellenVorgehenwerdengroße,komplexeIT-Systemeineinzelne„PaketeanFunktionsum- fang“(Inkremente)zerlegtundbearbeitet.DieRealisierungder„Pakete“wirdnachWasserfalldurchlaufen, d.h.TeilschritteimProjektmüsseninGänzeabgeschlossensein,bevordernächsteSchrittbegonnenwird. ÄnderungenandenRahmenbedingungenoderAnforderungenkönnennichtindenabgeschlossenenInkre- menten, sondern lediglich in den kommenden Inkrement-Entwicklungen berücksichtigt werden. Das V-Modell empfiehlt ein inkrementelles Vorgehensmodell bei der Softwareentwicklung. Im empfohlenen, agilen Vorgehen werden Keimzellen-Migrationen durch Migrationen von Inkrementen abgelöst, wobei auchKeimzellenundInkrementeparallelmigriertwerdenkönnen.UnterInkrementenwerdenimMigrati- onsleitfaden Konfigurationselemente verstanden, die durch Schnittstellen miteinander verbunden sind. HierfolgtderLeitfadendemGrundverständnisdesinkrementellenVorgehens.ImUnterschiedzumklassi- schen, inkrementellen Vorgehen der Softwareentwicklung können Änderungen am Zuschnitt der Inkre- menteundandengeplantenMigrationsschrittenimagilenMigrationsvorgehenumgesetztwerden,wenn bspw.Keimzellen-MigrationenzuneuenErkenntnissengeführthaben.

DasiterativeunddasinkrementelleVorgehenschließensichnichtgegenseitigaus,sondernkönneninei- nemProjektauchgleichzeitigeingesetztwerden.

ImArbeitspaket„Inbetriebnahme“desMigrationsleitfadenssolleneinzelneProjektschrittefürdiedefinier- tenMigrations-Inkrementenstrukturiertundnacheinanderdurchlaufenwerden.MitBezugaufInbetrieb- nahmeninWartungsfensternsollendiegeübtenundbewährtenWartungsprozesseineinerBehördeden VorrangvormöglichenIPv6-Besonderheitenhaben.

DasV-ModellXTBundVersion2.429kenntMigrationsprojektefürSoftware.„AG/AN-Projekte“dienennicht ausschließlichderNeuentwicklungeinerSoftware,sondernbeinhaltenauchMigrationenvonAltsystemen. Dementsprechend bringt das V-Modell XT Bund Version 2.4 auch entsprechende Dokumententemplates mitSchwerpunktaufMigration,wiedas„Migrationskonzept“,mit,derenVerwendunginnerhalbeinesMig- rationseinzelprojektes geprüft werden kann. Auchweitere Templates, wie „Prüfprotokolle“ oder „Altsys- temanalyse“könnenaufihreWiederverwendungineinemMigrationseinzelprojektgeprüftwerden.DasV- Modell XT Bund kennt dabei auch eine stufenweise Migration eines Altsystems. Beachtet werden muss dabei,dassdasV-ModellXTBunddenSchwerpunktaufSoftwarelegt.Arbeitsschritte,dieHardwareanbe- treffen,sindzumZweckederRealisierungunddesBetriebsvonSoftwarebeschrieben.

DasWasserfallmodellundauchdasV-ModellXTBundsindbewährteVorgehensmo- dellederBundesverwaltung,dieauchgegenwärtignochoftzumEinsatzkommen. SollteeineBehördeoderOrganisationeinenindividuellenProjektleitfadenhaben,der aufdiesenVorgehensmodellenbasiert,dannsolltedieserLeitfadenauchbeiderPla- nungeinesIPv6-MigrationseinzelprojekteszurAnwendungkommen.InAbänderung dieserindividuellenProjektleitfädensollteaufdasKeimzellen-Vorgehenallerdings Tippsfür nichtverzichtetwerden,dadiesessenziellfürdenErfolgdesMigrationsprojektsist. diePraxis: DasKeimzellen-VorgehenkannauchineinemProof-of-ConceptodereinemPiloten umgesetztwerden,bevordaseigentlicheMigrationseinzelprojektbeginnt.

DaauchbeidenInkrement-Migrationen„Überraschungen“möglichsind,bspw.im ErgebniseinerAbstimmungmitHerstellern,solltenWiederholungenvonProjekt- schrittenaufBasisneuerErkenntnisseeingeplantwerden.

29https://www.cio.bund.de/Webs/CIO/DE/digitaler-wandel/Achitekturen_und_Standards/V_modell_xt/v_mo- dell_xt-node.html;zuletztaufgerufenam11.11.2025

Version4.1 93

[Seite 94]

IPv6-ProgrammdesBundes

4 Organisatorische Rahmenbedingungen

DieUmstellungaufIPv6istmehralsnureintechnischerProzess.SieisteinetransformativeVeränderung, dieaucheineAnpassungvonorganisatorischenStrukturenineinerBehördeundOrganisationdesBundes erfordert.HierbeispielteineRolle,wiegutdiebeteiligtenMitarbeitendenineinerBehördezusammenar- beiten,wiegutsiekommunizierenundwieeffektivsiedieanstehendenAufgabenbewältigen.DiesesKapi- telkonzentriertsichaufdieorganisatorischenRahmenbedingungen,diefüreineerfolgreicheMigrationauf IPv6erforderlichsind.

InÜbereinstimmungmitdemindiesemMigrationsleitfadenempfohlenen„Keimzellen-Vorgehen“solldie ProjektorganisationfüreinMigrationseinzelprojektsukzessiveaufgebautwerden –auchfürdieseorgani- satorischeDimensiongibteseine„Keimzelle“.

4.1 Projektsponsor

BevordasMigrationseinzelprojektstartet,sollteeinProjektsponsorinderLeitungsebenederBehördeiden- tifiziertwerden.IndenBundesministerienkannderProjektsponsoraufEbeneeinerAbteilungsleitung(ggf. Abteilung Z) angesiedelt werden. In den Behörden und Organisationen des Bundes sollte der Pro- jektsponsoraufEbenederBehördenleitung,bspw.PräsidentoderVize-Präsident,benanntwerden.Dieser ProjektsponsorsolldieLeitungeinesMigrationseinzelprojektesdabeiunterstützen,dieerforderlichenRes- sourcen in Form von Haushaltsmitteln und Personal bereitzustellen, weswegen eine Vertretung auf Lei- tungsebeneerforderlichist.DerProjektsponsorspieltaucheinewichtigeRolleinderKommunikationmit denMitarbeitendenderBehörde–hierwirkteralsglaubwürdiges„Testimonial“,dersichmitanderenBe- hörden,demRessortansprechpartnerunddemIPv6-ProgrammvernetztundfürdenNutzenderbehördli- chenIPv6-Migrationsteht.

DieseRolleistvergleichbarmitdem„BusinessOwner“inSAFe30.InAnlehnunganSAFeistdiewichtigste FragezurIdentifizierungdesBusinessOwners:

AuchdieAnforderung,dassderProjektsponsordabeihelfensoll,dieBemühungenmitanderenAbteilungen undOrganisationenzukoordinieren,undzwarüberOrganisationsgrenzenhinweg,isteinwesentlichesAus- wahlkriteriuminderBehördefürdieseRolle.

DieseKompetenzen(BeseitigungvonHindernissen,übergreifendeKoordination)sindwichtigereAuswahl- kriterienfürdenProjektsponsoralsdieZuordnungzueinerEbeneimbehördlichenOrganigramm.

4.2 Technik-Team

Die„organisatorischeKeimzelle“fürdasProjektteambildetdasTechnik-Team.DasTechnik-Teamsorgtfür eineeffektiveUmsetzungdestechnischenWandelsundgewährleistet,dassdieMigrationfachgerechtund rechtzeitig durchgeführt wird. Dieses Technik-Team kann mit dem „Solution Train“31aus SAFe verglichen werden. Für die Migrationseinzelprojekte ist dieser Vergleich sinnvoll, da Teil eines Teams auch Herstel- ler/Lieferanten(„Supplier“)seinsollten.

30https://framework.scaledagile.com/business-owners/;zuletztaufgerufenam11.11.2025 31https://framework.scaledagile.com/solution-train/;zuletztaufgerufenam11.11.2025

Version4.1 94

[Seite 95]

IPv6-ProgrammdesBundes

DiepraktischenErfahrungenmitIPv6-Migrationenzeigen,dasstrotzguterVorberei- tung,inkl.desStudiumsdereinschlägigenRFCs(imIPv6-WikiaufderKommunikati- ons-undInteraktionsplattformauffindbar),FragenbeiderUmstellungeinzelnerKon- Tippsfür figurationselementeentstehen,dienurdieHerstellerbzw.Lieferantenbeantworten diePraxis: können.

Im „Technik-Team“ kommen verschiedene Experten zusammen, darunter Netzwerktechniker, IT-Sicher- heitsberater,IT-Administratoren,ExpertenfürVirtualisierung,Datenbank-undAnwendungsmanagersowie Entwickler.IhreunterschiedlichenFachkenntnissesorgendafür,dassalletechnischenAspektederMigra- tionberücksichtigtundeffektivumgesetztwerden.ZudenHauptaufgabendesTechnik-Teamsgehörendie DurchführungdergrobenIst-Aufnahme,dieEvaluierungderbestehendenIT-Infrastruktur,dieErarbeitung einesMigrationsplansunddieDurchführungvonKeimzellen-MigrationenoderMigrationeneinzelnerEle- mentederIT.ZudemstelltdasTechnik-TeamdieerforderlichenLeitfädenundTools(ggf.gemeinsammit demQuerschnittsteam,sieheunten)zuranschließendenÜberwachungdesneuenSystemsbereit.Dabeiist eswichtig,dassdietechnischeEinheitSicherheitsaspekteberücksichtigtundbeiBedarfPenetrationstests undSicherheitschecksdurchführt,umdieStabilitätundSicherheitdesneuenSystemszugewährleisten.

4.3 Cross-funktionaleSub-Teams

MitfortschreitenderMigrationreichertsichdasTechnik-TeamdurchweitereMitarbeitende/Expertenaus derBehördeanundbildetSub-TeamsinnerhalbeinerBehördeoderOrganisation,dieeineIPv6-Migration durchführt.

Hinweis:Hiersindkeineüberbehördlichencross-funktionalenTeamsgemeint.

DieseSub-Teamskönnenmitden„AgileReleaseTrains“(ART)innerhalbeines„SolutionTrains“nachSAFe verglichenwerden.SukzessiveentstehtüberdieZeitsodasgesamteTeameinesMigrationseinzelprojektes. DieARTliefernnachSAFeLösungen.IneinembehördlichenMigrationseinzelprojektkanneinSub-Teamder IPv6-Migration einer Keimzelle und deren nachfolgenden Wiederholungen zugeordnet werden. Weitere Sub-TeamsübernehmendieIPv6-MigrationenderInkrementeanIT-Infrastruktur,dienichtüberKeimzellen migriertwerden,undinderRegelmehrereKonfigurationselementeumfassen.EntscheidendfürdenErfolg der Sub-Teams ist, dass diese nicht nur die IT-Referate anbetreffen, sondern weitere Mitarbeitende aus anderenReferatenundAbteilungenhinzugezogenwerden.DieBedeutungdiesercross-funktionalenSub- TeamsfürdenErfolgvonMigrationseinzelprojektenisterheblich,weildieIPv6-Migrationen aufeinesich imBetriebbefindliche,komplexeBehörden-Gesamtarchitekturtreffen.

EinegesamthafteMigrationderbehördlichenITgelingtnur,wenndieZusammenar- beitüberdiegeschäftlicheEbene,dieDiensteEbene,dietechnischeEbeneunddie Tippsfür InformationsebenesowiemitdenVerantwortlichenfürInformationssicherheit,Da- diePraxis: tenschutzundGeheimschutzhinwegorganisiertwird.

Diesecross-funktionalenSub-TeamssindinÜbereinstimmungmitdemindiesemMigrationsleitfadenemp- fohlenen„Keimzellen-Vorgehen“einsinnvollesElementineinerProjektorganisationeinesMigrationsein- zelprojektes.

Als eine „Spezialisierung“ innerhalb der Sub-Teams sollte ein weiteres SAFe-Element in die Organisation einesMigrationseinzelprojektsaufgenommenwerden–dassogenannte„EnablingTeam“32oderübersetzt „Querschnittsteam“. Nach SAFe soll dieses Team den anderen Teams Tools, Dienstleistungen und

32Definitiondes„EnablingTeams“isteingebettetindenArtikelzum„SolutionTrain“,https://framework.scale- dagile.com/solution-train/;zuletztaufgerufenam11.11.2025

Version4.1 95

[Seite 96]

IPv6-ProgrammdesBundes

kurzfristigesFachwissenzurVerfügungstellen.UnterDienstleistungensindu.a.auchdieKommunikations- maßnahmenzufassen,dieerforderlichsind,umdieMitarbeitereinzubeziehen.ImMigrationseinzelprojekt istessinnvoll,einsolchesQuerschnittsteamzuetablieren,welchesu.a.dievomIPv6-Programmbereitge- stellteKommunikations-undInteraktionsplattform,inkl.IPv6-Wiki,nutzt,umkurzfristigFachwissenbereit- zustellen,undsichaktivamErfahrungsaustauschmitanderenBehörden,bspw.imForum,indenCommu- nitiesofPractice,v.a.auchimBereichderTestlabore,beteiligt.AucheinVerantwortlicherfürKommuni- kationsollteindiesesTeamaufgenommenwerden.

Zudemistessinnvoll,überdiesecross-funktionalenTeamsauchdiebehördlichenIT-Sicherheits-undDa- tenschutzbeauftragten in das Migrationseinzelprojekt einzubeziehen. Hier kann die Zusammenarbeit mit demVerantwortlichenfürKommunikationhilfreichsein,dadieserimBereichderMaßnahmenfürinterne KommunikationregelmäßigeAbstimmungenmitdenBeauftragtenvorsieht.

InAnlehnunganSAFekönnendiefolgendenSub-Teamsineinem„SolutionTrain“füreinMigrationseinzel- projektgebundenwerden:

Abbildung10:„SolutionTrain“füreinbehördlichesMigrationsprojekt

4.4 Migrationsprojektleitung

DemTechnik-TeamsowiedensukzessivegebildetenSub-TeamsstehtdieMigrationsprojektleitung(MPL) vor.ImControllingdesIPv6-ProgrammsistfürdenMPLeineeigeneRollevorgesehen.DerMPLkannmit dem „Solution Train Engineer“33(STE) nach SAFe verglichen werden. Dieser STE ist nach SAFe ein Coach, der Solution-Train-Events und -Prozesse moderiert, die Arbeit von ARTs und Lieferanten koordiniert und ARTs bei der Wertschöpfung unterstützt. In die Welt der Migrationseinzelprojekte übersetzt, koordiniert der MPL die Arbeit des Technik-Teams sowie der Sub-Teams, moderiert die Zusammenarbeit zwischen Technik-TeamundSub-Teams,sorgtdafür,dassdiePlanungenallerTeamszusammenpassen,arbeitetmit den Herstellern/Lieferanten zusammen und verantwortet, dass das Migrationseinzelprojekt für die Be- hördeoderOrganisationdesBundeseinenNutzenerzeugt.DerMPListebenfallsAnsprechpersonfürdie behördlicheHausleitung.DerMPLkanndurcheinenIPv6-Coach,dendasIPv6-ProgrammbeiBedarfbereit- stellt,unterstütztwerden.

In komplexen Migrationsszenarienkann essinnvoll sein,externe Berater hinzuzuziehen, die über spezifi- scheErfahrungenmitIPv6-Migrationenverfügen.DieexternenBeraterkönnensowohldemTechnik-Team alsauchdenSub-Teamszugeordnetwerden.

33https://framework.scaledagile.com/solution-train-engineer/;zuletztaufgerufenam11.11.2025

Version4.1 96

[Seite 97]

IPv6-ProgrammdesBundes

4.5 AnsprechpersonenfürorganisatorischeThemenderIPv6-Migration

ParallelzurtechnischenUmsetzungderMigrationistesvonentscheidenderBedeutung,auchdieorganisa- torischenAuswirkungenderUmstellungaufIPv6zuberücksichtigen.

Im„SolutionTrain“vonSAFekönnendieseAufgabenmit„Connectingwiththecustomer“34verglichenwer- den–wenn„Kunden“hiermit„Mitarbeitenden“derBehördenundOrganisationendesBundesgleichge- setztwerden,daessichbeiderIPv6-MigrationumProjektehandelt,dieBehörden-internenNutzenentfal- ten sollen.Dort wird dazu ausgeführt (© Scaled Agile, Inc., übersetzt): Feedback ist entscheidendfür die Wertschöpfung.AbgeleitetausSAFe,sollendieseAnsprechpersonenfürorganisatorischeAufgabenkonti- nuierlichFeedbackvondenMitarbeitenden,resp.denvonderMigrationbetroffenenReferatenundAbtei- lungen, einholen und kontinuierlich Gespräche und Abstimmungsformate zwischen den Teams, die die IPv6-Migration verantworten, und den Mitarbeitenden, Referats- und Abteilungsleitungen durchführen. Dies dient dazu, organisatorische Auswirkungen der Migration zu identifizieren underforderliche Anpas- sungengemeinsammitdenvonderIPv6-Migrationbetroffenenzudefinierenundumzusetzen.Zielistes, dassEntscheidungen,diedieArbeitsweltderMitarbeitendenbetreffen,auchdurchdiesemitbestimmtwer- den können (dezentralisierte Entscheidungsfindung). Lieferanten sind bei Bedarf einzubeziehen. Zudem können (wenige) Anpassungen inArbeitsabläufenimZuge der IPv6-Migrationerforderlichwerden.Diese müssenidentifiziertundindiebehördlichenGeschäftsprozessmodelleund-dokumentationeneingepflegt werden.Esistnichtdavonauszugehen,dassinfolgedieserAnpassungenSchulungenvonMitarbeiterner- forderlichwerden.DieskannderFallsein,wennsichdieBehördeimZugederIPv6-Migrationentschließt, eineAnwendung,dienichtIPv6-fähigist,nicht indenIPv4-Bestandsschutz aufzunehmen unddiese statt- dessenneuzubeschaffenoderneurealisierenzulassen.ZudemkönnendieseAnsprechpersonendasTech- nik-Teamdabeiunterstützen,erforderlicheIPv6-SchulungenfürMitarbeitendederIToderweitereInteres- siertezuorganisieren.

Einweiterer sehr wichtiger,organisatorischer Aspekt besteht darin, dassdie Auswirkungen der behördli- chenIPv6-MigrationinallerelevantenEinkaufs-undBeschaffungsverträgeaufgenommenwerden.InÜber- einstimmungmitdemindividuellenMigrationsvorgehenderBehördemüssendieverantwortlichenStellen darüber informiert werden, dass künftig ausschließlich Konfigurationselemente beschafft werden sollen, dieeineIPv6-Fähigkeitaufweisen(Dual-StackoderIPv6-Only).EntsprechendeAnforderungenmüssenge- meinsammitdemTechnik-Teamausgearbeitetwerden.

DurchdieZusammenarbeitdesTechnik-TeamsmitdiesenAnsprechpersoneninder BehördekanneineganzheitlicheMigrationaufIPv6erreichtwerden,diesowohldie Tippsfür technischenalsauchdieorganisatorischenAspektederUmstellungberücksichtigt diePraxis: undvorallemdieMitarbeitendenkontinuierlicheinbezieht.

DieseAufgabenhinsichtlichderorganisatorischenAuswirkungensollderProjektsponsorkoordinieren.Die AnsprechpersonenfürorganisatorischeThemenderIPv6-MigrationsolltenausdenmitOrganisations-und KommunikationsthemenbefasstenReferatenoderTeamseinerBehördeoderOrganisationdesBundesge- wonnenwerden.DerProjektsponsor(sieheKapitel3.1)stimmtsichregelmäßigmitdenAnsprechpersonen abundkoordiniertdieZusammenarbeitzwischendenAnsprechpersonenfürorganisatorischeThemenund demMPL.

34„Connectingwiththecustomer“istbeschriebenimArtikelzum„SolutionTrain“,https://framework.scale- dagile.com/solution-train/;zuletztaufgerufenam11.11.2025

Version4.1 97

[Seite 98]

IPv6-ProgrammdesBundes

4.6 ExemplarischesProjektorganigrammfüreinMigrationseinzelprojekt

InÜbereinstimmungmitdemindiesemMigrationsleitfadenvorgeschlagenen„Keimzellen-Vorgehen“und denbeschriebenenorganisatorischenElementenderZusammenarbeitinAnlehnunganSAFeergibtsichfür ein Migrationseinzelprojekt folgendes beispielhaftes Organigramm. Die Abbildung verdeutlicht ebenfalls diezuvorbeschriebenenmöglichenVerbindungenzueinzelnenUnterstützungsmaßnahmendesIPv6-Pro- grammssowiedemweiterenProjektumfeld.

Abbildung11:ExemplarischesOrganigrammeinesMigrationseinzelprojekts

Version4.1 98

[Seite 99]

[Seite 99: gedrehter Text]

[Seite 100]

[Seite 100: gedrehter Text]

[Seite 101]

[Seite 101: gedrehter Text]

[Seite 102]

IPv6-ProgrammdesBundes

5 Exkurs: Adressvergabeschema Bund 2.0 und Grundlagen der Verwaltung

von IPv6-Präfixen

EineIPv6-Adressebestehtaus128Bits,vondenendieersten64Bitsdierouting-relevantenInformationen enthalten.Den Behörden und Organisationen des Bundes steht einAdressbereichder Größe /28 für das RoutingindenVerwaltungsnetzen(de.gov)undeinweitererAdressbereichderGröße/28fürdasRouting insInternet(de.non-gov)zurVerfügung,sieheTabelle20.DiesebeidenBereichekönnenvondenBehörden undOrganisationendesBundes,welchenichtdurcheineandereSub-LIRmitAdressenversorgtwerden,bei derSub-LIRBundbeantragtwerden.Insgesamtsindsomit36Bitszubelegen.

Tabelle20:Sub-LIRBundIPv6-Adressbereiche

5.1 Vergabeschema

DasIPv6-VergabeschemasiehtproBehördeundOrganisationdesBundesmindestenseinPräfixderGröße /44vor.DieDifferenzzwischendemPräfix/28unddemPräfix/44entspricht16Bitunddamitergebensich 65.536PräfixederGröße/44fürdieVersorgungderBehördenundOrganisationendesBundes.

BehördenundOrganisationdesBundeserhaltenimmerein/48-PräfixalskleinstesmöglichesIPv6-Präfix. Damit folgt das IPv6-Vergabeschema den Empfehlungen der RIPE, insb. denen für die Betriebspraxis der Betreiber.35FürdiebessereAggregationundeinenmöglichenMehrbedarfbeidenBehördenundOrgani- sationendesBundeswirdmindestensein/44-PräfixbeiderErstbeantragungeinerBehördeundOrganisa- tiondesBundesreserviert.Darauskönnenbiszu16PräfixederGröße/48vergebenwerden.Die Tabelle 21zeigtanhandderPräfix-GrößedieAnzahlderzurVerfügungstehendenAdressen.

Tabelle21:ÜbersichtüberdieAnzahlvon/48-und/64-NetzwerkeningroßenPräfixen

BeieinerAuslastungvon80%desfürdieBehördeoderOrganisationzugewiesenen/44-Präfixes(12von16 /48-Präfixen) wird automatisch ein weiteres /44-Präfix reserviert. In der Tabelle 22 werden die initialen Zuweisungenvon/44-Präfixenaufgeführt.

35Siehe RIPE NCC, RIPE-690, Best Current Operational Practice for Operators: IPv6 prefix assignment for end- users-persistentvsnon-persistent,andwhatsizetochoose,insb.Kap.4.2.2 „/48forbusinesscustomersand /56for residentialcustomers“ sowienachfolgendeKapitel; https://www.ripe.net/publications/docs/ripe-690/; zuletztaufgerufenam11.11.2025

Version4.1 102

[Seite 103]

IPv6-ProgrammdesBundes

Tabelle22:GrenzenfürgrößerePräfixe

5.2 Aggregationsbereiche

DasindiesemKapitelgezeigteAdressierungsschemateiltdiezurVerfügungstehenden36BitsinzweiAg- gregationsbereiche. Der erste Aggregationsbereich beginnt beim 29. Bit (/28) und reicht bis zum 36. Bit (/36).DieDifferenzentspricht8Bitundermöglichen256PräfixeimerstenBereich.DerzweiteAggregati- onsbereichbeginntbeim37.Bitundreichtbiszum48.Bit.DieDifferenzentspricht12Bitundermöglicht 256 /44-Präfixe oder4096 /48-Präfixe. Diese Aufteilunggilt sowohlfür dende.gov-alsauchdende.non- gov-Bereich. Die Größe des Aggregationsbereichs 1 wurde so gewählt, dass eine Zuweisung eines aggre- gierbarenIPv6-PräfixesderGröße/36möglichist,sofernderBedarfdurchdieSub-LIRBundbestätigtwird.

Abbildung13:Grundstrukturder/28-Adressbereiche

DieVergabeandieBehördenundOrganisationendesBundeserfolgtimmerausdemAggregationsbereich 2,sieheTabelle23.

Tabelle23:Vergabeder/44-und/48-PräfixefürBehördenmitnormalemAdressbedarf

Version4.1 103

[Seite 104]

IPv6-ProgrammdesBundes

DabeisinddieBits1–28(/28),29–36(/36),37–48(/48)sowie65–128(/64)immergemäßderGrundstruktur ausTabelle24angeordnet.DieGrundabschnittederSchematalassensichwiefolgtdefinieren:

Tabelle24:GrundabschnittederAdressbereichsschemata

5.3 BeantragungvonAdressen

FürdieBeantragungvonPräfixenbeiderSub-LIRBundstehteinAntragsformularmitHilfetextenzurVer- fügung.NebendenStammdatenderBehördeoderOrganisationdesBundeswerdendarinderinitialeBe- darf, Erweiterungen, Änderungen andenStammdaten,Zusammenlegungen vonBehördenundLöschung vonIPv6-Präfixenbeauftragt.DasFormularberücksichtigtmehrereNetzanschlüsse.Eskönnen/48-,/44-, /40-oder/36-Präfixebeantragtwerden.DabeimusseinBedarfgrößerals/48immerbegründetwerden.

In der Beantragung wird zwischen dem Routing in denVerwaltungsnetzen (de.gov) und dem Routing ins Internet(de.non-gov)unterschieden.

Derde.gov-BereichbeziehtsichaufPräfixe,dieniemalsimöffentlichenInternetgeroutetwerdendürfen. EineEnde-zu-Ende-Kommunikationisthiernichtmöglich.UmindasInternetzugelangen,könnenProxy- Servergenutztwerden,diehinterihrerIPv6-Adressediede.gov-PräfixederBehördeoderOrganisationdes Bundesverschleiern.DieverschiedenenNetzanschlüssesindinderTabelle25beschrieben.

Tabelle25:Netzanschlussde.gov

Beim de.non-gov-Bereich werden IPv6-Präfixe mit der Möglichkeit zur Ende-zu-Ende-Kommunikation ge- nutzt.Dieseswirdbenötigt,umDienste,ServicesundVerfahrenausdemöffentlichenInternetnutzenzu

36https://datatracker.ietf.org/doc/html/rfc4291;Absatz2.5.1;zuletztaufgerufenam11.11.2025

Version4.1 104

[Seite 105]

IPv6-ProgrammdesBundes

können. Die IPv6-Präfixe werden dafür weltweit im Internet annonciert. Nach den Vorgaben des RIPE37 müssen hierzuInformationenzurBehörde oderOrganisationdesBundesineinerzentralenweltzweiter- reichbarenDatenbank,fürEuropadieRIPEDB,hinterlegtwerden.Hieristesaußerdemnotwendig,dievon der Behörde oder OrganisationdesBundesgenutzte AS-Nummer für dasPräfixmitzuteilen.Sollten noch keineAS-Nummervorhandensein,kanndieSub-LIRBunddiesezurVerfügungstellen.

Tabelle26:Netzanschlussde.non-gov

DasAntragsformulardientauchdazu,eineHistoriederBeantragungenundZuweisungenzuerstellenund diesezudokumentieren.

5.4 Grundlagen der Verwaltung von IPv6-Präfixen einer Behörde oder Organisation des Bundes

EineBehördeoderOrganisationdesBundeserhältIPv6-AdressennachihremBedarf.DieAdressenstam- menentwedervonderSub-LIRBundoderwerdenvomProviderbezogen.Jenachdem,obdieAdressenfür interne Verbindungen(Bereich: de.gov fürNdB oder Ressortnetze) oder für die Kommunikationmit dem Internet(Bereich:de.non-gov)bestimmtsind,werdenAdressenausdementsprechendenBereichverwen- det.

Nach der Zuweisung verfügt die Behörde oder Organisation des Bundes über mindestens ein IPv6- Adresspräfix.Esgiltnun,diesenAdressbereichzuorganisierenundeinenAdressplanaufzustellen.

EineBehördeoderOrganisationdesBundesbewirtschaftet denAdressraum,densieerhalten hat,eigen- ständig. Die Verteilung der Präfixe muss geplant und die Verwendung dokumentiert werden. Um einen stabilenBetriebdesNetzwerkszugewährleisten,isteinevollständigeundaktuelleDokumentationohnehin vongroßerBedeutung–somitkönnenhiergleichzweiwichtigeAufgabenmiteinergutstrukturiertenPla- nungerledigtwerden.

37SieheRIPENCC,RIPE-738,IPv6AddressAllocationandAssignmentPolicy,Kap.3.3, https://www.ripe.net/publications/docs/ripe-738/;zuletztaufgerufenam11.11.2025

Version4.1 105

[Seite 106]

IPv6-ProgrammdesBundes

Routerverlangsamen.DemeffizientenRoutingsolltedarumbeiderPlanungvon IPv6-NetzwerkenoberstePrioritäteingeräumtwerden.

FürdasIPv6-ProtokollgiltderGrundsatzdeseffizientenRoutings.DieserwurdeauchbeideraktuellenVer- sion des Konzepts zur Adressvergabe an die Behörden und Organisationen des Bundes („Adressvergabe- schemaBund2.0“)berücksichtigt(siehevorigesKapitel).Esistalsologisch,daseffizienteRoutingbeider VerwaltungderAdresseninnerhalbderOrganisationenebenfallszuverfolgen.

UntereinerLiegenschaftwirdimFolgendeneinbebautesoderunbebautesGrundstück,einGebäude,An- wesenodereineabgegrenzteAnlageverstanden.DerBegriffStandortlässtsichimGegensatzdazualsLo- kation im Sinne einer Ortsbezeichnung verstehen. Der Begriff „Netzübergang“ bezeichnet den Übergang eines lokalen Netzwerks in die Netze des Bundes (NdB) mit einem behördlichen Netzwerk-Terminator (BNT).VerallgemeinertwirdvoneinerAnbindungdeslokalenNetzesaneinWeitverkehrsnetzgesprochen.

Grundsatzisthier:JedeLiegenschaftmiteinereigenenAnbindungerhälteinepassendeAnzahlvonPräfixen zugewiesen.

• EineAnbindungistderÜbergangdeslokalenNetzwerkseinerLiegenschaftaneinWeitverkehrsnetz. • DiepassendeAnzahlderPräfixeergibtsichausdemBedarfderLiegenschaft.

DievergebenenPräfixeproLiegenschaft(Anschluss)solltensichan4-Bit-Grenzenorientieren(auchNibble genannt – ein Nibble entspricht einem halben Byte). Dies verbessert die Lesbarkeit der Adressen für die AdministratorenimBetrieb.

SichanNibble-Grenzenzuorientierenheißtvereinfacht,dassimmernurin4-Bit- SchrittenPräfixevergebenwerden.DiesbedeutetinunseremBeispiel,dassineinem zugewiesenen/48-PräfixbeiEinhaltungderNibble-Grenzentheoretischfolgende PräfixezurUnterteilungdesgroßenBereichesverwendetwerdenkönnen:

Präfix Anzahlder/64-Netzwerke

Tippsfür /56 256 diePraxis: /52 4.096

/48 65.536

/44 1.048.576

Das kleinste vergebene Netzwerk orientiert sich an den Empfehlungen des Dokuments RIPE-69038 zur VergabeanEndkundenundentsprichtsomiteinem/56-Präfix.DiesermöglichtdieNutzungvonbiszu256 NetzenderGröße/64fürdieHostseinesStandorts.

Sollte dieseAnzahlfürdieLiegenschaft nichtausreichen, werden größerePräfixevergeben.Diese sollten sich wiederum an den Nibble-Grenzen orientieren. Das nächstgrößere Präfix ist ein /52-Netz. An einem solchenStandortoderRechenzentrumsindalso4.096Netzwerkemöglich.DieSub-LIRBundvergibtStan- dardpräfixederGröße/48,sodassprinzipiell16LiegenschaftenderGröße/52oder256Liegenschaftender Größe/56versorgtwerdenkönnen.

Präfixe werden mit einer Reserve zwischen 20 und 30% vergeben. Auseinem Präfixblock der Größe /52 werdenLiegenschaftenmit/56-Präfixenversorgt.Vonden16möglichenPräfixenimBlockwerdenmaximal

38Sieheauchunter:https://www.ripe.net/publications/docs/ripe-690/;zuletztaufgerufenam11.11.2025

Version4.1 106

[Seite 107]

IPv6-ProgrammdesBundes

12vergeben,sodasseineReservebleibt,wenneineneueLiegenschafthinzukommt.BeiBedarfkanndann auch ein weiteres Präfix bei der Sub-LIR Bund beantragt werden. Solche Präfixe werden also für größere Standorte,RechenzentrenoderNetzwerkegenutzt,diefüreinegroßeAnzahlvonFachverfahrenoderzu- künftigeArchitekturensegmentiertwerden.

5.4.1 TypenvonNetzwerkanschlüssen

ImFeinkonzeptzumAdressvergabeschemaBund2.0sindzweiTypenvonNetzwerkübergängenbeschrie- ben,diejeweilseineigenesPräfixerhaltenkönnen:ZumeinengibteseinenÜberganginsInternet(„Routing insInternet“),derindiesemKontextalsde.non-govbezeichnetwird.ZumanderengibteseinenNetzwer- küberganginsVerwaltungsnetz(NdB,„RoutingindenVerwaltungsnetzen“),deralsde.govbezeichnetwird. InnerhalbeinerBehördeoderOrganisationdesBundeskommteinweitererAnschlusshinzu,wennsieein eigenesNetzwerkbetreibt,dasdieLiegenschaftenverbindet(„RoutingzwischendenLiegenschaften“).

EinNetzwerkanschlusskannverschiedeneArtenvonNetzwerkenverbinden.Sielassensichwiefolgtklas- sifizieren:

• Routing zwischen den Liegenschaften: Interne Netzwerkanschlüsse verbinden Netze einer Behörde oderOrganisationdesBundes.DiessindzumBeispielVerbindungenzwischendenLiegenschaftender eigenenBehördeoderOrganisation.EinBeispielwärehierdieStandortkopplung. • RoutingindenVerwaltungsnetzen:EinNetzwerkübergangandieinternenNetzederBundesverwaltung istebenfallseininternerNetzwerkübergang.ErverbindetdieverschiedenenBehördenundOrganisati- onenuntereinander.NdBoderRessortnetzesindBeispieleeinersolchenDienstleistung. • RoutinginsInternet:AlleVerbindungen anexterneNetze sindgesondertzu betrachten.Dazuzählen alleÜbergängeindasInternetundanandereexterneNetzewiezumBeispieldasDeutscheForschungs- netz(DFN).

PräfixewerdenproNetzwerkanschlussentsprechenddesTyps(intern/extern)vergeben.

5.4.2 VergabeinnerhalbderBehördeoderOrganisationdesBundes

Esistempfehlenswert,die/56-und/52-PräfixeodergrößerePräfixeineinemAbstandvonvierNetzwerken zuvergeben.DiesePraxiserlaubteinWachstumamStandortohneeineaufwendigeNeuvergabeundUm- nummerierungvonPräfixen.EineLiegenschaftmiteinemerhöhtenBedarferhälteinfachdasnächsteNetz- werk,dasfreigehaltenwurde.ImRoutingzumStandortwirdanstattdes/56-Präfixesein/55-Präfixeinge- tragenundderStandortkanndoppeltsovieleNetzeverwenden.

Die Behörde oder Organisation des Bundes sollte einen Adressplan für die Zuweisung der Präfixe an die Liegenschaftenerstellen.DiePlanungderPräfixekannzumBeispielnachdemZeitpunktderEinführungvon IPv6inderLiegenschafterfolgen.

InnerhalbderLiegenschaftkönnendieeinzelnenNetzederGröße/64nachähnlichenKriterienwiebisher vergebenwerden.ÜblicherweisesindNetzwerke nachFunktion(Server,Clients, Telefonie,Sonstiges)ge- trennt.

Version4.1 107

[Seite 108]

IPv6-ProgrammdesBundes

6 Exkurs: Programmeigene IPv6-Testlabore

DieMigrationvonIPv4aufIPv6isteinestrategischeNotwendigkeit,umdieZukunftsfähigkeitderNetzwer- kinfrastruktur der Behörden und Organisationen des Bundes zu gewährleisten. Die Migration birgt aller- dingsauchKomplexitätundpotenzielleFallstricke.DieVersuchung,ÄnderungendirektimLive-Betriebvor- zunehmen,umvermeintlichZeitzusparen,istverständlich–jedochmitpotenziellerheblichenRisikenver- bunden. Unvorhergesehene Kompatibilitätsprobleme mit bestehenden Anwendungen, Firewall-Regeln, Monitoring-SystemenoderDrittanbieterdienstenkönnensowohlinnerhalbderBehördenundOrganisati- onenselbstalsauchbeianBürgerinnenundBürgerngerichteteDienstezuAusfällenoderEinschränkungen führen.GenauhiersetztderBeitragderTestlaboreimRahmenvonTestsan.EinkontrolliertesTestumfeld ermöglichtesdenBehördenundOrganisationendesBundes,potenzielleProblemefrühzeitigzuidentifizie- renundzubeheben,dasMigrations-TeammitdenneuenGegebenheitenvertrautzumachenunddierei- bungsloseFunktionallerKomponentenunterIPv6-Bedingungenzuvalidieren.

FüreineerfolgreicheundmöglichstrisikoarmeIPv6-MigrationstelltdasIPv6-ProgrammdreiTestlaborebe- reit,diefortlaufendandieBedarfederBehördenundOrganisationenangepasstwerden.Dieseermöglichen dasumfassendeTesteneinerVielzahlvonAnwendungsfällenundKonfigurationselementenunterIPv6,um dieFunktionalitätsicherzustellen.Dazugehörenu.a.:

• GrundlegendeKonnektivität:ÜberprüfungderIPv6-Adressierung,RoutingundErreichbarkeit. • System-undAnwendungskompatibilität:SicherstellungderFunktionalitätvongeschäftskritischenAn- wendungen,DienstensowieDNSundNetzwerk-Basisdiensten(z.B.DHCPv6,NTP)unterIPv6. • Netzwerk-Monitoring:AnpassungundVerifizierungderÜberwachungssystemefürIPv6-Netzwerke. • Sicherheit:ValidierungvonIPv6-spezifischenFirewall-RegelnundSchutzmechanismen. • Dual-Stack-Betrieb:PrüfungdernahtlosenKoexistenzvonIPv4undIPv6(fallserforderlich). • Hochverfügbarkeit & Performance:Bewertung von Failover-Mechanismen und Lastverhalten unter IPv6-Bedingungen.

DieTestlaborkoordinationistdabeidiezentraleAnlaufstellefürdieeffizienteNutzungderTestlabore.Sie fungiert alsBindegliedzwischendenBehörden undOrganisationendesBundesunddenTestlaborbetrei- bern.Dabeifallenu.a.folgendeAufgabenindenBereichderTestlaborkoordination:

1. Bereitstellung und Anpassung der Testkapazitäten: Die Koordination stellt sicher, dass die richtigen Testumgebungen zur Verfügung stehen. Wichtig ist hierbei, dass die Erfahrungen der Behörden und OrganisationenindieWeiterentwicklungeinfließen.SolltenwährendderIPv6-TestsneueAnforderun- genoderKompatibilitätsproblemesichtbarwerden,moderiertdieTestlaborkoordinationdenProzess, umdieTestlaboreentsprechendweiterzuentwickeln.SobleibendiesegemäßdemProgrammgrundsatz derNutzerzentrierungaufdieaktuellenHerausforderungenderIPv6-Migrationausgerichtet.

2. KlareAnsprechpartner:MiteinemTestlaborkoordinatorfürdieübergeordneteSteuerungundeinem TestlaborbetreueralsdirektemtechnischenAnsprechpartnerfürFragenzurTestlabornutzunghaben Behörden und Organisationen stets klare Kommunikationswege. Die Testlaborbetreuer unterstützen zudembeitechnischenFragenzurNutzungderTestlaboreinZusammenarbeitmitdenIPv6-Coaches.

3. IndividuelleBegleitungundOnboarding:UmdenStartvonIPv6-Testszuoptimieren,bietetdieTestla- borkoordinationUnterstützungbeiBuchungundEinführungindieNutzungderTestlabore.

4. KontinuierlicheVerbesserungdurchFeedback:FeedbackistentscheidendfürdieAusrichtunganden Nutzenden. Die Testlaborkoordination sammelt aktiv Rückmeldungen im Rahmen der Nutzung der Testlabore. Nur so können die Testlabore kontinuierlich verbessert und an neue Gegebenheiten der IPv6-Migrationangepasstwerden.

Version4.1 108

[Seite 109]

IPv6-ProgrammdesBundes

5. Umfassendes Wissensmanagement und Best Practices: Die Testlaborkoordination stellt zudem im RahmenderKommunikations-undInteraktionsplattformverschiedeneHilfsmittelbereit,umdieNut- zungderTestlaborezuerleichtern.Dazugehörenu.a.:

• EinTestlaborhandbuch,dasalspraktischeNutzungsanleitungdient, • VorlagenfürTestpläneundTestfälle,diedieStrukturierungvonTestserleichtern, • Blog-Beiträge,dieüberneueErkenntnisse,TippsundBestPracticesrundumIPv6-Testsinformie- ren. GrundsätzlichkönnenBehördenundOrganisationendesBundesjedesTestlaborbuchen.VordemHinter- grunddesRadsderMigrationistesjedochempfehlenswert,imvirtuellenTestlaborzubeginnen,umsich aufweiterführendeTestsvorderMigrationvonKeimzellenundInkrementevorzubereiten.

6.1 VirtuellesTestlabor

DiesesbieteteinehochflexibleUmgebungaufBasisvonEVE-NGfürdenAufbaubeliebigerNetzwerktopo- logien. Es ist ideal für erste Schritte und den Erfahrungsaufbau sowie die Vorbereitung auf den Test von KeimzellenundInkrementen.

Abbildung14:BeispielhafteNetzwerkkonfigurationinEVE-NG

UmdiepraktischeAnwendungunsererTestumgebungenzudemonstrieren,betrachtenwireinenbeispiel- haftenVersuchsaufbaueinerklassischenClient-Server-Umgebung.Diesebestehtauseinemodermehreren Clients,die übereinenSwitchmiteinemRouter verbundensind.DerRouterermöglicht dabeidieAnbin- dung an das Internet sowohl über IPv4 als auch über IPv6.Auf dedizierten Servernkönnen reale Dienste wieDomain-Controller,WebserveroderDatenbankeninstalliertwerden,umdieFunktionsfähigkeitunter IPv6zuprüfen.DietechnischeBasisfürdiesenAufbaubildetEVE-NG,einevirtuelleLaborumgebung.Dies erlaubtesuns,dieNetzwerktopologieschnellundintuitivaufzubauenundzuvisualisieren.EingroßerVor- teilistdieMöglichkeit,KonfigurationsständeallerNetzwerkkomponenteninkürzesterZeitzuladen,zube- arbeitenundzuspeichern.SokönnenverschiedeneMigrationsschritteundKonfigurationeneffizientgetes- tetwerden.ZudemkönnendieinstalliertenServer-DiensteflexibelindiesevirtuelleUmgebungintegriert werden,wasrealitätsnaheTestskomplexerAnwendungenermöglicht.DieserAufbaudientdazu,diegrund- legendeKonnektivität, die FunktionsfähigkeitvonAnwendungen undDienstensowie dasZusammenspiel vonNetzwerkgerätenunterIPv6zutesten,bevorÄnderungenimProduktivsystemvorgenommenwerden.

Version4.1 109

[Seite 110]

IPv6-ProgrammdesBundes

DasvirtuelleTestlaborermöglichtsomitdenschnellen,grafischenAufbauvonIPv6-Szenarienmitvirtuellen Geräteabbildern(Images)undbietetsicherenZugriffausdemInternet.DieseUmgebungistideal,umfrüh- zeitigAnnahmenzuvalidierenundHerstellerangabenzuprüfen(z.B.imRahmenderInitiierungeinesPro- jekts). Der Vorteil liegt dabei im schnellen Aufbau von Szenarien und dem einfachen grafischen Ansatz – damit ist das virtuelle Testlabor sehr gut für erste Schritte und die Validierung von Konzepten geeignet. Allerdings können Performance-Beschränkungen der Images und die geteilte Hardware-Infrastruktur die Skalierbarkeit für sehr große oder ressourcenintensive Szenarien einschränken. Für anspruchsvollere An- forderungenstehendaherdasphysischeTestlaborunddasTestlaborfürKommunikations-ITbereit.

6.2 PhysischesTestlabor

Das physische Testlabor ermöglicht realitätsnahe Tests mit echter Hardware und Software. Es ist sowohl remotealsauchvorOrtnutzbarunderlaubtdieIntegrationeigenerGerätemittelsBringYourOwnDevice (BYOD),wasauchkomplexeTestszenarienermöglicht.

Internet FirewallundRouter

InternetfürNutzer

Verkabelungsswitch

Jumpserver

TerminalGateway

RackmitTestHardware VmwareESXi BYOD

norootaccess rootaccess

Managementvlan NAS

Abbildung15:AufbaudesphysischenTestlabors

Das Testlabor ermöglicht primär eine Durchführung von Verbindungs- und Anwendungstests. Dabei sind dieRacksnachfünfverschiedenenAnwendungsfeldernaufgebaut:Switching,SINA/Security,NdB-Routing, generischesRoutingundApplikationen/BringYourOwnDevice(BYOD).

Um die unterschiedlichsten Aspekte Ihrer Umstellung auf IPv6 gründlichtesten zu können, stehen Ihnen spezialisierte Hardware-Umgebungen (Racks) zur Verfügung. Jedes Rack ist darauf ausgelegt, bestimmte BereichederIT-InfrastrukturvonBehördenundOrganisationenimHinblickaufIPv6zuprüfen.

Rack„Switching“:DiesesRackkonzentriertsichaufdieGrundlagenlokalerNetzwerke,alsoaufdieGeräte, die denDatenverkehr innerhalbeinesStandortsoder einesGebäudesverteilen (Switches).Hier kannge- testetwerden,wiedieseVerteilungsgeräteselbstmitIPv6umgehen:Könnensierichtigverwaltetwerden? FunktionierendieMechanismen,diedafürsorgen,dassdasNetzwerkauchbeiAusfällenweiterläuft?Und vorallem:SinddiegrundlegendenSicherheitsfunktionen,diedirektandiesenGerätenansetzen,auchunter IPv6aktivundwirksam?Zielistes,sicherzustellen,dassdieBasisdeslokalenNetzwerksauchmitIPv6stabil undsicherfunktioniert.

Version4.1 110

[Seite 111]

IPv6-ProgrammdesBundes

Rack„SINA/Security“:DiesesRackistfokussiertaufSicherheitsfragenrundumIPv6.Hierkanngeprüftwer- den,obFirewallsundVPN-Verbindungen(alsosichereTunnelfürdenDatenaustausch)denIPv6-Datenver- kehr korrekt erkennen, filtern und schützen können. Es kann simuliert werden, wie diese Sicherheitssys- temebeieinemAusfalleinesGeräts(Hochverfügbarkeit)reagierenundobsieauchimTeam(Cluster)rei- bungslosmitIPv6arbeiten.AuchdiespezielleVerschlüsselungstechnologieSINA-VPN,dieinvielenBehör- dengenutztwird,kannhierunterLaborbedingungengeprüftwerden.

Rack„NetzedesBundes/NdB-Routing“:DiesesRackbildetstarkvereinfachtab,wieeineBehördeandie zentralen„NetzedesBundes“(NdB)angebundenist.Eskanngeprüftwerden,wiederIPv6-Datenverkehr durchdieseszentraleNetzwerkgeleitetwird.Besonderswichtigist dabei,zu prüfen,obIPv6-Datenauch dannkorrekttransportiertwerden,wenn dieNdBselbst nochaufIPv4 basieren(sogenanntes„IPv6 über IPv4“). Es geht darum, die reibungslose Kommunikation mit der zentralen IT unter IPv6-Bedingungen zu gewährleisten.

Rack„GenerischesRouting“:ImGegensatzzumNdB-RackkonzentriertsichdiesesRackdarauf,wieDaten innerhalbdeseigenen,behördeninternenNetzwerks–insbesondereübergrößereDistanzen(WAN)–mit IPv6geleitetwerden.SokönnenhierverschiedeneMethodenundRegeln(Routing-Protokolle)ausprobiert werden. Das Rack ist flexibel konfigurierbar, um die Vielfalt der internen Netzstrukturen abzubilden und sicherzustellen,dassderIPv6-Datenverkehreffizientundzuverlässigist.

Rack „Application/BYOD“: Dieses Rack ist der zentrale Punkt, um Anwendungen/Fachverfahren und DiensteaufihreIPv6-Fähigkeitzutesten–vongrundlegendenServerdiensten(z.B.fürE-MailsoderDaten- banken)bishinzuIhrenspezifischenFachanwendungen.ZudemkanneigeneHardware(BYOD)oderauch eigeneSoftwareeingebrachtwerdenunddieseimZusammenspielmitdenvorhandenenIPv6-fähigenKom- ponenten getestetwerden,egalobdieseaufContainer-TechnologienoderklassischenvirtuellenMaschi- nenbasieren.

6.3 TestlaborfürKommunikations-IT

DasTestlaborfürKommunikations-ITistspezialisiertaufAnwendungsfälleausdenBereichenVideo,Tele- fonie,GebäudeleittechnikundPeripheriegeräte.EskannsowohlremotealsauchvorOrtgenutztwerden undunterstütztdieBYOD-Möglichkeit.

NebenderErprobungvonKeimzellenwerdenimLaborauchInkrementegetestet.DiePlattformdientins- besonderezurValidierungvonIPv6-fähigenUnified-Communications-Diensten(UC),LAN-undWLAN-Sys- temensowieIoT-Komponenten.

DerverfügbareHardware-undSoftwareumfangumfasstunteranderem:

• einebreiteAuswahlanCampus-Infrastrukturkomponenten, • CiscoUC-Endgeräte(z.B.Telefone,Webex-Systeme), • BYOD-fähigeSchnittstellensowie • IoT-Sensorik.

Die Testumgebung basiert auf einer Referenzarchitektur, die sowohl klassische LAN-Topologien als auch SD-Access-Ansätze(SD:Software-Defined)unterstützt.DerZugrifferfolgtabgesichertüberHTTPS,sodass eine Erreichbarkeit aller am IPv6-Programm teilnehmenden Behörden und Organisationen gewährleistet ist.

Version4.1 111

[Seite 112]

IPv6-ProgrammdesBundes

In tern et Firew allu nd R o uter

In tern et für N utzer

Ju m pserver

Term in alG atew ay

n o roo t access N A S

Abbildung16:AufbaudesTestlaborsfürKommunikations-IT

EinBeispielszenariozurNutzungdesTestlaborsistinAbbildung17dargestellt.UmdenEinstiegzuerleich- tern, wurde eine abstrahierte Standardumgebung geschaffen, die die typischen Komponenten einer be- hördlichenTK-Anlagenachbildet.

FürdasBeispiel-SzenariokamenfolgendeKomponentenzumEinsatz:

• Core-Geräte:WANEdgeCatalyst8300 • Campus-undAccess-Geräte:Catalyst9300 • DataCenter:Nexus9300sowieUCSC245M8Series • Server:VMwareESXi • Kommunikations-ITEndpunkte:CiscoCP-7861 • Security:CiscoFirepower3120 • Software:Kommunikations-IT-SoftwarewieCUCMundWebex • Endgeräte:BringYourOwnDevice(BYOD)

Version4.1 112 M anagem en t vlan

[Seite 113]

IPv6-ProgrammdesBundes

Abbildung17:Dual-Stack–Beispiel-AufbauimLaborfürKommunikations-IT

DieobigeAbbildungzeigtdenDual-Stack-AufbaualsZwischenschrittbeiderUmstellungvonIPv4aufIPv6.

Version4.1 113

[Seite 114]

IPv6-ProgrammdesBundes

7 Exkurs: IT-Sicherheit und Datenschutz mit IPv6

IndiesemKapitelsindAspektefürIPv6-SicherheitundDatenschutzzusammengefasst.DieserAbschnittbie- teteinenÜberblicküberdieAuswirkungenundMaßnahmeneinerIPv6-MigrationaufdiebehördlicheIT- SicherheitunddenDatenschutz.

7.1 AspektederIT-Sicherheit

DiesesKapitelgibteineÜbersichtüberdieSicherheitsaspekte,diesichimZusammenhangmitderVerwen- dungdesIPv6-ProtokollsindenNetzender öffentlichenVerwaltung(ÖV)ergeben.WeitergehendeInfor- mationenzur IT- Sicherheit beim Einsatz von IPv6 bietet das BSI39in separaten Dokumenten an(z.B. ISi- LANA40,ISi-L-IPv641).

Sicherheitsaspekte bei der Einführung von IPv6 in bestehende IT-Infrastrukturen (die auf IPv4 basieren) gliedernsichfolgendermaßenauf:

• Sicherheitsaspekte des bisher ausschließlich genutzten Protokolls werden in diesem Leitfaden nicht weiterbetrachtet.Eswirddavonausgegangen,dassdiebestehendeIPv4-InfrastrukturvorBeginneiner IPv6-MigrationnachIT-GrundschutzundnachdemaktuellenStandderTechnikabgesichertist. • SicherheitsaspektedesneuhinzukommendenProtokollsIPv6,welcheinsbesonderedurchdieneuenin IPv4nochnichtvorhandenenFunktionenzustandekommen.DiebekanntenHerausforderungenbzgl. IPv6undIT-SicherheitsindinöffentlichenQuellengutbeschrieben.MitderaktuellenVerbreitungvon IPv6inalleNetzbereichesteigtauchdieallgemeineAuseinandersetzungmitdemProtokollunddamit dieWahrscheinlichkeit,weitereBedrohungenzuidentifizieren.DasBSIhatzumEinsatzvonIPv6einen entsprechendenLeitfadenveröffentlicht:ISi-L-IPv6. • Sicherheitsaspekte, die sich aus dem kombinierten Einsatz von IPv4 und IPv6 (Dual-Stack) ergeben. DurchdenparallelenEinsatzvonIPv4undIPv6erhöhtsichdasRisikovonFehlerndurchdiesteigende KomplexitätunddenerhöhtenWartungs-undÜberwachungsaufwand,waswiederumRaumfürneue Angriffszielebietet. • SicherheitsaspektevoneinzelnenÜbergangstechniken,welchedenÜbergangvonIPv4zuIPv6erleich- tern sollen oder dort IPv6 ermöglichen, wo wesentliche Netzkomponenten noch nicht IPv6-tauglich sind.

EinensehrdetailliertenÜberblickzuFragenderIPv6-SicherheitgibtauchNIST-800-11942.

Darüber hinausgelten die grundlegenden Regeln,welche schon bei der Sicherheitskonzeptionierungvon IPv4-Netzen mit IT-Grundschutz angewendet werden, auch weiterhin für IPv6. Dies gilt insbesondere für dieorganisatorischeSicherheitdurch43:

• dieDefinitionundEinhaltungvonSicherheitsrichtlinien • einenklarorganisiertenIT-BetriebmitdokumentiertenProzessen • geschultesundausreichendvorhandenesPersonal

39https://www.bsi.bund.de/;zuletztaufgerufenam11.11.2025 40https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlun- gen/ISI-Reihe/isi-reihe_node.html#doc453736bodyText2;zuletztaufgerufenam11.11.2025 41https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlun- gen/ISI-Reihe/isi-reihe_node.html#doc453736bodyText1;zuletztaufgerufenam11.11.2025 42https://csrc.nist.gov/pubs/sp/800/119/final;zuletztaufgerufenam11.11.2025 43Weitere Informationen bietet auch hier das BSI unter https://www.bsi.bund.de/DE/Themen/Unternehmen- und-Organisationen/Informationen-und-Empfehlungen/ISI-Reihe/isi-reihe_node.html; zuletzt aufgerufen am 11.11.2025

Version4.1 114

[Seite 115]

IPv6-ProgrammdesBundes

• Netzwerksicherheitskonzepte,welcheregelmäßigaktualisiertwerdenundsogestaltetsind,dasssiedie notwendigeKommunikationauchwirklichermöglichen,damitdieseSicherheitauchgelebtundnicht umgangenwird. • Eine angemessendimensionierte Infrastruktur, beginnendmit einer abgesichertenStromversorgung, überIP-verarbeitendeSystememitausreichenderRechen-undSpeicherkapazitätsowieStellflächeund KlimatisierungindenentsprechendenRäumlichkeiten.

7.1.1 TechnischeAspektederIT-Sicherheit

DietechnischenAspektesindentsprechenddemOSI-Modellstrukturiert.

7.1.1.1 TechnischeAspektederIT-Sicherheit–Layer2

BeiderImplementierungvonIPv6ergebensichbestimmteBesonderheitenundHerausforderungeninBe- zugaufdieLayer-2-Sicherheit.DienachfolgendeListemitIPv6-Sicherheits-Herausforderungenstellteinen Auszugdar;esistessenziell,stetswachsamzubleibenundsichkontinuierlichüberaktuelleSicherheitsent- wicklungenzuinformieren.GenerellsindNetzwerkportswiebeiIPv4vorunbefugtemZugangzuschützen.

Version4.1 115

[Seite 116]

IPv6-ProgrammdesBundes

Vorschlag Eswirdempfohlen,StandardkonfigurationenfürAccess-Portszuentwickeln.Zu- sätzlichsollte802.1X(Netzwerkzugangskontrolle)implementiertwerden,damit nurautorisierteGerätenZugangerhalten.

DietechnischenDetailszuVektorenundAbsicherunggegenAngriffeimlokalenKommunikationsnetzfin- densichimIPv6-WikidesIPv6-ProgrammsimAbschnitt„IPv6LANSecurity“44.

44https://confluence.ipv6-programm.bund.de/display/WIKI/IPv6+LAN+Security;zuletztaufgerufenam 11.11.2025

Version4.1 116

[Seite 117]

IPv6-ProgrammdesBundes

7.1.1.2 SicherheitimLayer-3-Netz

Layer3(Netzwerk)istvonbesondererBedeutung,dadarüberdasRoutingvonDatenverkehrzwischenver- schiedenenNetzwerkenverläuft.IndernachfolgendenListesindpotenzielleBedrohungenaufLayer3iden- tifiziert undVorschläge fürderenMitigationvorgestellt.Diese Bedrohungen sindv.a. fürNetzwerkadmi- nistratoren,Sicherheitsexpertenundalle,diesichmitderInfrastrukturdesmodernenInternetsbeschäfti- gen,vongroßerRelevanz.

Version4.1 117

[Seite 118]

IPv6-ProgrammdesBundes

Version4.1 118

[Seite 119]

IPv6-ProgrammdesBundes

DasAufrechterhaltenderNetzwerksicherheit,insbesonderebeiderUmstellungaufIPv6,erfordertständige Wachsamkeit, da neue Bedrohungen und Techniken fortlaufend entwickelt werden. Es ist entscheidend, diespezifischenRisikenundAnforderungenindenMigrationseinzelprojektenzuverstehenundeinenpro- aktivenAnsatzzurNetzwerksicherheitzuverfolgen.

7.1.1.3 SicherheitsaspektevonApplikationen

IndiesemAbschnittwerdenkurzSicherheitsaspekteaufgeführt,diebeiderEinführungvonIPv6betrachtet werdenmüssen.

Alle Applikationen, die nur IPv4 für die Kommunikation verwenden, müssen in der Migration betrachtet werden.EineMigrationbetrifftdarüberhinausauchApplikationen,dieselbstInformationenzuIP-Adressen verwalten.DassindinersterLiniedasDomainNameSystem(DNS)undRouting-ProtokollesowieManage- ment-Systeme wie IPAM (IP Address Management), CMDB (Configuration Management Database), Log- ging-undMonitoring-Systeme.

• Domain Name System Security Extensions (DNSSEC): Die Sicherheitsaspekte, welche in einem IPv4- Netzwerkbzgl.DNSrelevantsind,behaltenauchdurchdieEinführungvonIPv6weiterhinihreGültig- keit.Dies umfasst zum einen die Absicherungder DNS-Server selbst undzum anderen die Sicherheit desDNS-Dienstes.BezogenaufdenDNS-DienstbedeutetSicherheitz.B.dieVerwendungvonkrypto- grafischenSchutzmechanismen.ZweiStandardssindhierfürdefiniertworden: „DNSSecurityExtensi- ons“ (DNSSEC) in den RFCs – RFC 403345, RFC 403446und RFC 403547– für vertrauenswürdige DNS- Abfragenund„TheSecretKeyTransactionAuthentication“(TSIG,RFC894548)fürabgesicherteZonen- transfers zwischen zwei DNS-Servern. Wesentlich ist hierbei, dass in den DNS-Einträgen bei DNSSEC vertrauenswürdigesSchlüsselmaterialhinterlegtwird.DieseFunktionensindweitgehendidentischfür IPv4undIPv6.DNSSECbietetdieMöglichkeit,ZertifikatsinformationenverifizierbarimDNSabzulegen. SomitkannmitDNSalsVertrauensbasisabgesicherteKommunikation„ausdemStand“heraus(Oppor- tunisticencryption(OE)49)aufgebautwerden.DasbetrifftVPNsmitIPsec,TLS-Verbindungenundsogar SSH-Verbindungen. • Split-DNS: Wie schon für IPv4 ist auch für IPv6 die Verwendung von Split-DNS oder entsprechenden Alternativenrelevant.Hintergrundist,dassdieimDNSgespeichertenInformationenzuinternenSys- temenvonexternnichterreichbarseindürfen.Esmussalsosichergestelltsein,dassinterneClientsihre IP-Adressen auf DNS-Servern registrieren, die von außen nicht erreichbar sind. Der Einsatz von IPv4-

45https://datatracker.ietf.org/doc/html/rfc4033;zuletztaufgerufenam11.11.2025 46https://datatracker.ietf.org/doc/html/rfc4034;zuletztaufgerufenam11.11.2025 47https://datatracker.ietf.org/doc/html/rfc4035;zuletztaufgerufenam11.11.2025 48https://datatracker.ietf.org/doc/html/rfc8945;zuletztaufgerufenam11.11.2025 49https://en.wikipedia.org/wiki/Opportunistic_encryption;zuletztaufgerufenam11.11.2025

Version4.1 119

[Seite 120]

IPv6-ProgrammdesBundes

AdressennachRFC1918stelltzwarsicher,dasseineExpositionderDatenausdemDNSkeinendirekten Zugriffermöglicht.50DennochlässtsichdieinterneIT-Strukturermitteln.Daserleichtertespotenziellen Angreifern,sichnacherfolgreichemEindringenschnellzurechtzufinden. BeiderEinführungvonIPv6- Adressenmuss,wieauchinIPv4-Netzen,sichergestelltsein,dassNamenundAdresseninternerRech- ner nicht ins Internet exponiert werden. In Zusammenhang mit DNSSSEC kann die Zonenverwaltung komplex werden,wenn man für das interne Netz eine Subzone des eigenen Namensraums nutzt. Es musssichergestelltsein,dasskeineInformationenüberdieinterneZonenachaußenexponiertwerden. FürSplit-DNSdiskutiertdieIETFgeradeeinenVorschlag–Split-horizon-authority51.BeiderEinführung von IPv6 muss überprüft werden, dass eine vorhandene Split-DNS-Konfiguration die erforderlichen Funktionen auch mit IPv6-Adressen gewährleistet und alle neuen Sicherheitsaspekte berücksichtigt werden.

WeitereAspekte,diebeachtetwerdensollten,sind:

• NetworkSecurityEquipment:FürNetzwerksicherheitskomponenten(Firewalls,IDS/IPS,ALG)müssen unterIPv6vergleichbareFunktionalitätenwieunterIPv4zurVerfügung gestelltwerden.Diesumfasst u.a.Filtering,Monitoring,Logging,AuditingundReporting. • Performance:DieLeistungvonSystemenwieRoutern,Firewalls,ALGsundIDS/IPSkannnegativbeein- flusstwerden,wennbeideProtokolleparallelverarbeitetwerdenmüssen. DieLeistungsfähigkeitvon GerätenfürIPv6solltevorabfestgestelltwerden. • Monitoring/Auditing:EsmusseinIPv6-Monitoringetabliertwerden(sieheauchKapitel3.3),welches denIPv6-Datenverkehr ineiner Verwaltungüberwacht, sodassnicht gewünschter IPv6-Datenverkehr undRogue-Systemeentdecktwerdenkönnen.DasMonitoringundAuditingsollteinsbesondereauch TunnelverkehrsowieRouter-undNeighbor-Solicitationsentdeckenkönnen.

7.1.2 OrganisatorischeAspektederIT-Sicherheit

IndiesemKapitelsindorganisatorischeAspektederIT-SicherheitbeiderEinführungunddemBetriebeines IPv6-Netzwerks zusammengefasst. Wird ein IT-Sicherheitsmanagement nach IT-Grundschutz in der Be- hörde oder Organisation des Bundes umgesetzt, dann können folgende ergänzende Hinweise ganz oder teilweiseindasSicherheitskonzeptübernommenwerden.

• IPv6-Herstellersupport: Mittlerweile unterstützen fast alle am Markt erhältlichen Produkte IPv4 und IPv6.AuchschonlängerimEinsatzbefindlicheHard-undSoftwaresolltedieseUnterstützungliefern. Um sicherzustellen, dass die vorhandene IT-Landschaft hinsichtlich der IPv4-/IPv6-Eigenschaften den aktuellenSicherheitsstandardsentspricht,mussüberprüftwerden,welcheStandardsindereingesetz- ten Hard- und Software implementiert sind. Sollte es hier für den Parallelbetrieb von IPv4 und IPv6 keineverlässlichenAngabengeben,könnenFunktions-undLasttestsindenprogrammeigenenTestla- boren durchgeführt werden, um zu verifizieren, dass die Bestands-Hardware und -Software für den produktivenEinsatzgeeignetist.DieeingesetzteHardwareundSoftwarekannbeidiesenTestsaufbe- kannte(undnochunbekannte)Schwachstellenüberprüftwerden.BeieinerNeuanschaffungvonHard- waremusssichergestelltsein,dassdieerforderlichenSicherheitsstandardsunterstütztwerdenunddie zu erwartenden Datendurchsätze gewährleistet sind. Die Abstimmung mit den Herstellern, bspw. zu denzuerwartendenmöglichenDatendurchsätzenoderzurAnzahlderRouting-EinträgeindenRouting- TabellenjeIP-Protokoll,kannvieleFragenklärenundSchwachstellenidentifizieren.ImIPv6-Programm wurde mit den Hersteller-Roundtables eine Unterstützungsmaßnahme etabliert, um solche Abstim- mungengebündeltdurchführenzukönnen.

50https://datatracker.ietf.org/doc/html/rfc1918;zuletztaufgerufenam11.11.2025 51https://datatracker.ietf.org/doc/rfc9704/;zuletztaufgerufenam11.11.2025

Version4.1 120

[Seite 121]

IPv6-ProgrammdesBundes

• IPv6istStandardimBetriebssystem: BeiallenmodernenBetriebssystemenistIPv6bereitsaktiv.Ob esalsbevorzugtesProtokollzumEinsatzkommt,entscheidetdiejeweiligeAnwendung.Ohneeinequa- lifizierte und kontrollierte Einführung von IPv6, inklusive eines entsprechend angepassten IT-Sicher- heitskonzeptsundentsprechendkonfiguriertensowieIPv6-tauglichenSicherheitskomponenten,istdie NutzunginBehördennetzenmit unerwünschtenSicherheitsrisiken verbunden. Ist IPv6 nochnichtre- gulärineinerBehördeeingeführt,wieindiesemLeitfadenbeschrieben,sollteIPv6zunächstinallenCIs deaktiviert werden. Zusätzlich sollten alle Firewall-Systeme initial in der Lage sein, IPv6-Verkehr und IPv4-Tunnel, indenen IPv6 transportiert wird,zu erkennen undzu blockieren.Die Weiterleitungvon IPv6durchinterneRoutersolltedeaktiviertwerden.BeiRouterndesHerstellersCiscoerfolgtdiesmit demBefehl„noipv6unicast-routing“.Zubeachtenist,dassdiekompletteDeaktivierungvonIPv6auf ServernvonMicrosoftnichtempfohlenwird,dadieszueingeschränktemSupportführenkann.Hierist imVorfeldzuklären,obdieDeaktivierungvondenWartungsverträgenabgedecktwird.Alternativkann geprüftwerden,obdieDeaktivierungeinzelnerIPv6Funktionenausreichendist,umdieIT-Sicherheit zuwahren. • IPv6-Sicherheitsplanung:DieSicherheitsplanungsollgewährleisten,dassmindestensdasbisherigeSi- cherheitsniveau des IPv4-Only-Netzwerksauch nachder IPv6-Migrationgewährleistet ist.Die Sicher- heitsplanungsolltedabeifolgendePunkteumfassen:

o Sicherheitsrichtlinie:IPv6mussindieSicherheitsrichtlinieeinerBehördeundOrganisation desBundes,dieeinMigrationseinzelprojektumsetzt,mitaufgenommenwerden. o Konfigurationsvorgaben: Es sollten Konfigurationsvorgaben für alle Konfigurationsele- mente erstellt werden, die solche benötigen, z.B. Switches, Router, Firewalls, IDS / IPS, Betriebssysteme,ArbeitsplatzsystemeundServersoftware. o Perimeter-Schutz:DerNetzwerkperimetermussmitIPv6-fähigenFirewalls,IDS/IPSund ALGsgeschütztwerden.DabeimussfürbeideProtokolleeinidentischesSicherheitsniveau hergestellt werden. In der IPv6-Migration sollte zuerst der Perimeter gesichert werden. ZusätzlichistdieentsprechendeFirewallsozukonfigurieren,dassunerwünschterTunnel- Datenverkehr,z.B.Teredo-Datenpakete,anderFirewallblockiertwerden.Dasgleichegilt fürIDS-/IPS-SystemeundALGs. o PatchManagement:AuchfürCIs,dieIPv6-fähigsind,müssenwiebeiIPv4allesicherheits- relevantenPatcheszeitnaheingespieltwerden. o Infrastrukturdienste: Für diekorrekteFunktionder IPv6-SicherheitssystemesindIPv6-fä- higeInfrastrukturdienste,wieDNS,DHCPv6undNTPnotwendig. o Netzwerkmanagementund-Monitoring:FüreinsicheresNetzwerkmanagementund-mo- nitoringmüssendieseSystemeDatenundKonfigurationenmitIPv6-Adressenverarbeiten können.NotwendigsindNetzwerkmanagementsystemeundMonitoringsysteme,welche bereitsselbstdurchgängigIPv6nutzenkönnen. o VulnerabilityManagement/SecurityIncidentandEventManagement(SIEM):DasVulne- rability Management und das SIEM sollten, falls vorhanden, IPv6-fähig sein, um die zu überwachendenCIsansprechenzukönnen.ZusätzlichsolltendieseSystemediezuüber- wachendenCIsaufIPv6-spezifischeProblemeüberprüfenkönnen. o Netzwerkkomponenten:DieZugriffsregeln(AccessControlLists,ACL)vonRouternsindfür den IPv6-Datenverkehr anzupassen, sowie, wenn möglich, 802.1x (NAC / NAP) auch für IPv6 zu aktivieren. Zusätzlich sollte, falls unüblicherweise deaktiviert, Duplicate Address Detection(DAD)aktiviertwerden. o Security-Komponenten: Regelwerke von Firewalls, Krypto-Gateways, IDS / IPS und ALGs sindfürbeideProtokolleparallelzu pflegen.Dabei ist sicherzustellen, dassdiesesowohl für IPv4 alsauchfür IPv6 wirksamsind.Insbesondere ist für IDS/ IPSist sicherzustellen, dass die Erkennungssignaturen gleichermaßen wirksam sind. Entsprechende Tests sind

Version4.1 121

[Seite 122]

IPv6-ProgrammdesBundes

hierfürdurchzuführen,umzuevaluieren,obdieErkennungs-SignaturenfürbeideIP-Pro- tokollewirksamsindundumdieHersteller-Aussagenzuverifizieren. o SicherheitvonEndsystemen: DieSicherheitssoftware(Host-Firewall,Host-IDS/IPS,Anti- virensoftwareetc.)sowiedieManagementsoftware,dieaufEndsystemeneingesetztwird, mussIPv6-fähigsein. o Rogue Detection: Es sollte gewährleistet sein, dass unerwünschte (unplanmäßig auftau- chende) IPv6-Systeme im Intranet der Behörde oder Organisation des Bundes erkannt werden. o Konfigurationsmanagement: Der Dual-Stack-Betrieb ist komplexer als der Betrieb von IPv4.SosinddieAuswirkungenvoneinzelnenKonfigurationsänderungenschwerervorher- sehbar.AusdiesemGrundsolltedieEinführungeinesKonfigurationsmanagementsystems abgewogenwerden.VoraussetzungfürdessenEinsatzistzunächstderTestineinersepa- raten Testumgebung, welche auchschonunter IPv4 füreinen größeren IT-Betrieb erfor- derlichist. o Sicherheitszertifizierung:SicherheitszertifizierungenvonKonfigurationselementensollten auchdieSicherheitderIPv6-Funktioneneinschließenundzertifizieren. o Sicherheits-Monitoring / -Auditing: Das Monitoring undAuditingvonsicherheitsrelevan- tenVorfällensolltesowohlunterIPv4undIPv6verfügbarsein.Dabeisolltensicherheits- relevanteVorfällenachIPv4-Only,IPv6-OnlyundDual-Stackklassifiziertwerden. o Penetrationstests:DasBSIempfiehlt,regelmäßigallezweiJahrePenetrationstestsdurch- führenzulassen.ImZugeeinesMigrationseinzelprojektesistesratsam,dieseTestshäufi- ger durchzuführen, um die sich ändernde Bedrohungslage in der Migrationvon IPv4 auf IPv6 zu berücksichtigen.Penetrationstestsbetreffen sowohldie Infrastrukturkomponen- tenalsauchfürFachanwendungen.Soweitmöglich,solltendieTestsautomatisiertausge- führtundprotokolliertwerden.

7.2 DatenschutzbeiderEinführungvonIPv6

Neben den vielen Vorteilen bringt IPv6 auch neue Herausforderungen für den Datenschutz mit sich. Das betrifftvorallemdiejenigenIPv6-Adressen,dieohnezusätzlicheInformationeneindeutigeinemEndgerät zugeordnetwerdenkönnen.52UrsprünglichwarenfüralleKnotendesInternetsfesteAdressenvorgesehen. ErstdasrasanteWachstumdesInternetsunddieAdressknappheitbeiIPv4führtezurEinführungderdyna- mischen Adressvergabe beiEinwahl-Anschlüssen vonPrivatkunden (typischerweise DSL oder Mobilfunk). Für bestimmte Anwendungen konnten sich Produkte durchsetzen, die mit dynamischen IP-Adressen auf einfacheWeiseumgehenkönnen.BekanntestesBeispielistdieInternet-Telefonie-SoftwareSkype,dieeine Erreichbarkeit unter einem festen Nutzernamen trotz wechselnder IP-Adressen ermöglicht. Ein Datenschutz-Problem kann entstehen, wenn externe Dienste-Anbieter personenbezogene Nutzerprofile unter Nutzung der festen IPv6-Adressen je ausgehender Verbindung und Endgerät kontext-übergreifend anlegen und pflegen. Dies ist nicht zur DSGVO konform, wenn es keine Rechtsgrundlage dafür gibt (z.B. eineEinwilligungdesBetroffenen).

AllerdingsstellendieNetzedesBundesundeventuellauchweitereWAN-NetzederBundesverwaltungei- nen Schutz dar, da inder Regel kein Endgerät direkt mit dem Internet verbunden ist. Der Zugriff auf das InterneterfolgtinderRegelüberProxysysteme.DieseProxysystemenutzeneigeneexterneIPv6-Adressen fürdieKommunikationmitdemInternetundgebendieIPv6-AdressenderClientsnichtweiter.Diesstellt

52InzwischenistaufgrundeinesEuGH-Urteils(vom19.10.2016–C-582/14)abschließendgeklärt,dassIP-Adres- senbeimDatenschutzimmeralspersonenbezogeneDatengelten,egalobessichumstatischeoderdynamische IP-Adressenhandelt.DerUnterschiedbestehtlediglichdarin,dassfestestatischeIP-AdressenleichtereinerPer- son zugeordnet werden können als dynamischeIP-Adressen.DieVerschleierungvon IP-Adressen bietet daher alseineArtPseudonymisierungeinenverbessertenSchutzderPrivatsphäre.

Version4.1 122

[Seite 123]

IPv6-ProgrammdesBundes

die aus Sicht der Informationssicherheit und des Datenschutzes die empfohlene Lösung zur Nutzung des InternetsausNetzenderBundesverwaltungdar.

UnabhängigvonderIP-AdresseeinesNutzendengibteszudemauchnochandereMöglichkeitenzurWie- dererkennungvon Nutzenden imInternet (z.B.Cookiesund Fingerprinting imBrowser), so dass die Ver- schleierungder IP-Adresse zur VerhinderungvonTracking(z.B.durchdiePrivacy ExtensionsvonIPv6) in der Regel nicht ausreichend ist. Dennoch wird die Verwendung der Privacy Extensions von IPv6 in nicht vertrauenswürdigenNetzenempfohlen(z.B.inWLANs).

Für dieöffentlicheVerwaltunginDeutschlandliegt derUnterschiedvonIPv6zuIPv4 insbesondere darin, dassimGegensatzzuIPv4einübergreifendesAdressvergabeschemaerstelltwurde,beidemdurchgängig sogenannte„Global-Unicast“-Adressenverwendetwerdenkönnen,wasdiedoppelteVergabevonAdres- senverhindert.MitdiesemAdressvergabeschemasindOrganisationeninnerhalbderNetzederBundesver- waltungidentifizierbar,konkretePersonenhingegennicht,solangeClientsystemewieobenempfohlenim- merüberFirewall-ProxysystememitexternenNetzenkommunizieren.

Version4.1 123

[Seite 124]

IPv6-ProgrammdesBundes

8 Worst- und Best-Practice-Beispiele

Hinweis:DiesesKapitelistdie„Keimzelle“desBest-Practice-RepositoriesaufderKommunikations-und InteraktionsplattformdesIPv6-ProgrammsdesBundes.WiebeidenKeimzellen-Migrationen,dieindie- semMigrationsleitfadenbeschriebensind,wächstdiesesRepository kontinuierlichan.Dienachfolgen- dengutenwieschlechtenErfahrungenbasierenaufpraktischenProjekteinsätzenderIPv6-Coaches,mit denen sie über Erkenntnisse aus durchgeführten IPv6-Migrationsprojekten berichten. Diese Beispiele kommen mehrheitlich aus der Wirtschaft. Das Best-Practice-Repository des Programms soll mit Pro- jekterfahrungenausdenMigrationseinzelprojektenbefülltwerden.

Projektbeispiel1:VoreinerIPv6-MigrationineinemKRITIS-UnternehmenhattedieseskeinerleiIPv6-Kon- figurationenimNetzvorgenommen.AlleNetzwerkgerätesowiealleEndgerätewarennachStandard-Kon- figurationenaufgesetzt.EinesTageswurdeeinClientvoneinemVerschlüsselungs-Trojanerbefallen.Inkür- zesterZeitverbreitetesichdieserüberdaskompletteNetzwerkinnahezualleSysteme,obwohldasUnter- nehmendienotwendigenSicherheitsmaßnahmenergriffenhatte–aberleidernurfürIPv4,nichthingegen fürIPv6.SomitkonntesichderVirusüberdieStandard-IPv6-KonfigurationenvonClients,ServernundNetz- werkgerätenungehindertausbreiten.

IPv6nichtzukonfigurierenkannzuerheblichenSicherheitslückenführenunddieOr- ganisationgrundsätzlichgefährden.TatsächlichempfiehltMicrosoft,IPv6aktiviertzu Tippsfür lassenundnichtabzuschalten:https://learn.microsoft.com/en-us/trouble- diePraxis: shoot/windows-server/networking/configure-ipv6-in-windows.

Projektbeispiel2:EinUnternehmenausderAutomobil-Branchehatteeinenöffentlichen/16-IPv4-Adress- bereich(rund16MillionenAdressen)reserviert.DieserIPv4-Adressbereichwarnahezuaufgebraucht.Wei- tereIPv4-AdressensindaufdemWeltmarktnurnochteuerzuerwerben.AuchdieOption,Bogon-IP-Adres- sen53einzusetzen,wurdeverworfen,dadiesesVorgehenvondenSicherheitsexpertendesUnternehmens als „brandgefährlich“ eingeschätzt wurde. Das Unternehmen entschied sich, mit einer IPv6-Migration zu starten.NachdererfolgreichenMigrationaufIPv6bestanddieMöglichkeit,denkompletten/16-IPv4-Be- reichzuveräußern.DamitkonnteeinrelevanterBetragerwirtschaftetunddieMigrationskostengegenfi- nanziertwerden.

DasUS-DepartmentofDefenseundandereverfügenübergroßeBereichevonIPv4- Adressen,welcheaktuellimInternetnichtgeroutetwerden.EinBeispielist44/8,wel- chesursprünglichfürdenAmateurfunkreserviertwar.GroßeTeilediesesBlockssind anAmazon(AWS)verkauftworden.WennnuneinUnternehmenBogon-IP-Adressen imeigenen,privatenNetzverwendet,könnendieoffiziellenPunkteimInternetmit Tippsfür dengleichenAdressennichterreichtwerden.DielokalenRouterlenkendenVerkehr diePraxis: aufdielokale(„entwendete“)AdresseundnichtindasInternet.AlsResultatistes möglich,dassUnternehmen,welchedieseBogon-Adressenverwenden,entspre- chendeSystemez.B.beiAWSnichtmehransprechenkönnen.

Projektbeispiel 3: Durchdie Knappheit der IPv4-Adressen und die hohenKosten für neue Adressen oder AdressbereichehabenvieleProvideraufNAT(NetworkAddressTranslation)fürIPv4umgestellt–teilweise

53EineBogon ist eineunrechtmäßigeIP-Adresse,diein eineReihevon IP-Adressen fällt, dienicht offiziellvon einerInternetregistrierungsinstitution,wiederInternetAssignedNumberAuthority(IANA),aneineEntitätver- gebenwurden.BogonsentstehendurcheineFehlkonfigurationoderabsichtlichenMissbrauch,derdenEmpfän- gerüberseineQuell-IP-Adressetäuscht.DerBegriffBogonwirdumgangs-sprachlichverwendetundistabgeleitet vondemenglischenWortBogus(falsch,gefälscht).(aus: https://www.computerweekly.com/de/definition/Bo- gon;zuletztaufgerufenam11.11.202511.08.2025)

Version4.1 124

[Seite 125]

IPv6-ProgrammdesBundes

inVerbindungmitIPv6,aberauchteilweiseIPv4-Only.Damit„versteckt“derProviderdieEndkundengeräte, welcheimInterneteingesetztwerden,hintereineroderwenigenöffentlichenIPv4-Adressen.Dieskann,je nachImplementierung,zuProblemenmitz.B.VPNsführen.DiessetztEndkundenunterDruck.EinIT-Ver- antwortlichereinergroßenVersicherungführtineinemWorkshopaus:„Unsistegal,wowirmitIPv6an- fangen,aberdieBenutzer-VPNssindzuerstdran.DiemachenammeistenProbleme.“AuchGeschäftskun- denanbieterfangenan,IPv4-NATfürKundenzuimplementieren,wasgleichfallsProblemeverursacht.

Projektbeispiel4:EinUnternehmenausderverarbeitendenIndustrieplant,aufIPv6zumigrieren.Gleich- zeitig ist die Einführung eines neuen DDI-Systems (DNS, DHCP und IPAM) zur Vereinfachung des Client- Managementsgeplant.NachdenerstenTestszurVorbereitungderIPv6-Migrationwurdefestgestellt,dass derflächendeckendeEinsatzvonDHCPv6zuProblemenbeideneingesetztenAndroid-Gerätenführt.Diese unterstützen aktuellundauf absehbare Zeit DHCPv6 nicht.Somit können die Android-Geräte nicht –wie geplant–überdaszentraleDDIviaDHCPv6dokumentiertundbetriebenwerden.

Projektbeispiel 5: Die Migration auf IPv6 eines großen deutschen Internet-Service-Providers (ISP) im Be- reich der Geschäftskunden-Serverfarmen wurde 2011/2012 massiv vorangetrieben.Das Ziel war es, zum „IPv6Day“am8.Juni2011,IPv6zuaktivierenundalleKunden-ServermitIPv6zubetreiben.DasZielwurde erreichtundalleKunden-ServerkonntenproblemlosaufIPv6umgestelltundbetriebenwerden.AmEnde des„IPv6Day“2011stelltederISPallerdingsdenBetrieb nichtaufIPv4zurück,sondernbehieltdieIPv6- Konfigurationen bei. Zum „IPv6 Launch Day“ am 6. Juni 2012 konnte der ISP die Umstellung auf IPv6 als „erledigt“ melden. Im Rahmen dieser IPv6-Migration wurde im Labor sogar noch ein Fehler in der IPv6- KonfigurationineinemLoad-BalancergefundenundvomHerstellergelöst.

DerVorteildieserfrühenUmstellungwar,dassderISPdieMigration„selbstbe- stimmt“organisierenkonnte.HeutzutageistIPv6aufvielenClient-CIsinstalliertund alsbevorzugteKonfigurationausgewiesen.MithinerfordertdieIPv6-Migrationein Tippsfür ganzanderesLastmanagement,dadanndieMehrheitderClientsundeingesetzten diePraxis: CIsüberIPv6kommunizierenwird.JespätereineIPv6-Umstellungerfolgt,umsorisi- koreicherundkomplexerwirddasMigrationsvorhaben.

Projektbeispiel 6: Einanderer großer deutscher ISP startete die Migrationauf IPv6.Zu diesem Zeitpunkt beinhaltetendieFirewallsdesUnternehmensrund1600Firewall-Regeln.DieIT-Betriebsverantwortlichen schätztenvorBeginnderIPv6-Migrationein,dassalleFirewall-RegelnaufIPv6umgestelltwerdenmüssen. DiesstellteeinegroßeHerausforderungfürdasProjektunddieIT-Betriebsverantwortlichendar.Bevoreine Entscheidunggetroffenwerdensollte,welcheFirewall-Regelnumgestelltwerdensollten,wurdegemessen, wieofteineRegel„benutzt“wurde(inTagen/Wochen/Monaten).Überraschenderweisewurdemitdieser Messungfestgestellt,dassderGroßteilderRegeln(rund1400)praktischnichtmehrinBenutzungist.Die Umstellungderverbleibenden200RegelnstelltekeineHerausforderungfürdenIT-Betriebdar.Durchdiese Analyse konnte das Regelwerk der Firewalls „entschlackt“ werden, was auch die Sicherheit im IT-Betrieb erhöhte,danichtmehrverwendeteKommunikationsverbindungengeschlossenwerdenkonnten.DasUn- ternehmengingnocheinenSchrittweiterundforschtenach,wasdieUrsachefürdiesevielenungenutzten

Version4.1 125

[Seite 126]

IPv6-ProgrammdesBundes

Firewall-Regelnwar.Esstelltesichheraus,dassdurchverschiedeAkquisenderletztenJahreüberlappende IPv4-Adressräumemiterworbenwurden.ÜberNATundentsprechendeFirewall-Regelnwurdeversucht,die VerbindungenzudenjeweilsneuenGeschäftsbereicheneinzurichten.NachderIPv6-Migrationderneuen UnternehmensteilewurdeimIT-Betriebvergessen,dieentsprechendenNAT-undFirewall-Regelnzuent- fernen.

InVorbereitungaufdieIPv6-MigrationisteineDetail-AnalysederbestehendenFire- wall-bzw.NAT-Regelnanzuraten.DadurchkönnenimZugederMigration„Altlasten“ imBereichderFirewall-undNAT-Regelnaufgeräumtwerden,wasdieIPv6-Migration Tippsfür deutlichvereinfacht.IndenmeistenNetzen,dieschonlängerbetriebenwerden,sind diePraxis: Sonderkonfigurationenumgesetzt,dieimZugederIPv6-MigrationaufdenPrüfstand gestelltwerdensollten.

Projektbeispiel7:IneinemweiterenUnternehmenausderAutomobil-BranchewurdenSwitchesimRah- meneinesSoftware-Refreshaktualisiert.EshandeltesichumgroßeL3-Switches,welchealsAggregations- switcheseinezentralePositionimNetzhatten.NachdemdasSoftware-Updatedurchgelaufenwar,wurde getestet und diese Tests fielen positiv aus. Nacheiniger Zeit stellte sich jedoch heraus, dass die gesamte IPv6-Kommunikation flächendeckend gestört war. Ein Rollback wurde eingeleitet. Der Software-Refresh wurdeimLabornochmalsnachvollzogenundanalysiert.Esstelltesichheraus,dassdieSwitchesMulticast nichtmehrunterstützten.DadieNeighborDiscoveryvonIPv6überMulticastläuft,warendieClientsvom Next-Hop-Routerabgeschnitten.DasUnternehmennahmKontaktmitdemHerstellerauf,umzuanalysie- ren,wieeszudiesemProblemkam,dadieIPv6-FähigkeitindenHerstellerunterlagenandersausgewiesen war.DasEntwicklerteamdesHerstellersfürdiesenSwitchhattegewechselt.NachdenVorgabenderMar- keting-Abteilung(!)warenSwitchesperDefinition„Layer2“.DasalteEntwicklerteamkanntedenFehlerin derDefinitionundignoriertedieVorgabederMarketing-Abteilung.DasneueEntwicklerteamkanntediesen Fehlernichtundsahsichgezwungen,sämtlicheL3-FeaturesinderSoftwarezuentfernen,inklusiveMulti- cast. Der Hersteller veröffentlichte umgehend ein neues Software-Update, mit welchem die L3-Features wiederimplementiertwurden.

Projektbeispiel 8: Bei der IPv6-Migration eines Konzerns aus dem Energiesektor wurden auch die IPsec- VPN-Tunnelmigriert.DasgewählteRouting-ProtokollfürdasUnternehmenwarOSPF–nachderIPv6-Mig- rationalsoOSPFv3.BeiderIPv6-MigrationderIPsec-Tunnel,welchedieLokationenmiteinanderverbunden hatten, verloren die Router nach und nach alle Routen und damit auch alle Nachbarschaftsbeziehungen. DieKommunikationbrachfolglichzusammen.InderFolgemusstenumfangreicheRollback-Szenarienum- gesetztwerden.DieAnalysendieser SituationindenTestlaborenergaben,dassIPsec keinMulticastwei- terleitet.OSPFverwendetfürdenAustauschderRoutenundweiterNachbarschafts-Kommunikationaller- dings ausschließlich Multicast. Im Ergebnis der Analyse musste das Design nochmals angepasst werden. HierbeigibteszweiMöglichkeiten:EntwederwirdeinanderesRouting-ProtokollverwendetoderdieTun- nelmüssensoangepasstwerden,dasssieauchMulticastweiterleitenkönnen.

AusführlicheTests,welchedieaktuelleNetzwerk-Infrastruktur1:1abbilden,erlauben es,dieseoderähnlicheProblemeimVorfeldzuerkennenundfrühzeitigLösungsmög- Tippsfür lichkeitenzufinden.EinRollbackbelastetalleRessourcenimMigrationsprojektund diePraxis: imIT-Betrieb.

Version4.1 126

[Seite 127]

IPv6-ProgrammdesBundes

9 Anhang

9.1 Checkliste„GrobeIst-Aufnahme“

DieCheckliste„GrobeIst-Aufnahme“wirdimRahmenderMigrationseinzelprojektezurErfassungundBe- wertungdergenutztenIT-KonfigurationselementehinsichtlichihrerAbhängigkeitenundIPv6-Fähigkeitver- wendet.DiesesTemplatedientderDokumentationundverfolgtfolgendeZiele:

• ErlangungvonKenntniszudenamBetriebderIT-KomponentenbeteiligtenStellenundPersonen. • StrukturierteAuflistungderbetriebenenIT-Komponenten. • AnalyseundFeststellungderIPv6-TauglichkeitdereinzelnenaufgelistetenIT-Komponenten. • InformationsgrundlagezurEinschätzungdesInvestitionsbedarfsimRahmenderIPv6-Migration.

DiegrobeIst-AufnahmedientnichtzurErstellungeinesIPv6-AdresskonzeptsoderderErstellungdesMig- rationskonzepts.SiestelltjedochhierfürerforderlicheInformationenbereit.

9.2 PlanungstemplatezurPlanungderMigrationseinzelprojekte

DasPlanungstemplateunterstütztdasProjektmanagementdereinzelnenMigrationen.Konkretlistetesdie notwendigenAktivitätenaufundgibteinenÜberblickderFortschritteundZuständigkeiten.

Das Template besteht aus vier Excel-Blättern: Dem Deckblatt, den Aktivitäten, einem Kanban-Board und denEinstellungen.

9.2.1 Aktivitäten

IndiesemBlattfindensichallezudurchlaufendenAktivitätenjeweilseinmalproIteration.DieIterationist in Spalte C zu finden, die Aktivität in Spalte F und der voraussichtliche Aufwand in Personenstunden in Spalte K. Zusätzlich lassen sich der Status, Verantwortliche, das Start- und Enddatum einstellen. Je nach Statusfärbt sich die Zeile gelb (inArbeit), orange (inKlärung) oder grün (abgeschlossen). Aus dem Start- und Enddatum leitet sich das sich rechts anschließende Gantt-Diagramm ab. Enddaten von Meilenstein- AktivitätensindzudemmiteinerrotenRautegekennzeichnet.

DasBlattlässtsichnachdenunterschiedlichenParameternfiltern,umstetsdenBlickaufaktuelleAktivitä- tenzuwahren.

9.2.2 Kanban

ZusätzlichzumBlattAktivitätengibtesdasKanban-Board.DieszeigtdieAktivitätenjenachStatusproSpalte an. Zur weiteren Gliederung ist eine Sortierung nach Element, Aktivitätenkette oder Verantwortlichem möglich.DieArtderSortierunglässtsichmitdemDropdown-MenüimFeldB5einstellen.

9.2.3 Einstellungen

ImBlattEinstellungenlässtsichdasPlanungstemplateanddasvorliegendeMigrationseinzelprojektanpas- sen.Besonderssei dazu aufdie EinstellungderAnzahlderDurchläufe desRadsderMigrationimFeld B5 hingewiesen.AußerdemsinddieVerantwortlichenundTeamgrößenwichtigfürdieBerechnungderPerso- nenstunden.

Die Tabellen lassen sich nach Bedarf ergänzen und anpassen. In diesem Fall werden automatisch die Dropdown-MenüsimBlattAktivitätenaktualisiert.

Version4.1 127

[Seite 128]

IPv6-ProgrammdesBundes

9.2.4 ListeallerAktivitäten

ListeallerAktivitäten

Version4.1 128

[Seite 129]

IPv6-ProgrammdesBundes

Tabelle27:ListeallerEinzelaktivitäten

Version4.1 129

[Seite 130]

IPv6-ProgrammdesBundes

9.3 Bewertungsmatrix, inkl. Ausschlusskriterien, zur Klassifizierung von Keimzellen-Kan- didaten

DiesesTemplateenthältHinweiseundeineAnleitungzurIdentifikationvonKeimzellenfürdieIPv6-Migra- tionnachdergrobenIst-Aufnahme.

ImTabellenblatt„Identifikation“erfolgtaufderBasisderBewertungskriterien(sieheKapitel3.2)eineBe- wertungderKonfigurationselementemitPunktenjeKriterium.

JemehrPunkteinsgesamterreichtwerden,destobesseristdasKonfigurationselementalsKeimzellenkan- didatgeeignet.

9.4 Kommunikationsplanungstemplate

Das Kommunikationsplanungstemplate stellt einPlanungstemplate für Kommunikationsmaßnahmen dar, welchesBehördenundOrganisationenwährend ihrer IPv6-Migration verwenden können, umeinimEin- klangmitdemIPv6-ProgrammdesBundesstehendes,strategischesKommunikationsmanagementzuetab- lieren.ZieldesProgrammsbeidieserVorlage ist,einmöglichst umfassendesArbeitsdokumentzurVerfü- gungzustellen,ummöglichstvielenBedürfnissengerechtzuwerden.UmsetzendenBehördenoderOrga- nisationstehtesnatürlichfrei,obsiediesesTemplatekomplett,nurinTeilenodergarnichtnutzenmöch- ten.

Um die Verwendungsweise des Dokuments nachvollziehbar darzustellen, sind bereits beispielhafte Kom- munikationsmaßnahmenaufgeführt.DiesesindgleichzeitigEmpfehlungenvonSeitendesProgramms,die umgesetzt,mitdereigenenPlanungergänztoderüberschriebenwerdenkönnen.DasGleichegiltfürZiel- gruppenundKommunikationskanäle.

9.4.1 KommunikationsplanungstemplateBehörden

DasKommunikationsplanungstemplatestelltdenÜberblicküberallevonSeitenderBehördeoderOrgani- sationgeplantenKommunikationsmaßnahmendar.Unterschiedenwirdzwischen:

• Interne Maßnahmen: Kommunikation, die nur für die jeweilige Behörde / Organisation intern be- stimmtist • ExterneMaßnahmen:Kommunikation,dieauchnachaußengeht(andereBehörden,Programm,Me- dienetc.) • Krisenkommunikation:VorbereiteteKommunikationfürdenKrisenfall(z.B.beiDowntimes)

Jenachdem,welcheKategoriegewähltwird,werdenMaßnahmenviaDropdownvorgeschlagen.DieseVor- schlägekönnenunter„Einstellungen“angepasstwerden.DerausgewählteTyp(inPlanungoderfixiert),die KadenzsowieStartundEndebeeinflussendieDarstellungimdanebengezeigtenGantt-Chart.Dieseskann beiBedarfauchangepasstwerden.

9.4.2 NotwendigeAktivitäten

WeiterführendkanneinedetaillierteTo-Do-ListezurUmsetzungdernotwendigenAktivitätengeführtwer- den.IndiesemTemplatekönneneinzelneAufgabenaufgelistetsowieumverantwortlichePersonen,Dead- linesundWichtigkeitenergänztwerden.Diesistbesondershilfreich,wennmehrerePersonenanderUm- setzungarbeitenunddieArbeitsteilungfürallePersonenklarersichtlichseinsoll.

Version4.1 130

[Seite 131]

IPv6-ProgrammdesBundes

9.4.3 Einstellungen

DiesesArbeitsblattenthältdieListen,welcheimKommunikationsplanungstemplatehinterlegtsind.Diese sindalsVorschlägezubetrachten,wennandereStakeholderoderMaßnahmenverwendetwerden,können diesehierhinterlegtwerden.

9.4.4 ÜberblickZiele

DasIPv6-ProgrammdesBundeshat10Kommunikationszieledefiniert,diefürdasProgrammerreichtwer- densollen.Daheristesauchwichtig,dassdieseZieleindieEinzelmigrationsprojekteweitergetragenwer- den. Im Arbeitsblatt 5 ist aus diesem Grund ein Überblick und eine Beschreibung dieser Ziele zu finden. DiesesindauchimKommunikationsplanungstemplatebeiderSpalte„Hauptziel“hinterlegt.

9.4.5 ÜberblickProgrammmaßnahmen

DasletzteArbeitsblattdientzurInformationüberdiezentralenKommunikationsmaßnahmen,diedasIPv6- ProgrammdesBundesaktivführtoderplant.AufdieserBasiskönnenauchMaßnahmenderBehördenund Organisationenzeitlichabgestimmtwerden,fallserforderlich. Esistzu beachten,dasssichdiesePlanung regelmäßigändert.

9.5 Wirtschaftlichkeitsbetrachtung(WiBe)

DieMigrationseinzelprojektesindnachdenAnforderungendesBRH gehalten,eineWirtschaftlichkeitsbe- trachtung(WiBe)durchzuführen.Umsiezuentlasten,stelltdasIPv6-ProgrammUnterstützungbereit.Sie besteht ausdedizierten WiBe-Coaches,einem Konzept für die WiBe der Migrationseinzelprojekte, einem TemplatefürdiemonetäreWiBe(KW)undeinemThemenbereichaufderKommunikations-undInterakti- onsplattform.

DasTemplatefürdieWiBeKWistdasKernstückdervomProgrammbereitgestelltenUnterstützung.Zum einen ermöglicht es das Template, die Werte der Migrationseinzelprojekte zentral zu erfassen und stellt dabeidieErgebnisseineiner Formbereit,diedenAnforderungendesFachkonzeptsWiBe5.0entspricht. ZumanderensindmitdemTemplateModellrechnungenfüreinekleine(bis1.000Mitarbeitende),mittlere (1.001bis2.999Mitarbeitende)undgroße(ab3.000Mitarbeitende)BehördeoderOrganisationdesBundes verbunden.Auf derGrundlage dieserVorlageistesfürdie Migrationseinzelprojekte möglich,ihre Zahlen mitgeringemAufwandzuermitteln.DabeiunterstütztderWiBe-Coach,zudessenServiceleistungenesge- hört,dieEinträgeindasTemplatevorzunehmen.

Nebender monetärenBewertungvonIT-Projekten sindnochdie qualitativ-strategischen Kriterien(WiBe Q)unddieExternenEffekte(WiBeE)zuerstellen.FürbeidesiehtdasFachkonzeptWiBe5.0vor,zehnKri- terienzuevaluierenundqualitativzubewerten.FürdieWiBeQhatdasIPv6-ProgrammeineWiBeerstellt, dieweitestgehendvondenMigrationseinzelprojektenübernommenwerdenkann,dadieAusgangslageund Rahmenbedingungenfastvollständigdeckungsgleichsind.

Für die WiBe E gilt das nicht, denn es geht hierbei um die externen Kunden. Die sind bei den einzelnen BehördenundOrganisationendesBundesverschieden.EshängtvonihremgesetzlichenAuftragab,welche Personengruppen, Institutionen, Unternehmen etc. dazu gehören. Daher ist es notwendig, das in jedem Einzelfall zu betrachten. Der WiBe-Coach liefert den Migrationseinzelprojekten dazu in einem Workshop Hilfestellungen.

Version4.1 131

[Seite 132]

IPv6-ProgrammdesBundes

9.5.1 WiBeKW

Die Migrationseinzelprojekte können für ihre WiBen die Unterstützung durch den WiBe-Coach buchen. Wann eine Behörde oder Organisation des Bundes das IPv6-Migrationsprojekt beginnt, hängt davon ab, welchem Bündel sie angehört. Im Konzept WiBe für Migrationseinzelprojekte ist empfohlen, eine erste WiBevordergrobenIst-Aufnahmezuerstellen.

FolgendeVersionenderWiBesindvorgesehen,wobeidieBezeichnungenmitdemFachkonzeptWiBe5.0 abgeglichensind:

• GrobeIst-Aufnahme(entsprichtVorkalkulation) • ErsterDurchlauf„RadderMigration“,wieimKapitel3empfohlen(entsprichtEntscheidungsgrundlage zuFeinkonzept) • WeitereDurchläufe„RadderMigration“,wieimKapitel3empfohlen(entsprichtbegleitendeVersionen Realisierung) • ErreichenderMigrationsquote(entsprichtErfolgskontrolleÜbergangWirkbetrieb) • AbschlussMigration,andereMeilensteine(entsprichtweitererErfolgskontrolleimWirkbetrieb).

9.5.2 TemplateWiBeKW

Der Bundesrechnungshof (BRH)wünschte eine Vergleichbarkeit der WiBender Migrationseinzelprojekte. Dieseistnichtzugewährleisten,wennFormelnzurBerechnung,Kostensätze,Parameter imTemplateab- wandelbarsind.DasWiBeTemplateerlaubtdahernurdieEingabevonWertenfürdieMigrationseinzelpro- jekte, nicht aber die Veränderungder Struktur. Die Werte für die Personalkostensätze undweiterePara- meter gibt das BMF jährlich vor. Das IPv6-Programm übernimmt es, die aktuellen Werte zentral in das Templateeinzupflegen.ImTemplatesinddieJahre2023–2040hinterlegt.DasWiBe-KonzeptdesIPv6-Pro- grammsempfiehlt,einenBetrachtungszeitraumvon15Jahren anzunehmen,dadieEffekte,diezueinem positivenKapitalwertführenkönnen,erstübereinenlängerenZeitraumeintreten.Eshandeltsichdabeiin ersterLinieumdieAusgabenfürdieAdministrationvonIPv4,diedurcheineMigrationaufIPv6vermieden werden.

DasTemplatezeigtimerstenTabellenblattdasErgebnisderBerechnungan.AufgegliedertnachJahrenso- wieunterteiltinhaushaltswirksam(hw)undnichthaushaltswirksam(nhw)sinddieWerteaufgeführt.Unter demReiterBerechnungistausgewiesen,wiesichdieKostensteigerungenfürinternesundexternesPerso- nal(BeratungundUnterstützungsleistungen),IT-Produkte/ServicesüberdieZeitinProzentzahlenproJahr auswirken.ImReiterRisikokönnendieMigrationseinzelprojektedieRisikowerte,diesieindeneinzelnen Kategoriensehen,eintragen.DiewerdenindieBerechnungübernommen.ImReiterRohdatenerfolgtdie EingabederWertefüreinzelnenKriterienderWiBeKW.Unter ParametersinddieWertefürdiePKSein- sehbar,diedasBMFvorgibt.

Version4.1 132