Bug 2069257

Summary: IPv6 autoconfiguration for PPPoE broken
Product: Red Hat Enterprise Linux 8 Reporter: steve
Component: NetworkManagerAssignee: NetworkManager Development Team <nm-team>
Status: CLOSED UPSTREAM QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: bgalvani, bstinson, jwboyer, lrintel, rkhan, sfaye, sukulkar, till, zhh0000zhh
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-11-16 08:15:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Trace of Network Manager connecting a PPP session
none
A better trace log none

Description steve 2022-03-28 15:11:36 UTC
Description of problem:
A PPPoE connection with ipv6.method=auto should work as follows:
1. IPV6CP sets up the interface identifier and default route.
2. We client send an IPv6 router solicitation.
3. The peer sends an IPv6 router advertisement.
4. Depending on the advertisement, we do SLAAC or DHCPv6 to configure an interface address and get a delegated prefix from the peer.
5. Interfaces with ipv6.method=shared are configured using the prefix which was delegated to us by the peer (if any).

This worked under NetworkManager-1.34.0-0.3.el8.x86_64.rpm, but breaks under the next version of the package (NetworkManager-1.36.0-0.1.el8.x86_64.rpm).  NetworkManager 1.36.0 does not send the router solicitation, so the process stalls and we never get a working IPv6 connection.

Version-Release number of selected component (if applicable):
NetworkManager-1.36.0-0.1.el8.x86_64.rpm

How reproducible:
Always

Steps to Reproduce:
1. Configure a PPPoE connection with ipv6.method=auto, connecting to an IPv6 capable ISP.
2. Bring up the connection - no IPv6 address will be assigned and no interfaces with ipv6.method=shared will have addresses assigned.
3. The PPPoE traffic itself can be tcpdumped, which confirms that no solicitation is sent.

Actual results:
No IPv6 address assigned.

Expected results:
IPv6 address should be assigned.

Additional info:
The interface's /proc/sys/net/ipv6/conf/*/accept_ra is set to zero both under 1.34.0 (working) and 1.36.0 (broken).  I have read that NetworkManager intentionally sets this to zero and handles router solicitation itself rather than leaving it to the kernel, so the accept_ra setting is probably a red herring.

Comment 1 Till Maas 2022-04-07 10:16:04 UTC
Please provide a NetworkManager TRACE log when it fails, see https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/contrib/fedora/rpm/NetworkManager.conf#L27 for how to achieve this. Thank you.

Comment 2 zhh0000zhh 2022-06-08 08:25:40 UTC
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1017
RHEL9 has the same problem.
Need to upgrade NetwrokManager to the latest version.

Comment 3 steve 2022-11-09 11:08:37 UTC
Created attachment 1923332 [details]
Trace of Network Manager connecting a PPP session

I note that comment #2 says that this is fixed upstream.  This it the trace of Network Manager failing to autoconfigure IPv6 addresses over PPP.

Comment 4 steve 2022-11-09 11:12:16 UTC
Note: the trace log was captured from a machine running NetworkManager-1.40.0-1.el8.x86_64, But the upstream fix mentioned in comment #2 appears to have been merged into 1.39.5 so I'm not sure if this is the same bug as the upstream one?

Comment 5 steve 2022-11-09 13:08:51 UTC
The fix mentioned in comment #2 appears to be related to DHCPv6.  However, in my case NetworkManager is not completing router discovery, so it never gets as far as SLAAC / DHCPv6.

The trace was taken while connecting to an ISP that has the "managed address configuration" and "other configuration" flags unset in the router advertisement, so NetworkManager should be doing SLAAC, not DHCPv6.

I have also opened an upstream bug on this issue: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1137

Comment 6 steve 2022-11-14 16:04:52 UTC
Created attachment 1924273 [details]
A better trace log