A network's MTU is now only valid if it is the minimum value allowed based on the IP version of the associated subnets, 68 for IPv4 and 1280 for IPv6. This minimum is now enforced in the following ways: 1) When a subnet is associated with a network, validate the MTU is large enough for the IP version. Not only would the subnet be unusable if it was allowed, but the Linux kernel can fail adding addresses and configuring network settings like the MTU. 2) When a network MTU is changed, validate the MTU is large enough for any currently associated subnets. Allowing a smaller MTU would render any existing subnets unusable. Closes-bug: #1988069 Change-Id: Ia4017a8737f9a7c63945df546c8a7243b2673ceb
The current document states that O flag will be 1 when ipv6_ra_mode is dhcpv6_stateful, but the actual implementations of both ml2/OVS and ml2/OVN set O flag to 0 according to the following implementations: ML2/OVS https://github.com/openstack/neutron/blob/f545c002dc699f849026ccd1bad403b2933373aa/neutron/agent/linux/ra.py#L53-L55 ML2/OVN https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/controller/pinctrl.c#L3733-L3734 https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/lib/actions.c#L3349-L3350 This actual behavior looks correct because O flag can be either 1 or 0 when M flag is 1, according to the following statement of RFC 4861: https://www.rfc-editor.org/rfc/rfc4861#section-4.2 If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information. To make consistency between the documet and actually behavior, this commit changes the document to state that O flag can be either 1 or 0 when ipv6_ra_mode is dhcpv6_stateful. Closes-Bug: #2011687 Change-Id: Id61031d7e707d0ba7b007bae0c9e0f59b8b40f8b
Metadata service now supports IPv6 networks. This patch removes this limitation in the documentation. Related-Bug: #1460177 Change-Id: I1c50aef5e4aa60705f923f399e8d36c37a9d6289
This reverts commit bce27811dfea634118fdb609289ac70c8d4a6854. Reason for revert: neutron-fwaas has maintainers so the documentation should be available. Due to changes since the original deletion commit the following changes were added: * Add note that OVN is not yet supported * Remove note that Horizon support is not available Change-Id: I1a739ee045b49e9b44283c28f95b1accc8a1e37f
Change-Id: I85e17719eb4420a6cfd82ee54e60dd23ccfa0e95 Related-Bug: #1719806
Change-Id: I2b8642b6830d3e1e1ef86c779c55e9ac1d0f7568 Partial-Bug: #1877301
Based on discussions during the Zed PTG (see [1]) mark Prefix Delegation as experimental. Add warning to cfg option ipv6_pd_enabled and to IPv6 documentation's PD section that the feature has low test coverage, and dibbler is concluded (the tool used for notifing Neutron that a prefix was changed) see: [2]. [1]: https://etherpad.opendev.org/p/neutron-zed-ptg#L208 [2]: https://github.com/tomaszmrugalski/dibbler#project-status Related-Bug: #1916428 Change-Id: Ia712eb6f5b6f947aeab89ba7c018771eb4104e37
This patch adds information about what "A", "M" and "O" means in the ra_mode and and address_mode table. It also changes from the "radvd" to the "neutron-generated advertisements" in the same table as "radvd" is an implementation. Change-Id: I66e2815e451a6940402d49240ec743f99785850c