)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":17776,"name":"Reedip","email":"reedip.banerjee@gmail.com","username":"Reedip"},"change_message_id":"3763fa1e18602b5db2de90cc9e2516bf369bddb7","unresolved":false,"context_lines":[{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protectiong added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"},{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"1a430d35_6c5c694b","line":24,"range":{"start_line":24,"start_character":14,"end_line":24,"end_character":25},"updated":"2017-02-09 08:46:44.000000000","message":"couldnt get what it meant","commit_id":"28cc315302d72b014617f651a4c8c1c5ab4e34c1"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"40a748af298d5af9bdac0f572b962393222fd7e2","unresolved":false,"context_lines":[{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protectiong added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"},{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"1a430d35_79bdea01","line":24,"range":{"start_line":24,"start_character":14,"end_line":24,"end_character":25},"in_reply_to":"1a430d35_6c5c694b","updated":"2017-02-09 19:34:00.000000000","message":"\u0027protection\u0027 is what it was supposed to be.","commit_id":"28cc315302d72b014617f651a4c8c1c5ab4e34c1"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"49179c022c3eeed235141df8ff72f7ec1f7a6844","unresolved":false,"context_lines":[{"line_number":15,"context_line":"ipv6_address_mode is \u0027slaac\u0027."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_d10cc144","line":18,"updated":"2017-02-10 23:49:10.000000000","message":"Sorry, *not link local* and non-neutron.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"68d4d85abf7ce6cafd03963f2d66a18c0e9fbc16","unresolved":false,"context_lines":[{"line_number":14,"context_line":"router using SLAAC\"[2] when ipv6_ra_mode is empty and"},{"line_number":15,"context_line":"ipv6_address_mode is \u0027slaac\u0027."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_c63edeb7","line":18,"range":{"start_line":17,"start_character":0,"end_line":18,"end_character":26},"updated":"2017-02-10 12:33:54.000000000","message":"The logic already does this as long as the gateway_ip is link local, so it might be more accurate to say:\n\n  This patch adjusts the logic to always allow RAs from the gateway_ip\n  even if it isn\u0027t link-local.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"42f9119361fbf3e0d35534ee6c665eab028ddc79","unresolved":false,"context_lines":[{"line_number":15,"context_line":"ipv6_address_mode is \u0027slaac\u0027."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_fa49b5d1","line":18,"updated":"2017-02-10 13:56:27.000000000","message":"The previous code also doesn\u0027t work if it is link local and non-Neutron because the lla lookup function is dependent on finding a router port in the DB. This patch now adds the fallback to use the gateway_ip when that lookup fails.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"c12b33566f6e50fb4e1a8f76141ea1a5a2aae7ac","unresolved":false,"context_lines":[{"line_number":15,"context_line":"ipv6_address_mode is \u0027slaac\u0027."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_55045214","line":18,"in_reply_to":"fa31d9ce_fa49b5d1","updated":"2017-02-10 14:26:12.000000000","message":"If the gateway IP is already link local then the lla lookup function is never called because it skips the IF block beginning on L355. So it *should* currently be working in that scenario.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"49179c022c3eeed235141df8ff72f7ec1f7a6844","unresolved":false,"context_lines":[{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_f109c532","line":19,"updated":"2017-02-10 23:49:10.000000000","message":"But that requirement makes no sense. It ties a subnet flag to a specific L3 plugin.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"42f9119361fbf3e0d35534ee6c665eab028ddc79","unresolved":false,"context_lines":[{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_1a4769bc","line":19,"updated":"2017-02-10 13:56:27.000000000","message":"From the guide:\n\"The ipv6_ra_mode is used to specify if the Networking service should transmit ICMPv6 packets, for a subnet.\"\n\nIt doesn\u0027t imply that it has to be originating from a Neutron router.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"68d4d85abf7ce6cafd03963f2d66a18c0e9fbc16","unresolved":false,"context_lines":[{"line_number":15,"context_line":"ipv6_address_mode is \u0027slaac\u0027."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_6658d2fb","line":19,"range":{"start_line":18,"start_character":27,"end_line":19,"end_character":50},"updated":"2017-02-10 12:33:54.000000000","message":"Why? If ipv6_ra_mode is set then the subnet has been configured to have its RAs managed by neutron, so a router interface is expected to be present. The section of the networking guide you\u0027ve pasted above suggests that we should fallback only if ra_mode is NOT set.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"c12b33566f6e50fb4e1a8f76141ea1a5a2aae7ac","unresolved":false,"context_lines":[{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_d593e2a1","line":19,"in_reply_to":"fa31d9ce_1a4769bc","updated":"2017-02-10 14:26:12.000000000","message":"It also states that the only valid ra/address mode combination for RAs from non-openstack routers includes having ra_mode not set, so we may have a documentation issue here.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"6cbcf40dab024221e2abb611595e990678392074","unresolved":false,"context_lines":[{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_388dd27b","line":19,"in_reply_to":"fa31d9ce_971cd278","updated":"2017-02-13 12:41:42.000000000","message":"I should have been more specific. I\u0027m saying that RA\u0027s managed by neutron does not imply radvd. \n\n\"The ipv6_ra_mode is used to specify if the Networking service should transmit ICMPv6 packets, for a subnet.\" does not mean the reference implementation needs to do the work. Fields in the neutron API are implemented by a loaded core plugin/serviceplugin/driver, etc. \n\nI can write a driver that goes off and configures real physical hardware to issue RAs for a subnet when ipv6_ra_mode is set. In that case it\u0027s still the Neutron service setting up address assignment so it conforms to the API. However, this real physical router might not have a device_owner (or even a port in the DB) that this security groups code is looking for, so it will block traffic from this implementation.\n\nI\u0027m not proposing that we change it so ipv6_ra_mode slaac stops using radvd in the reference or changing the meaning of ipv6_ra_mode. I\u0027m proposing we have the security groups code stop trying to guess where RAs are being originated from.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"c12f63ac9cffbe28484a25d2d8318cb9ff568b30","unresolved":false,"context_lines":[{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This patch adjusts the logic to always allow RAs from the gateway_ip"},{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_971cd278","line":19,"in_reply_to":"fa31d9ce_f109c532","updated":"2017-02-13 11:09:58.000000000","message":"The ipv6_ra_mode flag is specifically for telling neutron that it is responsible for issuing RAs to that subnet. This is covered in sections [1] and [2] of the Networking Guide. It seems you\u0027re changing it to mean that RAs should be allowed to reach that subnet, whether from neutron or otherwise. I agree that the sentence you\u0027ve quoted above is ambiguous and even misleading, so it should be removed or modified. But the rest of that page is quite clear about the function of the flag.\n\n[1] http://docs.openstack.org/mitaka/networking-guide/config-ipv6.html#address-modes-for-ports\n[2] http://docs.openstack.org/mitaka/networking-guide/config-ipv6.html#using-slaac-for-addressing","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"68d4d85abf7ce6cafd03963f2d66a18c0e9fbc16","unresolved":false,"context_lines":[{"line_number":18,"context_line":"of the subnet in any mode. With ipv6_ra_mode set, we will also fallback"},{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protection added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_299b0dcb","line":22,"range":{"start_line":21,"start_character":0,"end_line":22,"end_character":68},"updated":"2017-02-10 12:33:54.000000000","message":"Again, they already do as long as the gateway_ip has a link-local address, so I think this patch might be making a different change to what\u0027s described.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"49179c022c3eeed235141df8ff72f7ec1f7a6844","unresolved":false,"context_lines":[{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protection added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_1107391d","line":22,"updated":"2017-02-10 23:49:10.000000000","message":"The change in the commit message is to allow neutron security groups to work with ipv6 routers other than our own. All of these conditionals are getting in the way of that in code that should be completely unrelated to the L3 plugin (security group filtering).","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"42f9119361fbf3e0d35534ee6c665eab028ddc79","unresolved":false,"context_lines":[{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protection added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_3a126db5","line":22,"updated":"2017-02-10 13:56:27.000000000","message":"Why does it need to be a link local address? I wasted a bunch of time helping someone with a provider net deployment where the gateway router was issuing ICMP type 134 messages that were being dropped because of this secret requirement in the security group code.\n\nThis code should not be deciding anything about blessed RAs. This was added as a hacky spoofing prevention that has long been made irrelevant by dropping RAs from VMs on ingress. Now it\u0027s just hidden unexplainable filtering behavior that is extremely difficult to troubleshoot. The long term fix is to completely eliminate all of this code and just always allow ICMP type 134 from everywhere on the agents; however, that\u0027s not backwards compatible for the RPC interface so this needs to be done for now for backportability.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"c12f63ac9cffbe28484a25d2d8318cb9ff568b30","unresolved":false,"context_lines":[{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protection added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_37f326d8","line":22,"in_reply_to":"fa31d9ce_1107391d","updated":"2017-02-13 11:09:58.000000000","message":"Now that we know about the RFC 4861 compliance issue, how would you feel about keeping the link-local requirement and documenting it with a pointer to the RFC? There may be wider implications to allowing users to violate it.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"6cbcf40dab024221e2abb611595e990678392074","unresolved":false,"context_lines":[{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protection added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_c3b128e3","line":22,"in_reply_to":"fa31d9ce_37f326d8","updated":"2017-02-13 12:41:42.000000000","message":"I think the firewall code is an inappropriate place to enforce RFC compliance of an RA ICMP originator. If a device shouldn\u0027t generate RAs of a specific format, then the device should be fixed or the client should ignore it. Our iptables shouldn\u0027t be responsible for checking the correctness of the protocols.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"c12b33566f6e50fb4e1a8f76141ea1a5a2aae7ac","unresolved":false,"context_lines":[{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protection added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_f50386b6","line":22,"in_reply_to":"fa31d9ce_3a126db5","updated":"2017-02-10 14:26:12.000000000","message":"I don\u0027t know if there\u0027s a good reason for continuing to require a link-local address here. If there isn\u0027t then I agree we should remove the restriction. But that\u0027s a different change to the one being described in this commit message, so I want to make sure we\u0027re capturing it properly.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"49179c022c3eeed235141df8ff72f7ec1f7a6844","unresolved":false,"context_lines":[{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"},{"line_number":28,"context_line":"are able to reach the VM interface."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"1. I1d5c7aaa8e4cf057204eb746c0faab2c70409a94"},{"line_number":31,"context_line":"2. docs.openstack.org/mitaka/networking-guide/adv-config-ipv6.html"},{"line_number":32,"context_line":"3. Ice1c9dd349864da28806c5053e38ef86f43b7771"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_31043d16","line":29,"updated":"2017-02-10 23:49:10.000000000","message":"It doesn\u0027t say that\u0027s the only way to get an RA address. This change also doesn\u0027t mean that the other methods are guaranteed to provide an RA after this change. This change just makes the security groups code stop processing L3 backend-specific code.\n\nAs it stands, nobody can write an L3 plugin that issues RA addresses to instances unless they use the same exact device owners and interface structures as the in-tree plugin.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"42f9119361fbf3e0d35534ee6c665eab028ddc79","unresolved":false,"context_lines":[{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"},{"line_number":28,"context_line":"are able to reach the VM interface."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"1. I1d5c7aaa8e4cf057204eb746c0faab2c70409a94"},{"line_number":31,"context_line":"2. docs.openstack.org/mitaka/networking-guide/adv-config-ipv6.html"},{"line_number":32,"context_line":"3. Ice1c9dd349864da28806c5053e38ef86f43b7771"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_5a1721a3","line":29,"updated":"2017-02-10 13:56:27.000000000","message":"There is nothing in that guide that I can find that references security group filtering behavior.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"68d4d85abf7ce6cafd03963f2d66a18c0e9fbc16","unresolved":false,"context_lines":[{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"},{"line_number":28,"context_line":"are able to reach the VM interface."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"1. I1d5c7aaa8e4cf057204eb746c0faab2c70409a94"},{"line_number":31,"context_line":"2. docs.openstack.org/mitaka/networking-guide/adv-config-ipv6.html"},{"line_number":32,"context_line":"3. Ice1c9dd349864da28806c5053e38ef86f43b7771"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_464f4e92","line":29,"updated":"2017-02-10 12:33:54.000000000","message":"This will need a DocImpact flag as it changes the behavior described in [2].","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"6cbcf40dab024221e2abb611595e990678392074","unresolved":false,"context_lines":[{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"},{"line_number":28,"context_line":"are able to reach the VM interface."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"1. I1d5c7aaa8e4cf057204eb746c0faab2c70409a94"},{"line_number":31,"context_line":"2. docs.openstack.org/mitaka/networking-guide/adv-config-ipv6.html"},{"line_number":32,"context_line":"3. Ice1c9dd349864da28806c5053e38ef86f43b7771"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_955be786","line":29,"in_reply_to":"fa31d9ce_146aa01a","updated":"2017-02-13 12:41:42.000000000","message":"\u003eRight now that is the only documented way on that page to get an RA from a non-neutron router.\n\nA physical router managed by an L3 plugin is not a non-neutron router from the API users perspective. If the physical router is being configured in response to API calls, that router is a \u0027neutron router\u0027. It\u0027s just a router implemented by a namespace in the l3 agent.\n\nSo the line \"The ipv6_ra_mode is used to specify if the Networking service should transmit ICMPv6 packets, for a subnet.\" should not in any way be tied to the reference architecture. It should just mean that if I set that on a subnet, I can expect the Networking service to configure something to issue RAs.\n\n\u003eI\u0027m not sure what\u0027s standing in the way of plugin writers here (genuinely curious, if we\u0027re getting in the way then I\u0027m all for making things easier)\n\nWe have code checking for ports with specific device owners. This breaks L3 implementations based on service VMs (device owner would be compute). Also, the LLA calculation is performed assuming no architecture that might use different MAC addresses per compute node so that rules out some distributed routing approaches.\n\n*routing* solutions are being constrained by the assumptions being made in a  *security groups implementation*. \n\n\u003eHowever, what you\u0027re proposing is a big change to the way we handle RAs so it needs to be properly documented.\n\nThis is security groups filter code. Not the code that generates the RAs. Can you explain to me what you think this change will invalidate on that page?\n\nHere is the commit that originally added this logic: https://review.openstack.org/#/c/72252/ It was done entirely as a security feature to stop VMs from spoofing address generation. It was not done to define the addressing behavior of the in-tree code, that was already present and will still be present after this patch.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"c12f63ac9cffbe28484a25d2d8318cb9ff568b30","unresolved":false,"context_lines":[{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"},{"line_number":28,"context_line":"are able to reach the VM interface."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"1. I1d5c7aaa8e4cf057204eb746c0faab2c70409a94"},{"line_number":31,"context_line":"2. docs.openstack.org/mitaka/networking-guide/adv-config-ipv6.html"},{"line_number":32,"context_line":"3. Ice1c9dd349864da28806c5053e38ef86f43b7771"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_146aa01a","line":29,"in_reply_to":"fa31d9ce_31043d16","updated":"2017-02-13 11:09:58.000000000","message":"Right now that is the only documented way on that page to get an RA from a non-neutron router. I think we\u0027ve discovered some ways that it can be made clearer, so I\u0027d like to work on that. Other than possibly misunderstanding the purpose of the ipv6_ra_mode flag, and a desire to violate RFC 4861, I\u0027m not sure what\u0027s standing in the way of plugin writers here (genuinely curious, if we\u0027re getting in the way then I\u0027m all for making things easier). However, what you\u0027re proposing is a big change to the way we handle RAs so it needs to be properly documented.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"c12b33566f6e50fb4e1a8f76141ea1a5a2aae7ac","unresolved":false,"context_lines":[{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"},{"line_number":28,"context_line":"are able to reach the VM interface."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"1. I1d5c7aaa8e4cf057204eb746c0faab2c70409a94"},{"line_number":31,"context_line":"2. docs.openstack.org/mitaka/networking-guide/adv-config-ipv6.html"},{"line_number":32,"context_line":"3. Ice1c9dd349864da28806c5053e38ef86f43b7771"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_d5a04293","line":29,"in_reply_to":"fa31d9ce_5a1721a3","updated":"2017-02-10 14:26:12.000000000","message":"The part you\u0027ve quoted above:\n\n  Guest instance obtains IPv6 address from non-OpenStack\n  router using SLAAC\"[2] when ipv6_ra_mode is empty and\n  ipv6_address_mode is \u0027slaac\u0027\n\nWill no longer be the only way to get an RA from a non-openstack router if we fallback to the gateway_ip even when ipv6_ra_mode is set.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"63ff7d1227bde561c7c56a044070bcb0fed12dc5","unresolved":false,"context_lines":[{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"},{"line_number":28,"context_line":"are able to reach the VM interface."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"1. I1d5c7aaa8e4cf057204eb746c0faab2c70409a94"},{"line_number":31,"context_line":"2. docs.openstack.org/mitaka/networking-guide/adv-config-ipv6.html"},{"line_number":32,"context_line":"3. Ice1c9dd349864da28806c5053e38ef86f43b7771"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_9fa6a00e","line":29,"in_reply_to":"fa31d9ce_955be786","updated":"2017-02-13 14:53:26.000000000","message":"A physical router managed by an L3 plugin is not a non-neutron router\n  from the API users perspective.\n\nAgreed. The ipv6_ra_mode flag is there to differentiate between the two for the purpose of receiving RAs. This patch removes that differentiation and allows ports to receive RAs from non-neutron routers even if the subnet has been configured to receive RAs from neutron routers only (i.e, ipv6_ra_mode set and gateway_ip not set to the LLA of a non-neutron router).\n\n  We have code checking for ports with specific device owners. This breaks\n  L3 implementations based on service VMs (device owner would be\n  compute). Also, the LLA calculation is performed assuming no\n  architecture that might use different MAC addresses per compute node\n  so that rules out some distributed routing approaches.\n\nThe case of physical or service VM routers managed by L3 plugins doesn\u0027t appear to be supported here when the gateway IP is not or cannot be set to the router LLA. By supporting those cases in this way though, we\u0027re breaking the reference implementation as documented.\n\n  This is security groups filter code. Not the code that generates the RAs.\n  Can you explain to me what you think this change will invalidate on that\n  page?\n\nSpecifically, it will invalidate the mode combinations table [1] for supported combinations where ipv6_ra_mode is set to SLAAC or DHCPV6_STATELESS. Currently those modes indicate that RAs will be managed by neutron. After this change, it will be neutron OR a non-neutron router reachable via the gateway IP if a neutron router does not exist. This is of course assuming that clients will be able to pick up RAs from non-LLAs at all. If the client just discards the RA anyway as RFC 4861 requires that it should, then this change will just add an erroneous SG rule that doesn\u0027t address the problem described in the bug.\n\nI think the problem we should be looking at here is how can we determine the LLA of the device the RA is coming from when it isn\u0027t part of the reference L3 implementation? (As mentioned by xuhanp\u0027s TODO).\n\n[1] http://docs.openstack.org/newton/networking-guide/config-ipv6.html#ipv6-ra-mode-and-ipv6-address-mode-combinations","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"919f02c575528952c5b46e17b3d5ea194b7bbe07","unresolved":false,"context_lines":[{"line_number":26,"context_line":"may consider completely removing all of this code and just allowing all"},{"line_number":27,"context_line":"RAs since we should be able to trust anything that can generate RAs that"},{"line_number":28,"context_line":"are able to reach the VM interface."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"1. I1d5c7aaa8e4cf057204eb746c0faab2c70409a94"},{"line_number":31,"context_line":"2. docs.openstack.org/mitaka/networking-guide/adv-config-ipv6.html"},{"line_number":32,"context_line":"3. Ice1c9dd349864da28806c5053e38ef86f43b7771"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"fa31d9ce_01acf98a","line":29,"in_reply_to":"fa31d9ce_9fa6a00e","updated":"2017-02-14 00:26:07.000000000","message":"\u003eCurrently those modes indicate that RAs will be managed by neutron. After this change, it will be neutron OR a non-neutron router reachable via the gateway IP if a neutron router does not exist. \n\nThat\u0027s only if an operator has actually configured something to act as an RA for the tenant subnets, in which case there is absolutely no difference from the perspective of the user!\n\nIf I create a subnet and set the ipv6_ra_mode, I expect automatic address assignment without extra work. If the operator has scripted something based on listening to RPC events to configure a physical router to start issuing addresses, that\u0027s completely fine.\n\nAgain, this is security groups code and there is nothing documented on that page about security groups filtering.\n\n\u003eI think the problem we should be looking at here is how can we determine the LLA of the device the RA is \n\nNo. I\u0027m not interested in bringing even more IPv6 address assignment logic into the security groups code. Especially when the LLA of the device may be entirely invisible to the neutron data model (the examples I offered in the previous comment: distributed mac addresses, physical routers).\n\nDid you read my comment about why this code was originally added? It has nothing to do with enforcing ipv6_ra_mode semantics. It\u0027s for *anti-spoofing*, you know... a security groups feature. :)","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"d372fdf1c358c6bc9c88cd6d03f1a3ac9b1761c0","unresolved":false,"context_lines":[{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protection added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"fa31d9ce_8d4b1e2b","line":22,"updated":"2017-02-10 15:07:20.000000000","message":"Kevin - you had asked why the address must be link-local.  RFC 4861 Section 6.1.2 requires it:\n\nA node MUST silently discard any received Router Advertisement\n   messages that do not satisfy all of the following validity checks:\n\n      - IP Source Address is a link-local address.  Routers must use\n        their link-local address as the source for Router Advertisement\n        and Redirect messages so that hosts can uniquely identify\n        routers.","commit_id":"72113ce278d5b42fd0fde6fe531e7e3f6c4a3977"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"e99dbd99bdfa372e4fe5cf77a674708e31d19e37","unresolved":false,"context_lines":[{"line_number":19,"context_line":"to allow whatever the subnet gateway_ip is set to."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This should ensure that RAs will always work from the subnet gateway_ip"},{"line_number":22,"context_line":"in both Neutron router deployments and provider network deployments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This spoofing protection added by [1] is largely irrelevant now that"},{"line_number":25,"context_line":"we ensure VMs can\u0027t spoof RAs as part of [3]. In a follow-up patch, we"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"fa31d9ce_9409572f","line":22,"updated":"2017-02-10 23:49:16.000000000","message":"That should be up to the client (the VM). Not our security groups code.\n\nWe don\u0027t validate that HTTP traffic is RFC compliant in our SG code, I don\u0027t know why we are trying to do it with IPv6 ICMP messages. Maybe I should just go all the way with this change so we don\u0027t miss the forrest for the trees...","commit_id":"72113ce278d5b42fd0fde6fe531e7e3f6c4a3977"}],"neutron/db/securitygroups_rpc_base.py":[{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"dfe50a87a339bc5ce3883c48a4e48e4726c791a3","unresolved":false,"context_lines":[{"line_number":356,"context_line":"                if subnet[\u0027ipv6_ra_mode\u0027]:"},{"line_number":357,"context_line":"                    gateway_ip \u003d self._get_lla_gateway_ip_for_subnet("},{"line_number":358,"context_line":"                        context, subnet) or gateway_ip"},{"line_number":359,"context_line":"            if gateway_ip:"},{"line_number":360,"context_line":"                ips[subnet[\u0027network_id\u0027]].add(gateway_ip)"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"        return ips"}],"source_content_type":"text/x-python","patch_set":2,"id":"fa31d9ce_55729de6","line":359,"updated":"2017-02-10 09:59:12.000000000","message":"Ah, missed the early return on L353","commit_id":"28cc315302d72b014617f651a4c8c1c5ab4e34c1"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"52b96a072618898a6ca9b0f68ad7b9e14acf8acf","unresolved":false,"context_lines":[{"line_number":356,"context_line":"                if subnet[\u0027ipv6_ra_mode\u0027]:"},{"line_number":357,"context_line":"                    gateway_ip \u003d self._get_lla_gateway_ip_for_subnet("},{"line_number":358,"context_line":"                        context, subnet) or gateway_ip"},{"line_number":359,"context_line":"            if gateway_ip:"},{"line_number":360,"context_line":"                ips[subnet[\u0027network_id\u0027]].add(gateway_ip)"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"        return ips"}],"source_content_type":"text/x-python","patch_set":2,"id":"1a430d35_868a4962","line":359,"range":{"start_line":359,"start_character":12,"end_line":359,"end_character":25},"updated":"2017-02-09 12:58:59.000000000","message":"This is gonna be always true now.","commit_id":"28cc315302d72b014617f651a4c8c1c5ab4e34c1"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"087ab38482937943ab8ba4b21698cbf31273b794","unresolved":false,"context_lines":[{"line_number":356,"context_line":"                if subnet[\u0027ipv6_ra_mode\u0027]:"},{"line_number":357,"context_line":"                    gateway_ip \u003d self._get_lla_gateway_ip_for_subnet("},{"line_number":358,"context_line":"                        context, subnet) or gateway_ip"},{"line_number":359,"context_line":"            if gateway_ip:"},{"line_number":360,"context_line":"                ips[subnet[\u0027network_id\u0027]].add(gateway_ip)"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"        return ips"}],"source_content_type":"text/x-python","patch_set":2,"id":"fa31d9ce_ccbb6d74","line":359,"range":{"start_line":359,"start_character":12,"end_line":359,"end_character":25},"in_reply_to":"1a430d35_195ce6ec","updated":"2017-02-10 07:56:51.000000000","message":"I mean that if the code execution gets here, it\u0027s always \"something\". If  None is passed via API then it won\u0027t get to this line because of L353 will call continue. Which means that result of L357 with your change always sets geteway_ip to \"something\" and thus this will in all cases evaluated as True.","commit_id":"28cc315302d72b014617f651a4c8c1c5ab4e34c1"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"40a748af298d5af9bdac0f572b962393222fd7e2","unresolved":false,"context_lines":[{"line_number":356,"context_line":"                if subnet[\u0027ipv6_ra_mode\u0027]:"},{"line_number":357,"context_line":"                    gateway_ip \u003d self._get_lla_gateway_ip_for_subnet("},{"line_number":358,"context_line":"                        context, subnet) or gateway_ip"},{"line_number":359,"context_line":"            if gateway_ip:"},{"line_number":360,"context_line":"                ips[subnet[\u0027network_id\u0027]].add(gateway_ip)"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"        return ips"}],"source_content_type":"text/x-python","patch_set":2,"id":"1a430d35_195ce6ec","line":359,"range":{"start_line":359,"start_character":12,"end_line":359,"end_character":25},"in_reply_to":"1a430d35_868a4962","updated":"2017-02-09 19:34:00.000000000","message":"Unless it\u0027s not. :)\n\nhttps://github.com/openstack/neutron/blob/67da6a31224adf7d773805096b5e6ea07329bdc7/neutron/api/v2/attributes.py#L175","commit_id":"28cc315302d72b014617f651a4c8c1c5ab4e34c1"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"e36b2673d1dacb8e080f008e799e716097517951","unresolved":false,"context_lines":[{"line_number":355,"context_line":"            if not netaddr.IPAddress(gateway_ip).is_link_local():"},{"line_number":356,"context_line":"                if subnet[\u0027ipv6_ra_mode\u0027]:"},{"line_number":357,"context_line":"                    gateway_ip \u003d self._get_lla_gateway_ip_for_subnet("},{"line_number":358,"context_line":"                        context, subnet) or gateway_ip"},{"line_number":359,"context_line":"            if gateway_ip:"},{"line_number":360,"context_line":"                ips[subnet[\u0027network_id\u0027]].add(gateway_ip)"},{"line_number":361,"context_line":""}],"source_content_type":"text/x-python","patch_set":3,"id":"fa31d9ce_9e11adb2","line":358,"updated":"2017-02-09 22:44:41.000000000","message":"Can this be reversed?  gateway_ip \u003d gateway_ip or...\n\nWould save a DB lookup.","commit_id":"a5f35d07c2238108063e400cb48ecbd04459e224"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"20b78063dcf1e6966b59a384fc0bdbf997688fa7","unresolved":false,"context_lines":[{"line_number":355,"context_line":"            if not netaddr.IPAddress(gateway_ip).is_link_local():"},{"line_number":356,"context_line":"                if subnet[\u0027ipv6_ra_mode\u0027]:"},{"line_number":357,"context_line":"                    gateway_ip \u003d self._get_lla_gateway_ip_for_subnet("},{"line_number":358,"context_line":"                        context, subnet) or gateway_ip"},{"line_number":359,"context_line":"            if gateway_ip:"},{"line_number":360,"context_line":"                ips[subnet[\u0027network_id\u0027]].add(gateway_ip)"},{"line_number":361,"context_line":""}],"source_content_type":"text/x-python","patch_set":3,"id":"fa31d9ce_957415d0","line":358,"updated":"2017-02-10 09:59:20.000000000","message":"No, we only want to fallback to gateway_ip if the lookup fails (i.e. the router isn\u0027t a Neutron router). Otherwise the LLA calculation wouldn\u0027t ever be triggered.","commit_id":"a5f35d07c2238108063e400cb48ecbd04459e224"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"42f9119361fbf3e0d35534ee6c665eab028ddc79","unresolved":false,"context_lines":[{"line_number":354,"context_line":"                continue"},{"line_number":355,"context_line":"            if not netaddr.IPAddress(gateway_ip).is_link_local():"},{"line_number":356,"context_line":"                if subnet[\u0027ipv6_ra_mode\u0027]:"},{"line_number":357,"context_line":"                    # fallback to gateway_ip if router interface not present"},{"line_number":358,"context_line":"                    gateway_ip \u003d self._get_lla_gateway_ip_for_subnet("},{"line_number":359,"context_line":"                        context, subnet) or gateway_ip"},{"line_number":360,"context_line":"            ips[subnet[\u0027network_id\u0027]].add(gateway_ip)"}],"source_content_type":"text/x-python","patch_set":4,"id":"fa31d9ce_7a0ce594","line":357,"updated":"2017-02-10 13:56:27.000000000","message":"Except for when someone is not using the Neutron L3 plugin...","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"},{"author":{"_account_id":6635,"name":"John Davidge","email":"john.davidge@rackspace.com","username":"john-davidge"},"change_message_id":"68d4d85abf7ce6cafd03963f2d66a18c0e9fbc16","unresolved":false,"context_lines":[{"line_number":354,"context_line":"                continue"},{"line_number":355,"context_line":"            if not netaddr.IPAddress(gateway_ip).is_link_local():"},{"line_number":356,"context_line":"                if subnet[\u0027ipv6_ra_mode\u0027]:"},{"line_number":357,"context_line":"                    # fallback to gateway_ip if router interface not present"},{"line_number":358,"context_line":"                    gateway_ip \u003d self._get_lla_gateway_ip_for_subnet("},{"line_number":359,"context_line":"                        context, subnet) or gateway_ip"},{"line_number":360,"context_line":"            ips[subnet[\u0027network_id\u0027]].add(gateway_ip)"}],"source_content_type":"text/x-python","patch_set":4,"id":"fa31d9ce_46174ea3","line":357,"range":{"start_line":357,"start_character":20,"end_line":357,"end_character":76},"updated":"2017-02-10 12:33:54.000000000","message":"Why? If ipv6_ra_mode is set then RAs are expected to be handled by radvd managed by a neutron router.","commit_id":"5b293ef92ebc0909320e697198e492247fdfb5b3"}]}