| Summary: | Cannot detect global IPv6 prefix if not /64 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jonathan Larmour <jifl-bugzilla> |
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> |
| Status: | CLOSED NOTABUG | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.1 | CC: | alexs, psimerda, the.ridikulus.rat, tpelka |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-05-01 21:36:22 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
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. 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. 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. 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. |
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.