New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

interfaces: restructure PPP to allow complex IPv6-only deployments and remove "Use IPv4 connectivity" by making it the default #7446

Open

7 of 8 tasks

fichtner opened this issue May 7, 2024 · 5 comments

Assignees

Labels

feature roadmap

Milestone

Member

fichtner commented May 7, 2024 •

edited

Loading

Important notices

Our forum is located at https://forum.opnsense.org , please consider joining discussions there in stead of using GitHub for these matters.

Before you ask a new question, we ask you kindly to acknowledge the following:

I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

TODO:

The ironic truth about the option is that "Use IPv4 connectivity" opt-in is that the opt-in is actually the default so the default gets inverted, but only when PPPoE is involved in the first place. It would be nice to restrict this to PPPoE and invert or migrate the current default in order to make the most sense and avoid a bit of code (and feature taint having the option always available causing undefined behaviour on non-PPPoE connections).
While here the side quest is to restructure PPP to be address family agnostic and allow for things like IPv6-only DHCPv6 over PPPoE which isn't possible at the moment.
Restructure the PPP code to be IP family agnostic (will backport to 24.7.x)
Prevent selection of wrong IPv4 modes for PPP devices in interface settings (will backport to 24.7.x)
Remove edit of PPP devices in interface settings.
Update the documentation to explain PPPoE device creation via PPP device page

fichtner added the cleanup label

fichtner added this to the 24.7 milestone

fichtner self-assigned this

fichtner modified the milestones: 24.7, 25.1

fichtner added feature and removed cleanup labels

fichtner added a commit that referenced this issue


          interfaces: decouple starting PPP from configured IP modes #7446

84a6d3a

We may or may not want to run PPP based on the sole fact that
the interface is assigned and as a PPP configuration.  The
analysis of what IP modes we need belongs to the actual config
file.

PR: https://forum.opnsense.org/index.php?topic=42008.0

fichtner added a commit that referenced this issue


          interfaces: hide away the IPv6 connectivity flag #7446

1de16d1

I believe the best course of action is to make it the default
and remove the option.

If people want to use the hardware interface and PPPoE at the
same time can simply assign a second interface for the hardware.

This will break fragile IPv6 setups, but is much better in the
long run and will allow further simplification.

fichtner added a commit that referenced this issue


          interfaces: replace "IPv4 connectivity" by defaulting to it #7446

88f1ec6

The bound logic is extended to be able to latch on to IPv6 events
later on by disabling IPv4.  It's all a bit complicated.  We may
consider moving these trickeries to the PPPoE uplink scripts where
they appear to belong anyway.

fichtner added a commit that referenced this issue


          interfaces: check if bound to IPv6 PPP and trigger reconfiguration #7446

7c313cf

fichtner added a commit that referenced this issue


          interfaces: move PPP-related IPv6 behaviour into linkup #7446

86c10dc

fichtner added a commit that referenced this issue


          interfaces: move PPP-related IPv6 behaviour into linkup #7446

b04f282

fichtner added a commit that referenced this issue


          interfaces: universal PPP POC #7446

1c7e538

PR: https://forum.opnsense.org/index.php?topic=42008.0

fichtner added a commit that referenced this issue


          interfaces: univeral PPP POC #7446

e6f0ac1

We may or may not want to run PPP based on the sole fact that
the interface is assigned and as a PPP configuration.  The
analysis of what IP modes we need belongs to the actual config
file.

PR: https://forum.opnsense.org/index.php?topic=42008.0

fichtner added a commit that referenced this issue


          interfaces: decouple starting PPP from configured IP modes #7446

3a41fdc

We may or may not want to run PPP based on the sole fact that
the interface is assigned and as a PPP configuration.  The
analysis of what IP modes we need belongs to the actual config
file.

PR: https://forum.opnsense.org/index.php?topic=42008.0

fichtner added a commit that referenced this issue


          interfaces: hide away the IPv6 connectivity flag #7446

36b27cd

I believe the best course of action is to make it the default
and remove the option.

If people want to use the hardware interface and PPPoE at the
same time can simply assign a second interface for the hardware.

This will break fragile IPv6 setups, but is much better in the
long run and will allow further simplification.

fichtner added a commit that referenced this issue


          interfaces: replace "IPv4 connectivity" by defaulting to it #7446

8c3f936

The bound logic is extended to be able to latch on to IPv6 events
later on by disabling IPv4.  It's all a bit complicated.  We may
consider moving these trickeries to the PPPoE uplink scripts where
they appear to belong anyway.

fichtner added a commit that referenced this issue


          interfaces: check if bound to IPv6 PPP and trigger reconfiguration #7446

f5ff464

fichtner added a commit that referenced this issue


          interfaces: move PPP-related IPv6 behaviour into linkup #7446

9c2f26f

fichtner added a commit that referenced this issue


          interfaces: decouple starting PPP from configured IP modes #7446

9e5433b

We may or may not want to run PPP based on the sole fact that
the interface is assigned and as a PPP configuration.  The
analysis of what IP modes we need belongs to the actual config
file.

PR: https://forum.opnsense.org/index.php?topic=42008.0

fichtner added a commit that referenced this issue


          interfaces: hide away the IPv6 connectivity flag #7446

I believe the best course of action is to make it the default
and remove the option.

If people want to use the hardware interface and PPPoE at the
same time can simply assign a second interface for the hardware.

This will break fragile IPv6 setups, but is much better in the
long run and will allow further simplification.

fichtner added a commit that referenced this issue


          interfaces: replace "IPv4 connectivity" by defaulting to it #7446

a3fcd45

The bound logic is extended to be able to latch on to IPv6 events
later on by disabling IPv4.  It's all a bit complicated.  We may
consider moving these trickeries to the PPPoE uplink scripts where
they appear to belong anyway.

fichtner added a commit that referenced this issue


          interfaces: check if bound to IPv6 PPP and trigger reconfiguration #7446

7e39131

fichtner added a commit that referenced this issue


          interfaces: move PPP-related IPv6 behaviour into linkup #7446

456786b

fichtner added a commit that referenced this issue


          interfaces: decouple starting PPP from configured IP modes #7446

140a62b

We may or may not want to run PPP based on the sole fact that
the interface is assigned and as a PPP configuration.  The
analysis of what IP modes we need belongs to the actual config
file.

PR: https://forum.opnsense.org/index.php?topic=42008.0

fichtner added a commit that referenced this issue


          interfaces: hide away the IPv6 connectivity flag #7446

9e8ce8a

I believe the best course of action is to make it the default
and remove the option.

If people want to use the hardware interface and PPPoE at the
same time can simply assign a second interface for the hardware.

This will break fragile IPv6 setups, but is much better in the
long run and will allow further simplification.

fichtner added a commit that referenced this issue


          interfaces: replace "IPv4 connectivity" by defaulting to it #7446

1ce50f2

The bound logic is extended to be able to latch on to IPv6 events
later on by disabling IPv4.  It's all a bit complicated.  We may
consider moving these trickeries to the PPPoE uplink scripts where
they appear to belong anyway.

fichtner added a commit that referenced this issue


          interfaces: check if bound to IPv6 PPP and trigger reconfiguration #7446

17a7dd7

fichtner added a commit that referenced this issue


          interfaces: move PPP-related IPv6 behaviour into linkup #7446

2d93765

fichtner added a commit that referenced this issue


          interfaces: decouple starting PPP from configured IP modes #7446

4b04a11

PR: https://forum.opnsense.org/index.php?topic=42008.0

fichtner changed the title ~~interfaces: improve the behaviour of "Use IPv4 connectivity"~~ interfaces: restructure PPP to allow complex IPv6-only deployments and remove "Use IPv4 connectivity" by making it the default

fichtner added a commit that referenced this issue


          interfaces: move IPv6 connectivity to a separate script for #7446

3a9f988

A number of cleanup and non-invasive restructuring efforts around
the way IPv6-based connectivity is handled in PPP environments so
that we can later use it allow IPv6-only deployments which takes
a different path based on whether PPP is allowed to do IPv4 (with
or without IPv6) or IPv6 without IPv4.

In theory this would also allow us to run DHCP over PPP, but it's
much outside the scope of the current effort and certainly needs
someone with that type of setup...  ;)

fichtner added a commit that referenced this issue


          interfaces: decouple starting PPP from configured IP modes #7446

805120e

PR: https://forum.opnsense.org/index.php?topic=42008.0

fichtner added a commit that referenced this issue


          interfaces: transform this a bit more #7446

d35a5f3

Ideally we should really handle an array of parent hardware
devices here.  In some cases IPv6 device is missed as well.
And later on the code will not check if this was a device
node for a modem so wrapping the hardware stuff into a function
for iteration is the way to go.

fichtner added a commit that referenced this issue


          interfaces: move IPv6 connectivity to a separate script for #7446

63fed10

A number of cleanup and non-invasive restructuring efforts around
the way IPv6-based connectivity is handled in PPP environments so
that we can later use it allow IPv6-only deployments which takes
a different path based on whether PPP is allowed to do IPv4 (with
or without IPv6) or IPv6 without IPv4.

In theory this would also allow us to run DHCP over PPP, but it's
much outside the scope of the current effort and certainly needs
someone with that type of setup...  ;)

fichtner added a commit that referenced this issue


          interfaces: decouple PPP configure/reset from IPv4/IPv6 modes #7446

182bab3

fichtner added a commit that referenced this issue


          interfaces: light scrubbing for interfaces page #7446

37efb1f

We want to avoid modifying ports for the PPP devices and
rearrange the type feed slightly.  Most of the PHP warnings
on this page relate to PPP trickery that will go away.

Next step will be only offering the matching IPv4/6 types.

Fix one valid warning while here.

fichtner added a commit that referenced this issue


          interfaces: lock down PPP modes #7446

b2d9372

This change reflects what PPP is actually capable off under
the hood and no functional changes intended.

You could still post a different type but since the goal is
to get rid of posting anything related to PPP this will make
it easier to judge if people actually used this.

fichtner added a commit that referenced this issue


          interfaces: place some exceptions #7446

23c9a95

As discussed with @AdSchellevis make this a reality for
PPP/PPTP/L2TP, but leave PPPoE as is for now.  This
allows inline creation of PPPoE to remain for the time
being.

Inline removal, OTOH, is removed hereby since buggy.

fichtner added a commit that referenced this issue


          interfaces: lock down PPP modes when editing interfaces #7446

1af766f

Keep the PPPoE trampoline code in the settings page, but otherwise
restrict and lock PPP in place meaning no other inline creation,
switching or moving back to raw types (which is buggy anyway).

The PPP device creation and edit page is responsible for creating
devices first and foremost and should be used in all the PPP cases
eventually.  This will make the interfaces page much easier to
convert to MVC/API when the time arrives.

PPPoE exceptions will probably be removed in 25.1 as well but it
needs a documentation sweep in order to cope with that new reality.

(cherry picked from commit 37efb1f)
(cherry picked from commit b2d9372)
(cherry picked from commit 23c9a95)
(cherry picked from commit 6e13590)

fichtner added a commit that referenced this issue


          interfaces: move IPv6 connectivity to a separate script for #7446

A number of cleanup and non-invasive restructuring efforts around
the way IPv6-based connectivity is handled in PPP environments so
that we can later use it allow IPv6-only deployments which takes
a different path based on whether PPP is allowed to do IPv4 (with
or without IPv6) or IPv6 without IPv4.

In theory this would also allow us to run DHCP over PPP, but it's
much outside the scope of the current effort and certainly needs
someone with that type of setup...  ;)

fichtner added a commit that referenced this issue


          interfaces: decouple PPP configure/reset from IPv4/IPv6 modes #7446

Contributor

doktornotor commented Aug 25, 2024 •

edited

Loading

Ok, appears there was a user using 6rd over PPPoE... This b2d9372 did not make him happy...

https://forum.opnsense.org/index.php?topic=42081.msg209929#msg209929

Contributor

doktornotor commented Aug 25, 2024

On another note - while doing all these PPP cleanups, just found this in the backlog. Those impossible to work options are still there.

jfieber commented Aug 25, 2024

Ok, appears there was a user using 6rd over PPPoE... This b2d9372 did not make him happy...

To be completely clear, I’m far more unhappy with the ISP (CenturyLink) on this issue than with opnsense. It would be helpful if the removal was called out in the 24.7.2 release notes, and a statement of if there is a plan to restore it in a future release.

The other facet is that the previous stf device configuration under the hood mostly survives the upgrade process, but doesn’t work quite right (I didn’t spend much time digging into why before reverting to 24.1) and has no UI I could find to fix it. That is a poor experience.

Contributor

doktornotor commented Aug 25, 2024

This 6rd-over-PPPoE implementation would be my favorite if there is a "worst ways to deploy IPv6" competition among ISPs.

The option is trivial to restore, I'd suppose no call was made because no one expected such a thing to be in use.

fichtner added a commit that referenced this issue


          interfaces: keep 24.7 backwards compat by allowing 6rd and 6to4 on PPP …

947e61b

…#7446

PR: https://forum.opnsense.org/index.php?topic=42081.msg209929#msg209929

Member Author

fichtner commented Aug 26, 2024

@jfieber hello, thanks for reaching out. I wrote the bulk in the forum, see https://forum.opnsense.org/index.php?topic=42081.msg209986#msg209986

For anyone else with that issue at the moment use 947e61b

# opnsense-patch 947e61b

It would be best to bring this into 24.7.3 as well.

The implications for the setup going forward are in the forum, but since is mostly a documentation effort done before releasing 25.1 I'll refrain from adding that to the current discussion here.

fichtner added a commit that referenced this issue


          interfaces: move IPv6 connectivity to a separate script for #7446

6b28dae

A number of cleanup and non-invasive restructuring efforts around
the way IPv6-based connectivity is handled in PPP environments so
that we can later use it allow IPv6-only deployments which takes
a different path based on whether PPP is allowed to do IPv4 (with
or without IPv6) or IPv6 without IPv4.

In theory this would also allow us to run DHCP over PPP, but it's
much outside the scope of the current effort and certainly needs
someone with that type of setup...  ;)

While here make sure the IPv4 connectivity abuse in DHCP scenarios
still somewhat works at least for 24.7.x.  We don't want it unless
we have a strict need for it or may want to come up with a simpler
approach.

fichtner added a commit that referenced this issue


          interfaces: decouple PPP configure/reset from IPv4/IPv6 modes #7446

82ea39b

fichtner added a commit that referenced this issue


          interfaces: move IPv6 connectivity to a separate script for #7446

ff32a81

A number of cleanup and non-invasive restructuring efforts around
the way IPv6-based connectivity is handled in PPP environments so
that we can later use it allow IPv6-only deployments which takes
a different path based on whether PPP is allowed to do IPv4 (with
or without IPv6) or IPv6 without IPv4.

In theory this would also allow us to run DHCP over PPP, but it's
much outside the scope of the current effort and certainly needs
someone with that type of setup...  ;)

While here make sure the IPv4 connectivity abuse in DHCP scenarios
still somewhat works at least for 24.7.x.  We don't want it unless
we have a strict need for it or may want to come up with a simpler
approach.

fichtner added a commit that referenced this issue


          interfaces: move IPv6 connectivity to a separate script for #7446

2cb1fff

A number of cleanup and non-invasive restructuring efforts around
the way IPv6-based connectivity is handled in PPP environments so
that we can later use it allow IPv6-only deployments which takes
a different path based on whether PPP is allowed to do IPv4 (with
or without IPv6) or IPv6 without IPv4.

In theory this would also allow us to run DHCP over PPP, but it's
much outside the scope of the current effort and certainly needs
someone with that type of setup...  ;)

While here make sure the IPv4 connectivity abuse in DHCP scenarios
still somewhat works at least for 24.7.x.  We don't want it unless
we have a strict need for it or may want to come up with a simpler
approach.

fichtner added a commit that referenced this issue


          interfaces: decouple PPP configure/reset from IPv4/IPv6 modes #7446

6592a9a

fichtner added a commit that referenced this issue


          interfaces: decouple PPP configure/reset from IPv4/IPv6 modes #7446

d24300f

fichtner added a commit that referenced this issue


          interfaces: decouple PPP configure/reset from IPv4/IPv6 modes #7446

a40bc6f

fichtner added the roadmap label

fichtner added a commit that referenced this issue


          interfaces: remove PPP edit in interfaces settings #7446

a0b86b4

Time to ditch this.  Leave a thin dialog for the ports display
and where to access the actual PPP settings.

page-getserviceproviders now folds into page-interfaces-ppps-edit
and remove only once use functions to edit page as well.

fichtner added a commit that referenced this issue


          interfaces: inline creation is no more #7446

669a602

fichtner mentioned this issue

source: change menu structure "other types" -> "devices" for clarity opnsense/docs#643

Draft

3 tasks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment