I know that's your problem. For inbound access to servers, the solution in IPv6 is static addressing
I understand, that's what dynamic addresses are. You need static IPv6 addresses to open ports on a specific IPv6 address only.
Odd, because even when I enabled DHCPv6 on LAN, it used the SLAAC gateway (which is Link-Local). I'm almost certain you must use SLAAC with a dynamic upstream; but I'd have to review the RFCs.
The purpose of the script is to automatically generate and update IPv6 DNS host names on the OpenWrt/LEDE router, making access to devices by name (either IPv4 or IPv6) on your network a snap. It does this by creating a hosts file giving local DNS names to IPv6 addresses that IPv6 enabled devices took via SLAAC mechanism.
IPv6 for SIP is great, except for this issue with the dynamic prefixes. Ideally your ISP would allow your prefix to remain reserved for at least say 5 days, so that even with longish power outages you'd get the same prefix on coming back up, but no obviously not in your case.
Suggests that there's an alternative using NAT66 but changing only the prefix, so that's a possibility.
What really is the issue with DHCP having a 2 minute timeout? I mean, if you don't have 100000 hosts on your LAN all hitting the DHCP server every 1 minute. For a typical LAN with less than 100 hosts you're going to get something like say 5000 bytes per minute of DHCP traffic or 0.00067 Mbps on your gigabit lan.
You could configure your VOIP devices on a separate VLAN (a good idea anyway) and then only have this very short DHCP timeout of 120 seconds for that VLAN. Then unless you have a football field size call center you're pretty much good to go.
As for restarting the DHCP server after a prefix change, is there a hotplug event we can hook into on OpenWRT?
iptables (and uci based fw3) support a special notation for that.
You can specify rules in the form ip6tables -I FORWARD -d ::6666:b3ff:fe47:e1b9/::ffff:ffff:ffff:ffff -j ACCEPT which will look at the last 64 bit of the destination address, ignoring the prefix part completely.
In /etc/config/firewall you can use the same notation (option dest_ip ::6666:b3ff:fe47:e1b9/::ffff:ffff:ffff:ffff) or a special short-hand notation with a negative prefix size (option dest_ip ::6666:b3ff:fe47:e1b9/-64)
Not yet. Thanks for the pointer, looks like a viable approach for a stable local DNS situation.
Yeah, this might be what I'll end up doing. Depending on what else I my "research" will unearth.
Of course. Thanks for reminding me that rules can be made to look at the interface identifier part only, by means of according masks.
All that said, here's a link to an Ubuntu setup where somebody does exactly what I was talking about
The setup is described further down, in the " NAT with a dynamic IPv6 prefix" section.
The result is a pure ULA setup on LAN. I.e. global prefixes from the ISP don't get propagated to LAN at all. And the ULA host addresses are then mapped to global addresses on the router by mere prefix mapping, 1-to-1. This is accomplished w/ the netfilter NETMAP target.
Of course, this would lead to the usual problems with protocols that encode host addresses themselves. But as a NAT solution that's at least technically a lot cleaner than MASQUERADE.
OpenWrt doesn't seem to allow that kind of setup right now though. To do that I'd probably have to look at odhcp6c and /lib/netifd/dhcpv6.script in particular, and potentially modify the latter to implement this sort of approach.
Thanks everybody for the feedback, very much appreciate it. Got some things to think about now.
You do end up w/ a pure ULA LAN, but w/ DHCPv6 and RA services provided. Of course, this net now isn't routable to the Internet. So this is where NETMAP should help. Because if it rewrites the prefixes before packets hit the routing table they should go through (I think?).
So to get the 1-1 NAT I've been thinking about, what would be left to do is trigger a firewall update script each time the global prefix changes. I guess the running process command line
tells us where we need to hook in. We can even grab the prefix from the environment variables odhcp6c itself passes into the script, by design.
So testing that would be next on the list. But if it works for the other guy on Ubuntu I guess there should be no reason why it wouldn't work on OpenWrt, too.
This is particularly going to break SIP hard. Also I'm not clear on why it works at all, presumably the kernel would not want to use a ULA address as a source address to reach a public destination... But maybe I'm wrong there If it has no public prefix.
Well, that broke SIP hard w/ NAT44 already. That's why there's STUN servers and the likes, to facilitate NAT traversal.
The ULAs aren't routable because the OpenWrt networking configuration software doesn't install a route. That's obviously intentional, to comply w/ whatever RFC. Those addresses aren't supposed to show up on the Internet.
It's not clear that STUN is going to work for IPv6 SIP hosts. Are there STUN servers that even listen on IPv6? Are there clients that even use STUN when they're configured for IPv6?
I promise you you will have far more headaches with SIP if you go this route than if you just set your DHCPv6 timeout to 120 seconds and suffer a short loss of connectivity once every time your power goes out (which in your area is how often?)
Thanks for your good wishes, but numb.viagenie.ca for example supports RFC6156.
Look, I've kind of had enough of IPv6 apostles preaching that one isn't supposed to use NAT because the theory says otherwise. At some point they need to understand that it's practical realities which drive user demand, and that it's the technology which has to adapt. That's why there's countless amendments to the original IPv6 specifications anyway, as there is to the SIP specifications.
There's a reason why the Netfilter developers provided NAT support for IPv6. Which is that they do not live in a bunker dreaming of a world that perfectly lines up w/ whatever's going on in their imagination.
Hey, whoa I'm not an apostle and there's no need to get upset. I'm just someone who's spent a decade working with the total shit that is SIP + NAT + ISPs that intercept SIP packets and rewrite them in their customer service equipment, and Carrier Grade NAT that isn't, etc and am extremely happy to have moved to IPv6 where none of that matters anymore and my calls never drop.
Well, sorry, it wasn't personal. But you mention NAT w/ IPv6 on any networking forum and people come jumping at you w/ vigor.
But then, just the other day I've seen video of a talk by a Cisco engineer about multihoming. Where he readily acknowledged that IPv6 isn't well suited for that, and that one preferably would use some NAT approach.
So that's why I'm doing what I'm doing. Which is: evaluating and testing the options. See how well each of them goes. And then decide what would suit my needs best.
Definitely evaluate your options, but as someone who's worked with SIP a lot, I was offering hard won opinion that SIP with plain IPv6 is great and you should consider avoiding all the crap that NAT introduces as far as SIP is concerned.
So, for example you might prefer to split your network into two VLANs one for SIP devices, and one for everything else. Have the SIP devices use a public prefix, and have a short DHCPv6 timeout on their VLAN, and work with your ULA scheme on the other VLAN so that your desktop machines don't experience disconnects, since they're less likely to be sensitive to this issue.
I hear you about the irritation of not getting a stable prefix. I just know that the irritation of having people basically refuse to talk to you on the phone because you can never maintain a connection is also really big.
That's certainly good advice and much appreciated. Maybe I end up doing that, or maybe something entirely different. Right now though, in the midst of things where all that's left to do is just write a script for the netfilter rules, curiosity has gotten the better of me. It's just too much fun to stray off the beaten path and check things out you're not supposed to
I can sympathize with the challenges of a non-stable IA_PD. The complexity of scripting I have ben looking at to be able to manage even a potential change of prefix on a multi-segment network has been frustrating. No matter what I do, I fear that one day Comcast won't "respect" the DHCP-assigned IA_PD and I'll have to renumber my entire public-facing IPv6 hosts, modify all my firewall rules, and deal with public DNS.
I think that much of the "don't use IPv6 NAT" is directed at at users that haven't yet understood IPv6 in any depth and attempt to replicate their IPv4 topology with IPv6. There certainly are situations where NPT are called for. One is when transitioning an enterprise from one prefix to another, typically when changing upstream transport providers. Unfortunately it seems that @rwberger has an ISP that is putting him in that situation on a regular basis.
Maybe he said that because Cisco doesn't have the tools.
I'm using IPv6 multihoming without any big problems. The solution is to use a dynamic routing protocol which supports source-specific routing such as babel. With dynamic prefixes you also need a way to dynamically assign addresses which is also included in the homenet protocols. (Unfortunately Path MTU discovery seems to be broken in recent versions of the Linux kernel when using source-specific default routes. It's working in Openwrt 18.06 but not in Ubuntu 18.04 which uses linux kernel 4.15)
Doesn't using something like Babel require cooperation from the ISP? Could a person with a typical consumer service or two succeed in using that? Can you give a brief outline of what's required other than installing babeld?
Another thing that can at least partially mitigate prefix renumbering is to use an HTTP proxy. These days a lot of the "user experience" is around being able to surf the web. If you run squid on your router and have all the LAN clients use the ULA of the router as the proxy (or a dns entry that points to the ULA) then no matter what happens in terms of renumbering, they can always contact the proxy and the proxy can always talk to the outside world.
It won't keep your email connections or skype etc from breaking, but it does mitigate a lot of hassle, and also adds filtering, prioritization, and bandwidth management features that can be useful.
It doesn't require cooperation from the ISP, Hurricane Electric in my case, since the source-specific default routes causes the traffic to exit at the router which has received the prefix delegation in question from the ISP.
If you have access to static IPv6 prefixes then assigning them to routers isn't hard. You can assign a subnet of each prefix in one or more ip6prefix options. (It's also possible to assign the whole prefix to several routers but you have to make sure that there is no conflicts in the IPv6 assignment hints.)
Source-Specific Routing in Babel is a work in progress. There exist a draft, but it's expired. But it seems to work well in the reference implementation.
