draft-ietf-lisp-interworking-00.txt   draft-ietf-lisp-interworking-01.txt 
Network Working Group D. Lewis Network Working Group D. Lewis
Internet-Draft D. Meyer Internet-Draft D. Meyer
Intended status: Experimental D. Farinacci Intended status: Experimental D. Farinacci
Expires: November 27, 2009 V. Fuller Expires: February 27, 2011 V. Fuller
Cisco Systems, Inc. Cisco Systems, Inc.
May 26, 2009 August 26, 2010
Interworking LISP with IPv4 and IPv6 Interworking LISP with IPv4 and IPv6
draft-ietf-lisp-interworking-00 draft-ietf-lisp-interworking-01.txt
Abstract
This document describes techniques for allowing sites running the
Locator/ID Separation Protocol (LISP) to interoperate with Internet
sites (which may be using either IPv4, IPv6, or both) but which are
not running LISP. A fundamental property of LISP speaking sites is
that they use Endpoint Identifiers (EIDs), rather than traditional IP
addresses, in the source and destination fields of all traffic they
emit or receive. While EIDs are syntactically identical to IPv4 or
IPv6 addresses, normally routes to them are not carried in the global
routing system so an interoperability mechanism is needed for non-
LISP-speaking sites to exchange traffic with LISP-speaking sites.
This document introduces three such mechanisms. The first uses a new
network element, the LISP Proxy Ingress Tunnel Routers (PITR)
(Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR)
for non-LISP-speaking hosts. Second the document adds Network
Address Translation (NAT) functionality to LISP Ingress and LISP
Egress Tunnel Routers (xTRs) to substitute routable IP addresses for
non-routable EIDs. Finally, this document introduces a Proxy Egress
Tunnel Router (PETR) to handle cases where a LISP ITR cannot send
packets to non-LISP sites without encapsulation.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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 February 27, 2011.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes techniques for allowing sites running the described in the Simplified BSD License.
Locator/ID Separation Protocol (LISP [LISP]) to interoperate with
Internet sites not running LISP. A fundamental property of LISP-
speaking sites is that they use Endpoint Identifiers (EIDs), rather
than traditional IP addresses, in the source and destination fields
of all traffic they emit or receive. While EIDs are syntactically
identical to IP addresses, routes for them are not carried in the
global routing system so an interoperability mechanism is needed for
non-LISP-speaking sites to exchange traffic with LISP-speaking sites.
This document introduces two such mechanisms: the first uses a new
network element, the LISP Proxy Tunnel Router (PTR) (Section 5) to
act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-
speaking hosts while the second adds Network Address Translation
(NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers
(xTRs) to substitute routable IP addresses for non-routable EIDs.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 3 2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 6
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8
4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 6 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 11
4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 6 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 11
4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 6 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 11
4.4. Use of Routable EIDs for Testing LISP . . . . . . . . . . 7 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 11
5. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 7 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 13
5.1. PTR EID announcements . . . . . . . . . . . . . . . . . . 7 5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 13
5.2. Packet Flow with PTRs . . . . . . . . . . . . . . . . . . 8 5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 13
5.3. Scaling PTRs . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Impact of the PTRs placement in the network . . . . . . . 9 5.4. Impact of the PITRs placement in the network . . . . . . . 15
5.5. Benefit to Networks Deploying PTRs . . . . . . . . . . . . 9 5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 15
6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. LISP-NAT for LISP-NR addressed hosts . . . . . . . . . . . 10 6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 16
6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending
to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 11 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 17
6.3. LISP Sites with Hosts using RFC 1918 Addresses 6.3. LISP Sites with Hosts using RFC 1918 Addresses
Communicating to Other LISP Sites . . . . . . . . . . . . 11 Sending Packets to Other LISP Sites . . . . . . . . . . . 17
6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 12 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 18
6.5. LISP-NAT and PTRs Together . . . . . . . . . . . . . . . . 12 6.5. When LISP-NAT and PITRs used by the same LISP Site . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 (PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document describes two mechanisms for interoperation between This document describes interoperation between LISP [LISP] sites
LISP [LISP] sites, which use non-globally-routed EIDs, and non-LISP which use non-globally-routed EIDs, and non-LISP sites. The first is
sites: use of PTRs, which create highly-aggregated routes to EID the use of Proxy Ingress Tunnel router (PITRs), which originate
prefixes for non-LISP sites to follow; and the use of NAT by LISP highly-aggregated routes to EID prefixes for non-LISP sites to use.
ETRs when communicating with non-LISP hosts. It also describes the use of NAT by LISP ITRs when sending packets to
non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers
(PETRs) LISP for sites relying on PITRs, and which are faced with
certain restrictions.
A key behavior of the separation of Locators and End-Point-IDs is A key behavior of the separation of Locators and End-Point-IDs is
that EID prefixes are not advertised to the Internet's Default Free that EID prefixes are normally not advertised into the Internet's
Zone (DFZ). Specifically, only RLOCs are carried in the Internet's Default Free Zone (DFZ). Specifically, only RLOCs are carried in the
DFZ. Existing Internet sites (and their hosts) who do not Internet's DFZ. Existing Internet sites (and their hosts) which do
participate in the LISP system must still be able to reach sites not run in the LISP protocol must still be able to reach sites
numbered from this non routed EID space. This draft describes a set numbered from LISP EID space. This draft describes three mechanisms
of mechanisms that can be used to provide reachability between sites that can be used to provide reachability between sites that are LISP-
that are LISP-capable and those that are not. This document capable and those that are not.
introduces two such mechanisms: the first uses a new network element,
the LISP Proxy Tunnel Router (PTR) (Section 5) to act as a The first mechanism uses a new network element, the LISP Proxy
intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking Ingress Tunnel Router (PITR) to act as a intermediate LISP Ingress
hosts while the second adds a form of Network Address Translation Tunnel Router (ITR) for non-LISP-speaking hosts. The second
(NAT) functionality to Tunnel Routers (xTRs) to substitute routable mechanism adds a form of Network Address Translation (NAT)
IP addresses for non-routable EIDs. functionality to Tunnel Routers (xTRs), to substitute routable IP
addresses for non-routable EIDs. The final network element is the
LISP Proxy Egress Tunnel Routers (PETR), which act as an intermediate
Egress Tunnel Router (ETR) for LISP sites which need to encapsulate
packets LISP packets destined to non-LISP sites.
More detailed descriptions of these mechanisms and the network More detailed descriptions of these mechanisms and the network
elements involved may be found in the following sections: elements involved may be found in the following sections:
- Section 2 describes the different cases where interworking - Section 2 describes the different cases where interworking
mechanisms are needed mechanisms are needed
- Section 3 defines terms used throughout the document - Section 3 defines terms used throughout the document
- Section 4 describes the relationship between the new EID prefix - Section 4 describes the relationship between the new EID prefix
space and the IP address space used by the current Internet space and the IP address space used by the current Internet
- Section 5 introduces and describes the operation of PTRs - Section 5 introduces and describes the operation of Proxy-ITRs
- Section 6 defines how NAT is used by ETRs to translate non-routable - Section 6 defines how NAT is used by ETRs to translate non-routable
EIDs into routable IP addresses. EIDs into routable IP addresses.
- Section 7 introduces and describes the operations of Proxy-ETRs
- Section 8 describes the relationship between asymmetric and
Symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP-
NAT)
Note that any successful interworking model should be independent of Note that any successful interworking model should be independent of
any particular EID-to-RLOC mapping algorithm. This document does not any particular EID-to-RLOC mapping algorithm. This document does not
comment on the value of any of the particular mapping system. comment on the value of any of the particular LISP mapping systems.
2. LISP Interworking Models 2. LISP Interworking Models
There are 4 unicast connectivity cases which describe how sites can There are 4 unicast connectivity cases which describe how sites can
communicate with each other: send packets to each other:
1. Non-LISP site to Non-LISP site 1. Non-LISP site to Non-LISP site
2. LISP site to LISP site 2. LISP site to LISP site
3. LISP site to Non-LISP site 3. LISP site to Non-LISP site
4. Non-LISP site to LISP site 4. Non-LISP site to LISP site
Note that while Cases 3 and 4 seem similar, there are subtle Note that while Cases 3 and 4 seem similar, there are subtle
differences due to the way communications are originated. differences due to the way packets are originated.
The first case is the Internet as we know it today and as such will The first case is the Internet as we know it today and as such will
not be discussed further here. The second case is documented in not be discussed further here. The second case is documented in
[LISP] and, hence, there are no new interworking requirements because [LISP] and there are no new interworking requirements because there
there are no new protocol requirements placed on intermediate non- are no new protocol requirements placed on intermediate non- LISP
LISP routers. routers.
In case 3, LISP site to Non-LISP site, a LISP site can send packets In case 3, LISP site to Non-LISP site, a LISP site can (in most
to a non-LISP site because the non-LISP site prefixes are routable. cases) send packets to a non-LISP site because the non-LISP site
The non-LISP site need not do anything new to receive packets. The prefixes are routable. The non-LISP site need not do anything new to
only action the LISP site needs to take is to know when not to LISP- receive packets. The only action the LISP site needs (with two
encapsulate packets. This can be achieved via two mechanisms: possible caveats introduced below) to take is to know when not to
LISP-encapsulate packets. This can be achieved by using one of two
mechanisms:
1. At the ITR in the source site, if the destination of an IP packet 1. At the ITR in the source site, if the destination of an IP packet
is found to match a prefix from the BGP routing table, then the is found to match a prefix from the BGP routing table, then the
site is directly reachable by the BGP core that exists and site is directly reachable by the BGP core that exists and
operates today. operates today.
2. Second, if (from the perspective of the ITR at the source site) 2. Second, if (from the perspective of the ITR at the source site)
the destination address of an IP address is not found in the EID- the destination address of an IP address is not found in the EID-
to-RLOC mapping database, the ITR could infer that it is not a to-RLOC mapping database, the ITR could infer that it is not a
LISP-capable site, and decide to not LISP-encapsulate the packet. LISP-capable site, and decide to not LISP-encapsulate the packet.
Case 4, the most challenging, occurs when a host at a non-LISP site 3. In either of the two exceptions mentioned above there could be
wishes to send traffic to a host at a LISP site. If the source host some situations where (unencapsualted) packets originated by a
uses a (non-globally-routable) EID as the destination IP address, the LISP site may not be forwarded to a non-LISP site. These cases
packet is forwarded inside the source site until it reaches a router are reviewed in section 7, (Proxy-Egress Tunnel Routers).
which cannot forward it, at which point the traffic is dropped. For
traffic not to be dropped, either some route must be exist for the
destination EID outside of LISP-speaking part of the network or an
alternate mechanism must be in place. Section 5 (PTRs) and Section 6
(LISP-NAT) describe two such mechanisms.
Note that case 4 includes packets returning to the LISP Site in case Case 4, typically the most challenging, occurs when a host at a non-
3. LISP site wishes to send traffic to a host at a LISP site. If the
source host uses a (non-globally-routable) EID as the destination IP
address, the packet is forwarded inside the source site until it
reaches a router which cannot forward tin (due to lack of a default
route), at which point the traffic is dropped. For traffic not to be
dropped, either some some mechanism to make this destination EID
routable must be in place. Section 5 (PITRs) and Section 6 (LISP-
NAT) describe two such mechanisms.
Case 4 also applies to packets returning to the LISP site, in Case 3.
3. Definition of Terms 3. Definition of Terms
Endpoint ID (EID): A 32- or 128-bit value used in the source and Endpoint ID (EID): Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit
destination fields of the first (most inner) LISP header of a (for IPv6) value used in the source and destination address fields
packet. A packet that is emitted by a system contains EIDs in its of the first (most inner) IP header of a packet. The host obtains
headers and LISP headers are prepended only when the packet a destination EID the same way it obtains an destination address
reaches an Ingress Tunnel Router (ITR) on the data path to the today, for example through a DNS lookup or SIP exchange. The
destination EID. source EID is obtained via existing mechanisms used to set a
host's "local" IP address. An EID is allocated to a host from an
EID-prefix block associated with the site where the host is
located. An EID can be used by a host to refer to other hosts.
EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be
assigned in a hierarchical manner, independent of the network
topology, to facilitate scaling of the mapping database. In
addition, an EID block assigned to a site may have site-local
structure (subnetting) for routing within the site; this structure
is not visible to the global routing system. When used in
discussions with other Locator/ID separation proposals, a LISP EID
will be called a "LEID". Throughout this document, any references
to "EID" refers to an LEID.
EID-Prefix: A power-of-2 block of EIDs which are allocated to a site
by an address allocation authority. EID-prefixes are associated
with a set of RLOC addresses which make up a "database mapping".
EID-prefix allocations can be broken up into smaller blocks when
an RLOC set is to be associated with the smaller EID- prefix. A
globally routed address block (whether PI or PA) is not an EID-
prefix. However, a globally routed address block may be removed
from global routing and reused as an EID-prefix. A site that
receives an explicitly allocated EID-prefix may not use that EID-
prefix as a globally routed prefix assigned to RLOCs
EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable
in the [RFC4632] sense. That is, an EID-Prefix aggregate is in the [RFC4632] sense. That is, an EID-Prefix aggregate is
defined to be a single contiguous power-of-two EID-prefix block. defined to be a single contiguous power-of-two EID-prefix block.
Such a block is characterized by a prefix and a length. Such a block is characterized by a prefix and a length. Provider
Independent (PI) Addresses: an address block assigned from a pool
where blocks are not associated with any particular location in
the network (e.g. from a particular service provider), and is
therefore not topologically aggregatable in the routing system.
Routing Locator (RLOC): An IP address of a LISP tunnel router. It Routing Locator (RLOC): The IPv4 or IPv6 address of an egress tunnel
is the output of a EID-to-RLOC mapping lookup. An EID maps to one router (ETR). It is the output of a EID-to-RLOC mapping lookup.
or more RLOCs. Typically, RLOCs are numbered from topologically- An EID maps to one or more RLOCs. Typically, RLOCs are numbered
aggregatable blocks and are assigned to a site at each point to from topologically-aggregatable blocks that are assigned to a site
which it attaches to the global Internet; where the topology is at each point to which it attaches to the global Internet; where
defined by the connectivity of provider networks, RLOCs can be the topology is defined by the connectivity of provider networks,
thought of as Provider Aggregatable (PA) addresses. RLOCs can be thought of as PA addresses. Multiple RLOCs can be
assigned to the same ETR device or to multiple ETR devices at a
site.
EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that
can be used to reach the EID. We use the term "mapping" in this can be used to reach the EID. We use the term "mapping" in this
document to refer to a EID-to-RLOC mapping. document to refer to a EID-to-RLOC mapping.
EID Prefix Reachability: An EID prefix is said to be "reachable" if EID Prefix Reachability: An EID prefix is said to be "reachable" if
one or more of its locators are reachable. That is, an EID prefix one or more of its locators are reachable. That is, an EID prefix
is reachable if the ETR (or its proxy) is reachable. is reachable if the ETR (or its proxy) is reachable.
Default Mapping: A Default Mapping is a mapping entry for EID-prefix Default Mapping: A Default Mapping is a mapping entry for EID-prefix
skipping to change at page 5, line 49 skipping to change at page 9, line 29
route can be learned by configuration or from a Map-Reply message route can be learned by configuration or from a Map-Reply message
[LISP]. [LISP].
LISP Routable (LISP-R) Site: A LISP site whose addresses are used as LISP Routable (LISP-R) Site: A LISP site whose addresses are used as
both globally routable IP addresses and LISP EIDs. both globally routable IP addresses and LISP EIDs.
LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are
EIDs only, these EIDs are not found in the legacy Internet routing EIDs only, these EIDs are not found in the legacy Internet routing
table. table.
LISP Proxy Tunnel Router (PTR): PTRs are used to provide LISP Proxy Ingress Tunnel Router (PITR): PITRs are used to provide
interconnectivity between sites which use LISP EIDs and those interconnectivity between sites which use LISP EIDs and those
which do not. They act as a gateway between the Legacy Internet which do not. They act as gateways between those parts of the
and the LISP enabled Network. A given PTR advertises one or more Internet which are not using LISP (the legacy Internet) A given
highly aggregated EID prefixes into the public Internet and acts PITR advertises one or more highly aggregated EID prefixes into
as the ITR for traffic received from the public Internet. LISP the public Internet and acts as the ITR for traffic received from
Proxy Tunnel Routers are described in Section 5. the public Internet. LISP Proxy Ingress Tunnel Routers are
described in Section 5.
LISP Network Address Translation (LISP-NAT): Network Address LISP Network Address Translation (LISP-NAT): Network Address
Translation between EID space assigned to a site and RLOC space Translation between EID space assigned to a site and RLOC space
also assigned to that site. LISP Network Address Translation is also assigned to that site. LISP Network Address Translation is
described in Section 6. described in Section 6.
LISP Proxy Egress Tunnel Router (PETR): PETRs provide a LISP
(Routable or Non-Routable EID) site's ITRs the ability to send
packets to non-LISP sites in cases where unencapsualted packets
(the default mechanism) would fail to be delivered. PETRs are
function by having an ITR encapsulate all non-LISP destined
traffic to a pre-configured PETR. LISP Proxy Egress Tunnel
Routers are described in Section 7.
EID Sub Namespace: A power-of-two block of aggregatable locators EID Sub Namespace: A power-of-two block of aggregatable locators
set aside for LISP interworking. set aside for LISP interworking.
4. Routable EIDs 4. Routable EIDs
An obvious way to achieve interworking between LISP and non-LISP An obvious way to achieve interworking between LISP and non-LISP
hosts is to simply announce EID prefixes into the DFZ, much like hosts is for a LISP site to simply announce EID prefixes into the
routing system, effectively treating them as "Provider Independent DFZ, much like the current routing system, effectively treating them
(PI)" prefixes. Doing this is undesirable as it defeats one of the as "Provider Independent (PI)" prefixes. Having a site do this is
primary goals of LISP - to reduce global routing system state. undesirable as it defeats one of the primary goals of LISP - to
reduce global routing system state.
4.1. Impact on Routing Table 4.1. Impact on Routing Table
If EID prefixes are announced into the DFZ, the impact is similar to If EID prefixes are announced into the DFZ, the impact is similar to
the case in which LISP has not been deployed, because these EID the case in which LISP has not been deployed, because these EID
prefixes will be no more aggregatable than existing PI addressing. prefixes will be no more aggregatable than existing PI addressing.
This behavior is not desirable and such a mechanism is not viewed as Such a mechanism is not viewed as a viable long term solution, but
a viable long term solution. may be a viable short term way for a site to transition a portion of
its address space to EID space without changing its existing routing
policy.
4.2. Requirement for using BGP 4.2. Requirement for using BGP
Non-LISP sites today use BGP to, among other things, enable ingress Non-LISP sites today use BGP to, among other things, enable ingress
traffic engineering. Relaxing this requirement is another primary traffic engineering. Relaxing this requirement is another primary
design goal of LISP. design goal of LISP.
4.3. Limiting the Impact of Routable EIDs 4.3. Limiting the Impact of Routable EIDs
Two schemes are proposed to limit the impact of having EIDs announced Two schemes are proposed to limit the impact of having EIDs announced
in the current global Internet routing table: in the current global Internet routing table:
Section 5 discusses the LISP Proxy Tunnel Router, an approach that 1. Section 5 discusses the LISP Proxy Tunnel Router, an approach
provides ITR functionality to bridge LISP-capable and non-LISP- that provides ITR functionality to bridge LISP-capable and non-
capable sites. LISP-capable sites.
Section 6 discusses another approach, LISP-NAT, in which NAT 2. Section 6 discusses another approach, LISP-NAT, in which NAT
[RFC2993] is combined with ITR functionality to limit the the [RFC2993] is combined with ITR functionality to limit the the
impact of routable EIDs on the Internet routing infrastructure. impact of routable EIDs on the Internet routing infrastructure.
4.4. Use of Routable EIDs for Testing LISP 4.4. Use of Routable EIDs for sites transitioning to LISP
A primary design goal for LISP (and other Locator/ID separation A primary design goal for LISP (and other Locator/ID separation
proposals) is to facilitate topological aggregation of addresses and, proposals) is to facilitate topological aggregation of namespace used
thus, decrease global routing system state. Another goal is to by the path computation, and, thus, decrease global routing system
achieve the benefits of improved aggregation as soon as possible. overhead. Another goal is to achieve the benefits of improved
Advertising routes for LISP EID prefixes into the global routing aggregation as soon as possible. Individual sites advertising their
system is therefore not recommended. own routes for LISP EID prefixes into the global routing system is
therefore not recommended.
That being said, sites that are already using provider-aggregated That being said, single homed sites (or multi-homed sites that are
prefixes can use these prefixes as LISP EIDs without adding state to not leaking more specific exceptions) and that are already using
the routing system; in other words, such sites do not cause provider-aggregated prefixes can use these prefixes as LISP EIDs
additional prefixes to be advertised. For such sites, connectivity without adding state to the routing system. In other words, such
to a non-LISP sites does not require interworking machinery because sites do not cause additional prefixes to be advertised. For such
the "PA" EIDs are already routable. sites, connectivity to a non-LISP sites does not require interworking
machinery because the "PA" EIDs are already routable (they are
effectively LISP-R type sites). Their EIDs are found in the LISP
mapping system, and their (aggregate) PA prefix(es) are found in the
DFZ Internet.
5. Proxy Tunnel Routers The continued announcements of an existing site's Provider
Independent (or "PI") prefix(es) is of course under control of that
site. Some period of transition, where a site is is found both in
the LISP mapping system, and as a discrete prefix in the Internet
routing system, may be a viable transition strategy. Care should be
taken not to advertise additional more specific LISP EID prefixes
into the DFZ.
Proxy Tunnel Routers (PTRs) allow for non-LISP sites to communicate 5. Proxy Ingress Tunnel Routers
with LISP-NR sites. A PTR is a new network element that shares many
characteristics with the LISP ITR. PTRs allow non-LISP sites to send
packets to LISP-NR sites without any changes to protocols or
equipment at the non-LISP site. PTRs have two primary functions:
Originating EID Advertisements: PTRs advertise highly aggregated Proxy Ingress Tunnel Routers (PITRs) allow for non-LISP sites to send
packets to LISP-NR sites. A PITR is a new network element that
shares many characteristics with the LISP ITR. PITRs allow non-LISP
sites to send packets to LISP-NR sites without any changes to
protocols or equipment at the non-LISP site. PITRs have two primary
functions:
Originating EID Advertisements: PITRs advertise highly aggregated
EID-prefix space on behalf of LISP sites to so that non-LISP sites EID-prefix space on behalf of LISP sites to so that non-LISP sites
can reach them. can reach them.
Encapsulating Legacy Internet Traffic: PTRs also encapsulate non- Encapsulating Legacy Internet Traffic: PITRs also encapsulate non-
LISP Internet traffic into LISP packets and route them towards LISP Internet traffic into LISP packets and route them towards
their destination RLOCs. their destination RLOCs.
5.1. PTR EID announcements 5.1. PITR EID announcements
A key part of PTR functionality is to advertise routes for highly- A key part of PITR functionality is to advertise routes for highly-
aggregated EID prefixes into part of the global routing system. aggregated EID prefixes into part of the global routing system.
Aggressive aggregation is performed to minimize the number of new Aggressive aggregation is performed to minimize the number of new
announced routes. In addition, careful placement of PTRs can greatly announced routes. In addition, careful placement of PITRs can
reduce the scope of these new routes. To this end, PTRs should be greatly reduce the advertised scope of these new routes. To this
deployed close to non-LISP-speaking rather than close to LISP sites. end, PITRs should be deployed close to non-LISP-speaking rather than
Such deployment not only limits the scope of EID-prefix route close to LISP sites. Such deployment not only limits the scope of
advertisements, it also also allows traffic forwarding load to be EID-prefix route advertisements, it also also allows traffic
spread among many PTRs. forwarding load to be spread among many PITRs.
5.2. Packet Flow with PTRs
Packets from a non-LISP site can reach a LISP-NR site with the aid of 5.2. Packet Flow with PITRs
a PTR. By advertising a route for a particular EID prefix into the
global routing system, traffic destined for that EID prefix is routed
to the PTR, which then performs LISP encapsulation. Once
encapsulated, traffic packets use the LISP (outer) header's
destination address to reach the destination ETR.
What follows is an example of the path a packet would take when using What follows is an example of the path a packet would take when using
a PTR. In this example, the LISP-NR site is given the EID prefix a PITR. In this example, the LISP-NR site is given the EID prefix
240.0.0.0/24. For the purposes of this example, this prefix and no 240.0.0.0/24. For the purposes of this example, this prefix and no
covering aggregate is present in the global routing system. In other covering aggregate is present in the global routing system. In other
words, if a packet with this destination were to reach a router in words, without the Proxy-ITR announcing 240.0.0.0/24, a packet with
the "Default Free Zone", it would be dropped. this destination were to reach a router in the "Default Free Zone",
it would be dropped.
A full protocol exchange example follows: A full protocol exchange example follows:
1. Source host makes a DNS lookup EID for destination, and gets 1. The source host makes a DNS lookup EID for destination, and gets
240.1.1.1 in return. 240.1.1.1 in return.
2. Source host has a default route to customer Edge (CE) router and 2. The source host has a default route to customer Edge (CE) router
forwards the packet to the CE. and forwards the packet to the CE.
3. The CE has a default route to its Provider Edge (PE) router, and 3. The CE has a default route to its Provider Edge (PE) router, and
forwards the packet to the PE. forwards the packet to the PE.
4. The PE has route to 240.0.0.0/24 and the next hop is the PTR. 4. The PE has route to 240.0.0.0/24 and the next hop is the PITR.
5. The PTR has or acquires a mapping for 240.1.1.1 and LISP 5. The PITR has or acquires a mapping for 240.1.1.1 and LISP
encapsulates, the packet now has a destination address of the encapsulates the packet. The outer IP header now has a
RLOC. The source address of this encapsulated packet is the destination address of one of the destination EID's RLOCs. The
PTR's RLOC. outer source address of this encapsulated packet is the PITR's
RLOC.
6. The PTR looks up the RLOC, and forwards LISP packet to the next 6. The PITR looks up the RLOC, and forwards LISP packet to the next
hop. hop, after which, it is forwarded by other routers to the ETR's
RLOC.
7. The ETR decapsulates the packet and delivers the packet to the 7. The ETR decapsulates the packet and delivers the packet to the
240.1.1.1 host in the destination LISP site. 240.1.1.1 host in the destination LISP site.
8. Packets from host 240.1.1.1 will flow back through the LISP 8. Packets from host 240.1.1.1 will flow back through the LISP
site's ITR. Such packets are not encapsulated because the ITR site's ITR. Such packets are not encapsulated because the ITR
knows that the destination (the original source) is a non-LISP knows that the destination (the original source) is a non-LISP
site. The ITR knows this because it can check the LISP mapping site. The ITR knows this because it can check the LISP mapping
database for the destination EID, and on a failure determine that database for the destination EID, and on a failure determine that
the destination site is not LISP enabled. the destination site is not LISP enabled.
9. Packets are then routed natively and directly to the destination 9. Packets are then routed natively and directly to the destination
(original source) site. (original source) site.
Note that in this example the return path is asymmetric, so return Note that in this example the return path is asymmetric, so return
traffic will not go back through the PTR. This is because the traffic will not go back through the PITR. This is because the
LISP-NR site's ITR will discover that the originating site is not a LISP-NR site's ITR will discover that the originating site is not a
LISP site, and not encapsulate the returning packet (see [LISP] for LISP site, and not encapsulate the returning packet (see [LISP] for
details of ITR behavior). details of ITR behavior).
The asymmetric nature of traffic flows allows the PTR to be The asymmetric nature of traffic flows allows the PITR to be
relatively simple - it will only have to encapsulate LISP packets. relatively simple - it will only have to encapsulate LISP packets.
5.3. Scaling PTRs 5.3. Scaling PITRs
PTRs attract traffic by announcing the LISP EID namespace into parts PITRs attract traffic by announcing the LISP EID namespace into parts
of the non-LISP-speaking global routing system. There are several of the non-LISP-speaking global routing system. There are several
ways that a network could control how traffic reaches a particular ways that a network could control how traffic reaches a particular
PTR to prevent it from receiving more traffic than it can handle: PITR to prevent it from receiving more traffic than it can handle:
First, the PTR's aggregate routes might be selectively announced, 1. The PITR's aggregate routes might be selectively announced,
giving a coarse way to control the quantity of traffic attracted giving a coarse way to control the quantity of traffic attracted
by that PTR. by that PITR. For example, some of the routes being announced
might be tagged with a BGP community and their scope of
announcement limited by the routing policy of the provider.
Second, the same address might be announced by multiple PTRs in 2. The same address might be announced by multiple PITRs in order to
order to share the traffic using IP Anycast. The asymmetric share the traffic using IP Anycast. The asymmetric nature of
nature of traffic flows allows the PTR to be relatively simple - traffic flows through the Proxy ITR means that operationally,
it will only have to encapsulate LISP packets. deploying a set PITRs would be very similar to existing Anycasted
services like DNS caches. Multiple Proxy ITRs could advertise
the same BGP Next Hop IP address as their RLOC, and traffic would
be attracted to the nearest Next Hop according to the the
network's IGP.
5.4. Impact of the PTRs placement in the network 5.4. Impact of the PITRs placement in the network
There are several approaches that a network could take in placing There are several approaches that a network could take in placing
PTRs. Placing the PTR near the ingress of traffic allows for the PITRs. Placing the PITR near the source of traffic allows for the
communication between the non-LISP site and the LISP site to have the communication between the non-LISP site and the LISP site to have the
least "stretch" (i.e. the least number of forwarding hops when least "stretch" (i.e. the least number of forwarding hops when
compared to an optimal path between the sites). compared to an optimal path between the sites).
Some proposals, for example CRIO [CRIO], have suggested grouping PTRs Some proposals, for example CRIO [CRIO], have suggested grouping
near an arbitrary subset of ETRs and announcing a 'local' subset of PITRs near an arbitrary subset of ETRs and announcing a 'local'
EID space. This model cannot guarantee minimum stretch if the EID subset of EID space. This model cannot guarantee minimum stretch if
prefix route advertisement points are changed (such a change might the EID prefix route advertisement points are changed (such a change
occur if a site adds, removes, or replaces one or more ISPs might occur if a site adds, removes, or replaces one or more of its
connections). ISP connections).
5.5. Benefit to Networks Deploying PTRs 5.5. Benefit to Networks Deploying PITRs
When traffic destined for LISP-NR site arrives and is encapsulated at When packets destined for LISP-NR sites arrive and are encapsulated
a PTR, a new LISP packet header is pre-pended. This causes the at a Proxy-ITR, a new LISP packet header is pre-pended. This causes
packet's destination to be set to the destination site RLOC. Because the packet's destination to be set to the destination ETRs RLOC.
traffic is thus routed towards RLOCs, it can potentially better Because packets are thus routed towards RLOCs, it can potentially
follow the network's traffic engineering policies (such as closest better follow the Proxy-ITR network's traffic engineering policies
exit routing). This also means that providers who are not default- (such as closest exit routing). This also means that providers which
free and do not deploy PTRs end up sending more traffic to expensive are not default-free and do not deploy Proxy-ITRs end up sending more
transit links rather than to RLOC addresses, to which they may have traffic to expensive transit links (assuming their upstreams have
settlement-free peering. For large transit providers, deploying PTRs deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to
may attract more traffic, and therefore more revenue, from their which they may well have cheaper and closer connectivity to (via, for
customers. example, settlement-free peering). A corollary to this would be that
large transit providers, deploying PITRs may attract more traffic,
and therefore more revenue, from their customers.
6. LISP-NAT 6. LISP-NAT
LISP Network Address Translation (LISP-NAT) is a limited form of NAT LISP Network Address Translation (LISP-NAT) is a limited form of NAT
[RFC2993]. LISP-NAT is designed to enable the interworking of non- [RFC2993]. LISP-NAT is designed to enable the interworking of non-
LISP sites and LISP-NR sites by ensuring that the LISP-NR's site LISP sites and LISP-NR sites by ensuring that the LISP-NR's site
addresses are always routable. LISP-NAT accomplishes this by addresses are always routable. LISP-NAT accomplishes this by
translating a host's source address from an 'inner' value to an translating a host's source address from an 'inner' (LISP-NR EID)
'outer' value and keeping this translation in a table that it can value to an 'outer' (LISP-R) value and keeping this translation in a
reference for subsequent packets. table that it can reference for subsequent packets.
In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to
talk to both LISP or non-LISP sites. talk to both LISP or non-LISP sites.
The basic concept of LISP-NAT is that when transmitting a packet, the The basic concept of LISP-NAT is that when transmitting a packet, the
ITR replaces a non-routable EID source address with a routable source ITR replaces a non-routable EID source address with a routable source
address, which enables packets to return to the site. address, which enables packets to return to the site.
There are two main cases that involve LISP-NAT: There are two main cases that involve LISP-NAT:
1. Hosts at LISP sites that use non-routable global EIDs speaking to 1. Hosts at LISP sites that use non-routable global EIDs speaking to
non-LISP sites using global addresses. non-LISP sites using global addresses.
2. Hosts at LISP sites that use RFC 1918 private EIDs speaking to 2. Hosts at LISP sites that use RFC 1918 private EIDs speaking to
other sites, who may be either LISP or non-LISP. other sites, who may be either LISP or non-LISP.
Note that LISP-NAT is not needed in the case of LISP-R (routable Note that LISP-NAT is not needed in the case of LISP-R (routable
global EIDs) sources. This is because the LISP-R source's address is global EIDs) sources. This case occurs when a site is announcing its
routable, and return packets will be able to natively reach the site. prefix into both the LISP mapping system as well as the Internet DFZ.
This is because the LISP-R source's address is routable, and return
packets will be able to natively reach the site.
6.1. LISP-NAT for LISP-NR addressed hosts 6.1. Using LISP-NAT with LISP-NR EIDs
LISP-NAT allows a host with a LISP-NR EID to communicate with non- LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP
LISP hosts by translating the LISP-NR EID to a globally unique hosts by translating the LISP-NR EID to a globally unique address (a
address. This globally unique address may be a either a PI or PA LISP-R EID). This globally unique address may be a either a PI or PA
address. address.
An example of this translation follows. For this example, a site has An example of this translation follows. For this example, a site has
been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize
LISP-NAT, the site has also been provided the PA EID of LISP-NAT, the site has also been provided the PA EID of
128.200.1.0/24, and uses the first address (128.200.1.1) as the 128.200.1.0/24, and uses the first address (128.200.1.1) as the
site's RLOC. The rest of this PA space (128.200.1.2 to site's RLOC. The rest of this PA space (128.200.1.2 to
128.200.1.254) is used as a translation pool for this site's hosts 128.200.1.254) is used as a translation pool for this site's hosts
who need to communicate with non-LISP hosts. who need to send packets to non-LISP hosts.
The translation table might look like the following: The translation table might look like the following:
Site NR-EID Site R-EID Site's RLOC Translation Pool Site NR-EID Site R-EID Site's RLOC Translation Pool
========================================================================= ==============================================================
220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2 - 128.200.1.254 220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2-254
Figure 1: Example Translation Table Figure 1: Example Translation Table
The Host 220.1.1.2 sends a packet destined for a non-LISP site to its The Host 220.1.1.2 sends a packet destined for a non-LISP site to its
default route (the ITR). The ITR receives the packet, and determines default route (the ITR). The ITR receives the packet, and determines
that the destination is not a LISP site. How the ITR makes this that the destination is not a LISP site. How the ITR makes this
determination is up to the ITRs implementation of the EID-to-RLOC determination is up to the ITRs implementation of the EID-to-RLOC
mapping system used (see, for example [LISP-ALT]). mapping system used (see, for example [LISP-ALT]).
The ITR then rewrites the source address of the packet from 220.1.1.2 The ITR then rewrites the source address of the packet from 220.1.1.2
skipping to change at page 11, line 37 skipping to change at page 17, line 30
in order to reverse this process when receiving packets destined to in order to reverse this process when receiving packets destined to
128.200.1.2. 128.200.1.2.
Finally, when the ITR forwards this packet without encapsulating it, Finally, when the ITR forwards this packet without encapsulating it,
it uses the entry in its LISP-NAT table to translate the returning it uses the entry in its LISP-NAT table to translate the returning
packets' destination IPs to the proper host. packets' destination IPs to the proper host.
6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP
Sites Sites
In the case where RFC 1918 addressed hosts desire to communicate with In the case where hosts using RFC 1918 addresses desire to send
non-LISP hosts the LISP-NAT implementation acts much like an existing packets to non-LISP hosts, the LISP-NAT implementation acts much like
IPv4 NAT device. The ITR providing the NAT service must use LISP-R an existing IPv4 NAT device. The ITR providing the NAT service must
EIDs for its global pool as well as providing all the standard NAT use LISP-R EIDs for its global address pool as well as providing all
functions required today. the standard NAT functions required today.
The source of the packet must be translated to a LISP-R EID in a The source of the packet must be translated to a LISP-R EID in a
manner similar to Section 6, and this packet must be forwarded to the manner similar to Section 6, and this packet must be forwarded to the
ITR's next hop for the destination, without LISP encapsulation. ITR's next hop for the destination, without LISP encapsulation.
6.3. LISP Sites with Hosts using RFC 1918 Addresses Communicating to 6.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets
Other LISP Sites to Other LISP Sites
LISP-NAT allows a host with a RFC 1918 address to communicate with LISP-NAT allows a host with an RFC 1918 address to send packets to
LISP hosts by translating the RFC 1918 address to a LISP EID. After LISP hosts by translating the RFC 1918 address to a LISP EID. After
translation, the communication between source and destination ITR and translation, the communication between source and destination ITR and
ETRs continues as described in [LISP]. ETRs continues as described in [LISP].
An example of this translation and encapsulation follows. For this An example of this translation and encapsulation follows. For this
example, a host has been assigned a RFC 1918 address of 192.168.1.2. example, a host has been assigned a RFC 1918 address of 192.168.1.2.
In order to utilize LISP-NAT, the site also has been provided the In order to utilize LISP-NAT, the site also has been provided the
LISP-R EID of 192.0.2.0/24, and uses the first address (192.0.2.1) as LISP-R EID prefix of 192.0.2.0/24, and uses the first address
the site's RLOC. The rest of this PA space (192.0.2.2 to (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2
192.0.2.254) is used as a translation pool for this site's hosts who to 192.0.2.254) is used as a translation pool for this site's hosts
need to communicate with both non-LISP and LISP hosts. who need to send packets to both non-LISP and LISP hosts.
The Host 192.168.1.2 sends a packet destined for a non-LISP site to The Host 192.168.1.2 sends a packet destined for a non-LISP site to
its default route (the ITR). The ITR receives the packet and its default route (the ITR). The ITR receives the packet and
determines that the destination is a LISP site. How the ITR makes determines that the destination is a LISP site. How the ITR makes
this determination is up to the ITRs implementation of the EID/RLOC this determination is up to the ITRs implementation of the EID/RLOC
mapping system. mapping system.
The ITR then rewrites the source address of the packet from The ITR then rewrites the source address of the packet from
192.168.1.2 to 192.0.2.2, which is the first available address in the 192.168.1.2 to 192.0.2.2, which is the first available address in the
LISP EID space available to it. The ITR keeps this translation in a LISP EID space available to it. The ITR keeps this translation in a
skipping to change at page 12, line 40 skipping to change at page 18, line 32
decapsulates returning traffic, it uses the entry in its LISP-NAT decapsulates returning traffic, it uses the entry in its LISP-NAT
table to translate the returning packet's destination IP address and table to translate the returning packet's destination IP address and
then forward to the proper host. then forward to the proper host.
6.4. LISP-NAT and multiple EIDs 6.4. LISP-NAT and multiple EIDs
When a site has two addresses that a host might use for global When a site has two addresses that a host might use for global
reachability, care must be chosen on which EID is found in DNS. For reachability, care must be chosen on which EID is found in DNS. For
example, whether applications such as DNS use the LISP-R EID or the example, whether applications such as DNS use the LISP-R EID or the
LISP-NR EID. This problem exists for NAT in general, but the LISP-NR EID. This problem exists for NAT in general, but the
specific issue described above is unique to LISP. Using PTRs can specific issue described above is unique to LISP. Using PITRs can
mitigate this problem, since the LISP-NR EID can be reached in all mitigate this problem, since the LISP-NR EID can be reached in all
cases. cases.
6.5. LISP-NAT and PTRs Together 6.5. When LISP-NAT and PITRs used by the same LISP Site
With LISP-NAT, there are two EIDs possible for a given host, the With LISP-NAT, there are two EIDs possible for a given host, the
LISP-R EID and the LISP-NR EID. When a site has two addresses that a LISP-R EID and the LISP-NR EID. When a site has two addresses that a
host might use for global reachability, name-to-address directories host might use for global reachability, name-to-address directories
may need to be modified. may need to be modified.
This problem, global addressability, exists for NAT in general, but This problem, global addressability, exists for NAT in general, but
the specific issue described above is unique to LOC/ID split schemes. the specific issue described above is unique to location/identity
Some schemes [ref: 6-1 proxy] have suggested running a separate DNS separation schemes. Some of these have suggested running a separate
instance for legacy types of EIDs. This solves the problem but DNS instance for new types of EIDs. This solves the problem but
introduces complexity for the site. Alternatively, using PTRs can introduces complexity for the site. Alternatively, using PITRs can
mitigate this problem, because the LISP-NR EID can hbe reached in all mitigate this problem, because the LISP-NR EID can be reached in all
cases. cases.
In summary, there are two options for interworking LISP with IPv4 and 7. Proxy Egress Tunnel Routers
V6. In the NAT case the LISP site can use NAT and manage the
transition on its own. In the PTR case, we add a new network element
called a PTR that can relieve that burden on the site, with the
downside of potentially adding stretch to sites trying to reach the
LISP site.
7. Security Considerations Proxy Egress Tunnel Routers (PETRs) allow for LISP sites to send
packets to non-LISP sites in the case where the access network does
not allow for the LISP site send packets with the source address of
the site's EID(s). A PETR is a new network element that,
conceptually, acts as an ETR for traffic destined to non-LISP sites.
This also has the effect of allowing an ITR avoid having to decide
whether to encapsulate packets or not - it can always encapsulate
packets. An ITR would encapsulate packets destined for LISP sites
(no change here) and these would be routed directly to the
corespondent site's ETR. All other packets (those destined to non-
LISP sites) will be sent to the originating site's PETR.
Like any LISP ITR, PTRs will have the ability to inspect traffic at There are two primary reasons why sites would want to utilize a PETR:
the time that they encapsulate. More work needs to be done to see if
this ability can be exploited by the control plane along the lines of
Remote Triggered BGP Black Holes. XXX:Reference?
As with traditional NAT, LISP-NAT will hide the actual host ID behind Avoiding strict uRPF failures: Some provider's access networks
the RLOCs used as the NAT pool. require the source of the packets emitted to be within the
addressing scope of the access networks. (see section 9)
When LISP Sites reply to non-LISP sites and rely on PTRs to enable Traversing a different IP Protocol: A LISP site may want to transmit
Interworking, packets will be sourced from addresses not recognized packets to a non-LISP site where the some of the intermediate
by their Internet Service Provider's Unicast Reverse Path Forwarding network does not support the particular IP protocol desired (v4 or
(uRPF) enabled on the Provider Edge Router. Several options are v6). PETRs can allow this LISP site's data to 'hop over' this by
available to the service provider. For example they could enable a utilizing LISP's support for mixed protocol encapsulation.
less strict version of uRPF, where they only look for the existence
7.1. Packet Flow with Proxy Egress Tunnel Routers
Packets from a LISP site can reach a non-LISP site with the aid of a
Proxy-ETR (or PETR). An ITR is simply configured to send all non-
LISP traffic, which it normally would have forwarded natively (non-
encapsulated), to a PETR. In the case where the ITR uses the Map-
Resolver interface the ITR will encapsulate packets that match its
Negative Map-Cache to the configured Proxy-ETR(s). In the case where
the ITR is connected to the mapping system directly it would
encapsulate all packets to the configured Proxy-ETR that are cache
misses. Note that this outer encapsulation to the Proxy-ETR may be
in an IP protocol other than the (inner) encapsulated data. Routers
then use the LISP (outer) header's destination address to route the
packets toward the configured Proxy-ETR.
A PETR should verify the (inner) source EID of the packet at time of
decapsulation in order to verify that this is from a configured LISP
site. This is to prevent spoofed inner sources from being
encapsulated through the Proxy-ETR.
What follows is an example of the path a packet would take when using
a PETR. In this example, the LISP-NR (or LISP-R) site is given the
EID prefix 240.2.0.0/24, and it is trying to reach host at a non-LISP
site with the IP prefix of 192.0.2.0/24. For the purposes of this
example, the destination is a non-LISP site and 192.0.2.0/24 is found
in the Internet's routing system.
A full protocol exchange example follows:
1. The source host makes a DNS lookup for the destination, and gets
192.0.2.100 (a host in a non-LISP site) in return.
2. The source host has a default route to customer Edge (CE) router
and forwards the packet towards the CE.
3. The CE is a LISP ITR, and is configured to encapsulate traffic
destined for non-LISP sites to a Proxy-ETR.
4. The Proxy ETR decapsulates the LISP packet and forwards the
original packet to its next hop.
5. The packet is then routed natively and directly to the
destination (non-LISP) site 192.0.2.0/24.
Note that in this example the return path is asymmetric, so return
traffic will not go back through the Proxy-ETR. This means that in
order to reach LISP-NR sites, non-LISP sites must still use Proxy
ITRs.
8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs)
In summary, there are three mechanisms for interworking LISP with
non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the
LISP site can manage and control the interworking on its own. In the
PITR case, we the site is not required to manage the advertisement of
it's EID prefix into the DFZ, with the cost of potentially adding
stretch to the connections of non-LISP sites sending packets to the
LISP site. The third option is Proxy-ETRs, which are optionally used
by sites relying on PITRs case to mitigate two caveats for LISP sites
sending packets to non-LISP sites. This means Proxy-ETRs are not
usually expected to be deployed by themselves, rather they will be
used to assist LISP-NR sites which are already using PITRs.
8.1. How Proxy-ITRs and Proxy-ETRs Interact
There is a subtle difference between Symmetrical (LISP-NAT) vs
Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques.
Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and
likely should) be decoupled since Proxy-ITRs are best deployed
closest to non-LISP sites, and Proxy-ETRs are best located close to
the LISP sites they are decapsulating for. This asymmetric placement
of the two network elements minimizes the stretch imposed on each
direction of the packet flow, while still allowing for coarsely
aggregated announcements of EIDs into the Internet's routing table.
9. Security Considerations
Like any router or LISP ITR, PITRs will have the opportunity to
inspect traffic at the time that they encapsulate. The location of
these devices in the network can have implications for discarding
malicious traffic on behalf of ETRs which request this behavior (via
the drop action bit in Map-Reply packets for an EID or EID prefix).
As with traditional NAT, LISP-NAT will obscure the actual host
LISP-NR EID behind the LISP-R addresses used as the NAT pool.
When LISP sites send packets to non-LISP sites (these non-LISP sites
rely on PITRs to enable Interworking), packets will have the Site's
EID as its source IP address. These EIDs may not be recognized by
their Internet Service Provider's Unicast Reverse Path Forwarding
(uRPF) rules enabled on the Provider Edge Router. Several options
are available to the service provider. For example they could enable
a less strict version of uRPF, where they only look for the existence
of the the EID prefix in the routing table. Another, more secure, of the the EID prefix in the routing table. Another, more secure,
option is to add a static route for the customer on the PE router, option is to add a static route for the customer on the PE router,
but not redistribute this route into the provider's routing table. but not redistribute this route into the provider's routing table.
Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF check
by encapsulating all of their egressing traffic destined to non-LISP
sites to the Proxy-ETR (thus ensuring the outer IP source address is
the site's RLOC).
8. Acknowledgments 10. Acknowledgments
Thanks goes to Christian Vogt, Lixia Zhang and Robin Whittle who have Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael
made insightful comments with respect to interworking and transition Menth, and Xuewei Wang, and Noel Chiappa who have made insightful
mechanisms. comments with respect to LISP Interworking and transition mechanisms.
A special thanks goes to Scott Brim for his initial brainstorming of A special thanks goes to Scott Brim for his initial brainstorming of
these ideas and also for his careful review. these ideas and also for his careful review.
9. IANA Considerations 11. IANA Considerations
This document creates no new requirements on IANA namespaces This document creates no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
10. References 12. References
10.1. Normative References 12.1. Normative References
[LISP] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-00 (work in progress), May 2009. draft-ietf-lisp-06 (work in progress), January 2010.
[LISP-ALT] [LISP-ALT]
Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Topology (LISP-ALT)", draft-ietf-lisp-alt-00 (work in Alternative Topology (LISP+ALT)",
progress), May 2009. draft-ietf-lisp-alt-03.txt (work in progress),
Febuary 2010.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-03.txt (work in progress), Feb 2010.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
10.2. Informative References 12.2. Informative References
[CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO: [CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO:
Scaling IP Routing with the Core Router-Integrated Scaling IP Routing with the Core Router-Integrated
Overlay". Overlay".
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
 End of changes. 90 change blocks. 
283 lines changed or deleted 472 lines changed or added

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