Re: Enhance CG-NAT Re: V6 still not supported
Hi, Bill: 0) Thanks for bringing up the NANOG posting guideline. We now have something tangible to discuss. 1) Section 6. looks most relevant. So, I copy and paste it below for our discussion: A. 6.1.1. "... > relevant excerpt 1 response to excerpt 1 ... ": This seems to be what I have been doing, except maybe how to interpret the keyword "excerpt". Perhaps you are expecting me to cite more text from the message that I am responding to, such as a complete paragraph, instead of only a short phrase or two? If so, I certainly will be glad to do so. B. On the other hand, the leading sentence "When posting to the NANOG list please avoid: Top-posting, i.e., putting your reply right on top of the message you're responding to, ... " seems to discourage threading the messages (keeping a long tail of the earlier texts)? Perhaps there is some kind of optimal trade-off between how much each of these two should be included in a message? 2) The two URLs are kind of odd: A. The first URL led me to a blank webpage. B. The second URL led me to a list of Q's that seem to be more humorous than instructive. *** *6. Posting Conventions* 1. *Format* When posting to the NANOG list please avoid: 1. Top-posting, i.e., putting your reply right on top of the message you're responding to, rather than quoting and responding as follows: > relevant excerpt 1 response to excerpt > relevant excerpt 2 response to excerpt > relevant excerpt 3 response to excerpt 2. Using non-standard methods of quoting prior text; 3. Failing to quote, or to snip, as appropriate; 4. Sending in HTML or other non-standard attachment formats; 5. Starting or participating in flame wars. The linux-kernel mailing list FAQ provides detailed instructions for* quoting prior text*: http://www.tux.org/lkml/#s3-9 "Dear Emily Postnews" at http://www.templetons.com/brad/emily.html makes lots of good suggestions about *signatures* and other items of interest. *** Please review and advise. Regards, Abe (2022-04-06 17:31) On 2022-04-06 11:33, William Nelson wrote: I am still learning the proper eMail etiquette on NANOG. Could you please echo back some of my writings as you received? So that I can see what they got transformed to. There is no transforming of your formatting after you send it. It's frustrating in the format you typed it in. https://archive.nanog.org/list/faq#posting -bn. Confidentiality Notice: This email message, any attachment, and the information therein is confidential, intended only for the named recipient(s), and may contain material that is proprietary, privileged, or otherwise private under applicable law. If you have received this message in error, or are not a named recipient: (1) You are advised that any disclosure, copying, distribution or use of this email, or the information in its content, is strictly prohibited; (2) We ask you immediately to notify the sender by return email or contact Third Federal at 1-800-THIRD-FED (1-800-844-7333); (3) We instruct you to delete this email message and any attachment from your computer. Thank you. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Enhance CG-NAT Re: V6 still not supported
Hi, Ant: 1) As I Cc:'ed you, I attempted to contact the author of the IPv4+ draft a few days ago to offer my reading of his work. I have not heard any response. In short, I believe that IPv4+ is paraphrasing the scheme of the unsuccessful RFC1385 that EzIP Draft cited as Informative Reference [12]. -- meaning that EzIP has avoided the trap of such approach. 2) I went back to earlier versions of the IPv4+ drafts and discovered a surprising trend. That is, through all eight revisions, there has been hardly any actual write-up text changes! It appears that the author is just keeping the six-months-timer ticking. 3) Since you indicated that IPv4+ was reported to NANOG, maybe you could retrieve that thread and check with the author about what is the status? 4) "Have you approached any vendors about the feasibility of IP Options being used for switching at line rate in silicon? ": No. For the first phase of implementing EzIP, the configuration is called RAN (Regional Area Network). It is essentially a numbering plan enhancement to CG-NAT. There is no change to the basic IPv4 Header. The only engineering effort is "disabling the program code that has been disabling the use of the 240/4 netblock", followed by retiring the NAT function. So that CG-NAT can operate as simple routers, by having the look-up state-tables capability as backup. 5) In the long run, yes, processing of the Option Word needs be considered and ideally be implemented in silicon to achieve the line rate switching. Many claim, however, such end-to-end connectivity is not needed according to the current trend, which is primarily Server / Client model by CDN business. So, EzIP is actually a forward looking two stage scheme. We can focus on the first phase for now to relieve the underlying issues. There will be plenty of lead time to upgrade the silicon when the demand for end-to-end connectivity begins to build up. 6) " ... but your replies are practically illegible because of formatting. ... ": I am still learning the proper eMail etiquette on NANOG. Could you please echo back some of my writings as you received? So that I can see what they got transformed to. Thanks, Abe (2022-04-06 11:25) On 2022-04-03 16:14, Anthony Newman wrote: You should check outhttps://datatracker.ietf.org/doc/html/draft-tang-ipv4plus-08 which is still dragging on after receiving similar treatment here to EzIP (although less patented by its author) and equally unlikely to be possible to implement in the real world in a timely fashion. Have you approached any vendors about the feasibility of IP Options being used for switching at line rate in silicon? Software IP stacks are the absolute least of your problem when proposing alterations to routing behaviour based on packet contents. Apologies if this has been covered, but your replies are practically illegible because of formatting. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Enhance CG-NAT Re: V6 still not supported
dule is not expected to make any changes from today's configuration for packet transmission between it and the Internet. For the CDN operation, the gateway has already been performing the address translation between unrelated IP address blocks as a two-port device. For packets going through it, it will continue to perform its NAT function. There is no reason to announce to the world that its internal addresses have been updated to 240/4. 7) "... IMHI: it would be a very dirty work-around if servers would need to teach their capabilities to every NAPT device. ... ": Based on the above description, I hope you will change your conclusion. I look forward to your further thoughts. Regards, Abe (2022-04-04 12:13 EDT) On 2022-04-04 06:32, Vasilenko Eduard wrote: 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 ; Masataka Ohta *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 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
RE: Enhance CG-NAT Re: V6 still not supported
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 ; Masataka Ohta 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 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
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 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 -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
