Bug 746586 - Cannot detect global IPv6 prefix if not /64
Summary: Cannot detect global IPv6 prefix if not /64
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: NetworkManager
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Dan Williams
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-17 07:11 UTC by Jonathan Larmour
Modified: 2012-05-01 21:36 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-01 21:36:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jonathan Larmour 2011-10-17 07:11:52 UTC
Description of problem:

Our ISP has allocated us an IPv6 global prefix which is a /56. We are using it directly (for now at least). I have verified using tcpdump that it is being advertised correctly by our router as a /56.

However while NM sets the interface with the correct prefix numerically, it sets it as a /64, which therefore doesn't work. On our network, we use both Router Advertisement (RA) for normal IPv6 allocation, and DHCPv6 in order to use well known addresses, DNS mapping of clients, and set things like DNS resolver to use, etc. Therefore NM is set with method "Automatic", and not the "Addresses only" nor "DHCP only" alternatives.

I've done a bit of investigation, and I think I see the problem but I'm not certain. DHCPv6 can allocate addresses, but it does not deal with distributing prefixes. See RFC3315. That's not in its remit. That's the job for RA.

The problem seems to be that dhclient (from ISC DHCP) will return a "new_ip6_prefixlen" of 64 no matter what. From dhclient's dhc6.c in dhc_marshall_values():
                        /* Current practice is that all subnets are /64's, but
                         * some suspect this may not be permanent.
                         */
                        client_envadd(client, prefix, "ip6_prefixlen",
                                      "%d", 64);

But as far as I can tell, subnets must not be smaller than a /64, but they can be larger. "Current practice" isn't the same as what may exist!

But I think the problem here is not from dhclient. It's because NetworkManager uses the prefix length, despite DHCPv6 inherently being unable to provide it. 

I may be wrong, but I think in NetworkManager's nm-device.c:merge_dhcp_config_to_master(), the address (including prefix) should not be wholly merged into the config, but the prefix length should be treated specially and the value from DHCP should not override the value provided by RA.


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

NetworkManager-0.8.1-9.el6_1.3.x86_64

It is also known to be reproducible on F14:
NetworkManager-0.8.5.92-1.git20110927.fc14.x86_64


How reproducible:

100%

Steps to Reproduce:

Configure a global prefix of a /56 on a network's IPv6 router and advertise it.
  
Actual results:

NM will assign the prefix but as a /64.

Comment 2 RHEL Program Management 2011-10-21 15:59:14 UTC
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 3 Pavel Šimerda (pavlix) 2012-04-30 22:01:00 UTC
I'm afraid host behavior is undefined in this case.

See RFC 4291:

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

Comment 4 Jonathan Larmour 2012-05-01 13:31:19 UTC
Thanks Pavel, I had briefly looked around for info like that but not found anything like that. Unless anyone on CC thinks there's any other interpretation or exception, then I intend to close this as NOTABUG.

Comment 5 Dan Williams 2012-05-01 21:36:22 UTC
I'll close as NOTABUG for now; perhaps in the future the IETF or somebody will update the specs and we can revisit then.  Thanks.


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