<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Yup; ok i'm not going to get into a religious war about this. But I will fight you on this and I have been around long enough to have been on the other side of the fence and am talking from a position of understanding it's not a great place we are in to need it. But we do:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">There are multiple use-cases for nat66. Here is the one that I have now encountered several times, and which I believe likely affects a large chunk of users. <br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Uplink ISP provides /56 PD via /128 PtP link-net using public ranges (normal so-far for dhcpv6 setup).</div><div class="gmail_default" style="font-family:verdana,sans-serif">Uplink ISP provides /32 v4 IP via dhcp</div><div class="gmail_default" style="font-family:verdana,sans-serif">End user requests static v4 ; ISP front end systems cope with this. <br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Despite requesting static addressing the v6 /56 PD does not honor this (there is an v6 update flag for this, but it's kind of useless if you still have to renumber all your internal sub-subnets when this happens).</div><div class="gmail_default" style="font-family:verdana,sans-serif">--</div><div class="gmail_default" style="font-family:verdana,sans-serif">So every reboot/timeout of the v6 upstream - potentially 1000's of endpoints internally all need to update their prefixes (suffixes are relatively easy to maintain...)</div><div class="gmail_default" style="font-family:verdana,sans-serif">--</div><div class="gmail_default" style="font-family:verdana,sans-serif">ULA solves this for consistent internal addressing, BUT does not solve it for Firewall rules for say things like Video Conference bridges/webservers/FIP/OpenStack pools/OpenShift exist routes, etc ,etc. That may be exposed via port-forwarding and Forwarding rules in the Routers/Edge firewall in Openwrt in combination with some $othernondhcpv6 aware config.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">NAT66 + ULA would solve for the above case. You still have the issue of needing to update all the DNS records but that is largely accomplishable via the same way DDNS for v4 is. <br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">---</div><div class="gmail_default" style="font-family:verdana,sans-serif">So yup provide me with a better way to cope with the above that does not need tunnels or require a provider uplink have static v6 allocations and I will wholeheartedly agree nat66 is not needed.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">-Joel<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">IPv6 PD /56 is delivered from Uplink RSP (retail service provider); MANY ISP's cannot and do-not allow for their PD announcements (via dhcpv6) to be statically set, even when their ipv4 addressing<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 5 May 2020 at 09:02, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com">fhfrediani@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>I believe NAT66 should not be stimulated in any sense.<br>
One of the greatest things of IPv6 is to restore end to end
communication.</p>
<p>PDs should only change when there is a re-connection and the CPE
should be able able to handle that correctly updating its LAN
prefixes accordingly.<br>
Stimulating and making that easy for general usage is like a crime
against IPv6. If one really needs to use that "chewing gun" he
must know what he is doing and to manually for that exception
case.</p>
<p>Regards<br>
Fernando<br>
</p>
<div>On 04/05/2020 17:52, Joel Wirāmu
Pauling wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">I am all for exposing
Cone Nat in UCI / Firewall zones as an option to the
masquerading configuration in a zone.</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">Also as much as I hate
it nat66 for IPv6 needs to be exposed in the same place -
specifically for mapping routable PD which change often to
ULA's. <br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">-Joel<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 5 May 2020 at 07:25,
Gracias Amigou <<a href="mailto:puchapapa01@gmail.com" target="_blank">puchapapa01@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Please add this package as official:<br>
<div><br>
</div>
<div><b>Posts:</b></div>
<div>
<ol>
<li><a href="https://forum.openwrt.org/t/xt-fullconenat-implementing-rfc-3489-full-cone-snat-in-openwrt/14816" target="_blank">xt_FULLCONENAT
-- Implementing RFC 3489 full cone SNAT in OpenWrt</a></li>
<li><a href="https://www.right.com.cn/forum/thread-319827-1-1.html" target="_blank">[12/8更新]OpenWrt
上实现 NAT1 (Full cone NAT) 的方法，无需 DMZ/UPnP - OPENWRT专版</a></li>
<li><a href="https://blog.chionlab.moe/2018/02/09/full-cone-nat-with-linux/" target="_blank">从DNAT到netfilter内核子系统，浅谈Linux的Full
Cone NAT实现 | ChionLab</a></li>
</ol>
</div>
<div><b><br>
</b></div>
<div><b>Git:</b><br>
</div>
<div>• <a href="https://github.com/LGA1150/openwrt-fullconenat" target="_blank">GitHub -
LGA1150/openwrt-fullconenat: Netfilter and iptables
extension for full cone NAT ported to OpenWrt.</a><br>
</div>
</div>
_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org" target="_blank">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel" rel="noreferrer" target="_blank">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
openwrt-devel mailing list
<a href="mailto:openwrt-devel@lists.openwrt.org" target="_blank">openwrt-devel@lists.openwrt.org</a>
<a href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel" target="_blank">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org" target="_blank">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel" rel="noreferrer" target="_blank">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a><br>
</blockquote></div>