
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div>Hi Fernando,<br></div><div><br></div><div>I think what you are describing is known as a rendezvous server.<br></div><div>It is responsible for security and for keeping track of ip address/ port number combinations of the unreachable client device which is behind NAT.<br></div><div>The client device initiates an outbound contact to the rendezvous server and that server records the ip address and the port number which the client device is listening on.<br></div><div><br></div><div>Now to reach that client, first you connect to the rendezvous server and provide credentials which allows the server to provide the ip address and port number of the client device.<br></div><div>At that point the user uses that ip address and port number to reach the device, even behind ever-changing ip addresses and port numbers. <br></div><div><br></div><div>Most applications these days are aware of the ubiquity of NAT and have used rendezvous servers to get around the reachability issues inherent with devices behind NAT.<br></div><div>Hard-coding static port redirection in NAT routers is rarely needed anymore. <br></div><div>In this scenario, only the rendezvous server needs a publicly reachable IP address, and some of the security can be removed from the dumb client device and instead be placed on the rendezvous server.<br></div><div>That server will authenticate any requests to access the dumb client device.<br></div><div><br></div><div>The use of rendezvous servers is a practical way to deal with NAT, and to deal with address exhaustion. <br></div><div>It additionally allows more security to be built into the rendezvous server than could normally be incorporated into relatively dumb device.<br></div><div><br></div><div><br></div><div>Regards,<br></div><div>Mike Burns<br></div><div>IPTrading.com<br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><div style="" class="zmail_extra"><br><div id="Zm-_Id_-Sgn1">---- On Fri, 14 Jun 2019 16:33:20 -0400 <b>Fernando Frediani <fhfrediani@gmail.com></b> wrote ----<br></div><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); padding-left: 6px; margin: 0px 0px 0px 5px;"><div><div dir="auto">Hello folks.<div dir="auto"><br></div><div dir="auto">I wanted to share a topic with you and gather your views on the matter so perhaps it can be useful to people specially for ISP operadors.<br></div><div dir="auto"><br></div><div dir="auto">With the growing need o CGNAT (or equivalent methods) at many ISPs some issues appear more frequentlly as for example users who require Incoming Connections and Port Reditections for various reasons like access a camera system as DVR/NVR for example, a Home/SMB Server or similar or even to be able to Host Games' matches.<br></div><div dir="auto"><br></div><div dir="auto">For DVRs there have been more recentlly some makers that developed a 'Cloud System' whihc kind of resolves the issue by doing some type of NAT Punch Hole with the help of an external 'coordinator' server and which becomes something very handy avoiding the ISP having to attribute a public IPv4 for that user.<br></div><div dir="auto"><br></div><div dir="auto">But that is specific to that application and the maker develop implement the technology and mantain the servers who coordinate this technique.<br></div><div dir="auto"><br></div><div dir="auto">I wanted to find out more other applications who are able to work with this technique to bypasss CGNAT issues lime this more easily going futher to perhaps having something that can work or is adaptable to other situations like a Home/SMB Server or a Gaming system.<br></div><div dir="auto"><br></div><div dir="auto">This can help many ISPs to resolve many problems caused by the adaption of the unavoidable CGNAT other than just the DVR scenarios.<br></div><div dir="auto"><br></div><div dir="auto">Note: even with IPv6 fully implemented at the ISP that still may be many cases where either the hosted equipment didn't get firmware upgrade to suport IPv6 or the most common, the access device not having a IPv6 connection available.<br></div><div dir="auto"><br></div><div dir="auto">Thanks<br></div><div dir="auto">Best regards<br></div><div dir="auto"><br></div><div dir="auto">Fernando Frediani<br></div><div dir="auto"><br></div></div>_______________________________________________<br>LACNOG mailing list <br><a target="_blank" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a> <br><a target="_blank" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a> <br>Cancelar suscripcion: <a target="_blank" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a> <br></div></blockquote></div><div><br></div></div><br></body></html>