draft-ietf-lisp-interworking-01.txt   draft-ietf-lisp-interworking-02.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: February 27, 2011 V. Fuller Expires: January 2, 2012 V. Fuller
Cisco Systems, Inc. Cisco Systems, Inc.
August 26, 2010 June 30, 2011
Interworking LISP with IPv4 and IPv6 Interworking LISP with IPv4 and IPv6
draft-ietf-lisp-interworking-01.txt draft-ietf-lisp-interworking-02.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
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 February 27, 2011. This Internet-Draft will expire on January 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 6
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8
4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 11 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 9
4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 11 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 9
4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 11 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 9
4.4. Use of Routable EIDs for sites transitioning to LISP . . . 11 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 9
5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 13 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 11
5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 13 5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 11
5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 13 5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 11
5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Impact of the PITRs placement in the network . . . . . . . 15 5.4. Impact of the PITRs placement in the network . . . . . . . 13
5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 15 5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 13
6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 16 6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . 17 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 15
6.3. LISP Sites with Hosts using RFC 1918 Addresses 6.3. LISP Sites with Hosts using RFC 1918 Addresses
Sending Packets to Other LISP Sites . . . . . . . . . . . 17 Sending Packets to Other LISP Sites . . . . . . . . . . . 15
6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 18 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 16
6.5. When LISP-NAT and PITRs used by the same LISP Site . . . . 18 6.5. When LISP-NAT and PITRs used by the same LISP Site . . . . 16
7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 19 7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 17
7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 19 7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 17
8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs
(PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 (PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 21 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document describes interoperation between LISP [LISP] sites This document describes interoperation between LISP [LISP] sites
which use non-globally-routed EIDs, and non-LISP sites. The first is which use non-globally-routed EIDs, and non-LISP sites. The first is
the use of Proxy Ingress Tunnel router (PITRs), which originate the use of Proxy Ingress Tunnel router (PITRs), which originate
highly-aggregated routes to EID prefixes for non-LISP sites to use. highly-aggregated routes to EID prefixes for non-LISP sites to use.
It also describes the use of NAT by LISP ITRs when sending packets to It also describes the use of NAT by LISP ITRs when sending packets to
non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers
(PETRs) LISP for sites relying on PITRs, and which are faced with (PETRs) LISP for sites relying on PITRs, and which are faced with
skipping to change at page 6, line 41 skipping to change at page 6, line 41
possible caveats introduced below) to take is to know when not to possible caveats introduced below) to take is to know when not to
LISP-encapsulate packets. This can be achieved by using one of two LISP-encapsulate packets. This can be achieved by using one of two
mechanisms: 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 packet's destination IP address is not found in the EID-to-
to-RLOC mapping database, the ITR could infer that it is not a RLOC mapping database, then the ITR could infer that it is not a
LISP-capable site, and decide to not LISP-encapsulate the packet. LISP-capable site. An ITR can also know explicitly that the
destination is non-LISP if the destination IP address matches a
Negative Map Reply found in its Map Cache.
3. In either of the two exceptions mentioned above there could be 3. In either of the two exceptions mentioned above there could be
some situations where (unencapsualted) packets originated by a some situations where (unencapsulated) packets originated by a
LISP site may not be forwarded to a non-LISP site. These cases LISP site may not be forwarded to a non-LISP site. These cases
are reviewed in section 7, (Proxy-Egress Tunnel Routers). 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 tin (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 some mechanism to make this destination EID dropped, either some mechanism to make this destination EID routable
routable must be in place. Section 5 (PITRs) and Section 6 (LISP- must be in place. Section 5 (PITRs) and Section 6 (LISP-NAT)
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 3. Definition of Terms
Endpoint ID (EID): Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit
(for IPv6) value used in the source and destination address fields
of the first (most inner) IP header of a packet. The host obtains
a destination EID the same way it obtains an destination address
today, for example through a DNS lookup or SIP exchange. The
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
in the [RFC4632] sense. That is, an EID-Prefix aggregate is
defined to be a single contiguous power-of-two EID-prefix block.
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): The IPv4 or IPv6 address of an egress tunnel
router (ETR). It is the output of a EID-to-RLOC mapping lookup.
An EID maps to one or more RLOCs. Typically, RLOCs are numbered
from topologically-aggregatable blocks that are assigned to a site
at each point to which it attaches to the global Internet; where
the topology is defined by the connectivity of provider networks,
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
can be used to reach the EID. We use the term "mapping" in this
document to refer to a EID-to-RLOC mapping.
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
is reachable if the ETR (or its proxy) is reachable.
Default Mapping: A Default Mapping is a mapping entry for EID-prefix
0.0.0.0/0. It maps to a locator-set used for all EIDs in the
Internet. If there is a more specific EID-prefix in the mapping
cache it overrides the Default Mapping entry. The Default Mapping
route can be learned by configuration or from a Map-Reply message
[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 Ingress Tunnel Router (PITR): PITRs 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 gateways between those parts of the which do not. They act as gateways between those parts of the
skipping to change at page 11, line 5 skipping to change at page 8, line 39
(Routable or Non-Routable EID) site's ITRs the ability to send (Routable or Non-Routable EID) site's ITRs the ability to send
packets to non-LISP sites in cases where unencapsualted packets packets to non-LISP sites in cases where unencapsualted packets
(the default mechanism) would fail to be delivered. PETRs are (the default mechanism) would fail to be delivered. PETRs are
function by having an ITR encapsulate all non-LISP destined function by having an ITR encapsulate all non-LISP destined
traffic to a pre-configured PETR. LISP Proxy Egress Tunnel traffic to a pre-configured PETR. LISP Proxy Egress Tunnel
Routers are described in Section 7. 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.
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
skipping to change at page 11, line 40 skipping to change at page 9, line 40
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 Tunnel Router, an approach
that provides ITR functionality to bridge LISP-capable and non- that provides ITR functionality to bridge LISP-capable and non-
LISP-capable sites. LISP-capable sites.
2. 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 impact
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 by 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.
skipping to change at page 12, line 18 skipping to change at page 10, line 18
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 sites 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 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 is found both in site. Some period of transition, where a site is found both in the
the LISP mapping system, and as a discrete prefix in the Internet LISP mapping system, and as a discrete prefix in the Internet routing
routing system, may be a viable transition strategy. Care should be system, may be a viable transition strategy. Care should be taken
taken not to advertise additional more specific LISP EID prefixes not to advertise additional more specific LISP EID prefixes into the
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 (PITRs) allow for non-LISP sites to send
packets to LISP-NR sites. A PITR is a new network element that packets to LISP-NR sites. A PITR is a new network element that
shares many characteristics with the LISP ITR. PITRs allow non-LISP shares many characteristics with the LISP ITR. PITRs allow non-LISP
sites to send packets to LISP-NR sites without any changes to sites to send packets to LISP-NR sites without any changes to
protocols or equipment at the non-LISP site. PITRs have two primary protocols or equipment at the non-LISP site. PITRs have two primary
functions: functions:
skipping to change at page 13, line 31 skipping to change at page 11, line 31
5.1. PITR EID announcements 5.1. PITR EID announcements
A key part of PITR 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 PITRs can announced routes. In addition, careful placement of PITRs can
greatly reduce the advertised scope of these new routes. To this greatly reduce the advertised scope of these new routes. To this
end, PITRs should be deployed close to non-LISP-speaking rather than end, PITRs should be deployed close to non-LISP-speaking rather than
close to LISP sites. Such deployment not only limits the scope of close to LISP sites. Such deployment not only limits the scope of
EID-prefix route advertisements, it also also allows traffic EID-prefix route advertisements, it also allows traffic forwarding
forwarding load to be spread among many PITRs. load to be spread among many PITRs.
5.2. Packet Flow with PITRs 5.2. Packet Flow with PITRs
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 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, without the Proxy-ITR announcing 240.0.0.0/24, a packet with words, without the Proxy-ITR announcing 240.0.0.0/24, a packet with
this destination were to reach a router in the "Default Free Zone", this destination were to reach a router in the "Default Free Zone",
it would be dropped. it would be dropped.
skipping to change at page 15, line 12 skipping to change at page 13, line 12
by that PITR. For example, some of the routes being announced by that PITR. For example, some of the routes being announced
might be tagged with a BGP community and their scope of 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 PITRs in order to
share the traffic using IP Anycast. The asymmetric nature of share the traffic using IP Anycast. The asymmetric nature of
traffic flows through the Proxy ITR means that operationally, traffic flows through the Proxy ITR means that operationally,
deploying a set PITRs would be very similar to existing Anycasted deploying a set PITRs would be very similar to existing Anycasted
services like DNS caches. Multiple Proxy ITRs could advertise services like DNS caches. Multiple Proxy ITRs could advertise
the same BGP Next Hop IP address as their RLOC, and traffic would the same BGP Next Hop IP address as their RLOC, and traffic would
be attracted to the nearest Next Hop according to the the be attracted to the nearest Next Hop according to the network's
network's IGP. IGP.
5.4. Impact of the PITRs 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
PITRs. Placing the PITR near the source 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 Some proposals, for example CRIO [CRIO], have suggested grouping
skipping to change at page 17, line 11 skipping to change at page 15, line 11
who need to send packets to 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-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 (which, for the purposes of this
default route (the ITR). The ITR receives the packet, and determines example is destined for a non-LISP site) to its default route (the
that the destination is not a LISP site. How the ITR makes this ITR). The ITR receives the packet, and determines that the
determination is up to the ITRs implementation of the EID-to-RLOC destination is not a LISP site. How the ITR makes this determination
mapping system used (see, for example [LISP-ALT]). is up to the ITRs implementation of the EID-to-RLOC 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
to 128.200.1.2, which is the first available address in the LISP-R to 128.200.1.2, which is the first available address in the LISP-R
EID space available to it. The ITR keeps this translation in a table EID space available to it. The ITR keeps this translation in a table
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.
skipping to change at page 18, line 43 skipping to change at page 16, line 44
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. When LISP-NAT and PITRs used by the same LISP Site 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 vs. local addressability, exists for NAT in
the specific issue described above is unique to location/identity general, but the specific issue described above is unique to
separation schemes. Some of these have suggested running a separate location/identity separation schemes. Some of these have suggested
DNS instance for new types of EIDs. This solves the problem but running a separate DNS instance for new types of EIDs. This solves
introduces complexity for the site. Alternatively, using PITRs can the problem but introduces complexity for the site. Alternatively,
mitigate this problem, because the LISP-NR EID can be reached in all using PITRs can mitigate this problem, because the LISP-NR EID can be
cases. reached in all cases.
7. Proxy Egress Tunnel Routers 7. Proxy Egress Tunnel Routers
Proxy Egress Tunnel Routers (PETRs) allow for LISP sites to send Proxy Egress Tunnel Routers (PETRs) allow for LISP sites to send
packets to non-LISP sites in the case where the access network does 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 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, 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. 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 This also has the effect of allowing an ITR avoid having to decide
whether to encapsulate packets or not - it can always encapsulate whether to encapsulate packets or not - it can always encapsulate
skipping to change at page 19, line 26 skipping to change at page 17, line 26
corespondent site's ETR. All other packets (those destined to non- corespondent site's ETR. All other packets (those destined to non-
LISP sites) will be sent to the originating site's PETR. LISP sites) will be sent to the originating site's PETR.
There are two primary reasons why sites would want to utilize a PETR: There are two primary reasons why sites would want to utilize a PETR:
Avoiding strict uRPF failures: Some provider's access networks Avoiding strict uRPF failures: Some provider's access networks
require the source of the packets emitted to be within the require the source of the packets emitted to be within the
addressing scope of the access networks. (see section 9) addressing scope of the access networks. (see section 9)
Traversing a different IP Protocol: A LISP site may want to transmit Traversing a different IP Protocol: A LISP site may want to transmit
packets to a non-LISP site where the some of the intermediate packets to a non-LISP site where some of the intermediate network
network does not support the particular IP protocol desired (v4 or does not support the particular IP protocol desired (v4 or v6).
v6). PETRs can allow this LISP site's data to 'hop over' this by PETRs can allow this LISP site's data to 'hop over' this by
utilizing LISP's support for mixed protocol encapsulation. utilizing LISP's support for mixed protocol encapsulation.
7.1. Packet Flow with Proxy Egress Tunnel Routers 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 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- Proxy-ETR (or PETR). An ITR is simply configured to send all non-
LISP traffic, which it normally would have forwarded natively (non- LISP traffic, which it normally would have forwarded natively (non-
encapsulated), to a PETR. In the case where the ITR uses the Map- encapsulated), to a PETR. In the case where the ITR uses a Map-
Resolver interface the ITR will encapsulate packets that match its Resolver(s), the ITR will encapsulate packets that match the received
Negative Map-Cache to the configured Proxy-ETR(s). In the case where Negative Map-Cache to the configured Proxy-ETR(s). In the case where
the ITR is connected to the mapping system directly it would the ITR is connected to the mapping system directly it would
encapsulate all packets to the configured Proxy-ETR that are cache encapsulate all packets to the configured Proxy-ETR that are cache
misses. Note that this outer encapsulation to the Proxy-ETR may be misses. Note that this outer encapsulation to the Proxy-ETR may be
in an IP protocol other than the (inner) encapsulated data. Routers in an IP protocol other than the (inner) encapsulated data. Routers
then use the LISP (outer) header's destination address to route the then use the LISP (outer) header's destination address to route the
packets toward the configured Proxy-ETR. packets toward the configured Proxy-ETR.
A PETR should verify the (inner) source EID of the packet at time of 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 decapsulation in order to verify that this is from a configured LISP
skipping to change at page 21, line 10 skipping to change at page 19, line 10
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 Proxy-ETR. This means that in 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 order to reach LISP-NR sites, non-LISP sites must still use Proxy
ITRs. ITRs.
8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs)
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, we the site is not required to manage the advertisement of PITR case, the site is not required to manage the advertisement of
it's EID prefix into the DFZ, with the cost of potentially adding 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 PITRs case 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 PITRs.
8.1. How Proxy-ITRs and Proxy-ETRs Interact 8.1. How Proxy-ITRs and Proxy-ETRs Interact
skipping to change at page 22, line 23 skipping to change at page 20, line 23
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 PITRs to enable Interworking), packets will have the Site's
EID as its source IP address. These EIDs may not be recognized by EID as its source IP address. These EIDs may not be recognized by
their Internet Service Provider's Unicast Reverse Path Forwarding their Internet Service Provider's Unicast Reverse Path Forwarding
(uRPF) rules enabled on the Provider Edge Router. Several options (uRPF) rules enabled on the Provider Edge Router. Several options
are available to the service provider. For example they could enable are available to the service provider. For example they could enable
a less strict version of uRPF, where they only look for the existence 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 EID prefix in the routing table. Another, more secure, option
option is to add a static route for the customer on the PE router, is to add a static route for the customer on the PE router, but not
but not redistribute this route into the provider's routing table. redistribute this route into the provider's routing table. Finally,
Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF check Proxy-ETRs can enable LISP sites to bypass this uRPF check by
by encapsulating all of their egressing traffic destined to non-LISP encapsulating all of their egressing traffic destined to non-LISP
sites to the Proxy-ETR (thus ensuring the outer IP source address is sites to the Proxy-ETR (thus ensuring the outer IP source address is
the site's RLOC). 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
skipping to change at page 25, line 11 skipping to change at page 23, line 11
This document creates no new requirements on IANA namespaces This document creates no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
12. References 12. References
12.1. Normative References 12.1. Normative References
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-06 (work in progress), January 2010. draft-ietf-lisp-14 (work in progress), June 2011.
[LISP-ALT] [LISP-ALT]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", Alternative Topology (LISP+ALT)",
draft-ietf-lisp-alt-03.txt (work in progress), draft-ietf-lisp-alt-07.txt (work in progress), June 2011.
Febuary 2010.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-03.txt (work in progress), Feb 2010. draft-ietf-lisp-ms-09.txt (work in progress), June 2011.
[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.
12.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", January 2006.
[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,
November 2000. November 2000.
Authors' Addresses Authors' Addresses
 End of changes. 29 change blocks. 
144 lines changed or deleted 86 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/