RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1261809 - NetworkManager removes IPv6LL address from device
Summary: NetworkManager removes IPv6LL address from device
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.2
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: 7.3
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1301628 1313485
TreeView+ depends on / blocked
 
Reported: 2015-09-10 08:26 UTC by Vladimir Benes
Modified: 2016-05-17 09:01 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-17 09:01:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 763236 0 None None None 2016-03-12 14:02:27 UTC

Description Vladimir Benes 2015-09-10 08:26:05 UTC 
Description of problem:
If there is an just IPv6LL address on device and NM service stopped device's IPv6LL address is removed upon NM service start.

Version-Release number of selected component (if applicable):
NetworkManager-1.0.6-2.el7.x86_64

How reproducible:
always

Steps to Reproduce:
 nmcli c del eth0               # delete existing connections on eth0
 systemctl stop NetworkManager
 ip a flush dev eth0            # delete all addresses on eth0
 ip l set eth0 down
 ip l set eth0 up               # now eth0 should have an IPv6 link-local address
 systemctl start NetworkManager

Actual results:
[root@qe-dell-ovs5-vm-5 ~]# ip  a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 52:54:02:2c:e1:2d brd ff:ff:ff:ff:ff:ff


Expected results:
[root@qe-dell-ovs5-vm-5 ~]# ip  a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 52:54:02:2c:e1:2d brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:2ff:fe2c:e12d/64 scope link 
       valid_lft forever preferred_lft forever


Additional info:
Comment 1 Beniamino Galvani 2015-09-11 09:04:21 UTC 
I think this is a minor problem and the user can fix it by tweaking NM
configuration.

This behavior was introduced to fix bug 1138426; before the change,
when a device was found at startup having only an IPv6LL address, NM
assumed the connection and kept its configuration, ignoring other
on-disk connections for the same device.

This caused many problems because it happened frequently that users
complained that NM was not activating connections and the reason was
that the device was already up with a IPv6LL address automatically
assigned by kernel.

Now NM ignores IPv6LL configurations, takes ownership of the device
and tries to activate on-disk connections, but if there are no
available connections, the devices remains without the initial IPv6LL
address. This can be fixed by setting the device as
'assume-ipv6ll-only' in configuration, which will revert to old
behavior; or by creating a persistent connection that will be
activated.

In my opinion, we can try to be better at not interfering with
existing configuration and, for example, don't touch the interface if
we don't have candidate connections for the device.  But this requires
some bigger changes that may not be appropriate for 7.2.

My proposal is to consider this as an improvement for the next NM 1.2
release.
Comment 2 Beniamino Galvani 2015-10-28 15:44:00 UTC 
After thinking longer about it, I'm convinced that the current
behavior is reasonable. Since NM is not assuming the IPv6LL-only
device and there are no candidate connections, the device goes to
DISCONNECTED state and therefore there can't be any addresses assigned
to it.

In order to keep the existing address NM has to assume the connection,
and this must be enabled explicitly in configuration with the
'assume-ipv6ll-only' option.

Vladimir, what's your opinion?
Comment 4 Beniamino Galvani 2016-01-15 12:51:37 UTC 
Hi Vlad,

I believe that the current behavior is acceptable for reasons explained in comment 2. In other words, either the connection gets assumed (and in that case we keep the IPv6LL address) or it doesn't (and then it will be disconnected when there aren't available connections). The behavior can be changed by the 'assume-ipv6ll-only' flag. What do you think? Thanks.
Comment 5 Beniamino Galvani 2016-03-14 07:52:11 UTC 
Patch posted on upstream bz https://bugzilla.gnome.org/show_bug.cgi?id=763236
Comment 6 Mike McCune 2016-03-28 22:20:08 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 7 Beniamino Galvani 2016-04-04 12:20:55 UTC 
(In reply to Beniamino Galvani from comment #5)
> Patch posted on upstream bz https://bugzilla.gnome.org/show_bug.cgi?id=763236

The upstream patch was wrong since it left the device configured while in DISCONNECTED state.
Comment 9 Beniamino Galvani 2016-05-16 09:21:58 UTC 
Yeah, I think at the moment this is working as designed. Maybe we can re-think how devices are managed and assumed, but that would be a different bug (the one mentioned in comment 8). I'm for closing this. Vladimir, do you agree?
Comment 10 Vladimir Benes 2016-05-16 15:34:59 UTC 
(In reply to Beniamino Galvani from comment #9)
> Yeah, I think at the moment this is working as designed. Maybe we can
> re-think how devices are managed and assumed, but that would be a different
> bug (the one mentioned in comment 8). I'm for closing this. Vladimir, do you
> agree?

Do whatever you like, I just reported suspicious behavior. If it's not buggy and there is no way to preserve IPv6LL address when assuming connection w/o touching the device then close it.
I was just expecting to preserve IPv6LL while still receiving RA in such reported scenario. Probably just corner case.
Note You need to log in before you can comment on or make changes to this bug.