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