ipv6: are we really ready to turn off ipv4? · ipv6 fragmentation is very unreliable why don’t we...

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!