<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Yes that's the update v6 flag I was mentioning.. BUT it won't actually solve this issue, as you would then need to someone dynamically adjust inbound stateful forwarding rules in nft/ip6tables dynamically... WHICH ... am not a fan of doing.</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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 5 May 2020 at 10:23, 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>Not all ISPs allow the user to request static PD. I like the idea
of a static PD, but it is the ISP choice what they will give the
user.<br>
I can understand the issues you are describing but they really
need to be fixed by other proper means, not by introducing another
problem which is stimulating users to do NAT66 which is more than
ugly thing to have. If this has to be used it is because of
something else that is not working as it should and that is what
should be fixed.</p>
<p>Internal sub-nets should be adjusted automatically either via RA
or DHCPv6.<br>
I believe there is currently a proposal in IETF to make this
scenario work as expected when these changes happen and that is
the correct way in my view to deal with this issue.</p>
<p>Regards<br>
Fernando<br>
</p>
<div>On 04/05/2020 19:00, Joel Wirāmu
Pauling wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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>
</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>