Hi Abraham, I propose you improve EzIP by the advice in the draft on the way how to randomize small sites choice inside 240/4 (like in ULA?). To give the chance for the merge that may be needed for a business. Minimize probability for address duplication inside 240/4 block (that everybody would use).
You have not discussed in the document CGNAT case that is typically called NAT444 (double NAT translation). I assume it is possible, but would be a big question how to coordinate one 240/4 distribution between all subscribers. Because address space between Carrier and Subscriber are Private too. I do not see a big difference between EzIP and NAPT that we have right now. Explanation: Initially, the majority of servers on the internet would not be capable to read Ez options (private 240/4 address extension). Hence, the Web server would see just UDP:Public_IP. The gateway (that would be exposing 240/4 options) would need additionally to translate UDP ports to avoid a collision (as usual for NAPT). The gateway could not stop NAPT till the last server on the internet would be capable to read address extension (240/4) in options, because the gateway would not know what server is capable to parse EzIP options. It means NEVER, at least not in this century. Hence, the additional value from EzIP is small, because the primary job would be still done by NAPT. You could try to patch this problem. If the new server would signal to the gateway that it is capable to understand EzIP options then overlapping UDP ports from the same Public IP address would be not a problem, because the server may additionally use private address space for traffic multiplexing. IMHI: it would be a very dirty work-around if servers would need to teach their capabilities to every NAPT device. Sorry, I have not read all 55 pages, but the principal architecture questions are not possible to understand from the first 9 pages. Your first pages are oriented for low-level engineers (“for dummies”). Eduard From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei....@nanog.org] On Behalf Of Abraham Y. Chen Sent: Sunday, April 3, 2022 6:14 AM To: Matthew Petach <mpet...@netflight.com>; Masataka Ohta <mo...@necom830.hpcl.titech.ac.jp> Cc: nanog@nanog.org Subject: Enhance CG-NAT Re: V6 still not supported Hi, Matt: 1) The challenge that you described can be resolved as one part of the benefits from the EzIP proposal that I introduced to this mailing list about one month ago. That discussion has gyrated into this thread more concerned about IPv6 related topics, instead. If you missed that introduction, please have a look at the following IETF draft to get a feel of what could be done: https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space 2) With respect to the specific case you brought up, consider the EzIP address pool (240/4 netblock with about 256M addresses) as the replacement to that of CG-NAT (100.64/10 netblock with about 4M addresses). This much bigger (2^6 times) pool enables every customer premises to get a static IP address from the 240/4 pool to operate in simple router mode, instead of requesting for a static port number and still operates in NAT mode. Within each customer premises, the conventional three private netblocks may be used to handle the hosts (IoTs). 3) There is a whitepaper that presents an overview of other possibilities based on EzIP approach: https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf Hope the above makes sense to you. Regards, Abe (2022-04-02 23:10) On 2022-04-02 16:25, Matthew Petach wrote: On Fri, Apr 1, 2022 at 6:37 AM Masataka Ohta <mo...@necom830.hpcl.titech.ac.jp<mailto:mo...@necom830.hpcl.titech.ac.jp>> wrote: If you make the stateful NATs static, that is, each private address has a statically configured range of public port numbers, it is extremely easy because no logging is necessary for police grade audit trail opacity. Masataka Ohta Hi Masataka, One quick question. If every host is granted a range of public port numbers on the static stateful NAT device, what happens when two customers need access to the same port number? Because there's no way in a DNS NS entry to specify a port number, if I need to run a DNS server behind this static NAT, I *have* to be given port 53 in my range; there's no other way to make DNS work. This means that if I have two customers that each need to run a DNS server, I have to put them on separate static NAT boxes--because they can't both get access to port 53. This limits the effectiveness of a stateful static NAT box to the number of customers that need hard-wired port numbers to be mapped through; which, depending on your customer base, could end up being all of them, at which point you're back to square one, with every customer needing at least 1 IPv4 address dedicated to them on the NAT device. Either that, or you simply tell your customers "so sorry you didn't get on the Internet soon enough; you're all second class citizens that can't run your own servers; if you need to do that, you can go pay Amazon to host your server needs." And perhaps that's not as unreasonable as it first sounds; we may all start running IPv4-IPv6 application gateways on Amazon, so that IPv6-only networks can still interact with the IPv4-only internet, and Amazon will be the great glue that holds it all together. tl;dr -- "if only we'd thought of putting a port number field in the NS records in DNS back in 1983..." Matt [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
