CGNAT Solutions

Thu Apr 30 03:45:10 UTC 2020

On Wed, Apr 29, 2020 at 7:46 PM Masataka Ohta <
mohta at necom830.hpcl.titech.ac.jp> wrote:

> Ca By wrote:
>
> >>>    You can't eliminate that unless the CPE also knows what internal
> port
> >>> range it's mapped to so that it restricts what range it uses.  If you
> >>> can do that, you can get rid of the programmatic state tracking
> entirely
> >>> and just use static translations for TCP and UDP which, while nice, is
> >>> impractical.  You're about 95% of the way to LW4o6 or MAP at that
> point.
> >>
> >> Interesting. Then, if you can LW4o6 or MAP, you are about 95% of the
> >> way to E2ENAT with complete end to end transparency using IPv4 only,
> >> which means we don't need IPv6 with 4to6 NAT lacking the transparency.
> >>
> >>          https://tools.ietf.org/html/draft-ohta-e2e-nat-00
> >>
> >>                                                  Masataka Ohta
>
> > Since we are talking numbers ans hard facts
>
> I'm rather interested in not numbers but facts on the E2E
> transparency, because, without the transparency, legacy
> NAT44 should be enough.
>
> But, as you insist on numbers:
>
> > 42% of usa accesses google on ipv6
> >
> > https://www.google.com/intl/en/ipv6/statistics.html
>
> The proper number to be considered should be percentage of IPv6
> hosts which can not communicate with IPv4 only hosts.
>
> Isn't it 0%?

For those of us running networks, especially growing networks, uniquely
numbering hosts is our goal and ipv6 fits that task.

For many networks, rfc1918 space is not sufficiently large to number
end-points. Around the world, there are many networks that fit this.

For those same network, nat44 scale is also a painful and costly effort.

To that end, ipv6 / 464xlat provides the one-two punch of uniquely
numbering nodes and by-passing NAT44 or NAT64 for the majority of traffic
we see (google, fb, netflix ...)

Being able to offer a product that disallows access to ipv4 is a non-goal

So far, i just talked about why eyeball networks deploy ipv6 — which is
basic and sensible engineering and economics.  A similar set of forces are
at work on the content / cloud / iot side.

>
>                                                         Masataka Ohta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200429/9748e053/attachment.html>