Internet DRAFT - draft-cheng-lisp-nat-traversal-extension
draft-cheng-lisp-nat-traversal-extension
LISP Working Group L. Cheng
Internet-Draft M. Sun
Intended status: Standards Track ZTE Corporation
Expires: January 16, 2014 July 15, 2013
draft-cheng-lisp-nat-traversal-extension-01
Extension to LISP NAT Traversal Proposal
Abstract
This draft specifies several special NAT traversal scenarios when two
or more LISP Sites/MNs which locate behind the same NAT equipment
communicate with each other. When these LISP Sites/MNs communicate
with each other, it may cause routing latency and will increase re-
encapsulation load on Re-encapsulating Tunnel Routers(RTRs) based on
existing LISP-NAT strategy.
In this draft, we give detail descriptions of these scenarios. Also
we propose some suggestions to solve the problems. According to our
strategy, a new kind of message is used for RTRs to send relative
information of Corresponding Sites/MNs to xTRs.
Status of This Memo
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 16, 2014.
Copyright Notice
Copyright (c) 2013 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
Cheng & Sun Expires January 16, 2014 [Page 1]
Internet-Draft Extension to LISP NAT Traversal Proposal July 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Issue Statement . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Basic Scenario-Single Level NAT . . . . . . . . . . . . . 3
3.2. Extended Scenario I-Multiple Levels NAT . . . . . . . . . 4
3.3. Extended Scenario II-Multiple Levels NAT . . . . . . . . 6
4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. RTR Processing . . . . . . . . . . . . . . . . . . . . . 7
4.2. ITR Processing . . . . . . . . . . . . . . . . . . . . . 8
4.3. ETR Processing . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Locator/ID Separation Protocol [RFC6830] defines a set of functions
for encapsulating routers to exchange information used to map from
Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs).
When a LISP site locates behind a NAT, LISP Tunnel Routers (xTRs) are
only reachable through the NAT's public address which broke the
assumption that xTRs are reachable at their RLOCs.
To make sure LISP devices locate behind a NAT reachable, [LISP-NAT]
proposes a NAT traversal mechanism for LISP. To achieve this, an ETR
of a LISP site will use its Map-Server to discover whether it is
behind a NAT and to get its translated global RLOC and port via two
LISP messages: Info-Request and Info-Reply. Once an ETR detects it
locates behind a NAT, it use a LISP Re-encapsulating Tunnel Router
(RTR) to act as a data plane 'anchor point' to send and receive
traffic through the NAT device.
According to RTR proxy strategy introduced in [LISP-NAT], when an ITR
behind a NAT needs to encapsulate outbound LISP traffic, it does not
send Map-Request for destination EIDs, but just use RTR RLOC as
locator for all destination EIDs that it wishes to send data to.
Cheng & Sun Expires January 16, 2014 [Page 2]
Internet-Draft Extension to LISP NAT Traversal Proposal July 2013
However, in some special scenarios such like two or more LISP Sites/
MNs locate behind the same NAT, when these LISP Sites/MNs communicate
with each other, this RTR proxy strategy will cause routing latency
and extra decapsulation/re-encapsulation cost on RTR. In this draft,
we list and describe several special cases. A new kind of message
"Info-Notify" is adopted. This message is used by RTR to notify the
LISP Site with relative information of its Corresponding Site which
locates behind the same NAT with it. Based on this "Info-Notify"
message, some feasible solutions are proposed.
2. Definition of Terms
This draft uses terms defined in [RFC6830] and [LISP-NAT]. This
section introduces some new terms used in the document.
Corresponding Site/MN When two LISP Sites/MNs communicate with each
other, each LISP Sites/MN is considered as Corresponding Site/MN
of the other one, regardless of Site's/MN's status, i.e. it is a
sender or a receiver.
Info-Notify A message used by RTR to notify LISP Site with relative
information of its Corresponding Site.
3. Issue Statement
In this section, several scenarios are specified.
3.1. Basic Scenario-Single Level NAT
As shown in Fig.1, there are two LISP Sites (Site1 and Site2) locate
behind the same Nat equipment (NAT1). Furthermore, xTRs of the two
sites choose the same RTR as proxy to register mapping information
and transfer data traffic.
+-------+
| RTR |
+---+---+
|
+---+---+
| NAT1 |
+-++-++-+
/ | | \
+----------------------------+ / | | \ +----------------------------+
| +------+_____+------+_____|/ | | \|_____+------+ __+------+ |
| |Host 1| | ITR1 | | | | | | ITR2 | / |Host 2| |
| +------+ +------+ | | | | +------+ / +------+ |
| +------+ | | | | +------+/ |
| Site1 | ETR1 |_____|____| |____|_____| ETR2 | Site2 |
Cheng & Sun Expires January 16, 2014 [Page 3]
Internet-Draft Extension to LISP NAT Traversal Proposal July 2013
| +------+ | | +------+ |
+----------------------------+ +----------------------------+
Fig.1 Case 1: Single Level Nat Traversal
Based on RTR proxy strategy proposed in [LISP-NAT], when Host1 in
Site1 want to send a packet to Host2 in Site2, following steps will
be performed.
1. Host1 sends a packet to ITR1 of Site1, destination of the packet
is EID address of Host2.
2. When ITR1 receives the packet, it encapsulates it in a LISP data
header with outer header destination set to RTR RLOC and outer
header destination port set to 4341. Based on RTR proxy
strategy, ITR1 will not send Map-Request for Host2. As a result,
ITR1 is not able to get RLOCs of Site2, i.e. ETR2's RLOC.
3. When encapsulated packet passes through NAT, NAT transform the
source address and source port in outer header to be global
address and port. This may create a state in the NAT device.
4. When RTR receive the encapsulated packet destination to its RLOC,
it decapsulates the packet, and look for if there are local
mapping information match the destination EID. As Site2 also
registers through the RTR, RTR will find mapping information of
Site2, as well as global state of ETR2 including the global
address and global port in its local cache.
5. RTR uses ETR2's global state information to re-encapsulate the
packet, and transfer it to ETR2.
Seen from steps enumerated above, based on existing RTR Proxy
strategy, even though Site1 and Site2 locate behind the same NAT,
traffic between these Sites need to route to the RTR which locates
outside the NAT.
However, as Site1 and Site2 locate behind the same NAT, that's to
say, ITR1 and ETR2 locate in the same Intranet, RLOC of ETR2 is
reachable to ITR1. As a result, if ITR1 could get mapping
information of Site2, it could encapsulate the packet directly to
RLOC of ETR2 which could avoid routing latency of packet and could
lighten re-encapsulation load on RTR.
3.2. Extended Scenario I-Multiple Levels NAT
Cheng & Sun Expires January 16, 2014 [Page 4]
Internet-Draft Extension to LISP NAT Traversal Proposal July 2013
In some topologies, there may include multiple NAT devices. Consider
the scenario depicted in Fig.2. Suppose NAT1 is a large industrial
NAT deployed by an internet service provider (ISP) to multiplex many
customers onto a few public IP addresses, and NAT2 is a small
consumer NAT router deployed by one of the ISP's customers to
multiplex its private home networks onto its ISP-provided IP
addresses. Only RTR and NAT1 have globally routable IP addresses;
Site1's RLOC addresses and the "public" IP addresses used by NAT2 are
actually private to the ISP's address realm, while Site2's addresses
are private to the addressing realms of NAT2.
+-------+
| RTR |
+---+---+
|
+---+---+
| NAT1 |
+++---+-+
|| \
|| +------+
|| | NAT2 |
|| +-+--+-+
+-------------------------+ || | | +-------------------------+
| +------+_____+------+__|___|| | |__|__+------+ __+------+ |
| |Host 1| | ITR1 | | | | | | ITR2 | / |Host 2| |
| +------+ +------+ | | | | +------+ / +------+ |
| +------+ | | | | +------+/ |
| Site1 | ETR1 |__|____| |_____|__| ETR2 | Site2 |
| +------+ | | +------+ |
+-------------------------+ +-------------------------+
When Site1 register through RTR, it follows the same steps described
in [LISP-NAT]. NAT1 establishes states for sessions between RTR and
xTR1s. RTR stores relative information of Site1 in its cache,
including mapping information, global IP addresses and global ports
of xTR1s, etc..
According to Site2, when Site2 register through RTR, both NAT1 and
NAT2 will establish states for sessions between RTR and xTRs. When
Site2 sends messages no matter control messages or data packets to
RTR, both NAT2 and NAT1 translates IP address and port of packet's
out header.
According to RTR, when RTR receives an encapsulated packet from
Site2, out header address of packet will be a routable address
assigned by NAT1, and inner header address will be EID of source
host. As a result, addresses which assigned by NAT2 and used for
Cheng & Sun Expires January 16, 2014 [Page 5]
Internet-Draft Extension to LISP NAT Traversal Proposal July 2013
routing between NAT1 and NAT2 are invisible to RTR. In RTR's local
cache, it will store relative information of Site2, including mapping
information, global IP addresses and global ports of xTR2s which are
assigned by NAT1, etc.
In this scenario, every packet from Host1 to Host2 will follow the
path:
Host1 -> ITR1 -> NAT1 -> RTR -> NAT2 -> ETR2 ->Host2
RTR will perform decapsulation and re-encapsulation process.
Based on existing RTR Proxy strategy, traffic between Site1 and Site2
still needs to route to the RTR which locates outside the NAT.
According to scenario depicted in Fig.2, even if ITR1 could get
mapping information of Site2, ETR2's RLOC is not reachable to ITR1.
However, if ITR2 gets global information of Site2, i.e. global
addresses and global ports of xTR2s which are used to route outside
NAT1, it could encapsulate packets directly to ETR2's global address.
If NAT1 supports Hairpin function, the packets destination to ETR2's
global address will be route to Site2, and need not to be re-
encapsulated by RTR.
3.3. Extended Scenario II-Multiple Levels NAT
As shown in Fig.3, Site1 and Site2 both locate behind two levels NAT.
Site1 and Site2 register through RTR as we described in Section 3.2.
In this scenario, each packet from Host1 to Host2 follows the path:
Host1 -> ITR1 -> NAT2 -> NAT1 -> RTR -> NAT3 -> ETR2 ->Host2
In this situation, if Site1 gets global information of the
Corresponding Site, ITR1 could probe ETR2's global IP address. If
NAT1 support Hairpin function, probe message will be transfer to
Site2, and Site1 need not to encapsulate packet to RTR anymore.
+-------+
| RTR |
+---+---+
|
+---+---+
| NAT1 |
+-+---+-+
/ \
+------+ +------+
Cheng & Sun Expires January 16, 2014 [Page 6]
Internet-Draft Extension to LISP NAT Traversal Proposal July 2013
| NAT2 | | NAT3 |
+-+--+-+ +-+--+-+
+-------------------------+ | | | | +-------------------------+
| +------+_____+------+__|_| | | |_|__+------+ __+------+ |
| |Host 1| | ITR1 | | | | | | ITR2 | / |Host 2| |
| +------+ +------+ | | | | +------+ / +------+ |
| +------+ | | | | +------+/ |
| Site1 | ETR1 |__|____| |____|__| ETR2 | Site2 |
| +------+ | | +------+ |
+-------------------------+ +-------------------------+
4. Solutions
According analysis we described above, in these section we propose
our solution strategy. In this
This mechanism enables RTR to send an "Info-Notify" message to the
LISP Site with relative information of its Corresponding Site.
4.1. RTR Processing
When RTR receives an encapsulated packet from ITR1 of Site1,
following steps will be performed.
1. RTR strips the outer header and lookup in local cache for mapping
information of destination EID.
2. In our extension, RTR will judge if Source Site and Destination
Site locate behind the same NAT. For example, based on whether
the global address of Source Site ITR1 and global address of
Destination Site ETR2 are the same, or whether the two global
addresses may locate in the same address prefix. Furthermore, if
ISP would like to build a relationship between NAT and
corresponding RTR, RTR could be informed with public address
information of the NAT.
3. If RTR judge that source site and destination site both locate
behind the same NAT, it could send "Info-Notify" messages which
contain relative information of Corresponding Site to Sender ITR
and Receiver ETR respectively. Relative information mentioned
above may include mapping information of Site, global addresses
and global ports information of Site xTRs.
Note: After RTR sending sage to ITR, if RTR receive packet from ITR
to the particular ETR, RTR continue to transfer the packet to
destination ETR.
Cheng & Sun Expires January 16, 2014 [Page 7]
Internet-Draft Extension to LISP NAT Traversal Proposal July 2013
4.2. ITR Processing
When ITR receives "Info-Notify" message from RTR,
1. Based on mapping information of Destination Site, ITR could send
a RLOC probe message to ETR's RLOC. After receiving Mapping
Reply from ETR, ITR could encapsulate packet directly to ETR's
RLOC.
2. If Destination Site locate behind multilevel NATs, such like
scenarios described in Fig.2 and Fig.3, ETR's RLOC is not
reachable to ITR, and ITR will not receive Map Reply form
Destination Site when it send RLOC Probe message to ETR's RLOC.
In this situation, ITR could then send Probe message to ETR's
global address. If ITR could get map reply message, then it
could use ETR's global address as destination address of outer
header to encapsulate packet.
Note In order to avoid traffic affection, during RLOC Probe phase,
ITR could continue to encapsulate data packet to RTR.
4.3. ETR Processing
When ETR receives "Info-Notify" message from RTR, ETR could choose to
send a message such like a SMR (Solicit-Map-Request)[RFC6830] to ITR
to trigger a mapping request operation. Furthermore, ETR could use
ITR's RLOC or global address as destination when it send the message.
5. Security Considerations
TBD
6. IANA Considerations
This document makes no requests to IANA.
7. Normative References
[LISP-NAT]
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
F., and C. White, "NAT traversal for LISP", March 2013.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", January 2013.
Authors' Addresses
Cheng & Sun Expires January 16, 2014 [Page 8]
Internet-Draft Extension to LISP NAT Traversal Proposal July 2013
Li Cheng
ZTE Corporation
R&D Building 1, Zijinghua Road No.68
Nanjing, Yuhuatai District 210012
P.R.China
Email: cheng.li2@zte.com.cn
Mo Sun
ZTE Corporation
R&D Building 1, Zijinghua Road No.68
Nanjing, Yuhuatai District 210012
P.R.China
Email: sun.mo@zte.com.cn
Cheng & Sun Expires January 16, 2014 [Page 9]
