> 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]
