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 656335 - anaconda generates an incorrect DHCPv6 configuration
Summary: anaconda generates an incorrect DHCPv6 configuration
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: All
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On: 656315 845867
Blocks: 656334 712003
TreeView+ depends on / blocked
 
Reported: 2010-11-23 14:48 UTC by Harald Hoyer
Modified: 2012-08-06 01:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 656315
Environment:
Last Closed: 2011-05-31 20:44:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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:

100%




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 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.


Note You need to log in before you can comment on or make changes to this bug.