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 <fhfredi...@gmail.com
<mailto: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 <mailto: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
<mailto:openwrt-devel@lists.openwrt.org>
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org>
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
<mailto: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
