draft-ietf-lisp-interworking-04.txt   draft-ietf-lisp-interworking-05.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: August 20, 2012 V. Fuller Expires: September 1, 2012 V. Fuller
Cisco Systems, Inc. Cisco Systems, Inc.
February 17, 2012 February 29, 2012
Interworking LISP with IPv4 and IPv6 Interworking LISP with IPv4 and IPv6
draft-ietf-lisp-interworking-04.txt draft-ietf-lisp-interworking-05.txt
Abstract Abstract
This document describes techniques for allowing sites running the This document describes techniques for allowing sites running the
Locator/ID Separation Protocol (LISP) to interoperate with Internet Locator/ID Separation Protocol (LISP) to interoperate with Internet
sites (which may be using either IPv4, IPv6, or both) but which are sites (which may be using either IPv4, IPv6, or both) but which are
not running LISP. A fundamental property of LISP speaking sites is not running LISP. A fundamental property of LISP speaking sites is
that they use Endpoint Identifiers (EIDs), rather than traditional IP that they use Endpoint Identifiers (EIDs), rather than traditional IP
addresses, in the source and destination fields of all traffic they addresses, in the source and destination fields of all traffic they
emit or receive. While EIDs are syntactically identical to IPv4 or emit or receive. While EIDs are syntactically identical to IPv4 or
IPv6 addresses, normally routes to them are not carried in the global IPv6 addresses, normally routes to them are not carried in the global
routing system so an interoperability mechanism is needed for non- routing system so an interoperability mechanism is needed for non-
LISP-speaking sites to exchange traffic with LISP-speaking sites. LISP-speaking sites to exchange traffic with LISP-speaking sites.
This document introduces three such mechanisms. The first uses a new This document introduces three such mechanisms. The first uses a new
network element, the LISP Proxy Ingress Tunnel Routers (PITR) network element, the LISP Proxy Ingress Tunnel Routers (Proxy-ITRs)
(Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR)
for non-LISP-speaking hosts. Second the document adds Network for non-LISP-speaking hosts. Second the document adds Network
Address Translation (NAT) functionality to LISP Ingress and LISP Address Translation (NAT) functionality to LISP Ingress and LISP
Egress Tunnel Routers (xTRs) to substitute routable IP addresses for Egress Tunnel Routers (xTRs) to substitute routable IP addresses for
non-routable EIDs. Finally, this document introduces a Proxy Egress non-routable EIDs. Finally, this document introduces the Proxy
Tunnel Router (PETR) to handle cases where a LISP ITR cannot send Egress Tunnel Router (Proxy ETR) to handle cases where a LISP ITR
packets to non-LISP sites without encapsulation. cannot send packets to non-LISP sites without encapsulation.
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). 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 August 20, 2012. This Internet-Draft will expire on September 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 6 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 3. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 7
4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8
4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 8 4.2. Requirement for sites to use BGP . . . . . . . . . . . . . 8
4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 8 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 8
4.4. Use of Routable EIDs for sites transitioning to LISP . . . 8 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 8
5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10
5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 10 5.1. Proxy-ITR EID announcements . . . . . . . . . . . . . . . 10
5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 10 5.2. Packet Flow with Proxy-ITRs . . . . . . . . . . . . . . . 10
5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Scaling Proxy-ITRs . . . . . . . . . . . . . . . . . . . . 11
5.4. Impact of the PITRs placement in the network . . . . . . . 12 5.4. Impact of the Proxy-ITRs placement in the network . . . . 12
5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 12 5.5. Benefit to Networks Deploying Proxy-ITRs . . . . . . . . . 12
6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 13
6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 13 6.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 13
6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending 7. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 14 7.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 15
6.3. LISP Sites with Hosts using RFC 1918 Addresses 7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending
Sending Packets to Other LISP Sites . . . . . . . . . . . 14 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 16
6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 15 7.3. LISP Sites with Hosts using RFC 1918 Addresses
7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 16 Sending Packets to Other LISP Sites . . . . . . . . . . . 16
7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 16 7.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 17
8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and
(PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Proxy-ETRs (Proxy-ETRs) . . . . . . . . . . . . . . . . . . . 18
8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 18 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document describes interoperation between LISP [LISP] sites This document describes interoperation mechanisms between LISP [LISP]
which use non-globally-routed EIDs, and non-LISP sites. The first is sites which use non-globally-routed EIDs, and non-LISP sites. A key
the use of Proxy Ingress Tunnel router (PITRs), which originate behavior of the separation of Locators and Endpoint IDs is that EID
highly-aggregated routes to EID prefixes for non-LISP sites to use. prefixes are normally not advertised into the Internet's Default Free
It also describes the use of NAT by LISP ITRs when sending packets to Zone (DFZ). Specifically, only Routing Locators (RLOCs) are carried
non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers in the Internet's DFZ. Existing Internet sites (and their hosts)
(PETRs) LISP for sites relying on PITRs, and which are faced with which do not run in the LISP protocol must still be able to reach
certain restrictions. sites numbered from LISP EID space. This draft describes three
mechanisms that can be used to provide reachability between sites
A key behavior of the separation of Locators and End-Point-IDs is that are LISP-capable and those that are not.
that EID prefixes are normally not advertised into the Internet's
Default Free Zone (DFZ). Specifically, only Routing Locators (RLOCs)
are carried in the Internet's DFZ. Existing Internet sites (and
their hosts) which do not run in the LISP protocol must still be able
to reach sites numbered from LISP EID space. This draft describes
three mechanisms that can be used to provide reachability between
sites that are LISP-capable and those that are not.
The first mechanism uses a new network element, the LISP Proxy The first mechanism uses a new network element, the LISP Proxy
Ingress Tunnel Router (PITR) to act as a intermediate LISP Ingress Ingress Tunnel Router (Proxy-ITR) to act as a intermediate LISP
Tunnel Router (ITR) for non-LISP-speaking hosts. The second Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. The second
mechanism adds a form of Network Address Translation (NAT) mechanism adds a form of Network Address Translation (NAT)
functionality to Tunnel Routers (xTRs), to substitute routable IP functionality to Tunnel Routers (xTRs), to substitute routable IP
addresses for non-routable EIDs. The final network element is the addresses for non-routable EIDs. The final network element is the
LISP Proxy Egress Tunnel Routers (PETR), which act as an intermediate LISP Proxy Egress Tunnel Routers (Proxy-ETR), which act as an
Egress Tunnel Router (ETR) for LISP sites which need to encapsulate intermediate Egress Tunnel Router (ETR) for LISP sites which need to
packets LISP packets destined to non-LISP sites. encapsulate 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 defines terms used throughout the document
- 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 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 Proxy-ITRs - Section 5 introduces and describes the operation of Proxy Ingress
tunnel Routerss
- Section 6 defines how NAT is used by ETRs to translate non-routable - Section 6 introduces and describes the operations of Proxy-ETRs
- Section 7 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 - Section 8 describes the relationship between asymmetric and
Symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP- symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP-
NAT) 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 LISP mapping systems. comment on the value of any of the particular LISP mapping systems.
Several areas concerning the Interworking of LISP and non-LISP sites Several areas concerning the Interworking of LISP and non-LISP sites
remain open for further study. These areas include an examination remain open for further study. These areas include an examination of
the impact of LISP-NAT on internet traffic and applications, the impact of LISP-NAT on Internet traffic and applications,
understanding the deployment motivations for the deployment and understanding the deployment motivations for the deployment and
operation of Proxy Tunnel Routers, the impact of EID routes operation of Proxy Tunnel Routers, the impact of EID routes
originated into the Internet's Default Free Zone,and the effects of originated into the Internet's Default Free Zone,and the effects of
Proxy Tunnel Routers or LISP-NAT on internet traffic and Proxy Tunnel Routers or LISP-NAT on Internet traffic and
applications. Until these issues are fully understood, it is applications. Until these issues are fully understood, it is
possible that the interworking mechanisms described in this document possible that the interworking mechanisms described in this document
are hard to deploy, or may have unintended consequences to are hard to deploy, or may have unintended consequences to
applications. applications.
2. LISP Interworking Models 2. Definition of Terms
Default Free Zone: The Default-Free Zone (DFZ) refers to the
collection of all Internet autonomous systems that do not require
a default route to route a packet to any destination.
LISP Routable (LISP-R) Site: A LISP site whose addresses are used as
both globally routable IP addresses and LISP EIDs.
LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are
EIDs only, these EIDs are not found in the legacy Internet routing
table.
LISP Proxy Ingress Tunnel Router (Proxy-ITR): Proxy-ITRs are used to
provide connectivity between sites which use LISP EIDs and those
which do not. They act as gateways between those parts of the
Internet which are not using LISP (the legacy Internet) A given
Proxy-ITR advertises one or more highly aggregated EID prefixes
into the public Internet and acts as the ITR for traffic received
from the public Internet. LISP Proxy-ITRs are described in
Section 5.
LISP Network Address Translation (LISP-NAT): Network Address
Translation between EID space assigned to a site and RLOC space
also assigned to that site. LISP Network Address Translation is
described in Section 7.
LISP Proxy Egress Tunnel Router (Proxy-ETR): Proxy-ETRs 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.
Proxy-ETRs function by having an ITR encapsulate all non-LISP
destined traffic to a pre-configured Proxy-ETR. LISP Proxy Egress
Tunnel Routers are described in Section 6.
EID Sub Namespace: A power-of-two block of aggregatable locators
set aside for LISP interworking.
For definitions of other terms, notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
consult the LISP specification [LISP].
3. 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
send packets to 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 packets 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 there are no new interworking requirements because there [LISP] and there are no new interworking requirements because there
are no new protocol requirements placed on intermediate non- LISP are no new protocol requirements placed on intermediate non- LISP
routers. routers.
In case 3, LISP site to Non-LISP site, a LISP site can (in most In case 3, LISP site to non-LISP site, a LISP site can (in most
cases) send packets to a non-LISP site because the non-LISP site cases) send packets to a non-LISP site because the non-LISP site
prefixes are routable. The non-LISP site need not do anything new to prefixes are routable. The non-LISP sites need not do anything new
receive packets. The only action the LISP site needs to take is to to receive packets. The only action the LISP site needs to take is
know when not to LISP-encapsulate packets. An ITR knows explicitly to know when not to LISP-encapsulate packets. An ITR knows
that the destination is non-LISP if the destination IP address of an explicitly that the destination is non-LISP if the destination IP
IP packet matches a (negative) Map-Cache entry which has the action address of an IP packet matches a (negative) Map-Cache entry which
'Natively-Forward'. has the action 'Natively-Forward'.
There could be some situations where (unencapsulated) packets There could be some situations where (unencapsulated) packets
originated by a LISP site may not be forwarded to a non-LISP site. originated by a LISP site may not be forwarded to a non-LISP site.
These cases are reviewed in section 7, (Proxy-Egress Tunnel Routers). These cases are reviewed in section 7, (Proxy Egress Tunnel Routers).
Case 4, typically the most challenging, occurs when a host at a non- Case 4, typically the most challenging, occurs when a host at a non-
LISP site wishes to send traffic to a host at a LISP site. If the 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 source host uses a (non-globally-routable) EID as the destination IP
address, the packet is forwarded inside the source site until it address, the packet is forwarded inside the source site until it
reaches a router which cannot forward it (due to lack of a default reaches a router which cannot forward it (due to lack of a default
route), at which point the traffic is dropped. For traffic not to be route), at which point the traffic is dropped. For traffic not to be
dropped, either some mechanism to make this destination EID routable dropped, either some mechanism to make this destination EID routable
must be in place. Section 5 (PITRs) and Section 6 (LISP-NAT) must be in place. Section 5 (Proxy-ITRs) and Section 6 (LISP-NAT)
describe two such mechanisms. describe two such mechanisms. Case 4 also applies to packets
returning to the LISP site, in Case 3.
Case 4 also applies to packets returning to the LISP site, in Case 3.
3. Definition of Terms
Default Free Zone: The Default-Free Zone (DFZ) refers to the
collection of all Internet autonomous systems that do not require
a default route to route a packet to any destination.
LISP Routable (LISP-R) Site: A LISP site whose addresses are used as
both globally routable IP addresses and LISP EIDs.
LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are
EIDs only, these EIDs are not found in the legacy Internet routing
table.
LISP Proxy Ingress Tunnel Router (PITR): PITRs are used to provide
interconnectivity between sites which use LISP EIDs and those
which do not. They act as gateways between those parts of the
Internet which are not using LISP (the legacy Internet) A given
PITR advertises one or more highly aggregated EID prefixes into
the public Internet and acts as the ITR for traffic received from
the public Internet. LISP Proxy Ingress Tunnel Routers are
described in Section 5.
LISP Network Address Translation (LISP-NAT): Network Address
Translation between EID space assigned to a site and RLOC space
also assigned to that site. LISP Network Address Translation is
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
set aside for LISP interworking.
For definitions of other terms, notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
consult the LISP specification [LISP].
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 for a LISP site to simply announce EID prefixes into the hosts is for a LISP site to simply announce EID prefixes into the
DFZ, much like the current routing system, effectively treating them DFZ, much like the current routing system, effectively treating them
as "Provider Independent (PI)" prefixes. Having a site do this is as "Provider Independent (PI)" prefixes. Having a site do this is
undesirable as it defeats one of the primary goals of LISP - to undesirable as it defeats one of the primary goals of LISP - to
reduce global routing system state. 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 addresses.
Such a mechanism is not viewed as a viable long term solution, but Such a mechanism is not viewed as a viable long term solution, but
may be a viable short term way for a site to transition a portion of 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 its address space to EID space without changing its existing routing
policy. policy.
4.2. Requirement for using BGP 4.2. Requirement for sites to use BGP
Non-LISP sites today use BGP to, among other things, enable ingress Routable EIDs might cause non-LISP sites today to use BGP to, among
traffic engineering. Relaxing this requirement is another primary other things, originate their site's routes into the DFZ, and to
design goal of LISP. enable ingress traffic engineering. Relaxing this requirement while
still letting sites control their ingress traffic engineering policy
is another primary 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:
1. Section 5 discusses the LISP Proxy Tunnel Router, an approach 1. Section 5 discusses the LISP Proxy Ingress Tunnel Router, an
that provides ITR functionality to bridge LISP-capable and non- approach that provides ITR functionality to bridge LISP-capable
LISP-capable sites. and non-LISP-capable sites.
2. Section 6 discusses another approach, LISP-NAT, in which NAT 2. Section 7 discusses another approach, LISP-NAT, in which NAT
[RFC2993] is combined with ITR functionality to limit the impact [RFC2993] is combined with ITR functionality to limit the impact
of routable EIDs on the Internet routing infrastructure. of routable EIDs on the Internet routing infrastructure.
4.4. Use of Routable EIDs for sites transitioning to 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 namespace used proposals) is to facilitate topological aggregation of namespace used
by the path computation, and, thus, decrease global routing system for the path computation, and, thus, decrease global routing system
overhead. Another goal is to achieve the benefits of improved overhead. Another goal is to achieve the benefits of improved
aggregation as soon as possible. Individual sites advertising their aggregation as soon as possible. Individual sites advertising their
own routes for LISP EID prefixes into the global routing system is own routes for LISP EID prefixes into the global routing system is
therefore not recommended. therefore not recommended.
That being said, single homed sites (or multi-homed sites that are That being said, single-homed sites (or multi-homed sites that are
not leaking more specific exceptions) and that are already using not leaking more specific exceptions) that are already using
provider-aggregated prefixes can use these prefixes as LISP EIDs provider-aggregated prefixes can use these prefixes as LISP EIDs
without adding state to the routing system. In other words, such without adding state to the routing system. In other words, such
sites do not cause additional prefixes to be advertised. For such sites do not cause additional prefixes to be advertised. For such
sites, connectivity to a non-LISP sites does not require interworking sites, connectivity to a non-LISP site does not require interworking
machinery because the "PA" EIDs are already routable (they are machinery because the "PA" EIDs are already routable (they are
effectively LISP-R type sites). Their EIDs are found in the LISP effectively LISP-R type sites). Their EIDs are found in the LISP
mapping system, and their (aggregate) PA prefix(es) are found in the mapping system, and their (aggregate) PA prefix(es) are found in the
DFZ Internet. DFZ of the Internet.
The continued announcements of an existing site's Provider The continued announcements of an existing site's Provider
Independent (or "PI") prefix(es) is of course under control of that Independent (or "PI") prefix(es) is of course under control of that
site. Some period of transition, where a site is found both in the site. Some period of transition, where a site is found both in the
LISP mapping system, and as a discrete prefix in the Internet routing LISP mapping system, and as a discrete prefix in the Internet routing
system, may be a viable transition strategy. Care should be taken system, may be a viable transition strategy. Care should be taken
not to advertise additional more specific LISP EID prefixes into the not to advertise additional more specific LISP EID prefixes into the
DFZ. DFZ.
5. Proxy Ingress Tunnel Routers 5. Proxy Ingress Tunnel Routers
Proxy Ingress Tunnel Routers (PITRs) allow for non-LISP sites to send Proxy Ingress Tunnel Routers (Proxy-ITRs) allow for non-LISP sites to
packets to LISP-NR sites. A PITR is a new network element that send packets to LISP-NR sites. A Proxy-ITR is a new network element
shares many characteristics with the LISP ITR. PITRs allow non-LISP that shares many characteristics with the LISP ITR. Proxy-ITRs allow
sites to send packets to LISP-NR sites without any changes to non-LISP sites to send packets to LISP-NR sites without any changes
protocols or equipment at the non-LISP site. PITRs have two primary to protocols or equipment at the non-LISP site. Proxy-ITRs have two
functions: primary functions:
Originating EID Advertisements: PITRs advertise highly aggregated Originating EID Advertisements: Proxy-ITRs advertise highly
EID-prefix space on behalf of LISP sites to so that non-LISP sites aggregated EID-prefix space on behalf of LISP sites so that non-
can reach them. LISP sites can reach them.
Encapsulating Legacy Internet Traffic: PITRs also encapsulate non- Encapsulating Legacy Internet Traffic: Proxy-ITRs also encapsulate
LISP Internet traffic into LISP packets and route them towards non-LISP Internet traffic into LISP packets and route them towards
their destination RLOCs. their destination RLOCs.
5.1. PITR EID announcements 5.1. Proxy-ITR EID announcements
A key part of PITR functionality is to advertise routes for highly- A key part of Proxy-ITR functionality is to advertise routes for
aggregated EID prefixes into part of the global routing system. highly- aggregated EID prefixes into parts of the global routing
Aggressive aggregation is performed to minimize the number of new system. Aggressive aggregation is performed to minimize the number
announced routes. In addition, careful placement of PITRs can of new announced routes. In addition, careful placement of Proxy-
greatly reduce the advertised scope of these new routes. To this ITRs can greatly reduce the advertised scope of these new routes. To
end, PITRs should be deployed close to non-LISP-speaking rather than this end, Proxy-ITRs should be deployed close to non-LISP-speaking
close to LISP sites. Such deployment not only limits the scope of rather than close to LISP sites. Such deployment not only limits the
EID-prefix route advertisements, it also allows traffic forwarding scope of EID-prefix route advertisements, it also allows traffic
load to be spread among many PITRs. forwarding load to be spread among many Proxy-ITRs.
5.2. Packet Flow with PITRs 5.2. Packet Flow with Proxy-ITRs
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 PITR. In this example, the LISP-NR site is given the EID prefix a Proxy-ITR. In this example, the LISP-NR site is given the EID
192.0.2.0/24. For the purposes of this example, neither this prefix prefix 192.0.2.0/24. For the purposes of this example, neither this
or any covering aggregate are present in the global routing system. prefix nor any covering aggregate are present in the global routing
In other words, without the Proxy-ITR announcing 192.0.2.0/24, a system. In other words, without the Proxy-ITR announcing
packet with this destination were to reach a router in the "Default 192.0.2.0/24, if a packet with this destination were to reach a
Free Zone", it would be dropped. router in the "Default Free Zone", it would be dropped.
A full protocol exchange example follows: A full protocol exchange example follows:
1. The source host makes a DNS lookup EID for destination, and gets 1. The source host makes a DNS lookup EID for destination, and gets
192.0.2.1 in return. 192.0.2.1 in return.
2. The source host has a default route to customer Edge (CE) router 2. The source host has a default route to Customer Edge (CE) router
and 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 192.0.2.0/24 and the next hop is the PITR. 4. The PE has a route to 192.0.2.0/24 and the next hop is the Proxy-
ITR.
5. The PITR has or acquires a mapping for 192.0.2.1 and LISP 5. The Proxy-ITR has or acquires a mapping for 192.0.2.1 and LISP
encapsulates the packet. The outer IP header now has a encapsulates the packet. The outer IP header now has a
destination address of one of the destination EID's RLOCs. The destination address of one of the destination EID's RLOCs. The
outer source address of this encapsulated packet is the PITR's outer source address of this encapsulated packet is the Proxy-
RLOC. ITR's RLOC.
6. The PITR looks up the RLOC, and forwards LISP packet to the next 6. The Proxy-ITR looks up the RLOC, and forwards LISP packet to the
hop, after which, it is forwarded by other routers to the ETR's next hop, after which, it is forwarded by other routers to the
RLOC. 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
192.0.2.1 host in the destination LISP site. 192.0.2.1 host in the destination LISP site.
8. Packets from host 192.0.2.1 will flow back through the LISP 8. Packets from host 192.0.2.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 determines
the destination site is not LISP enabled. that 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 PITR. This is because the traffic will not go back through the Proxy-ITR. 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 PITR to be The asymmetric nature of traffic flows allows the Proxy-ITR 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 PITRs 5.3. Scaling Proxy-ITRs
PITRs attract traffic by announcing the LISP EID namespace into parts Proxy-ITRs attract traffic by announcing the LISP EID namespace into
of the non-LISP-speaking global routing system. There are several parts of the non-LISP-speaking global routing system. There are
ways that a network could control how traffic reaches a particular several ways that a network could control how traffic reaches a
PITR to prevent it from receiving more traffic than it can handle: particular Proxy-ITR to prevent it from receiving more traffic than
it can handle:
1. The PITR's aggregate routes might be selectively announced, 1. The Proxy-ITR'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 PITR. For example, some of the routes being announced by that Proxy-ITR. For example, some of the routes being
might be tagged with a BGP community and their scope of announced might be tagged with a BGP community and their scope of
announcement limited by the routing policy of the provider. announcement limited by the routing policy of the provider.
2. The same address might be announced by multiple PITRs in order to 2. The same address might be announced by multiple Proxy-ITRs in
share the traffic using IP Anycast. The asymmetric nature of order to share the traffic using IP Anycast. The asymmetric
traffic flows through the Proxy ITR means that operationally, nature of traffic flows through the Proxy-ITR means that
deploying a set PITRs would be very similar to existing Anycasted operationally, deploying a set of Proxy-ITRs would be very
services like DNS caches. Multiple Proxy ITRs could advertise similar to existing Anycasted services like DNS caches. Multiple
the same BGP Next Hop IP address as their RLOC, and traffic would Proxy-ITRs could advertise the same BGP Next Hop IP address as
be attracted to the nearest Next Hop according to the network's their RLOC, and traffic would be attracted to the nearest Next
IGP. Hop according to the network's IGP.
5.4. Impact of the PITRs placement in the network 5.4. Impact of the Proxy-ITRs 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
PITRs. Placing the PITR near the source of traffic allows for the Proxy-ITRs. Placing the Proxy-ITR near the source of traffic allows
communication between the non-LISP site and the LISP site to have the for the communication between the non-LISP site and the LISP site to
least "stretch" (i.e. the least number of forwarding hops when have the least "stretch" (i.e. the least number of forwarding hops
compared to an optimal path between the sites). when compared to an optimal path between the sites).
Some proposals, for example Core Router-Integrated Overlay [CRIO], Some proposals, for example Core Router-Integrated Overlay [CRIO],
have suggested grouping PITRs near an arbitrary subset of ETRs and have suggested grouping Proxy-ITRs near an arbitrary subset of ETRs
announcing a 'local' subset of EID space. This model cannot and announcing a 'local' subset of EID space. This model cannot
guarantee minimum stretch if the EID prefix route advertisement guarantee minimum stretch if the EID prefix route advertisement
points are changed (such a change might occur if a site adds, points are changed (such a change might occur if a site adds,
removes, or replaces one or more of its ISP connections). removes, or replaces one or more of its ISP connections).
5.5. Benefit to Networks Deploying PITRs 5.5. Benefit to Networks Deploying Proxy-ITRs
When packets destined for LISP-NR sites arrive and are encapsulated When packets destined for LISP-NR sites arrive and are encapsulated
at a Proxy-ITR, a new LISP packet header is pre-pended. This causes at a Proxy-ITR, a new LISP packet header is pre-pended. This causes
the packet's destination to be set to the destination ETRs RLOC. the packet's destination to be set to the destination ETRs RLOC.
Because packets are thus routed towards RLOCs, it can potentially Because packets are thus routed towards RLOCs, it can potentially
better follow the Proxy-ITR network's traffic engineering policies better follow the Proxy-ITR network's traffic engineering policies
(such as closest exit routing). This also means that providers which (such as closest exit routing). This also means that providers which
are not default-free and do not deploy Proxy-ITRs end up sending more are not default-free and do not deploy Proxy-ITRs end up sending more
traffic to expensive transit links (assuming their upstreams have traffic to expensive transit links (assuming their upstreams have
deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to
which they may well have cheaper and closer connectivity to (via, for which they may well have cheaper and closer connectivity to (via, for
example, settlement-free peering). A corollary to this would be that example, settlement-free peering). A corollary to this would be that
large transit providers, deploying PITRs may attract more traffic, large transit providers, deploying Proxy-ITRs may attract more
and therefore more revenue, from their customers. traffic, and therefore more revenue, from their customers.
6. LISP-NAT 6. Proxy Egress Tunnel Routers
Proxy Egress Tunnel Routers (Proxy-ETRs) allow for LISP sites to send
packets to non-LISP sites in the case where the access network does
not allow the LISP site to send packets with the source address of
the site's EID(s). A Proxy-ETR 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 Proxy-ETR.
There are two primary reasons why sites would want to utilize a
Proxy-ETR:
Avoiding strict uRPF failures: Some provider's access networks
require the source of the packets emitted to be within the
addressing scope of the access networks. (see section 9)
Traversing a different IP Protocol: A LISP site may want to transmit
packets to a non-LISP site where some of the intermediate network
does not support the particular IP protocol desired (v4 or v6).
Proxy-ETRs can allow this LISP site's data to 'hop over' this by
utilizing LISP's support for mixed protocol encapsulation.
6.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 Proxy-ETR). An ITR is simply configured to send all
non-LISP traffic, which it normally would have forwarded natively
(non-encapsulated), to a Proxy-ETR. In the case where the ITR uses a
Map- Resolver(s), the ITR will encapsulate packets that match the
received 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 Proxy-ETR 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 Proxy-ETR. In this example, the LISP-NR (or LISP-R) site is given
the EID prefix 192.0.2.0/24, and it is trying to reach host at a non-
LISP site with the IP prefix of 198.51.100.0/24. For the purposes of
this example, the destination (198.51.100.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
198.51.100.100 (an IP address of a host in the 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 198.51.100.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.
7. 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' (LISP-NR EID) translating a host's source address from an 'inner' (LISP-NR EID)
value to an 'outer' (LISP-R) value and keeping this translation in a value to an 'outer' (LISP-R) value and keeping this translation in a
table that it can 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. Note that this
section is intended as rough overview of what could be done and not
an exhaustive guide to IPv4 NAT.
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 sites.
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 case occurs when a site is announcing its global EIDs) sources. This case occurs when a site is announcing its
prefix into both the LISP mapping system as well as the Internet DFZ. 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 This is because the LISP-R source's address is routable, and return
packets will be able to natively reach the site. packets will be able to natively reach the site.
6.1. Using LISP-NAT with LISP-NR EIDs 7.1. Using LISP-NAT with LISP-NR EIDs
LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP
hosts by translating the LISP-NR EID to a globally unique address (a hosts by translating the LISP-NR EID to a globally unique address (a
LISP-R EID). 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 203.0.113.0/24. In order to utilize been assigned a LISP-NR EID of 203.0.113.0/24. In order to utilize
LISP-NAT, the site has also been provided the PA EID of 192.0.2.0/24, LISP-NAT, the site has also been provided the PA EID of 192.0.2.0/24,
and uses the first address (192.0.2.1) as the site's RLOC. The rest and uses the first address (192.0.2.1) as the site's RLOC. The rest
skipping to change at page 14, line 11 skipping to change at page 16, line 13
hosts. 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
============================================================== ==============================================================
203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254 203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254
Figure 1: Example Translation Table Figure 1: Example Translation Table
The Host 203.0.113.2 sends a packet (which, for the purposes of this The host 203.0.113.2 sends a packet (which, for the purposes of this
example is destined for a non-LISP site) to its default route (the example is destined for a non-LISP site) to its default route (the
ITR). The ITR receives the packet, and determines that the ITR). The ITR receives the packet, and determines that the
destination is not a LISP site. How the ITR makes this determination destination is not a LISP site. How the ITR makes this determination
is up to the ITRs implementation of the EID-to-RLOC mapping system is up to the ITRs implementation of the EID-to-RLOC mapping system
used (see, for example [LISP-ALT]). used (see, for example [LISP-ALT]).
The ITR then rewrites the source address of the packet from The ITR then rewrites the source address of the packet from
203.0.113.2 to 192.0.2.2, which is the first available address in the 203.0.113.2 to 192.0.2.2, which is the first available address in the
LISP-R EID space available to it. The ITR keeps this translation in LISP-R EID space available to it. The ITR keeps this translation in
a table in order to reverse this process when receiving packets a table in order to reverse this process when receiving packets
destined to 192.0.2.2. destined to 192.0.2.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 7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP
Sites Sites
In the case where hosts using RFC 1918 addresses desire to send In the case where hosts using RFC 1918 addresses desire to send
packets to non-LISP hosts, the LISP-NAT implementation acts much like packets to non-LISP hosts, the LISP-NAT implementation acts much like
an existing IPv4 NAT device. The ITR providing the NAT service must an existing IPv4 NAT device that is doing address only (not port
use LISP-R EIDs for its global address pool as well as providing all translation. The ITR providing the NAT service must use LISP-R EIDs
the standard NAT functions required today. for its global address pool as well as providing all 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 7, 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 Sending Packets 7.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets
to Other LISP Sites to Other LISP Sites
LISP-NAT allows a host with an RFC 1918 address to send packets to 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 prefix of 192.0.2.0/24, and uses the first address LISP-R EID prefix of 192.0.2.0/24, and uses the first address
(192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2 (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2
to 192.0.2.254) is used as a translation pool for this site's hosts to 192.0.2.254) is used as a translation pool for this site's hosts
who need to send packets to 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
table in order to reverse this process when receiving packets table in order to reverse this process when receiving packets
destined to 192.0.2.2. destined to 192.0.2.2.
The ITR then LISP encapsulates this packet (see [LISP] for details). The ITR then LISP encapsulates this packet (see [LISP] for details).
The ITR uses the site's RLOC as the LISP outer header's source and The ITR uses the site's RLOC as the LISP outer header's source and
the translation address as the LISP inner header's source. Once it the translation address as the LISP inner header's source. Once it
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 forwards to the proper host.
6.4. LISP-NAT and multiple EIDs 7.4. LISP-NAT and multiple EIDs
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 vs. local addressability, exists for NAT in This problem, global vs. local addressability, exists for NAT in
general, but the specific issue described above is unique to general, but the specific issue described above is unique to
location/identity separation schemes. Some of these have suggested location/identity separation schemes. Some of these have suggested
running a separate DNS instance for new types of EIDs. This solves running a separate DNS instance for new types of EIDs. This solves
the problem but introduces complexity for the site. Alternatively, the problem but introduces complexity for the site. Alternatively,
using PITRs can mitigate this problem, because the LISP-NR EID can be using Proxy-ITRs can mitigate this problem, because the LISP-NR EID
reached in all cases. can be reached in all cases.
7. Proxy Egress Tunnel Routers
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.
There are two primary reasons why sites would want to utilize a PETR:
Avoiding strict uRPF failures: Some provider's access networks
require the source of the packets emitted to be within the
addressing scope of the access networks. (see section 9)
Traversing a different IP Protocol: A LISP site may want to transmit
packets to a non-LISP site where some of the intermediate network
does not support the particular IP protocol desired (v4 or v6).
PETRs can allow this LISP site's data to 'hop over' this by
utilizing LISP's support for mixed protocol encapsulation.
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 a Map-
Resolver(s), the ITR will encapsulate packets that match the received
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 192.0.2.0/24, and it is trying to reach host at a non-LISP
site with the IP prefix of 198.51.100.0/24. For the purposes of this
example, the destination (198.51.100.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
198.51.100.100 (a Ip address of a host in the 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 198.51.100.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) 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and Proxy-ETRs
(Proxy-ETRs)
In summary, there are three mechanisms for interworking LISP with In summary, there are three mechanisms for interworking LISP with
non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the 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 LISP site can manage and control the interworking on its own. In the
PITR case, the site is not required to manage the advertisement of Proxy-ITR case, the site is not required to manage the advertisement
it's EID prefix into the DFZ, with the cost of potentially adding 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 stretch to the connections of non-LISP sites sending packets to the
LISP site. The third option is Proxy-ETRs, which are optionally used 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 by sites relying on Proxy-ITRs to mitigate two caveats for LISP sites
sending packets to non-LISP sites. This means Proxy-ETRs are not sending packets to non-LISP sites. This means Proxy-ETRs are not
usually expected to be deployed by themselves, rather they will be usually expected to be deployed by themselves, rather they will be
used to assist LISP-NR sites which are already using PITRs. used to assist LISP-NR sites which are already using Proxy-ITRs.
8.1. How Proxy-ITRs and Proxy-ETRs Interact 8.1. How Proxy-ITRs and Proxy-ETRs Interact
There is a subtle difference between Symmetrical (LISP-NAT) vs There is a subtle difference between Symmetrical (LISP-NAT) vs
Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques. Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques.
Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and Operationally, Proxy-ITRs (Proxy-ITRs) and Proxy-ETRs (Proxy-ETRs)
likely should) be decoupled since Proxy-ITRs are best deployed can (and likely should) be decoupled since Proxy-ITRs are best
closest to non-LISP sites, and Proxy-ETRs are best located close to deployed closest to non-LISP sites, and Proxy-ETRs are best located
the LISP sites they are decapsulating for. This asymmetric placement close to the LISP sites they are decapsulating for. This asymmetric
of the two network elements minimizes the stretch imposed on each placement of the two network elements minimizes the stretch imposed
direction of the packet flow, while still allowing for coarsely on each direction of the packet flow, while still allowing for
aggregated announcements of EIDs into the Internet's routing table. coarsely aggregated announcements of EIDs into the Internet's routing
table.
9. Security Considerations 9. Security Considerations
Like any router or LISP ITR, Proxy ITRs will have the opportunity to Like any router or LISP ITR, Proxy-ITRs will have the opportunity to
inspect traffic at the time that they encapsulate. The location of inspect traffic at the time that they encapsulate. The location of
these devices in the network can have implications for discarding these devices in the network can have implications for discarding
malicious traffic on behalf of ETRs which request this behavior (via 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). the drop action bit in Map-Reply packets for an EID or EID prefix).
This is an area that would benefit from further experimentation and This is an area that would benefit from further experimentation and
analysis. analysis.
LISP-Interworking via Proxy-ITRs should have no impact on the LISP-Interworking via Proxy-ITRs should have no impact on the
existing network beyond what LISP ITRs and ETRs introduce when existing network beyond what LISP ITRs and ETRs introduce when
multihoming. That is, if a site multi-homes today (with LISP or BGP) multihoming. That is, if a site multi-homes today (with LISP or BGP)
skipping to change at page 19, line 33 skipping to change at page 19, line 33
insure the quality of service meets the site's expectations. insure the quality of service meets the site's expectations.
Proxy-ITRs and Proxy ETRs share many of the same security issues Proxy-ITRs and Proxy ETRs share many of the same security issues
discussed of ITRs and ETRs. For further information, see the discussed of ITRs and ETRs. For further information, see the
security considerations section of [LISP]. security considerations section of [LISP].
As with traditional NAT, LISP-NAT will obscure the actual host As with traditional NAT, LISP-NAT will obscure the actual host
LISP-NR EID behind the LISP-R addresses used as the NAT pool. 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 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 rely on Proxy-ITRs to enable Interworking), packets will have the
EID as its source IP address. These EIDs may not be recognized by site's EID as its source IP address. These EIDs may not be
their Internet Service Provider's Unicast Reverse Path Forwarding recognized by their Internet Service Provider's Unicast Reverse Path
(uRPF) rules enabled on the Provider Edge Router. Several options Forwarding (uRPF) rules enabled on the Provider Edge Router. Several
are available to the service provider. For example they could enable options are available to the service provider. For example they
a less strict version of uRPF, where they only look for the existence could enable a less strict version of uRPF, where they only look for
of the EID prefix in the routing table. Another, more secure, option the existence of the EID prefix in the routing table. Another, more
is to add a static route for the customer on the PE router, but not secure, option is to add a static route for the customer on the PE
redistribute this route into the provider's routing table. Finally, router, but not redistribute this route into the provider's routing
Proxy-ETRs can enable LISP sites to bypass this uRPF check by table. Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF
encapsulating all of their egressing traffic destined to non-LISP check by encapsulating all of their egress traffic destined to non-
sites to the Proxy-ETR (thus ensuring the outer IP source address is LISP sites to the Proxy-ETR (thus ensuring the outer IP source
the site's RLOC). address is the site's RLOC).
10. Acknowledgments 10. Acknowledgments
Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael
Menth, and Xuewei Wang, and Noel Chiappa who have made insightful Menth, and Xuewei Wang, and Noel Chiappa who have made insightful
comments with respect to LISP Interworking and transition 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.
skipping to change at page 22, line 44 skipping to change at page 22, line 44
Scaling IP Routing with the Core Router-Integrated Scaling IP Routing with the Core Router-Integrated
Overlay", January 2006. Overlay", January 2006.
[LISP-DEPLOY] [LISP-DEPLOY]
Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "LISP Network Element Pascual, J., and D. Lewis, "LISP Network Element
Deployment Considerations", Deployment Considerations",
draft-ietf-lisp-deployment-02.txt (work in progress), draft-ietf-lisp-deployment-02.txt (work in progress),
November 2011. November 2011.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
January 2001.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
 End of changes. 84 change blocks. 
314 lines changed or deleted 326 lines changed or added

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