Tracked IPv6 LAN goes down when WAN goes down

bimmerdriver

@virgiliomi:

@bimmerdriver:

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.

kpa

@bimmerdriver:

@virgiliomi:

@bimmerdriver:

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.

maverick_slo

Same happens to me but I use static ipv6 on lans and ia-pd method on pppoe..

twitched

IMO the best route would be to use ULAs https://tools.ietf.org/html/rfc4193 in addition to the GUAs assigned by the ISP prefix. pfSense could create its own Global ID advertise it via radvd. SLAAC clients would then create their own non-temporary addresses on this separate prefix that could be added to DNS, or DHCPv6 could hand them out. The whole scheme would be completely independent of and parallel to the WAN.

I just tried it out using the command line. First, I went to http://unique-local-ipv6.com/ and got a random /48 ULA prefix, then assigned an address to the LAN interface on pfSense:

ifconfig igb1 inet6 fdd6:3807:b7da::1/64 add

Then I added the following to /var/etc/radvd.conf.


	prefix fdd6:3807:b7da::/64 {
		DeprecatePrefix on;
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr on;
		AdvValidLifetime 86400;
		AdvPreferredLifetime 14400;
	};

After restarting radvd, my mac created two ULAs, one that stays constant and a temporary. These are in addition to the GUAs it already had (2001:xxxx…)


	inet6 2001:xxxx:xxxx:xxxx:1855:3d4c:2058:2c7c prefixlen 64 autoconf secured 
	inet6 2001:xxxx:xxxx:xxxx:1533:b4c1:fc82:ebdc prefixlen 64 autoconf temporary	
        inet6 fdd6:3807:b7da::75:4bf4:c696:aabe prefixlen 64 autoconf secured 
	inet6 fdd6:3807:b7da::d872:6e70:7d96:bc47 prefixlen 64 autoconf temporary

And they can now speak ipv6 over these addresses rather than those derived from the unstable prefix from the ISP or the link-local addresses that require the interface qualifier. After adding a rule to LAN to allow the ULA prefix, I was able to use```
https://[fdd6:3807:b7da::1]/


Of course, all of this goes away once pfSense rewrites /var/etc/radvd.conf and restarts radvd.  It would be really nice to have a feature that generated a ULA prefix (called, for some reason, a Global ID), assigned a static ULA to LAN from that prefix, and added the prefix to RA and DHCPv6.  This would solve at least the following issues:

*   The ability to put static IPv6 entries in DNS

*   The ability to put static IPv6 routes in VPNs for accessing your local network remotely

After writing the above, I found [https://redmine.pfsense.org/issues/5999](https://redmine.pfsense.org/issues/5999), which shows that you can sort of do the above with virtual IPs, but it still doesn't survive a reboot.

bimmerdriver

@maverick_slo:

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

bimmerdriver

@kpa:

@bimmerdriver:

@virgiliomi:

@bimmerdriver:

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.

kpa

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.

JKnott

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.

JKnott

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.

bimmerdriver

@JKnott:

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%.

JKnott

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.

severach

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.

JKnott

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.