IPv6 with DHCP6 on top of PPPoE and VLAN

[franco]

In general the development version is reached by switching the "release type" in the system: firmware: settings tab. After saving all you need to do is check and install the updates. Doing this after 24.7.1 is out will allow you to reapply the POC patch and on the next development update (which is always coupled with 24.7.x, sparsely out of sync for valid reasons).

I plan to merge a couple of things to subsequent 24.7.x releases related to these changes which will break the full patch apply. This is to ensure the compatible bits are not breaking and the final difference will be as minimal as it can be (still larger perhaps but for audits that's better than larger than large).


Cheers,
Franco

[pataps]

Hah, I haven't thought it's going to be that easy! I'll be careful with patching from now on, I suppose I will definitely test out the development version.

I appreciate your effort Franco, best of luck!

[csutcliff]

@csutcliff did you use IPv4 connectivity setting? It's gone from the GUI but I suppose you did because you said it keeps working.

Since when did you start using this anyway? 24.1.9?


Cheers,
Franco

Yes I was previously using this setting, I think since March 2021 when I first got ipv6 enabled with a previous ISP. At least

Code: [Select]

<dhcp6usev4iface>1</dhcp6usev4iface> is present in my oldest backup from June 2022.

[doktornotor]

The patch should apply to 24.7.1 as well, but the reboot might get in the way.

Sort of missing ability to automatically attempt to apply locally saved patches...

[franco]

Something could be scripted with opnsense-patch -N and rc.syshook but there is no sense of ordering in commit hashes and the local cache is probably polluted with all sorts of old cruft that stops applying sooner than later when lines overlap.

I also don't know what the correct patch point is... boot is silly because the patches may already be applied, older patches will fail for the right reasons. Firmware updates kind of, but we don't know which component got updated so we don't know which patches need to be reapplied.

Most patches are moved quickly to stable releases. For me personally opnsense-patch works within the same boundaries as opnsense-update in the sense that the next update will undo patches/custom packages which are mostly for testing anyway.


Cheers,
Franco

[doktornotor]

I also don't know what the correct patch point is... boot is silly because the patches may already be applied, older patches will fail for the right reasons. Firmware updates kind of, but we don't know which component got updated so we don't know which patches need to be reapplied.

In XigmaNAS you can run a custom script on updates just before system the system is rebooted after upgrade, that's a more generic hack (but the update process is completely different there, not really applicable here).

The syshooks - any hint how to run some custom code before the networking stuff gets started (and fails to do its job in this case)? I.e. - not rc.local style as that runs too late... some early boot phase. 🤔

[franco]

There is https://docs.opnsense.org/development/backend/autorun.html with early (before network and PHP), update (post-update minor version) and upgrade (pre-upgrade major version).


Cheers,
Franco

[doktornotor]

There is https://docs.opnsense.org/development/backend/autorun.html with early (before network and PHP), update (post-update minor version) and upgrade (pre-upgrade major version).

Nice, thanks! 

[carbas]

Hi,

Sorry for going silent yesterday.
I'm happy to report that your changes worked for me flawlessly. I got the prefix from DHCPv6 over PPPoE connection.
After that I was able to setup GIF tunnel with AFTR and make IPv4 traffic going through it.
What I noticed, DHCP6c doesn't support aftr-name (option 64) defined in RFC 6334 and doesn't know what to do with it when recived from server
Thank you, Franco, for all your great work 

[franco]

> What I noticed, DHCP6c doesn't support aftr-name (option 64) defined in RFC 6334 and doesn't know what to do with it when recived from server

Can you create a ticket for me? https://github.com/opnsense/dhcp6c


Cheers,
Franco

[carbas]

Can you create a ticket for me? https://github.com/opnsense/dhcp6c

Sure: https://github.com/opnsense/dhcp6c/issues/38
I hope it's good-enough 

[franco]

Looks good, thanks. For now we should try to allow this to be exported into the environment and/or add a log message for it with the value. About further integration I'm not sure as this gets way more tricky.


Cheers,
Franco

[carbas]

Looks good, thanks. For now we should try to allow this to be exported into the environment and/or add a log message for it with the value. About further integration I'm not sure as this gets way more tricky.

Sure, no hurry. I got around it by manually creating the GIF tunnel. For now i got the AFTR name by intercepting communication between my ONT and CPE i got from ISP And AFAIK my ISP does not change the AFTR adresses so I'm good with manual setup (however there are different AFTR's for every region of the country, if you know the address you can make yourself a poor-man's VPN service for IPv4 out of it - ISP does not prevent you from tunneling to other AFTR's  )