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 891245 - managable automatic IPv6 configuration
Summary: managable automatic IPv6 configuration
Keywords:
Status: CLOSED DUPLICATE of bug 906505
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jiri Pirko
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 880347
TreeView+ depends on / blocked
 
Reported: 2013-01-02 09:51 UTC by Pavel Šimerda (pavlix)
Modified: 2015-05-05 01:23 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-08 12:54:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Pavel Šimerda (pavlix) 2013-01-02 09:51:50 UTC 
This is a larger issue. Currently, it's difficult if not impossible to manage kernel's automatic IPv6 configuration support. So far it seems that link-local address configuration and global address configuration works well but routing configuration is flawed.

The way routing configuration should IMO work (needs fixing networkmanager, too):

1) Routing information is learned from configuration or dynamic configuration protocol (DHCP)

2) Policy decision is made

3) Routes (including device routes and default routes) are set based on the policy. Some of the routes are either not added, or added with different priorities. The details of this are yet to be specified.

The way it works with current kernels and networkmanager:

1) kernel sets routing information

2) networkmanager learns about it through netlink

3) networkmanager's policy decision

4) networkmanager tries to fix the wrong configuration by setting high-priority routes

The current way is clearly wrong but kernel doesn't provide a better way, AFAIK.

The desired behaviour is pretty obvious. Network communication (router discovery) first, then policy decision, then routing configuration. How to achieve this, is not so obvious.

Let's leave this bug report open for discussion.
Comment 1 Pavel Šimerda (pavlix) 2013-01-02 10:03:02 UTC 
The important question is how much will be up to networkmanager and how much up to the kernel. One idea is that kernel would set up device routes and default routes but these would be deactivated until networkmanager makes a policy decision (roughly "which interface is available for default route communication").

It is important to understand that this is not only about default routes. Device routes for the same network prefix should also be prioritized e.g. by quality of link or by user configuration.

Device route priorities are currently broken in networkmanager even for IPv4 but it would be nice to fix it properly without workarounds also for IPv6.
Comment 3 Pavel Šimerda (pavlix) 2013-01-30 11:19:48 UTC 
Currently, I think the most preferable way would be if I can tell the kernel a routing metric for automatic routes per-device, including a value that would disable the route entirely. A boolean enable/disable would be good too, but it must work immediately, i.e. kernel performs route configuration with default route disabled but can enable it at any time. I don't think accept_ra_defrtr does that.

Kernel also sets up device routes and these should be most probably handled separately. NetworkManager also sets up various types of routes for both IPv6 and IPv4, and therefore it should be able to read value and use it for NM-installed routes, too.

Plus if we use the metric, it should work smoothly with the router preference, which is currently not supported by kernel.

It still needs some more analysis, though.
Comment 4 Jiri Pirko 2013-03-08 12:54:10 UTC 
this is dup of 906505 -> closing it as such. Please feel free to reopen if anything changes.

*** This bug has been marked as a duplicate of bug 906505 ***
Note You need to log in before you can comment on or make changes to this bug.