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]
