IPv6, dynamic prefixes: NPTv6 an option?

Installing and Using OpenWrt Network and Wireless Configuration
1

Glorious IPv6. If only.

My ISP changes my prefix upon reconnection. Which causes me trouble in two areas:
(1) DNS for my LAN hosts
(2) stateful firewall config for incoming connections, in the absence of NAT66.

(1) can be tackled by configuring all clients to use DHCPv6 w/ very short lease times. Like 5 minutes or so. It's not perfect but maybe tolerable. In the meantime their global addresses are stale though, as are the corresponding DNS entries.

(2) is also somewhat problematic. I'd have to make the current prefix part of my firewall configuration and reconfigure on each prefix change. Assumed I wanted to open up ports really only for the hosts that are meant to receive traffic.

Both approaches are not optimal, so I've been looking for alternatives. NPTv6 seems to be a nice one, like it's used in multihomed setups, with pure ULA addressing on LAN and prefix translation on the router. OpenWrt doesn't seem to be quite ready for this though. Maybe also b/c the netfilter DNPT/SNPT targets don't work w/ connection tracking. So there goes the stateful firewall if I were to use those.

Maybe some of you guys found an elegant way out of this dynamic prefix mess? I mean, I'm really beginning to throughly appreciate my old, trusty, reliable and easily configurable IPv4 NAT.

Thanks, R.

1 Like
2

Place DNS settings here in LAN:

Screenshot%20from%202018-08-21%2015-22-25

Your IPv6 firewall should be on by default. There are few traffic rules for IPv6 by default. It should already be firewalled...are you trying to open something (i.e. a web server)?

1 Like
3

Thanks for your input, @lleachii.

A misunderstanding. It's about the DNS entries/names&addresses of my LAN hosts, as they are registered w/ dnsmasq on OpenWrt, by means of DHCPv6 leases. Like the host name of my media server. In the absence of ULA the only address registered is the global one. And that one would be wrong in the case of a global prefix change, up to the next lease renew. Pretty ugly, no?

Yes. VoIP for example, which now is the only way in which I can do telephone w/ my carrier. Good old analogue land lines are gone around here. Right now it works w/ IPv4. But if I were to switch to IPv6 I'd have to configure my firewall accordingly. And this is where dynamic prefixes become a source of trouble, if I want to allow incoming connections only for the precise hosts they are meant for.

1 Like
4

I'm almost certain that servers specify static addressing (or rather, a static IP per service) under IPv6.

In your case, I open the ports to the subnet.

Your only solution would to be statically address the WAN and the VoIP endpoint. If it's a server...you have issues.

As an alternative, you might look into SIP connection tracking.

This thread describes a user's success by turning it off with the value of 0. You would test setting yours to the value of 1.

If it is an inbound service, you may consider a DDNS provider to produce an AAAA record as the subnet updates.

1 Like
5

Well, that's the problem, isn't it. With dynamic prefixes there is no static address.

Imagine my VoIP host has the stable interface identifier ::1 and the prefix is 2003:abcd::/64. The "static" IPv6 address of the host then is 2003:abcd::1/64. Now my modem drops the connection and is back up after a minute. And my ISP now gives me the prefix 2003:1234::/64. Suddenly the address now is 2003:1234::1/64. And that does not look very static, does it.

On top of that, the host itself doesn't know that this is its new address, unless it's configured for SLAAC. But then there's no DNS entry for it on my OpenWrt router, a name under which my phones could reach the host. Unless it's configured for DHCPv6, too. Where even then the (local) DNS entry doesn't update until the next lease renew. Which by the way also means that I have to configure the interface identifier ::1 to be picked up by SLAAC on the host, too, with the aid of an interface token. And finally, the firewall needs to pick up the new address for incoming traffic.

So there's a bunch of issues which I myself, frankly, would consider a gigantic crap fest deluxe. Because the whole IPv6 theory just isn't made to cope well w/ dynamic prefixes. While good, old IPv4 NAT doesn't care the slightest when the dynamic Internet address changes.

I could of course do NAT66 and forget about the whole mess. But then I'd have to listen to all the "ahs" and "ohs" for years to come, about how my setup isn't according to gospel. But then, also, NPTv6 would be another, in theory at least much cleaner possibility. Portable, too, if I ever were to switch to another ISP bringing another set of peculiarities w/ it. Because NPTv6 would isolate the nets on the router, like NAT, but in a 1-to-1, bijective way. That's why my inquiry, if anyone had any experience w/ that.

SIP connection tracking is an entirely separate issue, by the way. I don't need that because the ports I need to open are well documented. Works flawlessly w/ IPv4.

2 Likes
6

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.

https://tools.ietf.org/html/rfc7084

The IPv6 CE router MUST support Stateless Address Autoconfiguration (SLAAC) [RFC4862].

Also, I was going to suggest a prefix hint, but the prefix issued by the ISP would still change.

In your situation, that's what you may need. I'm not sure how that would work with a SIP server, though. This simply is the design of IPv6.

Also, you could setup a Tunnelbroker.net account, then you'd have static IPs!

Yes, but you cannot open them on a single, dynamic IPv6 address...in addition, they don't close after done.

1 Like
7

Have you tried ip6neigh?

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.

1 Like
8

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?

2 Likes
9

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)

4 Likes
10

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.

2 Likes
11

Ok, minor update from Dr. Frankenstein's ill-lit basement lab.

To not propagate global prefixes to LAN do this

/etc/config/network:
config interface 'lan'
         ...
        list ip6class 'local'   
        option ip6assign '60'

/etc/config/dhcp:
config dhcp 'lan'
        ....
        option dhcpv6 'server'
        option ra 'server'
        option ra_management '1'
        option ra_default '1'

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

odhcp6c -s /lib/netifd/dhcpv6.script -P0 -t120 eth0

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.

EDIT:
also, ding dang:

2 Likes
12

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.

13

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.

1 Like
14

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?)

1 Like
15

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.

1 Like
16

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.

1 Like
17

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.

1 Like
18

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.

2 Likes
19

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 :wink:

1 Like
20

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.

1 Like