| Network Working Group | D. Lewis |
| Internet-Draft | D. Meyer |
| Intended status: Experimental Protocol | D. Farinacci |
| Expires: January 02, 2012 | V. Fuller |
| Cisco Systems, Inc. | |
| July 01, 2011 |
Interworking LISP with IPv4 and IPv6
draft-ietf-lisp-interworking-02.txt
This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites (which may be using either IPv4, IPv6, or both) but which are not running LISP. A fundamental property of LISP speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Routers (PITR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. Second the document adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces a Proxy Egress Tunnel Router (PETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 02, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes interoperation between LISP [LISP] sites which use non-globally-routed EIDs, and non-LISP sites. The first is the use of Proxy Ingress Tunnel router (PITRs), which originate 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 non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers (PETRs) LISP for sites relying on PITRs, and which are faced with certain restrictions.
A key behavior of the separation of Locators and End-Point-IDs is that EID prefixes are normally not advertised into the Internet's Default Free Zone (DFZ). Specifically, only 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 Ingress Tunnel Router (PITR) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. The second mechanism adds a form of Network Address Translation (NAT) functionality to Tunnel Routers (xTRs), to substitute routable IP addresses for non-routable EIDs. The final network element is the LISP Proxy Egress Tunnel Routers (PETR), which act as an intermediate Egress Tunnel Router (ETR) for LISP sites which need to encapsulate packets LISP packets destined to non-LISP sites.
More detailed descriptions of these mechanisms and the network elements involved may be found in the following sections:
- Section 2 describes the different cases where interworking mechanisms are needed
- Section 3 defines terms used throughout the document
- Section 4 describes the relationship between the new EID prefix space and the IP address space used by the current Internet
- Section 5 introduces and describes the operation of Proxy-ITRs
- Section 6 defines how NAT is used by ETRs to translate non-routable EIDs into routable IP addresses.
- Section 7 introduces and describes the operations of Proxy-ETRs
- Section 8 describes the relationship between asymmetric and Symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP-NAT)
Note that any successful interworking model should be independent of any particular EID-to-RLOC mapping algorithm. This document does not comment on the value of any of the particular LISP mapping systems.
There are 4 unicast connectivity cases which describe how sites can send packets to each other:
Note that while Cases 3 and 4 seem similar, there are subtle differences due to the way packets are originated.
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 [LISP] and there are no new interworking requirements because there are no new protocol requirements placed on intermediate non- LISP routers.
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 prefixes are routable. The non-LISP site need not do anything new to receive packets. The only action the LISP site needs (with two possible caveats introduced below) to take is to know when not to LISP-encapsulate packets. This can be achieved by using one of two mechanisms:
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 source host uses a (non-globally-routable) EID as the destination IP address, the packet is forwarded inside the source site until it reaches a router which cannot forward it (due to lack of a default route), at which point the traffic is dropped. For traffic not to be dropped, either some mechanism to make this destination EID routable must be in place. Section 5 (PITRs) and Section 6 (LISP-NAT) describe two such mechanisms.
Case 4 also applies to packets returning to the LISP site, in Case 3.
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].
An obvious way to achieve interworking between LISP and non-LISP hosts is for a LISP site to simply announce EID prefixes into the DFZ, much like the current routing system, effectively treating them as "Provider Independent (PI)" prefixes. Having a site do this is undesirable as it defeats one of the primary goals of LISP - to reduce global routing system state.
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 prefixes will be no more aggregatable than existing PI addressing. 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 its address space to EID space without changing its existing routing policy.
Non-LISP sites today use BGP to, among other things, enable ingress traffic engineering. Relaxing this requirement is another primary design goal of LISP.
Two schemes are proposed to limit the impact of having EIDs announced in the current global Internet routing table:
A primary design goal for LISP (and other Locator/ID separation proposals) is to facilitate topological aggregation of namespace used by the path computation, and, thus, decrease global routing system overhead. Another goal is to achieve the benefits of improved aggregation as soon as possible. Individual sites advertising their own routes for LISP EID prefixes into the global routing system is therefore not recommended.
That being said, single homed sites (or multi-homed sites that are not leaking more specific exceptions) and that are already using provider-aggregated prefixes can use these prefixes as LISP EIDs without adding state to the routing system. In other words, such sites do not cause additional prefixes to be advertised. For such sites, connectivity to a non-LISP sites does not require interworking machinery because the "PA" EIDs are already routable (they are effectively LISP-R type sites). Their EIDs are found in the LISP mapping system, and their (aggregate) PA prefix(es) are found in the DFZ Internet.
The continued announcements of an existing site's Provider Independent (or "PI") prefix(es) is of course under control of that site. Some period of transition, where a site is found both in the LISP mapping system, and as a discrete prefix in the Internet routing system, may be a viable transition strategy. Care should be taken not to advertise additional more specific LISP EID prefixes into the DFZ.
Proxy Ingress Tunnel Routers (PITRs) allow for non-LISP sites to send packets to LISP-NR sites. A PITR is a new network element that shares many characteristics with the LISP ITR. PITRs allow non-LISP sites to send packets to LISP-NR sites without any changes to protocols or equipment at the non-LISP site. PITRs have two primary functions:
A key part of PITR functionality is to advertise routes for highly- aggregated EID prefixes into part of the global routing system. Aggressive aggregation is performed to minimize the number of new announced routes. In addition, careful placement of PITRs can greatly reduce the advertised scope of these new routes. To this end, PITRs should be deployed close to non-LISP-speaking rather than close to LISP sites. Such deployment not only limits the scope of EID-prefix route advertisements, it also allows traffic forwarding load to be spread among many PITRs.
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 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 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", it would be dropped.
A full protocol exchange example follows:
Note that in this example the return path is asymmetric, so return traffic will not go back through the PITR. This is because the LISP-NR site's ITR will discover that the originating site is not a LISP site, and not encapsulate the returning packet (see [LISP] for details of ITR behavior).
The asymmetric nature of traffic flows allows the PITR to be relatively simple - it will only have to encapsulate LISP packets.
PITRs attract traffic by announcing the LISP EID namespace into parts of the non-LISP-speaking global routing system. There are several ways that a network could control how traffic reaches a particular PITR to prevent it from receiving more traffic than it can handle:
There are several approaches that a network could take in placing 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 least "stretch" (i.e. the least number of forwarding hops when compared to an optimal path between the sites).
Some proposals, for example CRIO [CRIO], have suggested grouping PITRs near an arbitrary subset of ETRs and announcing a 'local' subset of EID space. This model cannot guarantee minimum stretch if the EID prefix route advertisement points are changed (such a change might occur if a site adds, removes, or replaces one or more of its ISP connections).
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 the packet's destination to be set to the destination ETRs RLOC. Because packets are thus routed towards RLOCs, it can potentially better follow the Proxy-ITR network's traffic engineering policies (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 traffic to expensive transit links (assuming their upstreams have deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to which they may well have cheaper and closer connectivity to (via, for example, settlement-free peering). A corollary to this would be that large transit providers, deploying PITRs may attract more traffic, and therefore more revenue, from their customers.
LISP Network Address Translation (LISP-NAT) is a limited form of NAT [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 addresses are always routable. LISP-NAT accomplishes this by 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 table that it can reference for subsequent packets.
In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to talk to both LISP or non-LISP sites.
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 address, which enables packets to return to the site.
There are two main cases that involve LISP-NAT:
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 prefix into both the LISP mapping system as well as the Internet DFZ. This is because the LISP-R source's address is routable, and return packets will be able to natively reach the site.
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 LISP-R EID). This globally unique address may be a either a PI or PA address.
An example of this translation follows. For this example, a site has been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize LISP-NAT, the site has also been provided the PA EID of 128.200.1.0/24, and uses the first address (128.200.1.1) as the site's RLOC. The rest of this PA space (128.200.1.2 to 128.200.1.254) is used as a translation pool for this site's hosts who need to send packets to non-LISP hosts.
The translation table might look like the following:
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
The Host 220.1.1.2 sends a packet (which, for the purposes of this example is destined for a non-LISP site) to its default route (the ITR). The ITR receives the packet, and determines that the destination is not a LISP site. How the ITR makes this determination is up to the ITRs implementation of the EID-to-RLOC mapping system used (see, for example [LISP-ALT]).
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 EID space available to it. The ITR keeps this translation in a table in order to reverse this process when receiving packets destined to 128.200.1.2.
Finally, when the ITR forwards this packet without encapsulating it, it uses the entry in its LISP-NAT table to translate the returning packets' destination IPs to the proper host.
In the case where hosts using RFC 1918 addresses desire to send packets to non-LISP hosts, the LISP-NAT implementation acts much like an existing IPv4 NAT device. The ITR providing the NAT service must use LISP-R EIDs 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 manner similar to Section 6, and this packet must be forwarded to the ITR's next hop for the destination, without LISP encapsulation.
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 translation, the communication between source and destination ITR and ETRs continues as described in [LISP].
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. 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 (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 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 its default route (the ITR). The ITR receives the packet and determines that the destination is a LISP site. How the ITR makes this determination is up to the ITRs implementation of the EID/RLOC mapping system.
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 LISP EID space available to it. The ITR keeps this translation in a table in order to reverse this process when receiving packets destined to 192.0.2.2.
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 translation address as the LISP inner header's source. Once it decapsulates returning traffic, it uses the entry in its LISP-NAT table to translate the returning packet's destination IP address and then forward to the proper host.
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.
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 host might use for global reachability, name-to-address directories may need to be modified.
This problem, global vs. local addressability, exists for NAT in general, but the specific issue described above is unique to location/identity separation schemes. Some of these have suggested running a separate DNS instance for new types of EIDs. This solves the problem but introduces complexity for the site. Alternatively, using PITRs can mitigate this problem, because the LISP-NR EID can be reached in all cases.
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:
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 240.2.0.0/24, and it is trying to reach host at a non-LISP site with the IP prefix of 192.0.2.0/24. For the purposes of this example, the destination is a non-LISP site and 192.0.2.0/24 is found in the Internet's routing system.
A full protocol exchange example follows:
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.
In summary, there are three mechanisms for interworking LISP with non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the LISP site can manage and control the interworking on its own. In the PITR case, the site is not required to manage the advertisement of it's EID prefix into the DFZ, with the cost of potentially adding stretch to the connections of non-LISP sites sending packets to the LISP site. The third option is Proxy-ETRs, which are optionally used by sites relying on PITRs case to mitigate two caveats for LISP sites sending packets to non-LISP sites. This means Proxy-ETRs are not usually expected to be deployed by themselves, rather they will be used to assist LISP-NR sites which are already using PITRs.
There is a subtle difference between Symmetrical (LISP-NAT) vs Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques. Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and likely should) be decoupled since Proxy-ITRs are best deployed closest to non-LISP sites, and Proxy-ETRs are best located close to the LISP sites they are decapsulating for. This asymmetric placement of the two network elements minimizes the stretch imposed on each direction of the packet flow, while still allowing for coarsely aggregated announcements of EIDs into the Internet's routing table.
Like any router or LISP ITR, PITRs will have the opportunity to inspect traffic at the time that they encapsulate. The location of these devices in the network can have implications for discarding malicious traffic on behalf of ETRs which request this behavior (via the drop action bit in Map-Reply packets for an EID or EID prefix).
As with traditional NAT, LISP-NAT will obscure the actual host LISP-NR EID behind the LISP-R addresses used as the NAT pool.
When LISP sites send packets to non-LISP sites (these non-LISP sites rely on PITRs to enable Interworking), packets will have the Site's EID as its source IP address. These EIDs may not be recognized by their Internet Service Provider's Unicast Reverse Path Forwarding (uRPF) rules enabled on the Provider Edge Router. Several options are available to the service provider. For example they could enable a less strict version of uRPF, where they only look for the existence of the EID prefix in the routing table. Another, more secure, option is to add a static route for the customer on the PE router, but not redistribute this route into the provider's routing table. Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF check by encapsulating all of their egressing traffic destined to non-LISP sites to the Proxy-ETR (thus ensuring the outer IP source address is the site's RLOC).
Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael Menth, and Xuewei Wang, and Noel Chiappa who have made insightful comments with respect to LISP Interworking and transition mechanisms.
A special thanks goes to Scott Brim for his initial brainstorming of these ideas and also for his careful review.
This document creates no new requirements on IANA namespaces [RFC2434].
| [RFC1918] | Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. |
| [RFC4632] | Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. |
| [LISP] | Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "Locator/ID Separation Protocol (LISP)", Internet-Draft draft-ietf-lisp-14, June 2011. |
| [LISP-ALT] | Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "LISP Alternative Topology (LISP+ALT)", Internet-Draft draft-ietf-lisp-alt-07.txt, June 2011. |
| [LISP-MS] | Farinacci, D and V Fuller, "LISP Map Server", Internet-Draft draft-ietf-lisp-ms-09.txt, June 2011. |
| [RFC2434] | Narten, T. and H.T. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. |
| [RFC2993] | Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. |
| [CRIO] | Zhang, X, Francis, P, Wang, J and K Yoshida, "CRIO:Scaling IP Routing with the Core Router-Integrated Overlay", January 2006. |