IP without IP addresses - Saleem Bhatti · 2016. 4. 7. · Title: 2013-11-19-ilnp_gfi_summit_seoul.pptx Author: saleem Created Date: 4/7/2016 2:32:21 PM

IPwithoutIPaddresses

h"p://ilnp.cs.st-andrews.ac.uk/

Copyright,SaleemN.Bha?,19Nov2013 1

SaleemBha)SchoolofComputerScienceUniversityofStAndrews

Thanks


•  DrRanAtkinson•  PhDstudentsatStAndrews:

•  DitchaphongPhoomikia?sak•  BruceSimpson

•  IRTFRouMngResearchGroup(RRG):•  RFCs6740–6748•  RRGChair(attheMme),TonyLi(formerlyofCisco)•  IRTFChair,LarsEggert(NetApp)+RFCTeam

•  h"p://ilnp.cs.st-andrews.ac.uk/

ILNPIdenMfier-LocatorNetworkProtocol

1.  Why?2.  What?3.  How?


ThechangingworldofIP•  Howtosupportaharmonisedsolu-ontomanynetworkfuncAonsinascalablemanner?•  MulM-homing(hostandsite).•  Mobility(hostandnetwork).•  MulM-pathcapabletransportprotocols.•  Localisedaddressing(NAT).•  Trafficengineeringcapability.•  Packet-level,end-to-endsecurity.•  VirtualmachinemigraMon/mobility.

•  CurrentsoluMonsforsuchfuncMonsremaindisparate,donotfuncMonwelltogetherand/ormaynotscalewell.


UseofIPaddressestoday


NamingArchitecture:IP

FQDN=fullyqualifieddomainname6Copyright,SaleemN.Bha?,19Nov2013

ProtocolLayer IP

ApplicaMon FQDNorIPaddress

Transport IPaddress(+portnumber)

Network IPaddress

(Interface) IPaddress

EntanglementL

RFC2101(Feb1997)

!3. Ideal properties.!! ... it is easy to see the ideal ! properties of identifiers and locators. Identifiers should be ! assigned at birth, never change, and never be re-used. Locators ! should describe the host's position in the network's topology, and ! should change whenever the topology changes.!! Unfortunately neither of the these ideals are met by IPv4 addresses. !

IPv4AddressBehaviourTodayRFC2101(IAB,InformaMonal)pp3-4

7Copyright,SaleemN.Bha?,19Nov2013

RFC4984(Sep2007)

ReportfromtheIABWorkshoponRouMngandAddressingRFC4984(IAB,InformaMonal),p6

.... workshop participants !concluded that the so-called "locator/identifier overload" of the IP !address semantics is one of the causes of the routing scalability !problem as we see today. Thus, a "split" seems necessary to scale !the routing system, although how to actually architect and implement !such a split was not explored in detail. !

2012-07-11

8Copyright2012,SaleemBha?

Newnamespaces,separatesemanMcs•  Thisisawell-knownproblem:

•  RFC4984,IAB(2007)•  RFC2101,IAB(1997)•  IEN1(1977)

•  SemanMcoverloadofIPaddress:•  locatorsemanMcs+idenAfiersemanMcs•  easeimplementaMonofmulM-homing,mobility,etc…

•  Many“ID/LocatorseparaMon”soluMonsproposed:•  HIP,LISP,SHIM6,SixOne–re-useofIPaddress•  ILNP–deprecateuseofIPaddresses


NamingArchitecture:IPvsILNPILNP

FQDN(RFC1958)

(Node)IdenMfier(+portnumber)

Locator

(dynamicmapping)

SeparaAonJFQDN=fullyqualifieddomainname


ProtocolLayer IP

ApplicaMon FQDNorIPaddress

Transport IPaddress(+portnumber)

Network IPaddress

(Interface) IPaddress

EntanglementL

1.  Why?

2.  What?3.  How?



ILNP

•  IdenMfierLocatorNetworkProtocol:•  h"p://ilnp.cs.st-andrews.ac.uk/

•  ILNPenhancesInternetProtocolfuncMonalitythroughtheuseofcrispnaming.

•  March2010:IRTFRRGChairsrecommendILNPfordevelopmentwithintheIETF-RFC6115(Feb2011)


IdenMfier-LocatornamespacesinILNP

•  Locator,L:•  Topologicallysignificant.•  Namesa(sub)network(astoday’snetworkprefix).•  UsedonlyforrouMngandforwardinginthecore.

•  (Node)IdenAfier,NID:•  Isnottopologicallysignificant.•  Namesalogical/virtual/physicalnode,doesnotnameaninterface.

•  UpperlayerprotocolsbindonlytoNID.


ILNP:transportlayerstateexample


A=IPaddressP=portnumberAtX:<TCP:AX,PX,AY,PY><IP:AX,AY>AtY:<TCP:AY,PY,AX,PX><IP:AY,AX>

X Y

InternetL=LocatorI=(Node)IdenMfierP=portnumberAtX:<TCP:IX,PX,IY,PY><IP:LX,LY>AtY:<TCP:IY,PY,IX,PX><IP:LY,LX>

Namespaces&namebindings


ApplicaMon

Transportsession

IPsubnetwork

Physicalinterface

IPadd

ress

ApplicaMon

Transportsession

IPsubnetwork

Physicalinterface

FQDN

FQ

DN

FQDN

NID

NID

L LNID

L

IP–staMc ILNP–dynamic

animated knot from http://meritbadge.org/wiki/index.php/Knot#Granny_knot

ILNP:LocatorProperMes•  LocatornamesanIP(sub)network.•  LocatorisequivalenttoanIProuMngprefix:

• MulMpleLocatorscanbeusedsimultaneously.•  NodescanchangetheirLocatorvaluesduringthelifeAmeofanILNPsession.

•  Enables“NAT”,mobility,mulM-homing,end-to-endIPsec,site-controlledtrafficengineering,etc.

•  LocatorsNEVERusedfortransportlayerstate,e.g.byTCP,UDP,SCTP,etc.•  end-to-endstatenowindependentoftopology


ILNP:IdenMfier(NID)ProperMes•  NIDnamesanode,notaninterface•  RemainsconstantduringthelifeMmeofatransportsession

•  NodesmayusemulMpleNIDsconcurrently:•  onlyoneNIDforagiventransportsession•  NIDscanbestableoverMme

•  IPv6NIDformatssupportedbyILNP:•  e.g.EUI-64,Private(RFC4941),CGA(RFC3972)

•  OnlyNIDisusedbyTCP,UDP,SCTP,IPsec,etc.



1.  Why?2.  What?

3.  How?


ILNP:Engineering•  Possibletotrya“cleanslate”...notpracMcal.•  MainarchitecturalideascanbeappliedasextensionstobothIPv4andIPv6:•  currentRFCscoverboth

•  FocushereisonIPv6,astheengineeringiscleaner,butIPv4isalsopossible.

•  ILNPextensionstoIPv6–ILNPv6:•  RoutersseeanIPv6packet.•  ILNPv6hostsseeanILNPv6packet.


ILNPv6•  CanbeseenasasetofextensionstoIPv6:

•  SamepacketformatasIPv6,withextensions•  NochangesrequiredincoreIPv6routers•  IncrementallydeployableonIPv6networks•  BackwardscompaMblewithIPv6devices

•  Split128-bitIPv6address:•  64-bitLocator(L64) (sub)networkname.•  64-bitIdenAfier(NID) nodename.•  encodeNIDandL64intoexisAngIPv6packet


IPv6addressesandILNPv6I-Lvectors

IPv6 address (as in RFC3587 + RFC4291): !! | 3 | 45 bits | 8/16 bits | 64 bits | ! +---+---------------------+-----------+----------------------------+ ! | Unicast Routing Prefix | Interface Identifier | ! +---+---------------------+-----------+----------------------------+ !! !!!!!ILNPv6 I-L vector (as in RFC6741): !! | 64 bits | 64 bits | ! +---+---------------------+-----------+----------------------------+ ! | Locator | Node Identifier (NID) | ! +---+---------------------+-----------+----------------------------+ !!


samesyntaxandsemanAcsasIPv6rouAng(address)prefix

soIPv6coreroutersworkastoday

IPv6rouAng(address)prefix samesyntax,differentsemanAcs

thesebitsonlyexaminedandacteduponbyendsystems

encodeL64andNIDvaluesintoIPv6packets

IPv6packetheader–routerview 0 1 2 3 ! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! |Version| Traffic Class | Flow Label | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | Payload Length | Next Hdr | Hop Limit | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | | ! + Source IPv6 Address + ! | | ! +- -+ ! | | ! + + ! | | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | | ! + Destination IPv6 Address + ! | | ! +- -+ ! | | ! + + ! | | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !


ILNPv6packetheader–hostview 0 1 2 3 ! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! |Version| Traffic Class | Flow Label | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | Payload Length | Next Hdr | Hop Limit | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | | ! + Source Locator + ! | | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | | ! + Source Identifier + ! | | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | | ! + Destination Locator + ! | | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | | ! + Destination Identifier + ! | | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !


DNSenhancements

•  NewDNSrecordsrequired(RFC6742):•  NID–nodeidenMfier•  L64–ILNPv6locator•  L32–ILNPv4locator•  LP–locatorpointer

•  Productsupportavailable:•  NLnetLabs.nl–NSD(Feb2013)•  ISC–BIND(June2013)


Example1:LocalisedAddressing

(akaNAT)(fromRFC6748)


NATinIPv4andIPv6u  NAT:

u  singleaddresssharedamongstmanyhosts(useofportnumbersformulMplexing)

u  End-to-endintegritylost,asidenMtynamespacehasadisconMnuityatthesiteborderrouter(SBR),impacMngotherend-to-endfuncMons(e.g.IPsec)

u  SBRmayhavetoperformotherfuncMonsalso,e.g.applicaMonproxy

sitenetwork

SBR

{YL}

X1

<srcA=YL1,dstA=ZR>

<srcA=X1,dstA=ZR>


SBRsiteborderrouter

NATequivalentinILNPv6u  Localised‘addressing’isafeaturenotahack:u  Locatorisnotpartoftheendsystemtransportsessionstate.

u  LLasinRFC4193(ULA)u  end-to-endview

u  SBRsperformLocatorrewriAngwithoutaffecMngend-to-endstate.

sitenetwork

SBR

LL

L1

<srcNID=I1,dstNID=IR><srcL=LL,dstL=LR>

<srcL=L1,dstL=LR><srcNID=I1,dstNID=IR>


SBRsiteborderrouter

Example2:MobileNetworks(fromRFC6748)


CurrentIPmobilitymodel•  Useofproxies:

•  homeagent(HA),foreignagent(FA)•  UseofindirecMonviatunnelling:

•  mobilehostslookstobenon-mobiletocorrespondentnodes

•  IP-in-IPtunnelcancauseproblems•  Homeaddress(HoA)–idenMty:

•  DNSlookupresolvestoHoA•  Care-of-Address(CoA)–locator•  Similarprincipleformobilenetworks•  IPv6improvementsforMobileIPv6


MobileIP–basicoperaMon


1) MH arrives at FN, and locates FA (using agent advertisements from FA or by solicitation).

1

2) MH completes registration procedure with FA.

2

foreign network

FA

home network HA remote network HostA

3) MH updates HA with its new CoA (i.e. the FA).

3

4) Host A now tries to contact MH. Packets for MH are intercepted by HA.

4

src=HostA dst=MH data src=HostA

dst=MH data src=HostA dst=CoA

IP-in-IP encapsulation

5) HA tunnels the packets from Host A to the CoA for MH (i.e. the FA) 5

6) The FA de-encapsulates the inner IP packet and transmits the packet locally to MH.

6

7) The packets from MH to Host A are sent directly from the FN.

7

MH

ImprovedinMobileIPv6:•  mobilehostcanactasitsownFA•  useofBindingUpdate–sendCoAtoHostA

MobilenetworksinILNPv6[1]

u  Locatorre-wriMngcan‘hide’sitemovementfrominternalnodes.

u  SBRchangesLocatorvalueasthemobilenetworkmoves:u  SendsLocatorUpdate(LU)messagestocorrespondents.

u  UpdatesDNSwithnewLocatorvalue

sitenetwork

SBR

LL

L1


sitenetwork

SBR

LL

L2

SBRsiteborderrouter

ILNPLocatorUpdate(LU)[1]


X Y<IP:L1X,LY> <IP:LY,L1X>

<IP:L2X,LY>

locatorchangetriggered LU(L2X)

<IP:LY,L2X>

LU-ACK(L2X)

Hardhand-over(similartoBindingUpdateforMobileIPv6)

(newLvaluescanbelearnedfromIPv6routeradverMsements)

potenM

al

packetloss

MobilenetworksinILNPv6[2]u  Networklayerso_-hand-offpossible.

u  Requires2+radiochannels/interfaces.

u  SBRshandleLocatorrewriMng+forwardingasrequired.


sitenetwork

SBR

LLL2

sitenetwork

SBR

LL

L1

L2site

network

SBR

LL

L1

SBRsiteborderrouter

ILNPLocatorUpdate(LU)[2]


X Y<IP:L1X,LY> <IP:LY,L1X>

<IP:L1X,LY><IP:L2X,LY>

locatorchangetriggered LU(L2X)

<IP:LY,L2X>

<IP:L2X,LY>LU-AC

K(L2X)

So_hand-over(newLvaluescanbelearnedfromIPv6routeradverMsements)

OtherharmonisedfuncMonality...

•  MulM-homing•  MulM-pathtransport•  VMmigraMon/mobility•  TrafficengineeringopMons•  Improvedpacketandnetworksecurity•  Seepapers:

•  h"p://ilnp.cs.st-andrews.ac.uk/


Thankyou!QuesMons?

•  ILNPfurtherinformaMon:•  seeh"p://ilnp.cs.st-andrews.ac.uk/forlinkstoRFCs,papersandtalks

•  ...orcomeandtalktome!•  IhavePhDposiAonsopenJ

•  Reading–startoffwith:•  “EvolvingtheInternetArchitectureThroughNaming”,

IEEEJSAC,Oct2010h"p://dx.doi.org/10.1109/JSAC.2010.101009

•  RFC6740,Nov2012h"p://tools.ie|.org/html/rfc6740RFC6741,Nov2012h"p://tools.ie|.org/html/rfc6741


Documents

IP without IP addresses - Saleem Bhatti · 2016. 4. 7. · Title: 2013-11-19-ilnp_gfi_summit_seoul.pptx Author: saleem Created Date: 4/7/2016 2:32:21 PM