Page MenuHomeFreeBSD

EXPERIMENTAL: clear IPv6-Only flag on interface if link-state goes down
ClosedPublic

Authored by bz on Mar 6 2019, 11:41 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 4, 5:54 PM
Unknown Object (File)
Oct 10 2024, 2:25 PM
Unknown Object (File)
Sep 23 2024, 2:43 PM
Unknown Object (File)
Sep 8 2024, 8:27 PM
Unknown Object (File)
Sep 8 2024, 4:35 PM
Unknown Object (File)
Sep 8 2024, 12:36 PM
Unknown Object (File)
Sep 2 2024, 12:04 AM
Unknown Object (File)
Sep 2 2024, 12:03 AM
Subscribers

Details

Summary

When we roam between networks and our link-state goes down, automatically remove the IPv6-Only flag from the interface. Otherwise we might switch from an IPv6-only to and IPv4-only network and the flag would stay and we would prevent IPv4 from working.

While the actual function call to clear the flag is under EXPERIMENTAL, the eventhandler is not as I keep wondering if we should do more in the link-down event (such was re-calculate default routers for example). I left a comment for that so we can deal with it in a follow-up.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Looks good to me. We might want to put an INFO log line when ND6_IFF_IPV6_ONLY flag is changed by receiving RA or link-down event so that the sysadmin can know what is going on.

This revision is now accepted and ready to land.Mar 7 2019, 12:53 AM

One more comment: immediate change of the flag just after a link-down event may be problematic when the link is unstable. In such a situation, IPv4 packets can be allowed after a link-up and before another RA arrives even if the all of advertising routers keep sending ipv6only flag. We can assume that the interface should be configured to accept RA when the machine moves from a network to another, so sending a RS after a link-up then clearing ND6_IFF_IPV6_ONLY only when no RA arrives in a few seconds looks a more reasonable behavior. If at least one RA arrives after the RS, the normal handling of ipv6only flag works.

In D19487#417165, @hrs wrote:

One more comment: immediate change of the flag just after a link-down event may be problematic when the link is unstable. In such a situation, IPv4 packets can be allowed after a link-up and before another RA arrives even if the all of advertising routers keep sending ipv6only flag. We can assume that the interface should be configured to accept RA when the machine moves from a network to another, so sending a RS after a link-up then clearing ND6_IFF_IPV6_ONLY only when no RA arrives in a few seconds looks a more reasonable behavior. If at least one RA arrives after the RS, the normal handling of ipv6only flag works.

Well, in theory if there is IPv4 and the IPv6-Only flag on a link there is a configuration problem somewhere though I am actively (ab)using that situation for "transition periods". It should be no different to when a nodes boots up; you have the same "questions" at that time. There is only so much you can do.

In D19487#417158, @hrs wrote:

Looks good to me. We might want to put an INFO log line when ND6_IFF_IPV6_ONLY flag is changed by receiving RA or link-down event so that the sysadmin can know what is going on.

Ifconfig will show the flag in the ndoptions line, in my case currently the manual one.

nd6 options=423<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,IPV6_ONLY_MANUAL>

Logging each time we receive an RA is not a good idea as the IPv4 exemption logic logging has shown me (need to fix that). Logging on every "state toggle" would be good, I agree. I'll prepare that.

In D19487#417206, @bz wrote:
In D19487#417158, @hrs wrote:

Looks good to me. We might want to put an INFO log line when ND6_IFF_IPV6_ONLY flag is changed by receiving RA or link-down event so that the sysadmin can know what is going on.

Ifconfig will show the flag in the ndoptions line, in my case currently the manual one.

nd6 options=423<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,IPV6_ONLY_MANUAL>

Logging each time we receive an RA is not a good idea as the IPv4 exemption logic logging has shown me (need to fix that). Logging on every "state toggle" would be good, I agree. I'll prepare that.

Agreed. I meant logging upon a state toggle by RA, not each time receiving an RA.

In D19487#417291, @hrs wrote:

Agreed. I meant logging upon a state toggle by RA, not each time receiving an RA.

Will do that along with devd notifications or something (still have to figure out). I'll commit this one first.

This revision was automatically updated to reflect the committed changes.