InDefence ofNATsGeoffHuston

APNIC

IEEEGlobalInternetSymposium,May2017

TheArchitectureofthe1990Internet“DumbNetwork,SmartHosts”

Removeallthefunctionalityfromthenetworkapartfromforwardingandbuffering

Placealltheresponsibilityfordataflowintegrityandcontrolintotheendhostprotocolstacks

TheArchitectureofthe1990InternetEachIPheadercarriessufficientinformationtoenableanetworkofstatelessforwarderstopassapackettoitsintendeddestination

Version IHL Total Length

FlagsIdentification Fragment Offset

Time To Live

Source Address

Destination Address

Options Padding

Protocol Header Checksum

Type of Service

DataFlow

Application Application

Transport Transport

Internet InternetInternetInternetInternet

Link Link Link Link Link

HosttoHost

ProcesstoProcess

TheintentionwasthatonlytheIPheaderisusedbythenetwork,andtheentireremainderofthepacket,includingthetransportheaders,isanopaquepayload

Eachpacketcanbeforwarded(optionallyfragmented) ordiscarded

IP’sStrengths

• Thereisno“setup”and“teardown”ofnetworkstate

• Thereisnorequirementforsymmetrybetweenforwardandreversepacketflows

• Whileitispreferredthatthenetworkmaintaintheorderofpackets,it’snotastrictrequirement

• End-to-EndTransportandHop-by-HopForwardingaredecoupled:theend-to-endtransportprotocolisahostchoice,notanetworkchoice

Consequences

• IPaddressesaregloballysignificantuniqueidentifiers– theyarenotlocalvirtualcircuitidentifiers

• AllIProutersneedtobeawareoftherelativelocationofallactiveIPaddresses

• ThetotalcapacityofthenetworkislimitedbythenumberofIPaddressesandtheabilitytorepresenttherelativelocationofalltheseaddresseswithineveryrouter

Proceedingsofthe18th IETFMeetingAugust1990

“InternetGrowth”FrankSolensky,Proc.IETF,Aug1990

Proceedingsofthe18th IETFMeeting

“InternetGrowth”FrankSolensky,Proc.IETF,Aug1990

Address“Classes”

• EachIPaddresshasanetworkpartandahostpart• TheoriginalIPv4addressplandividedtheIPv4addresspoolintothree“Classes”

https://en.wikipedia.org/wiki/Classful_network

RemovingClasses

• Theproblemwasnot thatwewererunningoutofaddresses

• TheproblemwasthatwewererunningoutofClassBaddresses

• Theadoptedsolutionwastokeeptheimplicitroutingaggregationofthenetwork/hostdivisionofaddresses,butcarrythenetwork/hostdivisionpointwiththeaddressprefixE.g.192.0.2.0/24

Length of network prefix in bits

CIDRWorked!

March 1994 – deployment of CIDR in BGP-4

Pre-CIDR Routing Table Growth

Post-CIDR Routing Table Growth

“BuyingTime”wasjustastopgapmeasure• Theunderlyingissuewasthepersonalcomputer,whichdramaticallyincreasedthenumbersofconnecteddevicesandindirectlyfueledthefirstwaveofcommercializationoftheInternet

• Andthiswasnotgoingtostop– laptops,themobiledevicesalladdedtothenumbersofconnecteddevices

• Thethinkingatthetimewastochangeaslittleaspossible,sowethoughtthatenlargingtheaddressfieldsoftheIPheaderwouldbesufficienttomeetthischallengetoscaling

• TheanswerthatwasadoptedbytheIETFwasIPv6

TheoriginsofIPv6

• IPv6representedaminimalchangetoIPv4• SomeaspectsofIPwerechanged:

• Expandedaddressfields• Alteredfragmentationcontrols• Re-formattedoptionsandcontrolfields

• Muchwasunaltered:• UDPandTCPtransportprotocolbehaviour• Hop-by-hopdestination-baseddatagramforwarding

• Andsomewasunspecified:• IPv6AddressPlan

ThereweremanyotherideasthatwereairedatthetimeAndoneofthemwasamechanismforaddress”sharing”

AddressSharing

NAT

Private AddressRealm

PublicAddressRealm

Version IHL Total Length

FlagsIdentification Fragment OffsetTime To Live

Source AddressDestination Address

Options Padding

Protocol = 6 Header Checksum

Type of Service

IPHeade

rTCP

Destination PortSource PortSequence Number

Acknowledgment NumberDataoffset

FIN

SYN

URG

ACK

PSH

RST

Window

Checksum UrgentPointer

PaddingTCP OptionsTCP Data

TheseNATsallowaddresssharingbyusingthetransportprotocol’sportfieldsaspartoftheaddress‘distinguisher’

Port-TranslatingNATs

NAT

BindingtableSourceAddress/Port+Dest Address/Port SourceAddress/Port+Dest Address/Port

”Inside” ”Outside”

NATstakethe96-bit4-tupleofProtocol+Address+Ports andreplacethepacket’sfieldsthatmatchonesideofthebindingtablewiththefieldsontheotherside

Outboundpacketsthatdonotmatchanybindingtablegenerateanewtableentry

Inboundpacketsarediscarded

NATs:

• Enforcesymmetricnetworkpaths• Requiresessionstatewithinthenetwork• EnforceClient/Serverarchitecture• Createfragilityinthenetwork• Violatelayerintegrity• Motivatetheuseofproxiesandgateways• Preventinnovationintransportservices• HandleUDPbindingsinconsistently

NATsareEvil!

• TheseconsiderationsledtoalongheldmantraintheIETFthat“NATSareevil”andtheIETFrefusedtoworkonstandardizingNATbehaviour formanyyears

• TheconsequencewasthatNATsweredevelopedwithidiosyncraticbehaviours,particularlyinrelationtoUDP-basedbinding

• Whichledtoallkindsofconvolutedapplicationlevelbehaviours todiscoverandadapttotheNATsinthepath(STUN,TURN,ICE,TEREDO,…)

Andyet…

NATsruntoday’sInternet

• 2.8BadvertisedIPv4Addresses• 25Bconnecteddevices*• Theaverageaddresssharingratioappearstobe10:1

NATsareeverywhere!

*https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

WhyareNATssopervasive?

• Theyarebackwardcompatiblewiththeexistingnetwork• Theyallowforuncoordinatedpiecemealdeployment• Theyimpairopenpeertopeerconnectivityandenforceclientbehaviours behindtheNATs

• Theyusetheportspacetoenlargetheeffectiveaddressspace

HowfarcanwepushNATs?

I have 7,000 DSL broadband customers behind it. Peak time throughput is hitting up at 4 gbps... I see a little over 100,000 service flows(translations) at peak time

I think each MX104 MS-MIC-16G can able about ~7 million translations and about 7 gbps of cgnatthroughput... so I'm good.

I have a /25 for each MX104 outside public address pool (so /24 total for both MX104's)... pretty sweet how I use /24 for ~7,000 customers :)

AaronGould,NANOG,https://mailman.nanog.org/pipermail/nanog/2017-April/090809.html

HowfarcanwepushNATs?

TheNATbindingspaceisa96bitswide4-tuple

NATtype:CGNwithperuserportblocksCGNwithperuserportblocks+pooledoverflowCGNwithpooledportsCGNwith4-tuplebindingmaps

AddressCompressionRatio

10:1100:1

1,000:1>>10,000:1

SourceAddress/Port+Dest Address/Port96 bits

So,incomparison,whatdoesIPv6offer?• BackwardCompatibilitywithIPv4?

• Nope!

• Moreaddressbits?• ThecurrentIPv6addressplanstypicallyusea48bitendsiteprefix• CGNats potentiallypushthevirtualIPv4addressspacetobetween42and45

bits

• Moreflexibility?• Itisunclearifthereisaclearneedtoshiftbacktotheoverloadedlocation/

identifiersemanticsofaddressesastheclient/servermodeliscloselyalignedtotoday’sInternet

• Lesscost?• Wellno– foraslongasIPv4remainsthedominantprotocolthentheInternet

needstosupportIPv4,whichimpliestheuseofNATs.ItisIPv6thatisthediscretionaryexpenditureitemformanyserviceproviders

NATsareunder-appreciated!

Forsometimenowwehavebeencontemplatingwhatitmeanstohaveaname-baseddatanetwork,whereinsteadofusingafixedrelationshipbetweennamesandIPaddresses,weeschewthismappingandperformnetworktransactionsbyspecifyingthenameofthedesiredserviceorresource

NATsareunder-appreciated!

NATsareaninterestingstepinthisdirection,whereIPaddresseshavelosttheirstaticassociationwithparticularendpoints,andareusedmoreasephemeralsessiontokensthanendpointlocators.

NATsareunder-appreciated!

Thiscertainlyappearstobeaninterestingstepinthedirectionofnameddatanetworking whereaddressesloseanypermanentassociationwithendpointidentity,andretainonlythefixedsemanticsofanetworklocatorusedinrouting

InDefence ofNATs

• ItisNATsthathavekepttheInternetrunningforthepastdecade

• Inthattimethenetworkhasgrownfromaround2Bconnecteddevicestotentimesthatnumber

• TheIPv4networkanditsapplicationsuiteisnowbuiltontheassumptionofpervasiveuseofNATs

• ThesesameapplicationandservicedesignparametersareusedinthecontextofIPv6

IPv6Addresses

• Doweuse“fixed”endaddressesinIPv6anyway?• Well,no,notallthetime!

• Clientstypicallyuse“privacy”addressesthatusearandom64bitinterfaceidentifier

• SotheIPv6IPendaddressisnowephemeralforclients

• Servicesareincreasinglyusingnamebasedhosting• TherearemoreleversandcontrolpointsintheDNSasdistinctfromIPanycast

• SoevenIPv6haseschewed“fixed”endaddressing!

NATsinIPv6

Forsomethisisheresy!However:

• IPv6hasalreadydissociateditselffromfixedendaddresses• wehavealreadymarkedoffULAsasprivateuseIPv6addressprefixes(fc00::/7– RFC4193)

• PersistentprivateaddressesandNATsavoidforcedsiterenumbering

• NATsallowsitemulti-homingwithoutroutede-aggregation• NATsobscureinternalsitenetworkdetailsandenforceclientobscurity

• AsIPv6gathersmomentumitmaybethecasethatnetworkadminswilluseULAprefixesplusNATstore-createtheIPv4NATarchitectureinIPv6

InDefence ofNATS

• MaintaininganetworkinfrastructurethatuniquelynamesandnumberseveryattacheddevicehasprovedtobeeconomicallyinfeasibleintheInternet

• NATssegmentthedevicepopulationintoclientsandservers- Clientsarenotuniquelynamed,noruniquelyaddressed

• Wemaynothaveplanneditthisway,butundeniablywhatkeepstoday’sInternetrunningasa singlecosteffectivenetworkisNATs.

NATsaspartoftheArchitecture

• NATshavepushedthenetworkintoamodewhereIPaddressesareephemeralconversationtokenswithoutlastingsignificanceasanendpointidentifier

• Forclients,addressuniquenessisalocallyscopedproperty,ratherthanagloballyscopedattribute

• Someservicesstilluseuniqueaddresses• Otherservicesusegeneric“aggregate”addressesandrelayontheapplicationtoperformserviceidentification

Today’sInternetArchitecture

Isthisthemodelofdisambiguationoflocationandserviceidentitythatwe’vebeensearchingforforthepastcoupleofdecades?

Areweoveramodelofnetworkingwhere“addresses”uniquelydenotepointsofattachmenttoacommonnetwork?

Areaddresseslocallyscopedelementsthatprovidesdisambiguationonlytotheextentthattheyarenecessary?

Questions?