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