Bug 588163

Summary: Manual IPv6 configures SLAAC as well
Product: [Fedora] Fedora Reporter: Scott Schmit <i.grok>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 12CC: dcbw
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-04 07:31:09 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Scott Schmit 2010-05-02 18:10:57 EDT
Description of problem:
When configuring a connection with manual IPv6, connecting to the network results in SLAAC addresses as well as the manual one(s).

On one hand, IPv6 isn't like IPv4 -- you can have multiple addresses on your interface, so the extra addresses are probably harmless, but I can imagine where people would find the extra addresses to be undesirable (POLA/tradition, don't want the machine to respond to an Internet-accessible address, manual addresses interfere somehow with the SLAAC, etc).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Configure a connection to have the IPv6 method set to manual (IPv4 to whatever you want -- disable is probably the least distracting)
2. Connect to that connection
3. Look at ip addr, ip -6 route, /etc/resolv.conf
Actual results:
SLAAC addresses and routes are configured

Expected results:
SLAAC addresses and routes are not configured, and must be manually configured if desired. (I'm not counting the Link Local address as SLAAC here)

Additional info:
Comment 1 Dan Williams 2010-05-03 06:11:48 EDT
*** Bug 588149 has been marked as a duplicate of this bug. ***
Comment 2 Dan Williams 2010-05-03 06:12:42 EDT
So accept_ra isn't getting set back to 0 when we're using manual mode, that's the problem here I believe.
Comment 3 Dan Williams 2010-05-03 06:43:50 EDT
Upstream fix is 7926b3ca95f2c0c611e271f805437cca9dc004ea.
Comment 4 Scott Schmit 2010-05-04 07:31:09 EDT
I can confirm that this now works with NetworkManager-0.8.0-11.git20100503.fc12.x86_64