In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that...
Transcript of In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that...
![Page 1: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/1.jpg)
InDefence ofNATsGeoffHuston
APNIC
IEEEGlobalInternetSymposium,May2017
![Page 2: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/2.jpg)
TheArchitectureofthe1990Internet“DumbNetwork,SmartHosts”
Removeallthefunctionalityfromthenetworkapartfromforwardingandbuffering
Placealltheresponsibilityfordataflowintegrityandcontrolintotheendhostprotocolstacks
![Page 3: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/3.jpg)
TheArchitectureofthe1990InternetEachIPheadercarriessufficientinformationtoenableanetworkofstatelessforwarderstopassapackettoitsintendeddestination
Version IHL Total Length
FlagsIdentification Fragment Offset
Time To Live
Source Address
Destination Address
Options Padding
Protocol Header Checksum
Type of Service
![Page 4: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/4.jpg)
DataFlow
Application Application
Transport Transport
Internet InternetInternetInternetInternet
Link Link Link Link Link
HosttoHost
ProcesstoProcess
TheintentionwasthatonlytheIPheaderisusedbythenetwork,andtheentireremainderofthepacket,includingthetransportheaders,isanopaquepayload
Eachpacketcanbeforwarded(optionallyfragmented) ordiscarded
![Page 5: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/5.jpg)
IP’sStrengths
• Thereisno“setup”and“teardown”ofnetworkstate
• Thereisnorequirementforsymmetrybetweenforwardandreversepacketflows
• Whileitispreferredthatthenetworkmaintaintheorderofpackets,it’snotastrictrequirement
• End-to-EndTransportandHop-by-HopForwardingaredecoupled:theend-to-endtransportprotocolisahostchoice,notanetworkchoice
![Page 6: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/6.jpg)
Consequences
• IPaddressesaregloballysignificantuniqueidentifiers– theyarenotlocalvirtualcircuitidentifiers
• AllIProutersneedtobeawareoftherelativelocationofallactiveIPaddresses
• ThetotalcapacityofthenetworkislimitedbythenumberofIPaddressesandtheabilitytorepresenttherelativelocationofalltheseaddresseswithineveryrouter
![Page 7: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/7.jpg)
Proceedingsofthe18th IETFMeetingAugust1990
“InternetGrowth”FrankSolensky,Proc.IETF,Aug1990
![Page 8: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/8.jpg)
Proceedingsofthe18th IETFMeeting
“InternetGrowth”FrankSolensky,Proc.IETF,Aug1990
![Page 9: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/9.jpg)
Address“Classes”
• EachIPaddresshasanetworkpartandahostpart• TheoriginalIPv4addressplandividedtheIPv4addresspoolintothree“Classes”
https://en.wikipedia.org/wiki/Classful_network
![Page 10: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/10.jpg)
RemovingClasses
• Theproblemwasnot thatwewererunningoutofaddresses
• TheproblemwasthatwewererunningoutofClassBaddresses
• Theadoptedsolutionwastokeeptheimplicitroutingaggregationofthenetwork/hostdivisionofaddresses,butcarrythenetwork/hostdivisionpointwiththeaddressprefixE.g.192.0.2.0/24
Length of network prefix in bits
![Page 11: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/11.jpg)
CIDRWorked!
March 1994 – deployment of CIDR in BGP-4
Pre-CIDR Routing Table Growth
Post-CIDR Routing Table Growth
![Page 12: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/12.jpg)
“BuyingTime”wasjustastopgapmeasure• Theunderlyingissuewasthepersonalcomputer,whichdramaticallyincreasedthenumbersofconnecteddevicesandindirectlyfueledthefirstwaveofcommercializationoftheInternet
• Andthiswasnotgoingtostop– laptops,themobiledevicesalladdedtothenumbersofconnecteddevices
• Thethinkingatthetimewastochangeaslittleaspossible,sowethoughtthatenlargingtheaddressfieldsoftheIPheaderwouldbesufficienttomeetthischallengetoscaling
• TheanswerthatwasadoptedbytheIETFwasIPv6
![Page 13: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/13.jpg)
TheoriginsofIPv6
• IPv6representedaminimalchangetoIPv4• SomeaspectsofIPwerechanged:
• Expandedaddressfields• Alteredfragmentationcontrols• Re-formattedoptionsandcontrolfields
• Muchwasunaltered:• UDPandTCPtransportprotocolbehaviour• Hop-by-hopdestination-baseddatagramforwarding
• Andsomewasunspecified:• IPv6AddressPlan
![Page 14: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/14.jpg)
ThereweremanyotherideasthatwereairedatthetimeAndoneofthemwasamechanismforaddress”sharing”
![Page 15: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/15.jpg)
AddressSharing
NAT
Private AddressRealm
PublicAddressRealm
![Page 16: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/16.jpg)
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
![Page 17: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/17.jpg)
NAT
BindingtableSourceAddress/Port+Dest Address/Port SourceAddress/Port+Dest Address/Port
”Inside” ”Outside”
NATstakethe96-bit4-tupleofProtocol+Address+Ports andreplacethepacket’sfieldsthatmatchonesideofthebindingtablewiththefieldsontheotherside
Outboundpacketsthatdonotmatchanybindingtablegenerateanewtableentry
Inboundpacketsarediscarded
![Page 18: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/18.jpg)
NATs:
• Enforcesymmetricnetworkpaths• Requiresessionstatewithinthenetwork• EnforceClient/Serverarchitecture• Createfragilityinthenetwork• Violatelayerintegrity• Motivatetheuseofproxiesandgateways• Preventinnovationintransportservices• HandleUDPbindingsinconsistently
![Page 19: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/19.jpg)
NATsareEvil!
• TheseconsiderationsledtoalongheldmantraintheIETFthat“NATSareevil”andtheIETFrefusedtoworkonstandardizingNATbehaviour formanyyears
• TheconsequencewasthatNATsweredevelopedwithidiosyncraticbehaviours,particularlyinrelationtoUDP-basedbinding
• Whichledtoallkindsofconvolutedapplicationlevelbehaviours todiscoverandadapttotheNATsinthepath(STUN,TURN,ICE,TEREDO,…)
![Page 20: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/20.jpg)
Andyet…
![Page 21: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/21.jpg)
NATsruntoday’sInternet
• 2.8BadvertisedIPv4Addresses• 25Bconnecteddevices*• Theaverageaddresssharingratioappearstobe10:1
NATsareeverywhere!
*https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/
![Page 22: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/22.jpg)
WhyareNATssopervasive?
• Theyarebackwardcompatiblewiththeexistingnetwork• Theyallowforuncoordinatedpiecemealdeployment• Theyimpairopenpeertopeerconnectivityandenforceclientbehaviours behindtheNATs
• Theyusetheportspacetoenlargetheeffectiveaddressspace
![Page 23: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/23.jpg)
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
![Page 24: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/24.jpg)
HowfarcanwepushNATs?
TheNATbindingspaceisa96bitswide4-tuple
NATtype:CGNwithperuserportblocksCGNwithperuserportblocks+pooledoverflowCGNwithpooledportsCGNwith4-tuplebindingmaps
AddressCompressionRatio
10:1100:1
1,000:1>>10,000:1
SourceAddress/Port+Dest Address/Port96 bits
![Page 25: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/25.jpg)
So,incomparison,whatdoesIPv6offer?• BackwardCompatibilitywithIPv4?
• Nope!
• Moreaddressbits?• ThecurrentIPv6addressplanstypicallyusea48bitendsiteprefix• CGNats potentiallypushthevirtualIPv4addressspacetobetween42and45
bits
• Moreflexibility?• Itisunclearifthereisaclearneedtoshiftbacktotheoverloadedlocation/
identifiersemanticsofaddressesastheclient/servermodeliscloselyalignedtotoday’sInternet
• Lesscost?• Wellno– foraslongasIPv4remainsthedominantprotocolthentheInternet
needstosupportIPv4,whichimpliestheuseofNATs.ItisIPv6thatisthediscretionaryexpenditureitemformanyserviceproviders
![Page 26: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/26.jpg)
NATsareunder-appreciated!
Forsometimenowwehavebeencontemplatingwhatitmeanstohaveaname-baseddatanetwork,whereinsteadofusingafixedrelationshipbetweennamesandIPaddresses,weeschewthismappingandperformnetworktransactionsbyspecifyingthenameofthedesiredserviceorresource
![Page 27: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/27.jpg)
NATsareunder-appreciated!
NATsareaninterestingstepinthisdirection,whereIPaddresseshavelosttheirstaticassociationwithparticularendpoints,andareusedmoreasephemeralsessiontokensthanendpointlocators.
![Page 28: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/28.jpg)
NATsareunder-appreciated!
Thiscertainlyappearstobeaninterestingstepinthedirectionofnameddatanetworking whereaddressesloseanypermanentassociationwithendpointidentity,andretainonlythefixedsemanticsofanetworklocatorusedinrouting
![Page 29: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/29.jpg)
InDefence ofNATs
• ItisNATsthathavekepttheInternetrunningforthepastdecade
• Inthattimethenetworkhasgrownfromaround2Bconnecteddevicestotentimesthatnumber
• TheIPv4networkanditsapplicationsuiteisnowbuiltontheassumptionofpervasiveuseofNATs
• ThesesameapplicationandservicedesignparametersareusedinthecontextofIPv6
![Page 30: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/30.jpg)
IPv6Addresses
• Doweuse“fixed”endaddressesinIPv6anyway?• Well,no,notallthetime!
• Clientstypicallyuse“privacy”addressesthatusearandom64bitinterfaceidentifier
• SotheIPv6IPendaddressisnowephemeralforclients
• Servicesareincreasinglyusingnamebasedhosting• TherearemoreleversandcontrolpointsintheDNSasdistinctfromIPanycast
• SoevenIPv6haseschewed“fixed”endaddressing!
![Page 31: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/31.jpg)
NATsinIPv6
Forsomethisisheresy!However:
• IPv6hasalreadydissociateditselffromfixedendaddresses• wehavealreadymarkedoffULAsasprivateuseIPv6addressprefixes(fc00::/7– RFC4193)
• PersistentprivateaddressesandNATsavoidforcedsiterenumbering
• NATsallowsitemulti-homingwithoutroutede-aggregation• NATsobscureinternalsitenetworkdetailsandenforceclientobscurity
• AsIPv6gathersmomentumitmaybethecasethatnetworkadminswilluseULAprefixesplusNATstore-createtheIPv4NATarchitectureinIPv6
![Page 32: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/32.jpg)
InDefence ofNATS
• MaintaininganetworkinfrastructurethatuniquelynamesandnumberseveryattacheddevicehasprovedtobeeconomicallyinfeasibleintheInternet
• NATssegmentthedevicepopulationintoclientsandservers- Clientsarenotuniquelynamed,noruniquelyaddressed
• Wemaynothaveplanneditthisway,butundeniablywhatkeepstoday’sInternetrunningasa singlecosteffectivenetworkisNATs.
![Page 33: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/33.jpg)
NATsaspartoftheArchitecture
• NATshavepushedthenetworkintoamodewhereIPaddressesareephemeralconversationtokenswithoutlastingsignificanceasanendpointidentifier
• Forclients,addressuniquenessisalocallyscopedproperty,ratherthanagloballyscopedattribute
• Someservicesstilluseuniqueaddresses• Otherservicesusegeneric“aggregate”addressesandrelayontheapplicationtoperformserviceidentification
![Page 34: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/34.jpg)
Today’sInternetArchitecture
Isthisthemodelofdisambiguationoflocationandserviceidentitythatwe’vebeensearchingforforthepastcoupleofdecades?
Areweoveramodelofnetworkingwhere“addresses”uniquelydenotepointsofattachmenttoacommonnetwork?
Areaddresseslocallyscopedelementsthatprovidesdisambiguationonlytotheextentthattheyarenecessary?
![Page 35: In Defenceof NATs - potaroo.net · In Defenceof NATS •Maintaining a network infrastructure that uniquely names and numbers every attached device has proved to be economically infeasible](https://reader033.fdocuments.us/reader033/viewer/2022042222/5ec8bf3e0bac800987485299/html5/thumbnails/35.jpg)
Questions?