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.
On Tue, 5 May 2020 at 10:23, Fernando Frediani <[email protected]> wrote: > 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. > 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. > > Internal sub-nets should be adjusted automatically either via RA or DHCPv6. > 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. > > Regards > Fernando > On 04/05/2020 19:00, Joel Wirāmu Pauling wrote: > > 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 <[email protected]> > 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 <[email protected]> >> 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 >>> [email protected] >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >>> >> >> _______________________________________________ >> openwrt-devel mailing >> [email protected]https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> >> _______________________________________________ >> openwrt-devel mailing list >> [email protected] >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel >
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
