draft-ietf-lisp-interworking-02.txt   draft-ietf-lisp-interworking-03.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: January 2, 2012 V. Fuller Expires: August 12, 2012 V. Fuller
Cisco Systems, Inc. Cisco Systems, Inc.
June 30, 2011 February 9, 2012
Interworking LISP with IPv4 and IPv6 Interworking LISP with IPv4 and IPv6
draft-ietf-lisp-interworking-02.txt draft-ietf-lisp-interworking-03.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 January 2, 2012. This Internet-Draft will expire on August 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 6
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7
4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 9 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8
4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 9 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 8
4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 9 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 8
4.4. Use of Routable EIDs for sites transitioning to LISP . . . 9 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 8
5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 11 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10
5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 11 5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 10
5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 11 5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 10
5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Impact of the PITRs placement in the network . . . . . . . 13 5.4. Impact of the PITRs placement in the network . . . . . . . 12
5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 13 5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 12
6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 14 6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . 15 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . 15 Sending Packets to Other LISP Sites . . . . . . . . . . . 14
6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 16 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 15
6.5. When LISP-NAT and PITRs used by the same LISP Site . . . . 16 7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 16
7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 17 7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 16
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) . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 (PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 19 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 23 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 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
skipping to change at page 6, line 5 skipping to change at page 5, line 12
- Section 7 introduces and describes the operations of Proxy-ETRs - 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
remain open for further study. These areas include an examination
the impact of LISP-NAT on internet traffic and applications,
understanding the deployment motivations for the deployment and
operation of Proxy Tunnel Routers, the impact of EID routes
originated into the Internet's Default Free Zone,and the effects of
Proxy Tunnel Routers or LISP-NAT on internet traffic and
applications. Until these issues are fully understood, it is
possible that the interworking mechanisms described in this document
are hard to deploy, or may have unintended consequences to
applications.
2. LISP Interworking Models 2. LISP Interworking Models
There are 4 unicast connectivity cases which describe how sites can There are 4 unicast connectivity cases which describe how sites can
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
skipping to change at page 6, line 30 skipping to change at page 6, line 30
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 site need not do anything new to
receive packets. The only action the LISP site needs (with two receive packets. The only action the LISP site needs to take is to
possible caveats introduced below) to take is to know when not to know when not to LISP-encapsulate packets. An ITR knows explicitly
LISP-encapsulate packets. This can be achieved by using one of two that the destination is non-LISP if the destination IP address of an
mechanisms: IP packet matches a (negative) Map-Cache entry which has the action
'Natively-Forward'.
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
site is directly reachable by the BGP core that exists and
operates today.
2. Second, if (from the perspective of the ITR at the source site)
the packet's destination IP address is not found in the EID-to-
RLOC mapping database, then the ITR could infer that it is not a
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 There could be some situations where (unencapsulated) packets
some situations where (unencapsulated) packets originated by a originated by a LISP site may not be forwarded to a non-LISP site.
LISP site may not be forwarded to a non-LISP site. These cases 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 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 (PITRs) and Section 6 (LISP-NAT)
describe two such mechanisms. describe two such mechanisms.
skipping to change at page 11, line 38 skipping to change at page 10, line 38
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 allows traffic forwarding EID-prefix route advertisements, it also allows traffic 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 192.0.2.0/24. For the purposes of this example, neither this prefix
covering aggregate is present in the global routing system. In other or any covering aggregate are present in the global routing system.
words, without the Proxy-ITR announcing 240.0.0.0/24, a packet with In other words, without the Proxy-ITR announcing 192.0.2.0/24, a
this destination were to reach a router in the "Default Free Zone", packet with this destination were to reach a router in the "Default
it would be dropped. 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
240.1.1.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 240.0.0.0/24 and the next hop is the PITR. 4. The PE has route to 192.0.2.0/24 and the next hop is the PITR.
5. The PITR has or acquires a mapping for 240.1.1.1 and LISP 5. The PITR 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 PITR's
RLOC. RLOC.
6. The PITR looks up the RLOC, and forwards LISP packet to the next 6. The PITR looks up the RLOC, and forwards LISP packet to the next
hop, after which, it is forwarded by other routers to the ETR's hop, after which, it is forwarded by other routers to the ETR's
RLOC. RLOC.
7. The ETR decapsulates the packet and delivers the packet to the 7. The ETR decapsulates the packet and delivers the packet to the
240.1.1.1 host in the destination LISP site. 192.0.2.1 host in the destination LISP site.
8. Packets from host 240.1.1.1 will flow back through the LISP 8. Packets from host 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 determine that
the destination site is not LISP enabled. the destination site is not LISP enabled.
9. Packets are then routed natively and directly to the destination 9. Packets are then routed natively and directly to the destination
(original source) site. (original source) site.
Note that in this example the return path is asymmetric, so return Note that in this example the return path is asymmetric, so return
skipping to change at page 16, line 29 skipping to change at page 15, line 29
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 forward to the proper host.
6.4. LISP-NAT and multiple EIDs 6.4. LISP-NAT and multiple EIDs
When a site has two addresses that a host might use for global
reachability, care must be chosen on which EID is found in DNS. For
example, whether applications such as DNS use the LISP-R EID or the
LISP-NR EID. This problem exists for NAT in general, but the
specific issue described above is unique to LISP. Using PITRs can
mitigate this problem, since the LISP-NR EID can be reached in all
cases.
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 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,
skipping to change at page 18, line 4 skipping to change at page 17, line 4
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
site. This is to prevent spoofed inner sources from being site. This is to prevent spoofed inner sources from being
encapsulated through the Proxy-ETR. encapsulated through the Proxy-ETR.
What follows is an example of the path a packet would take when using What follows is an example of the path a packet would take when using
a PETR. In this example, the LISP-NR (or LISP-R) site is given the a PETR. In this example, the LISP-NR (or LISP-R) site is given the
EID prefix 240.2.0.0/24, and it is trying to reach host at a non-LISP EID prefix 192.0.2.0/24, and it is trying to reach host at a non-LISP
site with the IP prefix of 192.0.2.0/24. For the purposes of this site with the IP prefix of 198.51.100.0/24. For the purposes of this
example, the destination is a non-LISP site and 192.0.2.0/24 is found example, the destination (198.51.100.0/24) is found in the Internet's
in the Internet's routing system. routing system.
A full protocol exchange example follows: A full protocol exchange example follows:
1. The source host makes a DNS lookup for the destination, and gets 1. The source host makes a DNS lookup for the destination, and gets
192.0.2.100 (a host in a non-LISP site) in return. 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 2. The source host has a default route to customer Edge (CE) router
and forwards the packet towards the CE. and forwards the packet towards the CE.
3. The CE is a LISP ITR, and is configured to encapsulate traffic 3. The CE is a LISP ITR, and is configured to encapsulate traffic
destined for non-LISP sites to a Proxy-ETR. destined for non-LISP sites to a Proxy-ETR.
4. The Proxy ETR decapsulates the LISP packet and forwards the 4. The Proxy ETR decapsulates the LISP packet and forwards the
original packet to its next hop. original packet to its next hop.
5. The packet is then routed natively and directly to the 5. The packet is then routed natively and directly to the
destination (non-LISP) site 192.0.2.0/24. destination (non-LISP) site 198.51.100.0/24.
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
skipping to change at page 20, line 7 skipping to change at page 19, line 7
Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and
likely should) be decoupled since Proxy-ITRs are best deployed likely should) be decoupled since Proxy-ITRs are best deployed
closest to non-LISP sites, and Proxy-ETRs are best located close to closest to non-LISP sites, and Proxy-ETRs are best located close to
the LISP sites they are decapsulating for. This asymmetric placement the LISP sites they are decapsulating for. This asymmetric placement
of the two network elements minimizes the stretch imposed on each of the two network elements minimizes the stretch imposed on each
direction of the packet flow, while still allowing for coarsely direction of the packet flow, while still allowing for coarsely
aggregated announcements of EIDs into the Internet's routing table. aggregated announcements of EIDs into the Internet's routing table.
9. Security Considerations 9. Security Considerations
Like any router or LISP ITR, PITRs 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
analysis.
LISP-Interworking via Proxy-ITRs should have no impact on the
existing network beyond what LISP ITRs and ETRs introduce when
multihoming. That is, if a site multi-homes today (with LISP or BGP)
there is a possibility of asymmetric flows.
Proxy-ITRs and Proxy-ETRs will likely be operated by organizations
other than those of the end site receiving or sending traffic. Care
should be taken, then, in selecting a Proxy-ITR/Proxy-ETR provider to
insure the quality of service meets the site's expectations.
Proxy-ITRs and Proxy ETRs share many of the same security issues
discussed of ITRs and ETRs. For further information, see the
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 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
skipping to change at page 23, line 11 skipping to change at page 22, 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-14 (work in progress), June 2011. draft-ietf-lisp-20 (work in progress), January 2012.
[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-07.txt (work in progress), June 2011. draft-ietf-lisp-alt-10.txt (work in progress),
December 2011.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-09.txt (work in progress), June 2011. draft-ietf-lisp-ms-15.txt (work in progress),
January 2012.
[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", January 2006. Overlay", January 2006.
[LISP-DEPLOY]
Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "LISP Network Element
Deployment Considerations",
draft-ietf-lisp-deployment-02.txt (work in progress),
November 2011.
[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.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
Authors' Addresses Authors' Addresses
Darrel Lewis Darrel Lewis
Cisco Systems, Inc. Cisco Systems, Inc.
Email: darlewis@cisco.com Email: darlewis@cisco.com
David Meyer David Meyer
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 29 change blocks. 
83 lines changed or deleted 106 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/