Enhance CG-NAT Re: V6 still not supported
Abraham Y. Chen
aychen at avinta.com
Mon Apr 4 16:14:15 UTC 2022
Hi, Eduard:
0) Appreciate very much for you spending the time to read all 55
pages of our draft and then offering your extensive thoughts.
1) "....Your first pages are oriented for low-level engineers (“for
dummies”). ... ": Thanks. I believe that the Abstract, Introduction,
etc. at the beginning of a document are intended for "dummies" and those
busy high level executives to get a quick overview. Unless, the
descriptions are sugar coated to mislead the reader. In general,
however, I do admit that we have not done a good job of describing the
EzIP solution from the perspectives of colleagues who are used to the
current "Internet way". This is because we approached the topic from an
outsider's viewpoint, and there are more than a few parameters behind
the EzIP scheme that do not follow the current approaches, but the
alternatives which could be regarded as opposing techniques. We will
need to highlight these to alert the readers of the distinction. If you
could treat the EzIP scheme as unorthodox, but patiently review it with
a pair of critical eyes, I believe that you will see that the below
explanations are realistic.
2) " ... 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). ...how to coordinate one 240/4
distribution between all subscribers. Because address space between
Carrier and Subscriber are Private too. ": The implied EzIP address
management is by one administrative body per 240/4 netblock with
considerations such as static, geolocation and hierarchical. Thus, there
will not be issues when businesses merge. This implies that the 240/4
should be respected as "*/natural resources/*", instead of the current
treatment of being "*/personal properties/*", actually "*/business
property/*". --- This is analogous to how PSTN numbers were handled in
the old days.
3) "... You have not discussed in the document CGNAT case that is
typically called NAT444 (double NAT translation). ... ": If I
understand NAT444 properly, it is a network architecture going from
RG-NAT (Residential / Routing Gateway NAT) at one end of a link through
CG-NAT (Carrier Grade NAT) in the middle before reaching the public
Internet network. What EzIP proposes to do is to replace the CG-NAT with
a basic router. This can be achieved by simply assigning a 240/4 address
permanently to each subscriber premises that currently makes use of a
dynamic port number, without affecting the hardware equipment nor the
networking architecture. For software implementation, enabling the use
of 240/4 netblock is all what is needed. At least, we have identified a
simple case for the inspiration. And, the "IPv4 Unicast Extension"
project has found numerous equipment already supporting 240/4.
4) " ... I do not see a big difference between EzIP and NAPT that we
have right now. ... ": Precisely! Please see Pt. 3) above. Simply
put, EzIP is a numbering plan upgrade for CG-NAT.
5) " ... Initially, the majority of servers on the internet would not
be capable to read Ez options (private 240/4 address extension). ...
": Correct. But, this is only needed when we extend EzIP service to
include the true end-to-end connectivity between any two premises around
the world like the IDDD (International Direct Distance Dialing) of the
PSTN. The initial EzIP deployment is only RAN that upgrades the CG-NAT
modules in a coordinated process (see Pt. 2) above). Even so, it can be
done progressively by individual routers within a CG-NAT operation. That
is, enable the root level routers to be able to handle 240/4 addressed
packets for simple routing. Then, enable the next level routers to do
the same. These are just standby capabilities until each of the lowest
level (the subscriber premises) routers (the RGs) is assigned with a
static 240/4 address. At that point, the NAT functions in the CG-NAT
routers can be retired to standby status. This RAN architecture will
last a pretty long time because the Internet is currently predominantly
operated in Master/Slave mode by CDNs that are doing well with their
Sever/Client model. By the time the end-to-end connectivity between
different RANs is needed, either the RANs can designate some of their
own routers (the SPRs) for such interconnect function, or certain
existing Internet routers have been enabled to handle the Option Words.
6 " ....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
.... ": The gateway of a RAN cluster (we call it a Sub-Internet) or
a CDN module 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.com at nanog.org] *On
> Behalf Of *Abraham Y. Chen
> *Sent:* Sunday, April 3, 2022 6:14 AM
> *To:* Matthew Petach <mpetach at netflight.com>; Masataka Ohta
> <mohta at necom830.hpcl.titech.ac.jp>
> *Cc:* nanog at 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
> <mohta at 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://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>
>
>
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220404/2e2bf698/attachment.html>
More information about the NANOG
mailing list