IPv6prefixassignmentforend-customers- persistentvs non-

persistent,andwhatsizetochoose.

(BestCurrentOperationalPracticeforoperators)JanŽorž,InternetSociety/Zavod Go6

Whatisthisdocumentallabout?• ThisdocumentdiscussesthemainissuesrelatedtotheoperationalpracticesfortheassignmentofIPv6prefixesforend-customers.

• MakingwrongchoiceswhendesigningyourIPv6networkwillsoonerorlaterhavenegativeimplicationsonyourdeploymentandrequirefurthereffortsuchasrenumberingwhenthenetworkisalreadyinoperation.Thetemptationtotake“easy”approachesforquickerdeploymentshouldthereforeberesisted.

Co-authors• JanŽorž <zorz@isoc.org>,• SanderSteffann <sander@steffann.nl>,• Primož Dražumerič <Primoz.Drazumeric@telekom.si>,• MarkTownsley <townsley@cisco.com>,• AndrewAlston<andrew.alston@liquidtelecom.com>,• Gert Doering <gert@space.net>,• Jordi Palet <jordi.palet@consulintel.es>,• JenLinkova <furry@google.com>,• LuisBalbinot <lbalbinot@brfibra.com.br>,• KevinMeynell <meynell@isoc.org>,• LeeHoward<lee.howard@retevia.net>

Draftv.1

• https://sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf• [root@webserver]#grep draft-IPv6pd-BCOP-v1.pdfsinog-ssl_access_log*|wc -l

909

Draftv.2

• https://sinog.si/docs/draft-IPv6pd-BCOP-v2.pdf• Numberofcommentsandsuggestionson-listandoff-list…

• PresentedandgatheredsomecommentsalsoatRIPEBCOPTFmeetingonMonday

• Majorityofco-authors,presentatRIPE74meetinginBudapestgatheredinalobbybaronTuesdaytodotheeditorialcycle,followedbylanguagepass.

• SenttoRIPEIPv6mailingliston11th Mayat02:44am

Editingdraftv.2

Agenericsetofrecommendations:

a)IPv6isnotthesameasIPv4.InIPv6youassignanumberof“n”/64prefixestoeachend-customersite,sotheyareabletohaveasmanysubnetsastheywish.YoushouldnotbeconcernedwithexhaustingtheIPv6addressingspace,andyoushouldthinkbigwhenplanningfuturerequirements.Ifyouneedmorespace,youcangobacktoyourRegionalInternetRegistryandprovidingyouraddressingplanjustifiesit,youcanobtainmoreIPv6addresses.

Agenericsetofrecommendations:b)Ifyouwantasimpleaddressingplan,youshouldconsiderthesethreeoptions:1)/48foreachend-customer.ThiswillworkverywellforcustomerscomingfromotherISPs,thosethathavetheirownULA,orhavebeenusingtransitionmechanisms.Thiswillalsobeeasierwhenyouhaveamixofcustomersusingthesameinfrastructure,whethertheyareresidentialcustomers,SMEsorevenlargecorporates.2)Differentiateamongsttypesofcustomers,evenifthiswillincreasethecomplexityofyournetworkandthoseofyourcustomers,byoffering/48forbusinesscustomersand/56forresidentialcustomers.3)Atrade-offamongsttheprevioustwooptionsbyreservinga/48forresidentialcustomers,butactuallyjustassigningthemthefirst/56.Thereaspecificcaseforcellularphonestobeassignedasingle/64pereachPDPcontext,butthisisoutofscopeofthisdocument.

Agenericsetofrecommendations:

c)Inordertofacilitatetroubleshootingandhaveafutureproofnetwork,youshouldconsidernumberingtheWANlinksusingGUAs(GlobalUnicastAddresses),usinga/64prefixoutofadedicatedpoolofIPv6prefixes.Ifyoudecidetouse/127foreachpoint-to-pointlink,itisadvisabletoallocatea/64foreachlinkandjustuseone/127outofit.

Agenericsetofrecommendations:

d)Non-persistentprefixesareconsideredharmfulinIPv6asyoucan’tavoidissuesthatmaybecausedbysimpleend-customerpoweroutages,soassigningpersistentprefixesisasaferandsimplerapproach.Furthermore,thisavoidstheneedforexpensivelogging,increasesyourchancestooffernewbusinesstocustomers,anddecreasesyourcustomerchurn.

Acknowledgements

TheauthorswouldliketothankNathalieKunneke-Trenaman,MikaelAbrahamsson,JasonFesler,MartinLevy,IanDickinson,PhilipHomburg, IvanPepelnjak,MatthiasKluth,Ondřej Caletka,NickHilliard,PaulHoffmanandRomanNurul Islamforconstructivecritic,suggestionsandideashowtomakethisdocumentbetter.SpecialthanksgotoRIPEIPv6WorkingGroupcommunityandChairsforacceptingthisdocumentfortechnicalreview,andalsotheRIPEBCOPTaskForcecommunityandChairsforensuringitdoesconformwithactualbestoperational practice.

Q&A

Suggestions?Comments?

Ideas?

Wayforward?