IPv6 Prefix ID under LAN Track Interface

[darkain]

The UI has the following text:

The value in this field is the (Delegated) IPv6 prefix id. This determines the configurable network ID based on the dynamic IPv6 connection
Enter a hexadecimal value between 0 and 0 here, default value is 0.

First, the valid range is much larger than just 0 to 0. Secondly, at least on my setup and someone else who contacted me for help, 0 isn't even a valid value (in both of our cases, we're running CenturyLink 6RD). Prefix 0 is used on the WAN side, and LAN needs a value of 1 or larger to function properly.

[fichtner]

That's only partly true, you don't have to pull a prefix on WAN so you're free to use all of the prefixes in a /64 which is 1 which is ID 0. Question is why does it think your WAN is /64? What did you set there?

[darkain]

For whatever reason, setting the Prefix ID to 0 doesn't function with my 6RD configuration. Setting it to any other value within the accepted range works just fine. Also, the UI states that only 0 is the accepted range value, when in fact it is much larger (my ISP provides me a /56)

Re-thinking about it now, yes, ID 0 SHOULD work, but for whatever reason isn't with OPNsense. This could be a bug with the new 6RD code.

[thomasjsn]

I have /62, and the Prefix ID correctly show allowed values from 0 to 3, but as @darkain the 6rd stops workings completely if 0 is used for any interface.

[darkain]

For the UI displaying "0 to 0", AFTER saving the config, it then shows properly. The reason:

calculate_ipv6_delegation_length($pconfig['track6-interface'])

$pconfig['track6-interface'] is an empty string until after the configuration is saved, so calculate_ipv6_delegation_length() returns 0 the first time the UI is loaded.

This, however, still doesn't address the issue of prefix 0 not even functioning properly though.

[fichtner]

Tracking this via
#2663

[darkain]

There is still the secondary issue here of the UI showing the wrong information. I think this issue should be re-opened and focused on that instead, while the routing issue is handled on the other ticket.

[fichtner]

We would need to change the value with JavaScript, which seems to be a larger waste of effort for a cosmetic help text fix. The better fix would be to enter tracking information via the WAN interface where we know the correct prefix right away and could also validate the IDs against reuse / avoid selecting 0 in case of 6rd until the other issue is solved. This again would be a larger effort. It’s rather unlikely that somebody will do the work in both cases?

…

On 24. Aug 2018, at 21:05, Vincent Milum Jr ***@***.***> wrote: There is still the secondary issue here of the UI showing the wrong information. I think this issue should be re-opened and focused on that instead, while the routing issue is handled on the other ticket. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[darkain]

Why couldn't you just set it up to do something like "if empty string, assume 'WAN'" for that particular field? Seems like a super quick/simple fix to me.

[fichtner]

It’s not perfect, but if you insist we can preselected the first WAN from the list if the tracked interface field is empty to show the correct value when you first see the setting, but it breaks as soon as the selected interface changes. We could also remove the offending help text and do a check during page save trough validation alone and show that message if the input is outside its range?

…

On 25. Aug 2018, at 08:33, Vincent Milum Jr ***@***.***> wrote: Why couldn't you just set it up to do something like "if empty string, assume 'WAN'" for that particular field? Seems like a super quick/simple fix to me. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.