draft-ietf-lisp-introduction-10.txt   draft-ietf-lisp-introduction-11.txt 
Network Working Group A. Cabellos Network Working Group A. Cabellos
Internet-Draft UPC-BarcelonaTech Internet-Draft UPC-BarcelonaTech
Intended status: Informational D. Saucez (Ed.) Intended status: Informational D. Saucez (Ed.)
Expires: July 24, 2015 INRIA Expires: August 13, 2015 INRIA
January 20, 2015 February 9, 2015
An Architectural Introduction to the Locator/ID Separation Protocol An Architectural Introduction to the Locator/ID Separation Protocol
(LISP) (LISP)
draft-ietf-lisp-introduction-10.txt draft-ietf-lisp-introduction-11.txt
Abstract Abstract
This document describes the architecture of the Locator/ID Separation This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory of the LISP protocols. This document is used for introductory
purposes, more details can be found in RFC6830, the protocol purposes, more details can be found in RFC6830, the protocol
specification. specification.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 24, 2015. This Internet-Draft will expire on August 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5
3.2. Overview of the Architecture . . . . . . . . . . . . . . 5 3.2. Overview of the Architecture . . . . . . . . . . . . . . 6
3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 9
3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 9 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10
3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 11
3.4.2. Mapping System Interface . . . . . . . . . . . . . . 10 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11
3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 12
3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 14 3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 15
4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 15 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 16
4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 16
4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 16 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 17
4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 18
4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 18
5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20
7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20 7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 21
7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20 7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21
7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. A Brief History of Location/Identity Separation . . 25 Appendix A. A Brief History of Location/Identity Separation . . 26
A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 25 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
This document introduces the Locator/ID Separation Protocol (LISP) This document introduces the Locator/ID Separation Protocol (LISP)
[RFC6830] architecture, its main operational mechanisms and its [RFC6830] architecture, its main operational mechanisms and its
design rationale. Fundamentally, LISP is built following a well- design rationale. Fundamentally, LISP is built following a well-
known architectural idea: decoupling the IP address overloaded known architectural idea: decoupling the IP address overloaded
semantics. Indeed and as pointed out by the unpublished Internet semantics. Indeed and as pointed out by the unpublished Internet
Draft by Noel Chiappa [Chiappa], currently IP addresses both identify Draft by Noel Chiappa [Chiappa], currently IP addresses both identify
the topological location of a network attachment point as well as the the topological location of a network attachment point as well as the
skipping to change at page 3, line 33 skipping to change at page 3, line 33
to the appropriate location. to the appropriate location.
In summary: In summary:
o RLOCs have meaning only in the underlay network, that is the o RLOCs have meaning only in the underlay network, that is the
underlying core routing system. underlying core routing system.
o EIDs have meaning only in the overlay network unless they are o EIDs have meaning only in the overlay network unless they are
leaked into the underlay network. The overlay is the leaked into the underlay network. The overlay is the
encapsulation relationship between LISP-capable routers. encapsulation relationship between LISP-capable routers.
Furthermore EIDs are not assigned from the reserved address
blocks.
o The LISP edge maps EIDs to RLOCs o The LISP edge maps EIDs to RLOCs
o Within the underlay network, RLOCs have both locator and o Within the underlay network, RLOCs have both locator and
identifier semantics identifier semantics
o An EID within a LISP site carries both identifier and locator o An EID within a LISP site carries both identifier and locator
semantics to other nodes within that site semantics to other nodes within that site
o An EID within a LISP site carries identifier and limited locator o An EID within a LISP site carries identifier and limited locator
skipping to change at page 4, line 24 skipping to change at page 4, line 28
mechanisms as its design rationale. It is important to note that mechanisms as its design rationale. It is important to note that
this document does not specify or complement the LISP protocol. The this document does not specify or complement the LISP protocol. The
interested reader should refer to the main LISP specifications interested reader should refer to the main LISP specifications
[RFC6830] and the complementary documents [RFC6831], [RFC6832], [RFC6830] and the complementary documents [RFC6831], [RFC6832],
[RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the
protocol specifications along with the LISP deployment guidelines protocol specifications along with the LISP deployment guidelines
[RFC7215]. [RFC7215].
2. Definition of Terms 2. Definition of Terms
This document describes the LISP architecture and does not define or Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used to
introduce any new term. The reader is referred to [RFC6830], uniquely identify nodes irrespective of their topological location
[RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], and are typically routed intra-domain.
[RFC7052], [RFC7215] for the LISP definition of terms.
Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned
topologically to network attachment points and typically routed
inter-domain.
Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates
packets from a LISP site towards the core network.
Egress Tunnel Router (ETR): A LISP-capable router that decapsulates
packets from the core of the network towards a LISP site.
xTR: A router that implements both ITR and ETR functionalities.
Map-Request: A LISP signaling message used to request an EID-to-RLOC
mapping.
Map-Reply: A LISP signaling message sent in response to a Map-
Request that contains a resolved EID-to-RLOC mapping.
Map-Register: A LISP signaling message used to register an EID-to-
RLOC mapping.
Map-Notify: A LISP signaling message sent in response of a Map-
Register to acknowledge the correct reception of an EID-to-RLOC
mapping.
This document describes the LISP architecture and does not introduce
any new term. The reader is referred to [RFC6830], [RFC6831],
[RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052],
[RFC7215] for the complete definition of terms.
3. LISP Architecture 3. LISP Architecture
This section presents the LISP architecture, it first details the This section presents the LISP architecture, it first details the
design principles of LISP and then it proceeds to describe its main design principles of LISP and then it proceeds to describe its main
aspects: data-plane, control-plane, and internetworking mechanisms. aspects: data-plane, control-plane, and internetworking mechanisms.
3.1. Design Principles 3.1. Design Principles
The LISP architecture is built on top of four basic design The LISP architecture is built on top of four basic design
skipping to change at page 7, line 32 skipping to change at page 8, line 28
EID_A--|ITR_A|----| Space | |ETR_B|--EID_B EID_A--|ITR_A|----| Space | |ETR_B|--EID_B
| | RLOC_A1 |-------| | | | RLOC_A1 |-------| |
+-----+ | | RLOC_B2+-----+ +-----+ | | RLOC_B2+-----+
, / , /
\ / \ /
`', ,-` `', ,-`
``''-''`` ``''-''``
Figure 2.- Packet flow sequence in LISP Figure 2.- Packet flow sequence in LISP
1. HostA retrieves the EID_B of HostB (typically querying the DNS) 1. HostA retrieves the EID_B of HostB, typically querying the DNS
and generates an IP packet as in the Internet, the packet has and obtaining and A or AAAA record. Then it generates an IP
source address EID_A and destination address EID_B. packet as in the Internet, the packet has source address EID_A
and destination address EID_B.
2. The packet is routed towards ITR_A in the LISP site using 2. The packet is routed towards ITR_A in the LISP site using
standard intra-domain mechanisms. standard intra-domain mechanisms.
3. ITR_A upon receiving the packet queries the Mapping System to 3. ITR_A upon receiving the packet queries the Mapping System to
retrieve the locator of ETR_B that is servicing HostB's EID_B. retrieve the locator of ETR_B that is servicing HostB's EID_B.
In order to do so it uses a LISP control message called Map- In order to do so it uses a LISP control message called Map-
Request, the message contains EID_B as the lookup key. In turn Request, the message contains EID_B as the lookup key. In turn
it receives another LISP control message called Map-Reply, the it receives another LISP control message called Map-Reply, the
message contains two locators: RLOC_B1 and RLOC_B2 along with message contains two locators: RLOC_B1 and RLOC_B2 along with
traffic engineering policies: priority and weight per locator. traffic engineering policies: priority and weight per locator.
ITR_A also stores the mapping in a local cache to speed-up Note that a Map-Reply can contain more locators if needed. ITR_A
forwarding of subsequent packets. also stores the mapping in a local cache to speed-up forwarding
of subsequent packets.
4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according
to the priorities/weights specified in the mapping). The packet to the priorities/weights specified in the mapping). The packet
contains two IP headers, the outer header has RLOC_A1 as source contains two IP headers, the outer header has RLOC_A1 as source
and RLOC_B1 as destination, the inner original header has EID_A and RLOC_B1 as destination, the inner original header has EID_A
as source and EID_B as destination. Furthermore ITR_A adds a as source and EID_B as destination. Furthermore ITR_A adds a
LISP header, more details about LISP encapsulation can be found LISP header, more details about LISP encapsulation can be found
in Section 3.3.1. in Section 3.3.1.
5. The encapsulated packet is forwarded by the Internet core as a 5. The encapsulated packet is forwarded by the Internet core as a
skipping to change at page 8, line 29 skipping to change at page 9, line 26
This section provides a high-level description of the LISP data- This section provides a high-level description of the LISP data-
plane, which is specified in detail in [RFC6830]. The LISP data- plane, which is specified in detail in [RFC6830]. The LISP data-
plane is responsible for encapsulating and decapsulating data packets plane is responsible for encapsulating and decapsulating data packets
and caching the appropriate forwarding state. It includes two main and caching the appropriate forwarding state. It includes two main
entities, the ITR and the ETR, both are LISP capable routers that entities, the ITR and the ETR, both are LISP capable routers that
connect the EID with the RLOC space (ITR) and vice versa (ETR). connect the EID with the RLOC space (ITR) and vice versa (ETR).
3.3.1. LISP Encapsulation 3.3.1. LISP Encapsulation
ITRs encapsulate data packets towards ETRs. LISP data packets are ITRs encapsulate data packets towards ETRs. LISP data packets are
encapsulated using UDP (port 4341). A particularity of LISP is that encapsulated using UDP (port 4341), the source port is selected by
the ITR and ignored on reception. A particularity of LISP is that
UDP packets should include a zero checksum [RFC6935] [RFC6936] that UDP packets should include a zero checksum [RFC6935] [RFC6936] that
it is not verified in reception, LISP also supports non-zero it is not verified in reception, LISP also supports non-zero
checksums that may be verified. This decision was made because the checksums that may be verified. This decision was made because the
typical transport protocols used by the applications already include typical transport protocols used by the applications already include
a checksum, by neglecting the additional UDP encapsulation checksum a checksum, by neglecting the additional UDP encapsulation checksum
xTRs can forward packets more efficiently. xTRs can forward packets more efficiently.
LISP-encapsulated packets also include a LISP header (after the UDP LISP-encapsulated packets also include a LISP header (after the UDP
header and before the original IP header). The LISP header is header and before the original IP header). The LISP header is
prepended by ITRs and striped by ETRs. It carries reachability prepended by ITRs and striped by ETRs. It carries reachability
skipping to change at page 9, line 23 skipping to change at page 10, line 23
addresses. This header is created by the source end-host and is addresses. This header is created by the source end-host and is
left unchanged by LISP data plane processing on the ITR and ETR. left unchanged by LISP data plane processing on the ITR and ETR.
Finally, in some scenarios Recursive and/or Re-encapsulating tunnels Finally, in some scenarios Recursive and/or Re-encapsulating tunnels
can be used for Traffic Engineering and re-routing. Re-encapsulating can be used for Traffic Engineering and re-routing. Re-encapsulating
tunnels are consecutive LISP tunnels and occur when a decapsulator tunnels are consecutive LISP tunnels and occur when a decapsulator
(an ETR action) removes a LISP header and then acts as an encapsultor (an ETR action) removes a LISP header and then acts as an encapsultor
(an ITR action) to prepend another one. On the other hand, Recursive (an ITR action) to prepend another one. On the other hand, Recursive
tunnels are nested tunnels and are implemented by using multiple LISP tunnels are nested tunnels and are implemented by using multiple LISP
encapsulations on a packet. Typically such functions are implemented encapsulations on a packet. Typically such functions are implemented
by Reencapsulating Tunnel Routers (RTRs). An RTR can be thought as a by Reencapsulating Tunnel Routers (RTRs). An RTR can be thought of
router that first acts as an ETR by decapsulating packets and then as as a router that first acts as an ETR by decapsulating packets and
an ITR by encapsulating them towards another locator, more then as an ITR by encapsulating them towards another locator, more
information can be found at [RFC6830]. information can be found at [RFC6830].
3.3.2. LISP Forwarding State 3.3.2. LISP Forwarding State
In the LISP architecture, ITRs keep just enough information to route In the LISP architecture, ITRs keep just enough information to route
traffic flowing through it. Meaning that, ITRs retrieve from the traffic flowing through it. Meaning that, ITRs retrieve from the
LISP Mapping System mappings between EID prefixes and RLOCs that are LISP Mapping System mappings between EID prefixes and RLOCs that are
used to encapsulate packets. Such mappings are stored in a local used to encapsulate packets. Such mappings are stored in a local
cache called the Map-Cache for subsequent packets addressed to the cache called the Map-Cache for subsequent packets addressed to the
same EID prefix. Note that, in case of overlapping EID-prefixes, same EID prefix. Note that, in case of overlapping EID-prefixes,
skipping to change at page 19, line 31 skipping to change at page 20, line 31
the receiver's site multicast state. the receiver's site multicast state.
LISP [RFC6831] supports all PIM modes, additionally LISP can also LISP [RFC6831] supports all PIM modes, additionally LISP can also
support non-PIM mechanisms to maintain multicast state. support non-PIM mechanisms to maintain multicast state.
7. Use Cases 7. Use Cases
7.1. Traffic Engineering 7.1. Traffic Engineering
BGP is the standard protocol to implement inter-domain routing. With BGP is the standard protocol to implement inter-domain routing. With
BGP, routing informations are propagated along the network and each BGP, routing information are propagated along the network and each
autonomous system can implement its own routing policy that will autonomous system can implement its own routing policy that will
influence the way routing information are propagated. The direct influence the way routing information are propagated. The direct
consequence is that an autonomous system cannot precisely control the consequence is that an autonomous system cannot precisely control the
way the traffic will enter the network. way the traffic will enter the network.
As opposed to BGP, a LISP site can strictly impose via which ETRs the As opposed to BGP, a LISP site can strictly impose via which ETRs the
traffic must enter the the LISP site network even though the path traffic must enter the the LISP site network even though the path
followed to reach the ETR is not under the control of the LISP site. followed to reach the ETR is not under the control of the LISP site.
This fine control is implemented with the mappings. When a remote This fine control is implemented with the mappings. When a remote
site is willing to send traffic to a LISP site, it retrieves the site is willing to send traffic to a LISP site, it retrieves the
skipping to change at page 21, line 45 skipping to change at page 22, line 45
Care must also be taken so to not overload the mapping system (i.e., Care must also be taken so to not overload the mapping system (i.e.,
the control plane infrastructure) as the operations to be performed the control plane infrastructure) as the operations to be performed
by the mapping system may be more complex than those on the data- by the mapping system may be more complex than those on the data-
plane, for that reason [RFC6830] recommends to rate limit the sending plane, for that reason [RFC6830] recommends to rate limit the sending
of messages to the mapping system. of messages to the mapping system.
To improve resiliency and reduce the overall number of messages To improve resiliency and reduce the overall number of messages
exchanged, LISP offers the possibility to leak information, such as exchanged, LISP offers the possibility to leak information, such as
reachabilty of locators, directly into data plane packets. In reachabilty of locators, directly into data plane packets. In
environments that are not fully trusted, control informations gleaned environments that are not fully trusted, control information gleaned
from data-plane packets should be verified before using them. from data-plane packets should be verified before using them.
Mappings are the centrepiece of LISP and all precautions must be Mappings are the centrepiece of LISP and all precautions must be
taken to avoid them to be manipulated or misused by malicious taken to avoid them to be manipulated or misused by malicious
entities. Using trustable Map-Servers that strictly respect entities. Using trustable Map-Servers that strictly respect
[RFC6833] and the lightweight authentication mechanism proposed by [RFC6833] and the lightweight authentication mechanism proposed by
LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the
mapping integrity. In more critical environments, secure measures mapping integrity. In more critical environments, secure measures
may be needed. may be needed.
skipping to change at page 25, line 49 skipping to change at page 26, line 49
LISP transitioned from an IRTF activity to an IETF WG in March 2009, LISP transitioned from an IRTF activity to an IETF WG in March 2009,
and after numerous revisions, the basic specifications moved to and after numerous revisions, the basic specifications moved to
becoming RFCs at the start of 2013 (although work to expand and becoming RFCs at the start of 2013 (although work to expand and
improve it, and find new uses for it, continues, and undoubtly will improve it, and find new uses for it, continues, and undoubtly will
for a long time to come). for a long time to come).
A.1. Old LISP Models A.1. Old LISP Models
LISP, as initially conceived, had a number of potential operating LISP, as initially conceived, had a number of potential operating
modes, named 'models'. Although they are note used anymore, one modes, named 'models'. Although they are not used anymore, one
occasionally sees mention of them, so they are briefly described occasionally sees mention of them, so they are briefly described
here. here.
LISP 1: EIDs all appear in the normal routing and forwarding tables LISP 1: EIDs all appear in the normal routing and forwarding tables
of the network (i.e. they are 'routable');this property is used to of the network (i.e. they are 'routable');this property is used to
'bootstrap' operation, by using this to load EID->RLOC mappings. 'bootstrap' operation, by using this to load EID->RLOC mappings.
Packets were sent with the EID as the destination in the outer Packets were sent with the EID as the destination in the outer
wrapper; when an ETR saw such a packet, it would send a Map-Reply wrapper; when an ETR saw such a packet, it would send a Map-Reply
to the source ITR, giving the full mapping. to the source ITR, giving the full mapping.
 End of changes. 13 change blocks. 
52 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/