Bug 656335

Summary: anaconda generates an incorrect DHCPv6 configuration
Product: Red Hat Enterprise Linux 6 Reporter: Harald Hoyer <harald>
Component: anacondaAssignee: Radek Vykydal <rvykydal>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team>
Severity: high Docs Contact:
Priority: low    
Version: 6.0CC: rps, tmraz
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 656315 Environment:
Last Closed: 2011-05-31 20:44:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 656315, 845867    
Bug Blocks: 656334, 712003    

Description Harald Hoyer 2010-11-23 14:48:15 UTC
+++ This bug was initially created as a clone of Bug #656315 +++

Description of problem:

IPv6 network configuration is available in the installer, but not in the management tools provided by the distribution.

When selecting DHCPv6 in the installer, the installer generates an incorrect DHCPv6 configuration which results in a broken IPv6 stack by default.

The network and firewall configuration tools should be IPv6-aware (like the installer is) and produce the _correct_ IPv6 configuration.

There is currently no way to undo the IPv6 configuration generated by the installer without manually editing configuration files.

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

RHEL 6.0 installer, system-config-network, and system-config-firewall (maybe others)

How reproducible:


Steps to Reproduce:
1. Select DHCPv6 in the installer for network configuration.
2. Wait for install to complete and boot into new system.
3. Profit(?)

Actual results:

Broken IPv6 configuration.  No configuration tools in OS.

Expected results:

A functional IPv6 configuration and OS tools that provide the same options as the installer tools.

Additional info:

Problem 1: Default Firewall blocking DHCPv6

The default ip6tables configuration was written to replicate the behavior of the default iptables policy.  This is a good thing.  Unfortunately, the default ip6tables policy blocks DHCPv6 traffic, breaking DHCPv6 on the system.  This is because conntrack has no way to track DHCPv6, which uses multicast, so DHCPv6 traffic is not caught by allowing ESTABLISHED,RELATED connections.  The default firewall must be modified to allow DHCPv6 traffic by default.  This means the addition of the following rule:

-A INPUT -p udp --dport 546 -j ACCEPT

Problem 2: DHCPv6 and Stateless Address Auto-Configuration are treated as exclusive.

The installer makes the assumption that a user will want to select either Manual, Stateless configuration, or DHCPv6 when enabling IPv6.  The result is that when DHCPv6 is selected the installer adds a IPV6_AUTOCONF="no" statement to the interface configuration.  This results in signaling the kernel to not accept IPv6 router advertisements assuming that DHCPv6 would provide all configurations.  This is a false assumption.  Unlike DHCP, DHCPv6 provides no mechanism for providing a host with default route information.  That task is handled by the IPv6 router advertisement.  So by disabling router advertisements, you essentially create a situation where a host receives an IPv6 address and IPv6 DNS servers, but no IPv6 routing information.

The solution is to either omit the IPV6_AUTOCONF statement (since it defaults to yes) or hard-set the value to yes instead of no, unless manual (static) configuration is selected by the user.

The assumption is also made that you will use either DHCPv6 or Stateless for IPv6 configuration.  This is again, false.  It is perfectly valid for a host to use both DHCPv6 and Stateless configuration for addressing at the same time (and receive two addresses).  DHCPv6 is also the only way for a stateless host to receive IPv6 DNS server information (DHCPv6-Light).

The user will generally have no idea which addressing method is used for IPv6.  It is very poor practice to try to distinguish between DHCPv6 and Stateless configuration.  That is decided by the network (If Stateless is disabled on a network, the "A" (autonomous) flag for the prefix will be false in the router advertisement and kernel will respect this and not configure a stateless address).

The correct method for IPv6 configuration is to only present the user with options for "Manual" or "Automatic" configuration, and always start a DHCPv6 client for automatic configuration in case it is needed.  If a user really wants to disable the client they can manually edit the configuration.  The default should be functional.

This problem is going to cause a lot of frustration for users trying to make use of IPv6.  Clearly a lot of work has gone into making RHEL work well with IPv6 (and we're thankful for that).  Please don't make it meaningless by messing up what should be the most simple part of IPv6 support.  We can't wait for RHEL 7 for this to get fixed.

--- Additional comment from pm-rhel@redhat.com on 2010-11-23 08:42:22 EST ---

Since this issue was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 2 Radek Vykydal 2010-11-23 16:14:46 UTC
In anaconda, we use NetworkManager Connection Editor (nm-c-e) to configure network in stage 2, while in loader, where we have to use our own UI, we follow its behaviour:

Correspondence between our three options and nm-c-e UI:

Automatic neighbor discovery         -> Automatic
Dynamic IP configuration (DHCPv6)    -> Automatic, DHCP only
Manual configuration                 -> Manual

After the change in bug https://bugzilla.redhat.com/show_bug.cgi?id=612445, the DHCP method is (as in nm-c-e) "stateful" (IPV6_AUTOCONF=no). We could add another DHCP ("stateless") method, or change it back, but this should first happen in nm-c-e (ifcfg-rh plugin).

Comment 3 RHEL Program Management 2011-05-31 20:44:54 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.