49
IPv6: Are we really ready to turn off IPv4?
IPv6: Are we really ready to turn off
IPv4?
The IPv6 Timeline…
1990 2000 2010 2020
The IPv6 Timeline…
1990 2000 2010 2020
Yes, we’ve been working on this for close to 30 years!
The IPv6 Timeline…
1990 2000 2010 2020
Yes, we’ve been working on this for close to 30 years!
In-situ transition…
In-situ transition…
IPv4 Internet
Phase 1 – Early Deployment
Edge Dual -Stack Networks
IPv6 networks interconnect byIPv6-over-IPv4 tunnels
In-situ transition…Phase 2 – Dual Stack Deployment
Edge Dual-StackNetworks
IPv6 networks interconnect byDual Stack transit paths
Transit Dual-StackNetworks
In-situ transition…
IPv6 Internet
Phase 3 – IPv4 Sunset
Edge Dual Stack Networks
IPv4 networks interconnect byIPv4-over-IPv6 tunnels
In-situ transition…
IPv4PoolSize
IPv6Deployment
SizeoftheInternet
Dual Stack Transition
We’re pretty lousy at following plans!
We’re stuck in Phase 2
Some15%- 20%ofInternetusershaveIPv6capability
MostnewIPdeploymentsuseIPv6+(NATTED) IPv4
IPv4-onlyLegacynetworksarebeing(gradually)migratedtodualstack
The Map of IPv6 penetration – August 2017
The Map of IPv6 penetration – August 2017
We’re stuck in Phase 2
Some15%ofInternetusershaveIPv6capability
MostnewIPdeploymentsuseIPv6
IPv4-onlyLegacynetworksarebeing(gradually)migratedtodualstack
Today
Weappeartobeinthemiddleofthetransition!
DualStack networksuseappsthatprefertouseaIPv6connectionoveranIPv4connectionwhenbothareavailable
ThisimpliesthatthehighertheIPv6deploymentnumbersthelessthelevelofuseofV4connection,andthelowerthepressureontheNATbindingclients
Today
Weappeartobeinthemiddleofthetransition!
DualStack networksuseappsthatprefertouseaIPv6connectionoveranIPv4connectionwhenbothareavailable(*)
ThisimpliesthatthehighertheIPv6deploymentnumbersthelessthelevelofuseofV4connection,andthelowerthepressureontheNATbindingclients
Couple of problems with this:
This preference is often relative, and in the quest for ever faster connections the ante keeps rising – Apple is now pressing for a 50ms differential. This means that there is strong pressure for the IPv4 and IPv6 routing systems to be congruent – and this is just not the case today!
Secondly, it’s a client/server Internet, rather than a client/client network, and the number of end clients running IPv6 has to be matched against the server population
*
Today
Weappeartobeinthemiddleofthetransition!
DualStack networkscannotdropsupportforIPv4aslongassignificantservicesanduserpopulationsdonotsupportIPv6– andwecan’ttellwhenthatmaychange
Nobodyisreallyinapositiontodeployarobustat-scaleipv6-onlynetworkservicetoday,eveniftheywantedto!
Andwearenotevensureifwecan!
Today
Weappeartobeinthemiddleofthetransition!
DualStack networkscannotdropsupportforIPv4aslongassignificantservicesanduserpopulationsdonotsupportIPv6– andwecan’ttellwhenthatmaychange
Nobodyisreallyinapositiontodeployarobustat-scaleipv6-onlynetworkservicetoday,eveniftheywantedto!
Andwearenotevensureifwecan!
The Issue
WecannotrunDual-Stackservicesindefinitely
AtsomepointweneedtosupportnetworksthatonlyhaveIPv6
Isthatviable?
In other words…
WhatdowerelyontodayinIPv4thatdoesnotappeartohaveaclearworkingcounterpartinIPv6?
In other words…
WhatdowerelyontodayinIPv4thatdoesnotappeartohaveaclearworkingcounterpartinIPv6?
Iftheansweris“nothing”thenwearedone!
Butifthereisanissuehere,thenweshouldbeworkingonit!
Version IHL Total Length
FlagsIdentification Fragment Offset
Time To Live
Source Address
Destination Address
Options Padding
Protocol Header Checksum
Type of Service
Version Class Flow
Payload Length Hop Limit
Source Address
Destination Address
Next Header
IPv4 Header
IPv6 Header
IPv6: What changed?
IPv6: What changed?
TypeofServiceischangedtoTrafficClass
32bitFragmentationControlwerepushedintoanExtensionHeader
FlowLabelAdded
OptionsandProtocolfieldsreplacedbyExtensionHeaders
Checksumbecomesamedialayerfunction
IPv6: What changed?
TypeofServiceischangedtoTrafficClass
32bitFragmentationControlwerepushedintoanExtensionHeader
FlowLabelAdded
OptionsandProtocolfieldsreplacedbyExtensionHeaders
Checksumbecomesamedialayerfunction
IPv6: What changed?
TypeofServiceischangedtoTrafficClass
32bitFragmentationControlwerepushedintoanExtensionHeader
FlowLabelAdded
OptionsandProtocolfieldsreplacedbyExtensionHeaders
Checksumbecomesamedialayerfunction
IPv4 Router
IPv4 header
PayloadTCP/UDP header
IPv4 header
PayloadTCP/UDP header1
2
IPv6: What changed?IPv4 “Forward Fragmentation”
IPv4 Router
IPv4 header
PayloadTCP/UDP header
IPv4 header
PayloadTCP/UDP header
IPv6 Router
IPv6 header
PayloadTCP/UDP xtn header
PayloadTCP/UDP xtn header
ICMPv6 PTBIPv6 header
IPv6 header
PayloadTCP/UDP xtn header
Fragmentation xtn header
1
2
3
12
IPv6: What changed?IPv4 “Forward Fragmentation”
IPv6 “Source Fragmentation”
Source
Source
New Dependencies
ForIPfragmentationtoworkinIPv6then:
- allICMPv6messageshavetobepassedbackwards fromtheinteriorofthenetworktothesender
- IPv6packetscontainingaIPv6FragmentationExtensionheadershouldnot bedropped
ICMPv6
Onlythesendinghostnowhascontroloffragmentation– thisisanewtwist
AreceivedICMPv6messageneedstoalterthesender’sstatetothatdestination
ForTCP,iftheICMPpayloadcontainstheTCPheader,thenyoucanpassthistotheTCPcontrolblock.TCPcanalterthesessionMSSandresendthedroppeddata,oryoucanjustalterthelocalper-destinationMSSandhopethatTCPwillbepromptedtoresend
ForUDP – um,err,umwell
ICMPv6
Onlythesendinghostnowhascontroloffragmentation– thisisanewtwist
AreceivedICMPv6messageneedstoalterthesender’sstatetothatdestination
ForTCP,iftheICMPpayloadcontainstheTCPheader,thenyoucanpassthistotheTCPcontrolblock.TCPcanalterthesessionMSSandresendthedroppeddata,oryoucanjustalterthelocalper-destinationMSSandhopethatTCPwillbepromptedtoresend
ForUDP – um,err,umwell
MaybeyoushouldstoretherevisedpathMTUinahost forwardingtablecacheforawhile
IfyoueverneedtosendanotherUDPpackettothishostyoucanusethiscacheentrytoguideyourfragmentationbehaviour
ICMPv6 and Anycast
Sender InstanceClient
Sender Instance
Sender Instance
Anycast Constellation
Sender Instance
Sender Instance
Itisnotobvious(orevenassured)thateveryrouteronthepathfromananycastinstancetoaclienthostwillnecessarilybepartofthesameanycast instance“cloud”
Theimplicationisthatinanycast,thereverseICMPv6PTBmessageswillnotnecessarilyheadbacktotheoriginalsender!
IPv6 Fragmentation Extension Header Handling
TheextensionheadersitsbetweentheIPv6packetheaderandtheupperlevelprotocolheaderfortheleadingfraggedpacket,andsitsbetweentheheaderandthetrailingpayloadfragsforthetrailingpackets
Practically,thismeansthattransport-protocolawarepacketprocessors/switchesneedtodecodetheextensionheaderchain,ifitspresent,whichcanconsumeadditionalcyclestoprocess/switchapacket– andtheadditionaltimeisnotpredictable.Fortrailingfragsthereisnotransportheader!
OrtheunitcansimplydiscardallIpv6packetsthatcontainextensionheaders!
WhichiswhatalotoftransportprotocolsensitiveIPv6deployedswitchingequipmentactuallydoes(e.g.loadbalancers!)
IPv6 header
Payload
TCP/UDP xtn header
Fragmentation xtn header
IPv6 Fragmentation Extension Header Handling
Thereisalotof“drop”behaviour intheIpv6InternetforFragmentationExtensionheaders
RFC7872– recordeddropratesof30%- 40%
Thisexperimentsentfragmentedpacketstowardswell-knownserversandobservedwhethertheserverreceivedandreconstructedthefragmentedpacket
Butsendingfragmentedqueriestoserversisnotallthatcommon– thereversesituationofbigresponsesismorecommon
SowhataboutsendingfragmentedpacketsBACK fromservers– what’sthedroprateofthereversecase?
IPv6 Fragmentation Extension Header Handling
Weusedanad-basedmeasurementsystem,usingacustompacketfragmentationwranglerasafrontendtoaDNSandWebservertotestIPv6fragmentationbehaviour
Client
DNS Resolver IPv6 DNS Server
IPv6 NGINX Server
IPv6 ‘Fragmenter’DNS Goo
Weusedanad-basedmeasurementsystem,usingacustompacketfragmentationwranglerasafrontendtoaDNSandWebservertotestIPv6fragmentationbehaviour
IPv6 Fragmentation Extension Header Handling
Client
DNS ResolverIPv6 ‘Fragmenter’DNS Goo
We use a technique of “glueless” delegation and fragmentation of the NS query response to allow us to detect if the DNS resolver received the fragmented response
We track TCP ACKs at the server to see if the client received the fragmented TCP response
Client
DNS Resolver IPv6 DNS Server
IPv6 NGINX Server
IPv6 Fragmentation Extension Header Handling
OurExperimentswererunacrosssome40Mindividualsamplepoints:
37%ofenduserswhousedIPv6-capableDNSresolverscouldnotreceiveafragmentedIPv6DNSresponse
20%ofIPv6-capableenduserscouldnotreceiveafragmentedIPv6packet
IPv6 Fragmentation is very unreliable
Whydon’tweseethisunreliabilityintoday’sIPv6networksaffectingusertransactions?
IPv6 Fragmentation is very unreliable
Whydon’tweseethisunreliabilityintoday’sIPv6networksaffectingusertransactions?
BecauseIPv4papersovertheproblem!
IPv6 Fragmentation is very unreliable
Whydon’tweseethisunreliabilityintoday’sIPv6networksaffectingusertransactions?
BecauseIPv4papersovertheproblem!
InaDual-StackenvironmentthereisalwaystheoptiontofliptouseIPv4ifyouarestuckwithIpv6.
TheDNSdoesthis,andHappyEyeballsdoesthis
Sothereisnouser-visibleprobleminadualstackenvironment
ThismeansthatthereisnourgentimperativetocorrecttheseunderlyingproblemsindeployedIPv6networks
IPv6 Fragmentation is very unreliable
Whydon’tweseethisunreliabilityintoday’sIPv6networksaffectingusertransactions?
BecauseIPv4papersovertheproblem!
InaDual-StackenvironmentthereisalwaystheoptiontofliptouseIPv4ifyouarestuckwithIpv6.
TheDNSdoesthis,andHappyEyeballsdoesthis
Sothereisnouser-visibleprobleminadualstackenvironment
ThismeansthatthereisnourgentimperativetocorrecttheseunderlyingproblemsindeployedIPv6networks
Living without IPv6 Fragmentation
Ifweapparentlydon’twanttofixthis,canwelivewithit?
WearelivingwithitinaDualStackworld,becauseIPv4justmakesitallbetter!
ButwhathappenswhenthereisnoIPv4left?
Living without IPv6 Fragmentation
Ifweapparentlydon’twanttofixthis,canwelivewithit?
WearelivingwithitinaDualStackworld,becauseIPv4justmakesitallbetter!
ButwhathappenswhenthereisnoIPv4left?
TCPcanworkaslongasIPv6sessionsuseconservativeMSSsizes
UDPcanworkaslongasUDPpacketsizesarecappedsoastoavoidfragmentation
We have to avoid IPv6 Fragmentation!
Living without IPv6 Fragmentation
TCPcanworkaslongasIPv6sessionsuseconservativeMSSsizes
UDPcanworkaslongasUDPpacketsizesarecappedsoastoavoidfragmentation
We have to avoid IPv6 Fragmentation!
DNSSEC!
What can we do about it?
A. Get all the deployed routers and switches to deliver ICMPv6 packets and accept packets with IPv6 Fragmentation Headers
What can we do about it?
B. Get all the deployed routers and switches to alter the way IPv6 manages packet fragmentation
What can we do about it?
C. Move the DNS off UDP
Where are we?Intermsofprotocolsupportandreliability,ItseemsthatwearemostlyreadyforanIPv6-onlyenvironment,withtheoneexceptionofIPv6packetfragmentationhandling.
Theconsequenceisthattoday’senvironmentcannotsupportanIPv6-onlyenvironmentfortheDNS,andDNSSECinparticular
Change the deployed IPv6 network and change vendor equipment to correctly manage fragmentation, and stop using anycast!
Change host configurations and change the DNS protocol to avoid any reliance on IPv6 fragmentation
An IPv6-only Internet?TheissueoftheunreliabilityofIPv6fragmentationisasignificantissue.
Thesemitigationapproachesrepresentsignificanteffortandcost
EffortandcostthatisunnecessaryforaslongasIPv4canpaperovertheproblem!
Sowearetakingtheeasyoption,andcollectivelywearedoingnothingatall!
An IPv6-only Internet?TheissueoftheunreliabilityofIPv6fragmentationisasignificantissue.
Thesemitigationapproachesrepresentsignificanteffortandcost
EffortandcostthatisunnecessaryforaslongasIPv4canpaperovertheproblem!
Sowearetakingtheeasyoption,andcollectivelywearedoingnothingatall!
Thanks!
