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:
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. Uplink ISP provides /56 PD via /128 PtP link-net using public ranges (normal so-far for dhcpv6 setup). Uplink ISP provides /32 v4 IP via dhcp End user requests static v4 ; ISP front end systems cope with this. 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). -- 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...) -- 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. 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. --- 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. -Joel 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 On Tue, 5 May 2020 at 09:02, Fernando Frediani <fhfredi...@gmail.com> wrote: > I believe NAT66 should not be stimulated in any sense. > One of the greatest things of IPv6 is to restore end to end communication. > > 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. > 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. > > Regards > Fernando > On 04/05/2020 17:52, Joel Wirāmu Pauling wrote: > > I am all for exposing Cone Nat in UCI / Firewall zones as an option to the > masquerading configuration in a zone. > > 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. > > -Joel > > On Tue, 5 May 2020 at 07:25, Gracias Amigou <puchapap...@gmail.com> wrote: > >> Please add this package as official: >> >> *Posts:* >> >> 1. xt_FULLCONENAT -- Implementing RFC 3489 full cone SNAT in OpenWrt >> >> <https://forum.openwrt.org/t/xt-fullconenat-implementing-rfc-3489-full-cone-snat-in-openwrt/14816> >> 2. [12/8更新]OpenWrt 上实现 NAT1 (Full cone NAT) 的方法,无需 DMZ/UPnP - >> OPENWRT专版 <https://www.right.com.cn/forum/thread-319827-1-1.html> >> 3. 从DNAT到netfilter内核子系统,浅谈Linux的Full Cone NAT实现 | ChionLab >> <https://blog.chionlab.moe/2018/02/09/full-cone-nat-with-linux/> >> >> >> *Git:* >> • GitHub - LGA1150/openwrt-fullconenat: Netfilter and iptables extension >> for full cone NAT ported to OpenWrt. >> <https://github.com/LGA1150/openwrt-fullconenat> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> > > _______________________________________________ > openwrt-devel mailing > listopenwrt-devel@lists.openwrt.orghttps://lists.openwrt.org/mailman/listinfo/openwrt-devel > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel >
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel