Thanks Dino, I’ll fix the text once the draft submission is open again.
Ciao L. > On 4 Mar 2026, at 15:39, Dino Farinacci <[email protected]> wrote: > > 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]
