[OpenWrt-Devel] FULL CONE NAT in OpenWrt

[Fernando Frediani]

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 <fhfrediani at gmail.com 
> <mailto:fhfrediani at 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
>>     <puchapapa01 at gmail.com <mailto:puchapapa01 at 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 at lists.openwrt.org
>>         <mailto:openwrt-devel at lists.openwrt.org>
>>         https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
>>
>>     _______________________________________________
>>     openwrt-devel mailing list
>>     openwrt-devel at lists.openwrt.org  <mailto:openwrt-devel at lists.openwrt.org>
>>     https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>     _______________________________________________
>     openwrt-devel mailing list
>     openwrt-devel at lists.openwrt.org
>     <mailto:openwrt-devel at lists.openwrt.org>
>     https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200504/dd0ddb8f/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel