Upgrade to 22.1.4_1 no IPv6 connectivity

[franco]

Still trying to think of how to make this code more resilient when PPPoE is being used in conjunction with DHCPv6, but I don't think there isn't any uncertainty here:

ppp-linkup.sh gets called for IPv6 setup (due piggybacking on the IPv4 PPPoE setup actually) before the real IPv6 configuration code can run rtsold which on 22.1.4 cleared the router file written by linkup script a fraction of a second before.

So what worries me is that PPPoE IPv4 connectivity also sets up IPv6 connectivity unrelated to actual IPv6 GUI interface configuration. Sure, there is no other way to obtain a prefix, but the nameserver file could clash as well (if the ISP screws up their end that is).


Cheers,
Franco

[i81b4u]

But that's because of a PPPoE "feature" that allows IPv6 information to be requested using IPv4 connectivity. That's a setting that has to be set manually. So it seems to me that there has to be a way to solve this in an elegant way, right?

[franco]

Forgive my ignorance: which setting is that exactly?


Thanks,
Franco

[i81b4u]

Use IPv4 connectivity? Which after checking seems to be a DHCPv6 client configuration thing (or is it still PPPoE?).

The RFC that talks about it is: https://www.rfc-editor.org/rfc/rfc4241.html if I'm not mistaken.

[franco]

No, use IPv4 connectivity is for moving dhcp6c on top of PPPoE device instead of attached network port that PPPoE runs on. What I mean here is that mpd5 daemon PPPoE connection establishment handles IPv4 and IPv6 although it's supposed to be a pure IPv4 connectivity thing.

You can check this by disabling IPv6 mode on WAN and rebooting... there should still be a /tmp/pppoe0_routerv6 file there?


Cheers,
Franco

[i81b4u]

Correct. So that info is not derived using dhcpv6. Looking at figure 2 used in rfc 4241 is it possible the info comes from IPV6CP? Anyway. I'll try and do some more investigating tonight. Can´t interrupt my internet connection too often because of grumpy customers (a.k.a. family) 

[franco]

> Looking at figure 2 used in rfc 4241 is it possible the info comes from IPV6CP?

Yes I think so. So with PPPoE we have two mechanisms to provide name servers and router address. In theory the ISP should match both if he sends them through multiple channels at once, but if that's not the case it's no fun for the customer.

Further, I believe that this could explain the reports over the years regarding endless "reload" cycles on WAN with IPv6 involved, because

https://github.com/opnsense/core/blob/master/src/opnsense/scripts/interfaces/ppp-linkup.sh#L28

and

https://github.com/opnsense/core/blob/master/src/etc/inc/interfaces.inc#L2773

will both execute a WAN-type reload once they receive their information as closely in time as possible even though it's not required.


Cheers,
Franco

[franco]

PS: it might be that we prevent these type of loops since 22.1 via https://github.com/opnsense/core/commit/028302ae74c5bb86 where we avoid removing "cache" files for IP registration inside WAN reload scripts so that the script will always detect it was running if connectivity is still up. Previously I think that the file was cleared and it went into a loop of "oh this address is new let's reload" going to "oh this address is new reload" etc.

[franco]

And maybe one more thought... https://github.com/opnsense/core/commit/01913bf7125ec this prevents a full reload on address removal mimicking what PPPoE always did which seems to be more reasonable (or address is gone which we don't care about but the DNS information needs to be cleared).


Cheers,
Franco

[i81b4u]

That's a lot to take in, but I'll dive into it when I have some "spare" time. It's too interesting to let go. Thanks a lot. i really appreciate it. Will report back in a while.

Best regards.

[dinguz]

I, too, have a PPPoE internet connection, and I'm having the same issues with IPV6 sometimes working and sometimes not. I noticed that the ssh/terminal screen shows different info than the GUI dashboard, as can be seen in the screenshots. Could this be related?

[i81b4u]

Hi dinguz,

The fe80-address is a link local address (https://en.wikipedia.org/wiki/Link-local_address). Nothing wrong with that  .

Best regards.

[dinguz]

The difference I'm observing is that WAN_INET has 2a02:a468:4bba:0:4262:31ff:fe00:4d05/64 in one view, and fe80::4262:31ff:fe00:4d05 in the other. Or is this not an issue?

[staticznld]

The FE80 address is the gateway for IPv6.
I think the info in the SSH screenshot is wrong, because the Preifx ID "0" is selected for LAN and not WAN.

[i81b4u]

And both addresses can be valid although they have a different scope. To elaborate on that ... someone on the internet could ping your "normal" IPv6 address even when having no direct connection where the link local address can only be used in situations where there is a direct connection (Layer-2) between devices.

As can be seen in your screenshots, 4262:31ff:fe00:4d05 is the host part of the address and that it's the same for both the link local fe80:: and the global 2a02:a468:4bba:: or 2a02:a468:4bba:0 network address.

Code: [Select]

i81b4u@OPNsense:~ % ping -c 5 2a02:a468:4bba::4262:31ff:fe00:4d05
PING6(56=40+8+8 bytes) [OPNsense_IPv6] --> 2a02:a468:4bba:0:4262:31ff:fe00:4d05
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=0 hlim=61 time=5.547 ms
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=1 hlim=61 time=5.493 ms
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=2 hlim=61 time=5.481 ms
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=3 hlim=61 time=5.518 ms
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=4 hlim=61 time=5.524 ms

--- 2a02:a468:4bba::4262:31ff:fe00:4d05 ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 5.481/5.513/5.547/0.024 ms