Bug 891245

Summary:	managable automatic IPv6 configuration
Product:	Red Hat Enterprise Linux 7	Reporter:	Pavel Šimerda (pavlix) <psimerda>
Component:	kernel	Assignee:	Jiri Pirko <jpirko>
Status:	CLOSED DUPLICATE	QA Contact:	Red Hat Kernel QE team <kernel-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	jpirko, rkhan, tgraf
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-03-08 12:54:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	880347

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