draft-ietf-lisp-interworking-03.txt | draft-ietf-lisp-interworking-04.txt | |||
---|---|---|---|---|
Network Working Group D. Lewis | Network Working Group D. Lewis | |||
Internet-Draft D. Meyer | Internet-Draft D. Meyer | |||
Intended status: Experimental D. Farinacci | Intended status: Experimental D. Farinacci | |||
Expires: August 12, 2012 V. Fuller | Expires: August 20, 2012 V. Fuller | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
February 9, 2012 | February 17, 2012 | |||
Interworking LISP with IPv4 and IPv6 | Interworking LISP with IPv4 and IPv6 | |||
draft-ietf-lisp-interworking-03.txt | draft-ietf-lisp-interworking-04.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 August 12, 2012. | This Internet-Draft will expire on August 20, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 4, line 18 | skipping to change at page 4, line 18 | |||
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 | |||
certain restrictions. | certain restrictions. | |||
A key behavior of the separation of Locators and End-Point-IDs is | A key behavior of the separation of Locators and End-Point-IDs is | |||
that EID prefixes are normally not advertised into the Internet's | that EID prefixes are normally not advertised into the Internet's | |||
Default Free Zone (DFZ). Specifically, only RLOCs are carried in the | Default Free Zone (DFZ). Specifically, only Routing Locators (RLOCs) | |||
Internet's DFZ. Existing Internet sites (and their hosts) which do | are carried in the Internet's DFZ. Existing Internet sites (and | |||
not run in the LISP protocol must still be able to reach sites | their hosts) which do not run in the LISP protocol must still be able | |||
numbered from LISP EID space. This draft describes three mechanisms | to reach sites numbered from LISP EID space. This draft describes | |||
that can be used to provide reachability between sites that are LISP- | three mechanisms that can be used to provide reachability between | |||
capable and those that are not. | sites that are LISP-capable and those that are not. | |||
The first mechanism uses a new network element, the LISP Proxy | The first mechanism uses a new network element, the LISP Proxy | |||
Ingress Tunnel Router (PITR) to act as a intermediate LISP Ingress | Ingress Tunnel Router (PITR) to act as a intermediate LISP Ingress | |||
Tunnel Router (ITR) for non-LISP-speaking hosts. The second | Tunnel Router (ITR) for non-LISP-speaking hosts. The second | |||
mechanism adds a form of Network Address Translation (NAT) | mechanism adds a form of Network Address Translation (NAT) | |||
functionality to Tunnel Routers (xTRs), to substitute routable IP | functionality to Tunnel Routers (xTRs), to substitute routable IP | |||
addresses for non-routable EIDs. The final network element is the | addresses for non-routable EIDs. The final network element is the | |||
LISP Proxy Egress Tunnel Routers (PETR), which act as an intermediate | LISP Proxy Egress Tunnel Routers (PETR), which act as an intermediate | |||
Egress Tunnel Router (ETR) for LISP sites which need to encapsulate | Egress Tunnel Router (ETR) for LISP sites which need to encapsulate | |||
packets LISP packets destined to non-LISP sites. | packets LISP packets destined to non-LISP sites. | |||
skipping to change at page 7, line 7 | skipping to change at page 7, line 7 | |||
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. | |||
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 | |||
Default Free Zone: The Default-Free Zone (DFZ) refers to the | ||||
collection of all Internet autonomous systems that do not require | ||||
a default route to route a packet to any destination. | ||||
LISP Routable (LISP-R) Site: A LISP site whose addresses are used as | 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 12, line 23 | skipping to change at page 12, line 23 | |||
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 Core Router-Integrated Overlay [CRIO], | |||
PITRs near an arbitrary subset of ETRs and announcing a 'local' | have suggested grouping PITRs near an arbitrary subset of ETRs and | |||
subset of EID space. This model cannot guarantee minimum stretch if | announcing a 'local' subset of EID space. This model cannot | |||
the EID prefix route advertisement points are changed (such a change | guarantee minimum stretch if the EID prefix route advertisement | |||
might occur if a site adds, removes, or replaces one or more of its | points are changed (such a change might occur if a site adds, | |||
ISP connections). | removes, or replaces one or more of its ISP connections). | |||
5.5. Benefit to Networks Deploying PITRs | 5.5. Benefit to Networks Deploying PITRs | |||
When packets destined for LISP-NR sites arrive and are encapsulated | When packets destined for LISP-NR sites arrive and are encapsulated | |||
at a Proxy-ITR, a new LISP packet header is pre-pended. This causes | at a Proxy-ITR, a new LISP packet header is pre-pended. This causes | |||
the packet's destination to be set to the destination ETRs RLOC. | the packet's destination to be set to the destination ETRs RLOC. | |||
Because packets are thus routed towards RLOCs, it can potentially | Because packets are thus routed towards RLOCs, it can potentially | |||
better follow the Proxy-ITR network's traffic engineering policies | better follow the Proxy-ITR network's traffic engineering policies | |||
(such as closest exit routing). This also means that providers which | (such as closest exit routing). This also means that providers which | |||
are not default-free and do not deploy Proxy-ITRs end up sending more | are not default-free and do not deploy Proxy-ITRs end up sending more | |||
skipping to change at page 13, line 44 | skipping to change at page 13, line 44 | |||
packets will be able to natively reach the site. | packets will be able to natively reach the site. | |||
6.1. Using LISP-NAT with LISP-NR EIDs | 6.1. Using LISP-NAT with LISP-NR EIDs | |||
LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP | LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP | |||
hosts by translating the LISP-NR EID to a globally unique address (a | hosts by translating the LISP-NR EID to a globally unique address (a | |||
LISP-R EID). This globally unique address may be a either a PI or PA | LISP-R EID). This globally unique address may be a either a PI or PA | |||
address. | address. | |||
An example of this translation follows. For this example, a site has | An example of this translation follows. For this example, a site has | |||
been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize | been assigned a LISP-NR EID of 203.0.113.0/24. In order to utilize | |||
LISP-NAT, the site has also been provided the PA EID of | LISP-NAT, the site has also been provided the PA EID of 192.0.2.0/24, | |||
128.200.1.0/24, and uses the first address (128.200.1.1) as the | and uses the first address (192.0.2.1) as the site's RLOC. The rest | |||
site's RLOC. The rest of this PA space (128.200.1.2 to | of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation | |||
128.200.1.254) is used as a translation pool for this site's hosts | pool for this site's hosts who need to send packets to non-LISP | |||
who need to send packets to non-LISP hosts. | hosts. | |||
The translation table might look like the following: | The translation table might look like the following: | |||
Site NR-EID Site R-EID Site's RLOC Translation Pool | Site NR-EID Site R-EID Site's RLOC Translation Pool | |||
============================================================== | ============================================================== | |||
220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2-254 | 203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254 | |||
Figure 1: Example Translation Table | Figure 1: Example Translation Table | |||
The Host 220.1.1.2 sends a packet (which, for the purposes of this | The Host 203.0.113.2 sends a packet (which, for the purposes of this | |||
example is destined for a non-LISP site) to its default route (the | example is destined for a non-LISP site) to its default route (the | |||
ITR). The ITR receives the packet, and determines that the | ITR). The ITR receives the packet, and determines that the | |||
destination is not a LISP site. How the ITR makes this determination | destination is not a LISP site. How the ITR makes this determination | |||
is up to the ITRs implementation of the EID-to-RLOC mapping system | is up to the ITRs implementation of the EID-to-RLOC mapping system | |||
used (see, for example [LISP-ALT]). | used (see, for example [LISP-ALT]). | |||
The ITR then rewrites the source address of the packet from 220.1.1.2 | The ITR then rewrites the source address of the packet from | |||
to 128.200.1.2, which is the first available address in the LISP-R | 203.0.113.2 to 192.0.2.2, which is the first available address in the | |||
EID space available to it. The ITR keeps this translation in a table | LISP-R EID space available to it. The ITR keeps this translation in | |||
in order to reverse this process when receiving packets destined to | a table in order to reverse this process when receiving packets | |||
128.200.1.2. | destined to 192.0.2.2. | |||
Finally, when the ITR forwards this packet without encapsulating it, | Finally, when the ITR forwards this packet without encapsulating it, | |||
it uses the entry in its LISP-NAT table to translate the returning | it uses the entry in its LISP-NAT table to translate the returning | |||
packets' destination IPs to the proper host. | packets' destination IPs to the proper host. | |||
6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP | 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP | |||
Sites | Sites | |||
In the case where hosts using RFC 1918 addresses desire to send | In the case where hosts using RFC 1918 addresses desire to send | |||
packets to non-LISP hosts, the LISP-NAT implementation acts much like | packets to non-LISP hosts, the LISP-NAT implementation acts much like | |||
skipping to change at page 21, line 8 | skipping to change at page 21, line 8 | |||
Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael | Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael | |||
Menth, and Xuewei Wang, and Noel Chiappa who have made insightful | Menth, and Xuewei Wang, and Noel Chiappa who have made insightful | |||
comments with respect to LISP Interworking and transition mechanisms. | comments with respect to LISP Interworking and transition mechanisms. | |||
A special thanks goes to Scott Brim for his initial brainstorming of | A special thanks goes to Scott Brim for his initial brainstorming of | |||
these ideas and also for his careful review. | these ideas and also for his careful review. | |||
11. IANA Considerations | 11. IANA Considerations | |||
This document creates no new requirements on IANA namespaces | This document creates no new requirements on IANA namespaces | |||
[RFC2434]. | [RFC5226]. | |||
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-20 (work in progress), January 2012. | draft-ietf-lisp-20 (work in progress), January 2012. | |||
[LISP-ALT] | [LISP-ALT] | |||
skipping to change at page 22, line 44 | skipping to change at page 22, line 44 | |||
Scaling IP Routing with the Core Router-Integrated | Scaling IP Routing with the Core Router-Integrated | |||
Overlay", January 2006. | Overlay", January 2006. | |||
[LISP-DEPLOY] | [LISP-DEPLOY] | |||
Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- | Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- | |||
Pascual, J., and D. Lewis, "LISP Network Element | Pascual, J., and D. Lewis, "LISP Network Element | |||
Deployment Considerations", | Deployment Considerations", | |||
draft-ietf-lisp-deployment-02.txt (work in progress), | draft-ietf-lisp-deployment-02.txt (work in progress), | |||
November 2011. | November 2011. | |||
[RFC2434] Narten, T. and H. 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, | [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, | |||
November 2000. | November 2000. | |||
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation | [RFC4787] Audet, F. and C. Jennings, "Network Address Translation | |||
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, | (NAT) Behavioral Requirements for Unicast UDP", BCP 127, | |||
RFC 4787, January 2007. | RFC 4787, January 2007. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
May 2008. | ||||
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. | [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. | |||
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, | Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, | |||
RFC 5382, October 2008. | 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 | |||
End of changes. 15 change blocks. | ||||
35 lines changed or deleted | 39 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/ |