Yes better thanks. Dino
> On Mar 4, 2026, at 12:15 AM, Luigi Iannone <[email protected]> wrote: > > > >>> On 4 Mar 2026, at 01:22, Dino Farinacci <[email protected]> wrote: >>> >>> let’s roll back a bit…. >>> >>> In the initial text you quoted: >>> >>> 5. LISP NAT Traversal Overview >>> >>> There are two attributes of a LISP device behind a typical NAT that >>> requires special consideration in LISP protocol behavior in order to >>> make the device reachable. First, the RLOC assigned to the device is >>> typically not globally unique nor globally routable. Hence, for NAT >>> traversal, outbound packets are required to create state before the >>> NAT accepts inbound packets. Second, LISP protocol requires an xTR >>> to receive traffic on the specific UDP port 4341, hence, the random >>> UDP port allocated by the NAT on its public side to associate with a >>> xTR behind the NAT cannot be used by other xTRs to send LISP traffic. >>> This section provides an overview of the LISP NAT traversal mechanism >>> which deals with these conditions, while the rest of the document >>> specifies the mechanism in details. >>> >>> Which sentence do you coinsider incorrect and/or misleading ? >> >> When you say "receive traffic on the specific UDP port 4341" is not specific >> enough. That is my comment. It is not clear if you are talking about LISP in >> general, where there destination UDP port of 4341 and won't make it through >> the NAT. Or you saying, with the NAT-traversal logic, in order to receive a >> packet, the source port must be 4341 because the destination port is the one >> that is translated. > > Got it. Thanks. > > What about: > > Second, LISP protocol requires data plane traffic to use the specific UDP > destination port 4341, hence, the random > UDP port allocated by the NAT on its public side to associate with a xTR > behind the NAT cannot be used by other xTRs to send LISP traffic. > > Better? > > L. > >> >> My comment is that you need to use "source" and/or "destination" when >> referring to the port. >> >> Dino >> >>> >>> Ciao >>> >>> L. >>> >>>> On 20 Feb 2026, at 16:56, Dino Farinacci <[email protected]> wrote: >>>> >>>> I do not mean 4342. Even though they are also used for Info-Request >>>> messages so map-servers can return a list of RTRs to xTRs. >>>> >>>> The 4341 I am referring is to open filters in NATs. >>>> >>>> Dino >>>> >>>>> On Feb 20, 2026, at 6:09 AM, Luigi Iannone <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>>> On 19 Feb 2026, at 18:20, Dino Farinacci <[email protected]> wrote: >>>>>> >>>>>> I'm referring to the NAT close to the ETR. The only time the source-port >>>>>> is 4341 is when the RTR encapsulates packets to the ETR. All other times >>>>>> (for control messages), the destination port from the ETR to the RTR is >>>>>> 4341. >>>>> >>>>> You mean 4342, as you are talking about control messages…. >>>>> >>>>> >>>>>> >>>>>> The NAT by the RTR, opens its filters with the same control message from >>>>>> the ETR. So one Info-Reply with a destination port of 4341 opens both >>>>>> NATs. >>>>> >>>>> Again… Info-request/reply are control messages that use 4342. >>>>> >>>>> >>>>>> >>>>>> I have this deployed in many lispers.net <http://lispers.net/> >>>>>> deployments where there are cases, the control message and the returning >>>>>> encapsulated packet from the RTR goes through 4 NATs!!!! >>>>>> >>>>>> So this spec is really important or you cannot practically deploy LISP >>>>>> in residential networks, satellite networks, and cloud environments. >>>>> >>>>> That is why we are ahving this discussion, to finalize the document ;-) >>>>> >>>>> Let me try to go back to your initial mail, the text that you highlgihted >>>>> states that because xTR send data traffic to port 4341, the random port >>>>> in the NAT state cannot be used by other xTRs to send traffic. That is >>>>> what is stated there and is just a problem statement. >>>>> >>>>> L. >>>>> >>>>>> >>>>>> Dino >>>>>> >>>>>>>> On Feb 19, 2026, at 7:52 AM, Luigi Iannone <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 19 Feb 2026, at 16:30, Dino Farinacci <[email protected]> wrote: >>>>>>>> >>>>>>>>> This: The xTR needs to receive traffic with the destination port >>>>>>>>> equal to the translated port and the source port equal to the >>>>>>>>> well-known port 4341. >>>>>>>> >>>>>>>> This is true and this is how it’s accomplished: >>>>>>>> >>>>>>>> (1) An Info Request is sent by the ETR to the RTR with destination >>>>>>>> port 4341. This opens the NAT. >>>>>>> >>>>>>> The NAT toward the RTR is opened with an ECM Map Register that has >>>>>>> destination port 4342 and source port 4341, hence the ETR will receive >>>>>>> on 4341. >>>>>>> >>>>>>> L. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> (2) So then, when the RTR sends an encapsulated packet, it must be >>>>>>>> sent FROM port 4341. >>>>>>>> (3) And the destination port is the port that was translated from the >>>>>>>> Info-Request. >>>>>>>> >>>>>>>>> Is not what the document says. The NAT state is such that the xTR >>>>>>>>> behind it will receive LISP packets with destination port 4341 (as >>>>>>>>> for the standard), your sentence seems to suggest the opposite. >>>>>>>> >>>>>>>> My comment was about packets flowing from RTR to ETR direction. >>>>>>>> >>>>>>>> Dino >>>>>>>> >>>>>>>>> >>>>>>>>> L. >>>>>>>>> >>>>>>>>>> On 18 Feb 2026, at 18:19, Dino Farinacci <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Your text is misleading. Just use what I told you. >>>>>>>>>> >>>>>>>>>> And your last point isn’t true in a decentralized >>>>>>>>>> NAT environment. But for this document’s scope, use RTR as the xTR >>>>>>>>>> term. >>>>>>>>>> >>>>>>>>>> Dino >>>>>>>>>> >>>>>>>>>>>> On Feb 18, 2026, at 6:34 AM, Luigi Iannone <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Dino, >>>>>>>>>>> >>>>>>>>>>> DO you meqns the “Second … “ Sentence? >>>>>>>>>>> >>>>>>>>>>> What about: >>>>>>>>>>> >>>>>>>>>>> Second, LISP protocol requires an xTR >>>>>>>>>>> to receive traffic on the specific UDP port 4341, hence, the random >>>>>>>>>>> UDP port allocated by the NAT on its public side is not used by >>>>>>>>>>> other >>>>>>>>>>> xTRs to send LISP traffic. >>>>>>>>>>> >>>>>>>>>>> Better? >>>>>>>>>>> >>>>>>>>>>> L. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 16 Feb 2026, at 19:06, Dino Farinacci <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Luigi, to be more precise, this paragraph sound say: >>>>>>>>>>>> >>>>>>>>>>>> <Screenshot 2026-02-16 at 10.03.48 AM.png> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The xTR needs to receive traffic with the destination port equal >>>>>>>>>>>> to the translated port and the source port equal to the >>>>>>>>>>>> well-known port 4341. >>>>>>>>>>>> >>>>>>>>>>>> Dino >>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 16, 2026, at 5:26 AM, [email protected] wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Internet-Draft draft-ietf-lisp-nat-traversal-01.txt is now >>>>>>>>>>>>> available. It is a >>>>>>>>>>>>> work item of the Locator/ID Separation Protocol (LISP) WG of the >>>>>>>>>>>>> IETF. >>>>>>>>>>>>> >>>>>>>>>>>>> Title: NAT traversal for LISP >>>>>>>>>>>>> Author: Luigi Iannone >>>>>>>>>>>>> Name: draft-ietf-lisp-nat-traversal-01.txt >>>>>>>>>>>>> Pages: 28 >>>>>>>>>>>>> Dates: 2026-02-16 >>>>>>>>>>>>> >>>>>>>>>>>>> Abstract: >>>>>>>>>>>>> >>>>>>>>>>>>> This document describes a mechanism for IPv4 NAT traversal for >>>>>>>>>>>>> LISP >>>>>>>>>>>>> tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a >>>>>>>>>>>>> Network >>>>>>>>>>>>> Address Translator (NAT) device. A LISP device both detects the >>>>>>>>>>>>> NAT >>>>>>>>>>>>> and initializes its state. Forwarding to the LISP device through >>>>>>>>>>>>> a >>>>>>>>>>>>> NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) >>>>>>>>>>>>> network element, which acts as an anchor point in the data plane, >>>>>>>>>>>>> forwarding traffic from unmodified LISP devices through the NAT. >>>>>>>>>>>>> >>>>>>>>>>>>> The IETF datatracker status page for this Internet-Draft is: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-lisp-nat-traversal/ >>>>>>>>>>>>> >>>>>>>>>>>>> There is also an HTMLized version available at: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nat-traversal-01 >>>>>>>>>>>>> >>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-nat-traversal-01 >>>>>>>>>>>>> >>>>>>>>>>>>> Internet-Drafts are also available by rsync at: >>>>>>>>>>>>> rsync.ietf.org::internet-drafts >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> lisp mailing list -- [email protected] >>>>>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> lisp mailing list -- [email protected] >>>>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
