Tracked IPv6 LAN goes down when WAN goes down
-
Same happens to me but I use static ipv6 on lans and ia-pd method on pppoe..
Of course that will get around the problem, but if the prefix changes, you will have to manually correct the gateway address and dhcpv6 ranges. It would be nice if pfsense would do this itself. (OP, sorry for jacking your thread.)
-
@kpa:
@virgiliomi:
This is probably off topic, but I've often wondered why ipv6 on the lan goes down when the wan goes down. Is there a reason why the lan can't stay operational while the wan is down? (I mean a reason other than because it's doing what it's designed to do.)
Is your LAN tracking your WAN for its prefix to use? If so, that's why. :) LAN relies on WAN for IPv6 settings. WAN goes down, LAN loses its IPv6 configuration.
I understand that, but just because the wan is having a temporary outage, it doesn't mean the prefix is no longer valid. I don't see why pfsense could not continue to offer lan routing.
There is no way to know if the outage is temporary or not (unless you can hook up a crystal ball to your system) and so the only reasonable assumption is that the prefixes delegated are invalid.
For situations where the prefix is reasonably static, I think it's more reasonable to keep using the existing prefix unless it gets changed by the isp. If the wan connection goes down and comes back up with the same prefix, no problem. If the wan comes back and the prefix has changed, renew the leases.
-
If the lease is lost, i.e. not renewed then it's dhcp6c that removes the prefix and any assigned address on the WAN. I suppose it's possible to prevent it from doing that, but it would break all the rules, I'm pretty sure RFC states that any prefix or addresses assigned by dhcp should be removed on failure, but I'm open to correction on that.
-
Well, think of it this way. The delegated prefixes that you get from the track interface are exactly the same kind of configuration data you get from the standard IPv4 DHCP, for example DNS forwarders, default gateway, even static routes if your DHCP client supports that. The delegated prefixes are just used slightly differently as prefixes for LAN type networks. Are you going to say that when your WAN IPv4 DHCP lease expires you could still treat the cached configuration data as valid? I'm sure you agree that you can't.
For what it's worth I consider the track interface system a bogus one. The IPv6 address space is so large that every ISP could assign you a personal static /48 for life.
-
@kpa:
.
For what it's worth I consider the track interface system a bogus one. The IPv6 address space is so large that every ISP could assign you a personal static /48 for life.
They could and they should… but they don't. :)
One of the reasons I am now in the process of changing ISP to one that gives me a static /48. My current ISP issues a 'sticky' /56 IPv6 prefix, and although I hold the DUID and no-release is set it can and has changed when they reset thier BNG; this leaves me having to change a few DNS pointers, nothing major falls over though.
-
Are you going to say that when your WAN IPv4 DHCP lease expires you could still treat the cached configuration data as valid?
I don't think a temporary failure is the same as an expired lease. On IPv4, a device "owns" the address until the lease expires, regardless of what happens to the WAN connection. There is no way to revoke it before the lease expires. With IPv6, there's the DUID, to maintain the same address block and it also provides local addresses for a lease time. When the WAN fails, it may still be desirable to maintain local networking, until the WAN comes back up. Should it come up with a different LAN prefix, then the router will issue an RA with that prefix, causing all hosts to update. So, assuming the ISP is properly handling the DUID the same prefix will be used before and after the interruption. In the mean time, there's no problem with using the old prefix on the local LAN.
-
I take your point, dhcp6c exits on WAN down, this is the way pfSense is designed. It woulld take a little bit of work to keep it alive and just send a SIGHUP on WAN up, but it should be possible.
-
It woulld take a little bit of work to keep it alive and just send a SIGHUP on WAN up, but it should be possible.
It already does that. Prior to a recent bug fix, I would wind up with a different prefix if I did nothing more than disconnect & reconnect the WAN cable. So, it already updates when the connection is restored. It just shouldn't do anything on the LAN, until the WAN is restored. At that point, is should just send an RA, as I believe it already does.
I just did some testing. I unplugged my WAN cable for a few minutes. Prior to unplugging, the RAs showed a router life time of 30 or 60 seconds. After unplugging, the life time dropped to 0, but I still had IPv6 addresses. After reconnecting, the life time returned to 30 or 60 seconds. I didn't see anything that would cause the address to drop. This is with pfSense 2.3.3-RELEASE-p1 (amd64). I don't know if older versions do things differently.
-
I'm talking 2.4.
-
Are you going to say that when your WAN IPv4 DHCP lease expires you could still treat the cached configuration data as valid?
I don't think a temporary failure is the same as an expired lease. On IPv4, a device "owns" the address until the lease expires, regardless of what happens to the WAN connection. There is no way to revoke it before the lease expires. With IPv6, there's the DUID, to maintain the same address block and it also provides local addresses for a lease time. When the WAN fails, it may still be desirable to maintain local networking, until the WAN comes back up. Should it come up with a different LAN prefix, then the router will issue an RA with that prefix, causing all hosts to update. So, assuming the ISP is properly handling the DUID the same prefix will be used before and after the interruption. In the mean time, there's no problem with using the old prefix on the local LAN.
I agree 100%.
-
I'm talking 2.4.
If it does that in 2.4, but not 2.3.3, then I'd consider it a bug in 2.4. There is no reason to kill IPv6 when the WAN is down. That certainly doesn't happen with IPv4.
Fire up Wireshark and watch what happens when you disconnect the WAN. I'd like to see what it's doing. You can configure Wireshark to filter based on ICMPv6 and router link-local IPv6 address to limit the garbage.
-
The default route should be dropped immediately on WAN flap. The address should stay until the timers expire. This is the functionality IPv6 is designed for.
-
The default route should be dropped immediately on WAN flap
That's what my test showed, when the router life time dropped to 0. Perhaps someone can try a similar test with 2.4.
