Re: [lisp] LISP NAT Traversal [Was: Virtual meeting]

[Dino Farinacci <[e-mail]>]

> I would also like to add the NAT Traversal draft discussion into the agenda.

I agree it should on the agenda and an over-due work item we need to get working.

> We have experience implementing the NAT traversal functionality in our LISP open source implementation (OOR) which have support for Android and IOS devices. We believe that NAT traversal is a critical point for LISP-MN and we would like to share our experience on that. .
> 
> Our implementation is based on the draft-ermagan-lisp-nat-traversal and during its study some questions have emerged that could be interesting to discus:

I have an implementation of NAT-traversal in the lispers.net implementation which is a subset and simpler version of the draft-ermagan-lisp-nat-traversal. I think that NAT-traversal is so important as a core functionality for LISP because many people use it today just to traverse NATs.

I would suggest we make this a working group document. It is in the charter and is long over-due to move from individual submission.

> 	• What happens when a device handovers between NAT and not NAT interfaces? The xTR has to notify the remote ITRs, however an xTR behind NAT usually only has a default map cache entry with the RTR as a default gateway. Therefore, the xTR cannot notify directly ITRs of the change of the mapping.

If the remote ITR subscribes for 0.0.0.0/0 then any more specific mappings which are registered and Map-Notified by the Map-Server to the subscribers. That is one way the problem can be solved. 

Another way is now that the xTR is not behind a NAT, it can SMR currently RLOCs it is talking to. Which also may be an RTR that the remote ITRs can be using (when they are behind NATs). That causes the non-NAT ITR and the remote RTR to do mapping lookup to get the global/non-translated RLOC of this xTR.

> 	• What happens in the previous case if the not NAT interface is IPv6? IPv6 is a ­special case. We want to maintain the connectivity with established connections (keep using the same RTR, which has the map-cache). For that to work, the RTR needs to have an IPv6 to receive an SMR from the xTR after the handover (from the new xTR’s IPv6 RLOC). Therefore RTRs announced by the Map Server should have both IPv4 and IPv6. As we don't know which RTR IPv6 addresses map to which IPv4 addresses, all RTRs should be notified.

It can be a local decision if an ITR uses an RTR for IPv6 traffic or just encapsulate directly to the ETRs that register the EID. Most customers are going to want the shortest path so I have seen the latter be deployed.

I would suggest you only use RTRs for IPv6 when you are either doing (1) signal-free IPv6 multicast or (2) have a traffic-engineering requirement. Both in general, specify that IPv4 and IPv6 can and should run ships-in-the-night.

> 	• Which should be the procedure of an RTR in front of receiving an SMR from the xTR that just handover from NAT to not NAT? Probably the answer is that the xTR sends an SMR to the RTR which then has two options 1) the 

> RTR can do an SMR to the appropriates ITRs based on the map-cache entries (but then how to know which of the map-cache entries were used by the xTR) or 2) it can act as a PxTR for the xTR that performed the handover. In that case, until when? Until the expiration of the TTL? Furthermore, what happens when an xTR roams again before the previous TTL expires.

This is no different than any other type of RLOC change. And we have many mechanisms documented for this. They are:
TTL-expiry, SMRs, pubsub Map-Notify from mappingn system.

> 	• Which is the mechanism to change the RTR used by and xTR?

Note the xTR gets periodic Info-Replies back from the map-server. The list of RTRs can change. So when the list of RTRs is changed, it is configured in the map-server and the next Info-Request that the NAT-assisted xTR sends is returned with the new list. The lispers.net implementation updates RTRs when the list changes and RLOC-probes each one to make sure they have reachability before using.

> 	• Is there any procedure from MS point of view to notify associated xTRs to change the RTR they are using?

Yes, in the Info-Reply messages the map-sever send, that is in draft-ermagan-lisp-nat-traversal.

> 	• If a NATed device wants to manage their map request and map replies, which ITR RLOCS should use to fill the Map Request?

It needs to be reachable RLOCs. And in the lispers.net implementation, an xTR behind a NAT registers it’s translated RLOC and the RTR RLOCs. That is so the remote RTR can use the translated RLOC (and the translated port it learns from Info-Requests) and remote ITRs to use the RTR’s RLOC (since that RTR is the only node that can get packets through the NAT).

Another topic but related to NAT-traversal.

Note there is a problem I came across during deployment of an IoT use-case. This is a description of the problem with an example. Say I am xTR1 and learn from the Map-Server RTRs A, B, and C. and I want to encapsulate packets for an EID behind xTR2. The encapsulation algorithms indicate that xTR1 use a 5-tuple hash to load-split packets across A, B, and C. And xTR1 knows that A, B, and C are reachable via RLOC-probing. However, xTR1 has no idea if any of A, B, or C, can reach xTR2. So xTR1 can choose an RTR that would drop packets if it couldn’t reach xTR2.

I solved this in the lispers.net implementation to have the ETRs only register the RLOC addresses of RTRs if they are currently reachable via RLOC-probing. This is how it works using the example from above:

(1) xTR2 learns of RTRs A, B, and C from the map-server.
(2) It uses those RTRs as the RLOCs for the map-cache entry 0.0.0.0/0.
(3) It RLOC-probes A, B, and C.
(4) It registers its translated RLOC and RTRs A, B, and C in 4 RLOC-records of the Map-Register.
(5) That means any remote ITR (xTR1) would encap to either A, B, or C.
(6) If xTR2 lost reachability to A, then what is registered is only B and C (and the translated RLOC).
(7) Then xTR1 only has a choice of B and C to encapsulate to for the EID behind xTR2.

What limits the solution is asymmetry. Meaning if the path from xTR2 to RTR A is down but the path from RTR A to xTR2 is up, xTR1 would not use RTR A. So bidirectional connectivity is required (for the pair of RLOCs that are part of the RLOC-probe).

So as you can see, we have a lot to talk about.

Cheers,
Dino