[OpenWrt-Devel] FULL CONE NAT in OpenWrt

Mon May 4 20:02:24 EDT 2020

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 <fhfrediani at gmail.com> 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 <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
>>
> _______________________________________________
> 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/3bcfcfdd/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel