Bug 1302081
Summary: | [DOC] When one of the leading zeros of the last IPv6 quartet is omitted the public VIP gets set on all 3 controllers | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Angus Thomas <athomas> |
Component: | documentation | Assignee: | Dan Macpherson <dmacpher> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | RHOS Documentation Team <rhos-docs> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 10.0 (Newton) | CC: | athomas, bfournie, dmacpher, dsneddon, jcoufal, mburns, mcornea, mlopes, rhel-osp-director-maint, srevivo |
Target Milestone: | --- | Keywords: | Documentation |
Target Release: | 10.0 (Newton) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Known Issue | |
Doc Text: |
Address ranges entered for the `AllocationPools` IPv6 networks and IP allocation pools must be input in a valid format according to RFC 5952. Consequently, invalid entries will result in an error.
As a result, IPv6 addresses should be entered in a valid format: Leading zeros can be omitted or entered in full, and repeating sequences of zeros may be replaced by "::".
For example, an IP address of "fd00:0001:0000:0000:00a1:00b2:00c3:0010" may be represented as: "fd00:1::a1:b2:c3:10", but not as: "fd00:01::0b2:0c3:10", because there are an invalid number of leading zeros (01, 0b2, 0c3). The field must be truncated of leading zeros or fully padded.
|
Story Points: | --- |
Clone Of: | 1301923 | Environment: | |
Last Closed: | 2017-09-13 01:16:13 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: | 1301923 | ||
Bug Blocks: |
Description
Angus Thomas
2016-01-26 17:46:28 UTC
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10. Entering addresses with a invalid number of leading zeros will lead to errors. According to RFC 5952, leading zeros within each hexadecimal group (between the ":" delineators) must be fully-padded or all leading zeros may be omitted. Doc text has been updated, and the installation and usage guide should be updated appropriately. Cleaning up my backlog and I found this bug. I checked in the IPv6 Guide and it looks like this is mentioned: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html-single/ipv6_networking_for_the_overcloud/#defining_ipv6_networking === Notice you can also represent IPv6 addresses without leading zeros in each bit group and omit a set of zero bit groups once per IP address. In our example, you can represent the 0db8 bit grouping as just db8 and omit the three sets of 0000 bit groups, which shortens the representation from 2001:0db8:88ec:9fb3:0000:0000:0000:0001 to 2001:db8:88ec:9fb3::1. For more information, see "RFC 5952: A Recommendation for IPv6 Address Text Representation" === Dan, are we okay to close this BZ? (In reply to Dan Macpherson from comment #5) > Cleaning up my backlog and I found this bug. I checked in the IPv6 Guide and > it looks like this is mentioned: > > https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/ > html-single/ipv6_networking_for_the_overcloud/#defining_ipv6_networking > > === > Notice you can also represent IPv6 addresses without leading zeros in each > bit group and omit a set of zero bit groups once per IP address. In our > example, you can represent the 0db8 bit grouping as just db8 and omit the > three sets of 0000 bit groups, which shortens the representation from > 2001:0db8:88ec:9fb3:0000:0000:0000:0001 to 2001:db8:88ec:9fb3::1. For more > information, see "RFC 5952: A Recommendation for IPv6 Address Text > Representation" > === > > Dan, are we okay to close this BZ? Yes, we are OK to close this BZ, it is documented. Just to be clear, the example you gave (2001:db8:88ec:9fb3::1) works, as does the version with all the zeroes, and even this (2001:db8:88ec:9fb3::0001), what doesn't work is an invalid number of zeroes, such as 2001:db8:88ec:9fb3::01. Thanks, Dan! Closing this BZ. |