[OpenWrt-Devel] FULL CONE NAT in OpenWrt

[Joel Wirāmu Pauling]

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> 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> 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
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
>
> _______________________________________________
> openwrt-devel mailing listopenwrt-devel at lists.openwrt.orghttps://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> _______________________________________________
> openwrt-devel mailing list
> 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/20200505/a830a1f2/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel