Pruning some texts. Answers to your questions inline. > On Apr 1, 2020, at 2:28 AM, Albert López <[email protected]> wrote: > >> When the remote ETR isn’t behind NAT, the RTR can reach it directly but so >> can the ITR. > You say " That causes the non-NAT ITR and the remote RTR to do mapping lookup > to get the global/non-translated RLOC" but who sends them an SMR to update > the mapping? ETR can not do it because he doesn't have their entries in the > cache.
The 3 mechanisms I mentioned in previous email. SMRs (both control or data-driven), Map-Notify with pubsub from Map-Server, or map-cache TTL management. >>>> 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, >> >> Yes. But now I’m not clear if you the “IPv6 connection” is referring to an >> IPv6 EID or RLOC. Please clarify. > I am referring to IPv6 RLOCs Then you don’t need NAT-traversal. >> >>> 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. >> >> If IPv6 is an RLOC, it is assumed anyone can reach it and a site xTR need >> not encap packets to an RTR. RTRs for NAT-traversal are used only for IPv4 >> RLOCs, regardless if the EID is IPv4 or IPv6. > If we want to maintain established connections, when we handover from NAT to > IPv6 RLOC, we need to notify the change of mapping. If we use SMR procedure, > our only entry is the RTR, so if it doesn't have an IPv6 RLOC, we can not SMR > it and the xTR will loose the already established connections. This is true. That is why you use an RTR for NAT-traversal only for IPv4 RLOCs. >> >> Note, that SMRs will cause a flurry of messages depending on how aggressive >> the ETR wants the ITRs sending to it to be updated. And requires queuing >> demands on the ETR for reliable delivery. Hence why data-driven SMRs were >> introduced in implementations. But that only happens for EID-mobility (EID >> is not co-located with RLOC) and not in LISP-MN (where EID and RLOC are >> co-located). > From my point of view a TTL of 3-5 seconds is also quite aggressive from the > perspective of the Map Server that receive the queries (probably will have > several MN registered to it). May be, a good point would be to evaluate all > the pros and cons of each mechanism and recommend to use one for each case. > In any case, I believe that we need to specify what is the behaviour of an > RTR when receiving an SMR. It depends where your mobility domain is. And how fast the requirements are to change mappings. We have 3 mechanisms and they all have their disadvantages. >>>>> >>>> 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?. >> >> I don’t have something written up but I do have slides that show protocol >> flow. See at the end of this email. It can all be explained in one slide. ;-) > The Info Request message contain authentication section, is the key shared > between MS,xTR and RTRs? I don’t use authentication for Info-Request and Info-Replies. Otherwise, you need a security association with the RTR that can change quickly. You don’t want to provision keys between xTRs and RTRs but since xTR to MS is more of a provision based admission control to the control-plane system, it is acceptable and necessary there. >> >>> 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. >> >> You MUST put public-RLOCs in the mapping and the only node that can do that >> is the ETR. And it discovers its public-RLOC but receiving a Info-Reply from >> the MS that echos the outer source address and source UDP port from the >> Info-Request message. The message that the NAT translated the source address >> and source port. > May be I am wrong but the scenario of open the NAT with the Info-Request > Info-Reply messages is only valid for a scenario with a single MS where all > EIDs are registered with proxy mode. If the reply of the Map-Request comes > form other MS or remote ETR, then we don't have a hold in the NAT and the > Map-Reply message will not be received. No, not true. My implementation allows an ETR to send Info-Requests to 2 map-servers and assumes/requires that the RTR-list configured on each map-server is the same. Yes, and proxy mode is required because in my implementation, the map-server returns ETR public-RLOCs to requesting RTRs and RTR RLOCs to requesting ITRs. Plus the map-server can’t send packets to destination port 4342 through the NAT. But this part is solvable. Just not documented or implemented. >> Also note, there is a requirement for an xTR to have two interfaces, each >> connected to different NATs. And load-splitting is required across the two >> intefaces (inbound) > I think that the draft already contemplate this scenario, at least when both > interfaces use the same RTR despite using different NATs. If they are using > different RTRs, both RTR's RLOCs will be included in the mapping, then is the > ITR the responsible to split the traffic between RLOCs. Does it cover your > scenario? Yes, and it also supports two xTRs behind the same NAT to know the fact so they can encapsulate each other via private-RLOCs. I call this short-cut NAT-traversal in my implementation. Cheers, Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
