<div><div><br></div><div><br><div class="gmail_quote"></div></div></div><div><div dir="ltr" class="gmail_attr">On Wed, Apr 29, 2020 at 7:46 PM Masataka Ohta <<a href="mailto:mohta@necom830.hpcl.titech.ac.jp" target="_blank">mohta@necom830.hpcl.titech.ac.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ca By wrote:<br>
<br>
>>>    You can't eliminate that unless the CPE also knows what internal port<br>
>>> range it's mapped to so that it restricts what range it uses.  If you<br>
>>> can do that, you can get rid of the programmatic state tracking entirely<br>
>>> and just use static translations for TCP and UDP which, while nice, is<br>
>>> impractical.  You're about 95% of the way to LW4o6 or MAP at that point.<br>
>><br>
>> Interesting. Then, if you can LW4o6 or MAP, you are about 95% of the<br>
>> way to E2ENAT with complete end to end transparency using IPv4 only,<br>
>> which means we don't need IPv6 with 4to6 NAT lacking the transparency.<br>
>><br>
>>          <a href="https://tools.ietf.org/html/draft-ohta-e2e-nat-00" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-ohta-e2e-nat-00</a><br>
>><br>
>>                                                  Masataka Ohta<br>
<br>
> Since we are talking numbers ans hard facts<br>
<br>
I'm rather interested in not numbers but facts on the E2E<br>
transparency, because, without the transparency, legacy<br>
NAT44 should be enough.<br>
<br>
But, as you insist on numbers:<br>
<br>
> 42% of usa accesses google on ipv6<br>
> <br>
> <a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="noreferrer" target="_blank">https://www.google.com/intl/en/ipv6/statistics.html</a><br>
<br>
The proper number to be considered should be percentage of IPv6<br>
hosts which can not communicate with IPv4 only hosts.<br>
<br>
Isn't it 0%?</blockquote><div dir="auto"><br></div></div><div><div dir="auto">For those of us running networks, especially growing networks, uniquely numbering hosts is our goal and ipv6 fits that task. </div><div dir="auto"><br></div><div dir="auto">For many networks, rfc1918 space is not sufficiently large to number end-points. Around the world, there are many networks that fit this. </div><div dir="auto"><br></div><div dir="auto">For those same network, nat44 scale is also a painful and costly effort. </div><div dir="auto"><br></div><div dir="auto">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 ...)</div><div dir="auto"><br></div><div dir="auto">Being able to offer a product that disallows access to ipv4 is a non-goal</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
                                                        Masataka Ohta<br>
</blockquote>
</div>