Thanks Dino for your reply. Answers inline
On 31/3/20 1:27, Dino Farinacci wrote:
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.
So here, you are suggesting to use the publish/subscribe draft isn’t it? Yes
this could be a good solution. Is there any study ofscalability regarding this
option?
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.
When the xTR is only using the RTR (I believe is the usual case), xTR doesn’t
know who are its remote ITRs to send and SMR so it depends on how the RTR react
to SMR.
• 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.
What I was referring with this question is , If we are behind NAT using an RTR
as a default gateway and then we handover to an IPv6 connection (at that point
we are not considering the publish/subscribe solution), If we don't want to
lose established connections, xTR has to notify the RTR (SMR) of the change of
the mapping. To notify it, the RTR should have an IPv6 RLOC that should be
included in the list of RTRs of the Info Reply message. Depending on what the
RTR does with the SMR, remote ITRs could move stablished connections to direct
path or continue using the RTR.
• 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.
TTL-expiry is not realistic for mobility scenarios where handovers can be
frequent and you don’t know when will happen
The behaviour of an RTR receiving an SMR is what I would like to clarify with
this question
pubsub is a good option but at this point I would like to clarify what
happens when an RTR receive an SMR.
• 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.
I believe this answer is replying next question. With this question, my
intention was to make constance that the draft doesn’t specify (may be it is
not needed to go into this detail level) a mechanism, from the xTR point of
view, to use a different RTR from the list of the info reply (for example, due
to a better latency time)
• 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).
I don’t have the full details of the lispers implementation of NAT-Traversal
solution. Is any document describing it?.
My concern here is regarding section 5.1.2 of the draft (Map-Request and
Map-Reply handling). When we sent an Encap Map-Request to get a mapping, we add
a list of iTR addresses to receive the Map-Reply. We can add here the global
address of the xTR but if the NAT has not been previously punched, we will not
receive never a Map-Reply, at least for symetrics NATs.
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).
In the scenario you are proposing, both xTR are behind NAT using the
same MS or at least the same RTRs isn’t it? What would happen if the xTR
2 is not behind NAT or it is behind NAT but using different RTRs?
Regards, Albert L.
So as you can see, we have a lot to talk about.
Cheers,
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
