LISP Encryption

8/3/2019 LISP Encryption

1/11

1 2011 Cisco and/or its ailiates. All rights reserved.

Craig Hill

Distinguished Systems EngineerU.S. Federal Area

[email protected]

Individual Contributors:

Tim Thomas Sr. Systems Engineer, U.S. Federal

Dino Farinacci Cisco Fellow

Network-Based ProtocolInnovations in Secure

Encryption EnvironmentsUsing Locator/ID Separation Protocol (LISP)

to Optimize Routing in IP Encryption Environments
mailto:crhill%40cisco.com?subject=http://www.cisco.com/mailto:crhill%40cisco.com?subject=


2/11


3/11

White Paper


However, there are known industry challenges in trying to build an IP backbone with these devices as they

all short in delivering several key eatures users have come to expect in todays IP-based routers:

Limited/nosupportfordynamicIPunicastroutingprotocols

NosupportfordynamicIPmulticastprotocols

NosupportforVirtualRouteForwarding(VRF),virtualLAN(VLAN),orMultiprotocolLabelSwitching

(MPLS)functions(controlanddataplane)

LimitedcapabilitiesfortransportingIPtypeofservice/differentiatedservicescodepoint(ToS/DSCP)bits

No802.1Q/psupportontheencryptorsEthernetinterfaces

Nomeanstorapidlydetecthostmobilitybetweenlocations

Given these limitations, network operators instead most commonly deploy IP tunnel technology, namely

genericroutingencapsulation(GRE)(RFC2784),betweenthesecureroutersinsidetheIVDboundary.

GREtunnels,incombinationwiththeIVD,allowthetransportofIPservicepackets(e.g.,IPv4/v6,multicast,

orMPLS)throughtheIVDs.Initsmostgenericform(andasstatedinRFC2784),GREallowsthetransport

o a payload packet (the packet needing to be encapsulated and delivered) within an outer header

consistingofaGREheaderplusanIPheader(24bytestotal).

TheresultisthecreationofanoverlayIPtopologybetweentheGREtunnelendpointsonthesecure

routers, which is transparent to the IVDs and the networks between IVDs. The IVDs route the traic based

onthedestinationIPaddressintheouterIPheaderoftheGREpackets.ByleveragingthisIPtunnel

overlay topology, the secure routers are able to support more sophisticated technologies than can be

provided by the IVDs alone. These technologies include interior gateway protocols (IGPs) such as Open

ShortestPathFirst(OSPF)orEnhancedInteriorGatewayRoutingProtocol(EIGRP);MPLSservicessuchas

IPBorderGatewayProtocol(BGP)VPNs;Layer2VPNpoint-to-pointorpoint-to-multipoint;IPmulticast;

and IPv6.

TheuseofGREtunnelsoverIVDshasbecomecommonpracticeincertaincustomerdeployments.It

shouldbenotedthatenhancementstoGREperformance(upto40GbpsofGREpacketencapsulation

andforwardingontheCiscoCRS-1CarrierRoutingSystem,withfuturesupportof140GbpsofGREon

theCiscoCRS-3)andincreasedflexibilitythroughtheuseofmultipointGREtunnelslooktoovercome

operationalburdenshistoricallyassociatedwithpoint-to-pointGREtunnels,especiallyinenvironments

requiringlargernumberofsites(N1GREtunnelsforfullmesh,whereNisthenumberoflocations).

However,usingGREtunnelsinlarger-scaleenvironmentshasprovencomplexandtroublesome,both

operationallyandintermsofthehardwarerequiredtoforwardGREpacketsandmanagethemaximum

transmissionunit(MTU)implicationsGREintroduces.

The use o dynamic discovery o the routes to the secure networks the IVDs are protecting couldincrease demand on hardware resources and IVD unctionality in order to process and hold a potentially

larger number o IP preixes being received rom the protected network. This could prove challenging,

particularly i the IVD hardware design was not originally intended to hold a large amount o IP preixes.


4/11

White Paper


Proposed Solution

This document details a solution to simpliy the overall deployment and operations o IVDs, including usingthe Locator ID Separation Protocol (LISP) routing architecture ramework to simpliy the connectivity,

orwarding, and operations between secure router endpoints when IVDs are required. The paper

speciically addresses the challenges described prior, which could signiicantly impact how these

types o networks are designed.

LISP is not a eature, but rather a new routing architecture that is gaining traction or the broad range

o uses and applications with which it can integrate. LISP implements a new semantic or IP addressing

that creates two name spaces: Endpoint Identiiers (EIDs), which are the current addresses assigned to

endhoststoday,andRoutingLocators(RLOCs),whicharetheaddressesassignedtodevices

(primarily routers) comprising the global routing system.

SplittingEIDandRLOCfunctionsyieldsmanybenefits,includingimprovedroutingscalability,superiormulti-homingefficiency,IPv6transition,andvirtualmachine(VM)andIPmobility.Additionally,given

the level o indirection incorporated into its orwarding scheme, LISP has been identiied as a method or

simpliying IP network deployments in customer networks when the use o external IVDs is required.

LISP can greatly simpliy the overall IP routing paradigm in environments requiring IVDs, eliminating the

needforfull-meshGREtunnelsrunningend-to-endroutingprotocols.LISPusesapullmodelsimilar

to DNS, which only requests endpoint host addresses when needed or communication. Because LISP

inherently uses IP/UDP or orwarding (e.g., IP encapsulation), the data plane works seamlessly over

IVDswithouttheneedtomanuallyconfigureGREtunnelsbetweeneachpairofsecurerouters.Further,

LISPsignificantlylimitsthepotentialnumberofIPprefixestheIVDmightberequiredtohold(e.g.,RLOC

addresses) to simpliy the operational aspect o these networks. In turn, this will reduce the preix memory

and other related resources needed in the IVD design.

For a detailed description on how LISP operates, see http://tools.iet.org/id/drat-arinacci-lisp-12.txt.

That site also provides details about LISP and its control plane components that are outside the scope o

this paper.
http://tools.ietf.org/id/draft-farinacci-lisp-12.txthttp://tools.ietf.org/id/draft-farinacci-lisp-12.txt


5/11

White Paper


Solution Description o LISP in IVD Environments

This section addresses using LISP as the IP routing ramework in an IVD environment, and assumes thereader has a basic understanding o the various LISP components, including data planes and control planes.

Figure1depictsthetopologyandcomponentsofatypicalIParchitectureinusingIVDsandGREtunnels.

Inthistopology,point-to-pointGREtunnelsareestablishedbetweenthesecurerouterendpoints(ateach

campus/datacentersite),thusallowingfull-orpartial-meshcommunicationsovereachGREtunnel.This

communications overlay is transparent to the IVDs and the IP transport o the encrypted IVD traic.

Figure 1 Typical IVD Architecture Leveraging GRE Tunnel Overlay

IntheGREdeploymentmodel,eachIVDisresponsibleforholdingtheIPaddressprefixthattheouter

IPheaderoftheGREtunnelusesforcommunicatingwitheachendpoint.Itisimportanttonotethatthismodel

hides the secure plaintext preixes within each campus or data center site rom the IVDs, thus limiting thenumberofprefixentriesineachIVDtoonlythoseneededforGREtunnelendpointcommunications

(vs.holdingeachsecureprefixinthesitecampusordatacenter).Inthismodel,GREtunnelscouldbe

configuredmanually,orsolutionssuchasDynamicMultipointVPN(DMVPN)couldbeused.


6/11

White Paper


Figure 2 depicts the topology and components o a typical IP architecture using IVDs, this time with

the use o a LISP ramework and its associated components. The secure routers S1/S2 and D1/D2 will

functionasingresstunnelrouters(ITRs)andegresstunnelrouters(ETRs)inthearchitecture.(Note:

AnxTRcorrelatestoarouterfunctioningasbothanITRandETR.)Themapresolver(MR)andmap

server(MS)(MR/MSinthefigure)willberedundantandaccessibleonlyinthesecureaddressspace.If

the need exists to communicate to non-LISP locations (this would be normal, even i only in a transition

stage),oneormoreproxyITRs/ETRs(PxTRs)willbeprovisioned;again,onlyaccessiblewithinthesecure

address space.

Figure 2 - Typical IVD Architecture Leveraging LISP

ItshouldbenotedthattheIPnetworktransportfortheRLOCinthissolutionisimmaterialtothefunctionof

the LISP architecture and can be assumed to use any o the network solutions typically ound today in any

IVD environment (e.g., IP, Ethernet, serial, optical).


7/11

White Paper

72011Ciscoand/oritsaffiliates.Allrightsreserved.

LISP Operation in an IVD Environment

TouseLISPinthissecureenvironment,thesecurexTRswillbedirectlyconnectedtotheIVDs.TheRLOCaddresses(shownas10.0.0.1/32,11.0.0.1/32,12.0.0.1/32,and13.0.0.1/32)wouldnormallybe

manually entered into the IVD but could be advertised i an IGP was supported to allow this. The IVD will be

responsiblefordistributingtheseRLOCaddressestoallIVDsthroughoutthenetworkaspartofthenormal

IVD discovery process (details or IVD preix discovery are outside the scope o this document). Lastly,

theIPaddressesfortheMR/MSmustalsobeadvertisedandreachablebyallsecurexTRsforthemap

registration and request unctions to operate.

AsinanyLISPdesign,theEIDaddressspacewillbehiddenfromtheRLOCaddressspaceand,inthis

proposal, hidden rom the IVDs as well. LISP operation in an IVD environment does not change rom that

foundintheserviceprovider/commercialspace,meaningbothdataplane(ITRtalkingtoanETR)and

controlplane(ETRregisteringtoaMSandanITRrequestingtheRLOC-to-EIDmappingfromtheMR)

remain the same. However, in this secure environment, all communications will be over the IVD. Because

LISP natively uses an IP encapsulation (IP/UDP) or orwarding, the operator is not required to manuallyconfigureanyIP/GREtunnelsbetweenanysecurerouters(e.g.,ITRs/ETRs)overtheIVDs.

One o the key concerns in an IVD architecture in which an IGP will be used or secure IP route discovery

and exchange is the impact that a large amount o preixes could have on the IVD devices, particularly

whennotusingGREtunnels.ConsiderthatwhenusingIVDdiscoverywithanIGP,theIVDdeviceitself

would potentially need to learn all secure preixes ound within the agencys secure network and distribute

those preixes to every other IVD. The preix count in each IVD could get very large, potentially impacting

the overall perormance and scale o the IVD devices and network perormance.

Using the LISP ramework or this type o network can greatly reduce the potential or route explosion in

theIVD,asLISPinherentlyhidestheend-usernetworkprefixes(EIDs)fromtheIVDsthroughtheRLOC/

EID separation. No matter how large the secure routing tables become in the EID space, the IVDs will

notbeimpactedandwillonlyrequireknowledgeoftheRLOCaddressofeachxTRwhenusingtheLISP

ramework.

TheIVDroutingtablesize-scalingfactorisbasedonlyonthescaleoftheRLOCaddressspaceinthe

network,whichwillbeminimal.ConsiderthatthenumberofRLOCaddresseswillequalthenumberof

securerouter(xTR)interfaces,plus/minustheaddressesoftheMR/MS/PxTR,regardlessofhowmuchthe

prefixcountincreasesbehindeachxTR(i.e.,EIDaddressspace).ThisisanenormousbenefitofLISPfor

scaling large IVD environments.

Aside rom basic IP routing requirements in these networks, applications can be deployed that will increase

this explosion o preixes in the agency networks. One key application is the rapid addition o virtual

machines(VMs),inwhicheachVMhostwillhavea/32address(IPv4).Thesamecanbesaidformobile

or tactical networks, where /32 addresses are much more requently seen to identiy each endpoint. (LISPhasothermethodsforsimplifyingthisVMmobilitychallenge,whichisdescribedbrieflyintheusecase

section.)

The LISP ramework oers unlimited potential and should continue to be evaluated and considered in

these complex IVD environments. Combining the pull method or host-to-host communication, dynamic

preix discovery in the IVD using IGPs, and native IP encapsulation, LISP has the potential to dramatically

simpliy overall network operation, setup, and scale or IVD network deployments and operation.


8/11

White Paper

82011Ciscoand/oritsaffiliates.Allrightsreserved.

Key Advantages or LISP in an IVD Environment

Using the LISP routing architecture in combination with IVD deployments addresses several key challengescommon in IVD networks today. Highlighted below are key advantages o how the LISP + IVD solution

could beneit network operators and designers who are either already running IVDs in their networks, or

planning to deploy them:

1. Native IP orwarding: Using the LISP ramework in an IVD environment eliminates almost all the

manualsetupandchangemanagementrequiredinIVDnetworkstoday,includingGREtunnel

establishment,IGP/BGPpeeringoverGRE,theimpactofaddingnewlocations,andaddressmoves

within a location.

2. IP-encapsulated data plane: The LISP data plane natively uses IP/UDP encapsulation (verses stateul

tunnel technology) or orwarding, eliminating the need or the network operator to manually conigure

GREtunnelsbetweensecurerouterendpoints.

3. IVD discovery option: In combining LISP unctionality with optional IP preix discovery options in theIVD,LISPxTRscandynamicallyadvertisetheirRLOCaddresstotheIVD.Thiseliminatestheneed

forestablishingIGPsoverstaticGREtunnelsbetweenxTRs(thetypicaldiscoveryprocess),andalso

simpliiesor eliminatesthe coniguration o static entries in each IVD device.

4. Conversational learning (on-demand pull model):UsingLISP,eachsecurehost(and/orxTR)only

requests (i.e., pulls) communications to the speciic host with which it needs to communicate,

on demand. This can be thought o as conversational learning in that it only requests speciic

inormation (/32 IP address) to talk to a speciic host, verses ineiciently pushing routes, even where

theyarenotneeded.ThiscreatesanEID-to-RLOCcacheentryinthesendingrouter(ITR),whichwill

maintain the cache or a period o time while the low is active. In turn, this eliminates the need or

all secure routers (and IVDs depending upon the preix discovery method chosen) to hold all o the

routes or the entire customer routing domain. It also eliminates the need to conigure a ull or partial

meshofGREtunnelsthatrequireIGPneighborestablishmentforrouteexchange.

5. Reduction o routing table preix entries in the IVD (assuming the use o IGPs or preix discovery):

Because LISP uses a pull model and the IVD can use IGPs or secure IP preix discovery, the IVD is no

longer required to hold all the preixes or each subnet in the secure routers on the secure side o the

IVD.Instead,theIVDwillonlyrequireknowledgeoftheRLOCprefixes,whichwillbe/32addresses

and will equate to the number o secure router interaces connecting to the secure side o the IVD. In

contrast, a standard routing solution would use the push model, in which each secure router at each site

would advertise its entire routing table to the IVD, which would then distribute it ully to the other IVDs

and give each IVD and secure router an identical copy o the agency-wide routing table and topology.

6. Controlling traic in multi-homing topologies:

For locations running LISP that oer multiple entry points (two IVDs and/or two secure routers),

operatorshavetheoptiontocontrolhowthetrafficloadissenttothereceivinglocation(ETR)ona

per-prefixbasis.LISPETRshavetheabilitytosetapriority/weightonaper-prefixbasistodictatehow

trafficissenttothembytheoriginatingITRs.

7. Seamless mobility o host/node/VM:ByleveragingtheRLOCandEIDseparationcapabilityinherentwithin

LISP,node/hostmobilitybetweenxTRsisavailabletothelevelthatTCPconnectionscanbemaintained

during the move. In this case, the host with an EID address would move (e.g., a virtual machine mobility

requirement) and, while the same EID preix ollows the mobile host, the LISP inrastructure would

dynamicallydiscoverthenewRLOCnowassociatedwiththeEIDhost,allowingcommunicationstobe

seamlessly maintained.


9/11

White Paper


8. IPv6 transition: Another key beneit o LISP is that it has the ability to use IPv6 addresses in the EID

spacewhilemaintainingIPv4addressesintheRLOCspace,thusallowingtheIVDsandthesecure

transport to remain at IPv4. In an IVD environment, IPv6 transition can begin in the secure router

domain(EIDs)withouttheIVDand/orcoretransportingtheRLOCaddressestoalsorequire

a simultaneous transition to IPv6. This could be thought o as a 6 over 4 transition mechanism.

LISP and Competing TechnologiesAlthough this paper highlights the advantages LISP oers in terms o simpliying IVD environments that are

deployed in a variety o secure network topologies, it should be noted that LISP has relevant advantages

forthesecureencryptedtraffic(e.g.,RLOCaddresses)networkdesignsaswell.Forexample,a

standard IP transport or the encrypted traic might have security requirements mandating the need or

an additional layer o IPsec encryption or encrypted packets traversing between IVDs. LISP could be

deployed on this network or reasons discussed in this paper, but would also provide the ability to leverage

technologies such as Group Encrypted Transport (GET) VPN, which would hide (i.e., encrypt) the IVD

addressspace.ThiswouldalsoincludehidingtheunsecurexTREIDaddressesintheencryptedpayload.

Inthisscenario,theIVDsourceaddresswouldbeanEIDaddressrelativetoaxTRontheencryptedside

oftheIVD.AddingGETVPNencryption,theEIDaddresswouldbeencrypted,leavingonlytheRLOCspace

intact while transiting the IP transport, adding another level o security to the deployment.

IntheareaswhereLayer3virtualization(VRFs)isrequired,thereareprovenMPLSVPNsolutionsusing

dynamicmultipointGREtechnologythataretailoredspecificallytoIVDenvironments.LISPis,however,

also targeting virtualization deployment capabilities that will complement Ciscos suite o network

virtualization options.

LISPisakeyemergingtechnologyforIPandiscompletelyopenstandard.Assuch,LISPandMPLS

VPN over IP eature enhancements and use cases continue to evolve. Cisco will continue to drive these

innovations into eatures and capabilities or secure network communities.

Why CiscoCisco oers innovative products and solutions together with a wide range o services programs to

accelerate customer success. These are delivered through a combination o people, processes, tools, and

partners, resulting in high levels o customer satisaction. LISP is Cisco innovation that is being promoted

as an open standard. Through its participation in standards bodies such as the IETF LISP Working Group,

Cisco is committed to the development o the LISP architecture.

For More Inormation

Full details on these IPv6 transition strategies using LISP can be ound in an IPv6 transition white paperlocated on the download page o the LISP website located at lisp.cisco.com. For more inormation about

LISP, including inormation about the protocol itsel, LISP deployment, LISP component descriptions, and

LISP interworking, please visit www.cisco.com/go/lisp or lisp.cisco.com.

For general LISP solution questions, including deployment guidance, contact your local Cisco account

representative or send an email to [email protected].
http://www.cisco.com/go/lisphttp://lisp.cisco.com/mailto:lisp-support%40cisco.com?subject=mailto:lisp-support%40cisco.com?subject=http://lisp.cisco.com/http://www.cisco.com/go/lisp


10/11

White Paper

References

GlenNakamoto,LisaHiggins,JustinRicher:MITRECorporation,ScalableHAIPEDiscoveryUsingaDNS-LikeReferralModel

LISPReferenceSource

http://tools.iet.org/id/drat-arinacci-lisp-12.txt

LISP Overview

http://tools.iet.org/id/drat-arinacci-lisp-12.txt

Inormative Reerences rom drat-arinacci-lisp-12

[AFI] IANA,AddressFamilyIndicators(AFIs),ADDRESSFAMILYNUMBERS

http://www.iana.org/numbers.html,February2007.

[ALT] Farinacci,D.,Fuller,V.,Meyer,D.,andD.Lewis,LISPAlternativeTopology(LISP-ALT),

drat-uller-lisp-alt-03.txt (work in progress), February 2009.

[APT] Jen,D.,Meisel,M.,Massey,D.,Wang,L.,Zhang,B.,andL.Zhang,APT:APractical

TransitMappingService,draft-jen-apt-01.txt(workinprogress),November2007.

[CHIAPPA] Chiappa, J., Endpoints and Endpoint Names: A Proposed Enhancement to the Internet

Architecture, Internet-Drat http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999.

[CONS] Farinacci,D.,Fuller,V.,andD.Meyer,LISP-CONS:AContentDistributionOverlay

Network Service or LISP, drat-meyer-lisp-cons-03.txt (work in progress),

November2007.

[DHTs] Ratnasamy,S.,Shenker,S.,andI.Stoica,RoutingAlgorithmsforDHTs:SomeOpen

Questions,PDFfilehttp://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.

[GSE] GSE - An Alternate Addressing Architecture or IPv6, drat-iet-ipngwg-gseaddr-00.txt

(workinprogress),1997.

[INTERWORK] Lewis,D.,Meyer,D.,Farinacci,D.,andV.Fuller,InterworkingLISPwithIPv4andIPv6,

drat-lewis-lisp-interworking-01.txt (work in progress), January 2009.

[LISA96] Lear,E.,Katinsky,J.,Coffin,J.,andD.Tharp,Renumbering:ThreatorMenace?,

Usenix, September 1996.

[LISP-MS] Farinacci,D.andV.Fuller,LISPMapServer,draft-fuller-lisp-ms-00.txt(workin

progress),March2009.

[LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, Locator/ID Separation Protocol (LISP1)

[RoutableIDVersion],Slidesethttp://www.dino.net/~dino/iet/lisp1.ppt, October 2006.

[LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, Locator/ID Separation Protocol (LISP2)

[DNS-basedVersion],Slidesethttp://www.dino.net/~dino/iet/lisp2.ppt, November 2006.
http://www.mitre.org/work/tech_papers/tech_papers_05/05_0966/05_0966.pdfhttp://www.mitre.org/work/tech_papers/tech_papers_05/05_0966/05_0966.pdfhttp://www.mitre.org/work/tech_papers/tech_papers_05/05_0966/05_0966.pdfhttp://tools.ietf.org/id/draft-farinacci-lisp-12.txthttp://tools.ietf.org/id/draft-farinacci-lisp-12.txthttp://www.iana.org/numbers.htmlhttp://www.chiappa.net/~jnc/tech/endpoints.txthttp://www.cs.rice.edu/Conferences/IPTPS02/174.pdfhttp://www.dinof.net/~dino/ietf/lisp1.ppthttp://www.dinof.net/~dino/ietf/lisp1.ppthttp://www.dinof.net/~dino/ietf/lisp1.ppthttp://www.dinof.net/~dino/ietf/lisp1.ppthttp://www.cs.rice.edu/Conferences/IPTPS02/174.pdfhttp://www.chiappa.net/~jnc/tech/endpoints.txthttp://www.iana.org/numbers.htmlhttp://tools.ietf.org/id/draft-farinacci-lisp-12.txthttp://tools.ietf.org/id/draft-farinacci-lisp-12.txthttp://www.mitre.org/work/tech_papers/tech_papers_05/05_0966/05_0966.pdfhttp://www.mitre.org/work/tech_papers/tech_papers_05/05_0966/05_0966.pdf


11/11

White Paper

[LISPDHT] Mathy,L.,Iannone,L.,andO.Bonaventure,LISP-DHT:TowardsaDHTtomapidentifiers

ontolocators,draft-mathy-lisp-dht-00.txt(workinprogress),February2008.

[LOC-ID-ARCH] Meyer,D.andD.Lewis,ArchitecturalImplicationsofLocator/IDSeparation,draft-

meyer-loc-id-implications-01.txt (work in progress), January 2009.

[MLISP] Farinacci,D.,Meyer,D.,Zwiebel,J.,andS.Venaas,LISPforMulticastEnvironments,

draft-farinacci-lisp-multicast-01.txt(workinprogress),November2008.

[NERD] Lear,E.,NERD:ANot-So-NovelEIDtoRLOCDatabase,draft-lear-lisp-nerd-04.txt

(workinprogress),April2008.

[OPENLISP] Iannone,L.andO.Bonaventure,OpenLISPImplementationReport,

draft-iannone-openlisp-implementation-01.txt(workinprogress),July2008.

[RADIR] Narten,T.,RoutingandAddressingProblemStatement,draft-narten-radir-problem-statement-00.txt(workinprogress),July2007.

[RFC3344bis] Perkins,C.,IPMobilitySupportforIPv4,revised,draft-ietf-mip4-rfc3344bis-05

(workinprogress),July2007.

[RFC4192] Baker,F.,Lear,E.,andR.Droms,ProceduresforRenumberinganIPv6NetworkWithout

aFlagDay,RFC4192,September2005.

[RPFV] Wijnands,I.J.,Boers,A.,andE.Rosen,TheRPFVectorTLV,

draft-ietf-pim-rpf-vector-08.txt(workinprogress).

[RPMD] Handley,M.,Huici,F.,andA.Greenhalgh,RPMD:ProtocolforRoutingProtocolMetadataDissemination,draft-handley-p2ppush-unpublished-2007726.txt(workinprogress),

July2007.

[SHIM6] Nordmark,E.andM.Bagnulo,Level3multi-homingshimprotocol,

drat-iet-shim6-proto-06.txt (work in progress), October 2006.

Cisco has more than 200 ofces worldwide. Addresses, phone numbers, and ax numbers are listed on the Cisco Website at www.cisco.com/go/oces .

Cisco and the Cisco Logo are trademarks o Cisco Systems, Inc. and/or its afliates in the U.S. and other countries. A listing o Ciscos trademarks can be ound atwww.cisco.com/go/trademarks. Third party trademarks mentioned are the property o their respective owners. The use o the word partner does not imply a partnership

relationshipbetweenCiscoandanyothercompany.(1005R)

Americas HeadquartersCisco Systems, Inc.San Jose, CA

Asia Pacifc HeadquartersCisco Systems (USA) Pte. Ltd.Singapore

Europe HeadquartersCisco Systems International BV Amsterdam,The Netherlands

9/11

Documents

LISP Encryption