<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Nice!<div class=""><br class=""></div><div class=""><div class="">It would be good if developers could know about that because privacy extension is becoming the default on every operate systems. I've tested last version of *ubuntu and some FreeBSD kernels, all operating with privacy extension by default. </div><div class=""><br class=""></div><div class="">So, this way of creating the iptables rules need to be reviewed. </div><div class=""><br class=""></div><div class="">Tks!</div></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 28 Sep 2017, at 20:23, Sterdnot Shaken <<a href="mailto:sterdnotshaken@gmail.com" class="">sterdnotshaken@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">I really appreciate your help Jorge and David! <br class=""><br class=""></div>After far to many hours of troubleshooting the root cause ended up being caused by the IPv6 Privacy Extensions (RFC 4941) that is on with Windows by default... Had I mentioned these issues were happening on a Windows instance, you guys would have undoubtedly zeroed in on this root cause too. With Privacy Extensions, Windows 10 was contriving a random arrangement for the host bits of the IPv6 address, instead of using the EUI-64 construct that Openstack was expecting for the Link Local address. Some folks on the Neutron IRC channel really helped out with pointing us in the correct direction. Looking closer at the iptables ruleset associated with the respective VM, we noticed the Chain that verified the source Link Local IPv6 address was the EUI-64 format showed a different Link Local address then what Windows had assigned to it's NIC. Once we turned off Privacy Extensions in Windows 10, DHCPv6 worked like a charm!<br class=""><br class=""></div>Thanks again for your help!!<br class=""><br class=""></div>Steve<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Sep 27, 2017 at 6:13 PM, Jorge Luiz Correa <span dir="ltr" class=""><<a href="mailto:correajl@gmail.com" target="_blank" class="">correajl@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hum, nice inspection.<div class=""><br class=""></div><div class="">Try to create rules that pass the IPv6 Multicast addresses and ICMPv6 protocol. These are the addresses used by IPv6. </div><div class=""><br class=""></div><div class=""><table id="m_256078563199918059table-link-local" class="m_256078563199918059sortable" style="border-collapse: collapse; border: 0px; margin: 1em 0px; font-family: 'Open Sans', 'Helvetica Neue', Helvetica, sans-serif; font-size: 13.333333015441895px;"><tbody class=""><tr style="border-top-width:1px;border-top-style:solid;border-top-color:rgb(236,239,248)" class=""><td style="padding-left:0.5em;padding-right:0.5em;vertical-align:top;font-family:monospace" class="">FF02:0:0:0:0:0:1:2</td><td style="padding-left:0.5em;padding-right:0.5em;vertical-align:top" class="">All-dhcp-agents</td></tr></tbody></table><div class=""><table id="m_256078563199918059table-site-local" class="m_256078563199918059sortable" style="border-collapse: collapse; border: 0px; margin: 1em 0px; font-family: 'Open Sans', 'Helvetica Neue', Helvetica, sans-serif; font-size: 13.333333015441895px;"><tbody class=""><tr style="border-top-width:1px;border-top-style:solid;border-top-color:rgb(236,239,248)" class=""><td style="padding-left:0.5em;padding-right:0.5em;vertical-align:top;font-family:monospace" class="">FF05:0:0:0:0:0:1:3</td><td style="padding-left:0.5em;padding-right:0.5em;vertical-align:top" class="">All-dhcp-servers</td></tr></tbody></table><div class=""><br class=""></div></div></div><div class="">I think all-dhcp-agents is sufficient. </div><div class=""><br class=""></div><div class=""><a href="https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml" target="_blank" class="">https://www.iana.org/<wbr class="">assignments/ipv6-multicast-<wbr class="">addresses/ipv6-multicast-<wbr class="">addresses.xhtml</a></div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On 27 Sep 2017, at 20:44, Sterdnot Shaken <<a href="mailto:sterdnotshaken@gmail.com" target="_blank" class="">sterdnotshaken@gmail.com</a>> wrote:</div><br class="m_256078563199918059Apple-interchange-newline"></div></div><div class=""><div class=""><div class="h5"><div dir="ltr" class=""><div class=""><div class="">So, after more digging, it appears DHCPv6 traffic coming from the test VM's is being dropped at the Security Group (Linux Bridge) enforcement point ... I can restart a VM's while doing a tcpdump on the respective tap interface for that VM and see DHCPv6 request packets being sent out as expected, but they never make it through the IPTables rules associated with the Linux Bridge that represents the Security Group assigned to the VM. Hopefully that makes sense.<br class=""><br class=""></div>The DHCPv6 packets seem to be getting dropped by the last IPTables Drop rule:<br class=""><br class="">Chain neutron-openvswi-sd36b2151-0 (1 references)<br class=""> pkts bytes target prot opt in out source destination <br class=""> 0 0 RETURN all * * 2604:ba00:ffff:fff2::b ::/0 MAC FA:16:3E:05:C1:A3 /* Allow traffic from defined IP/MAC pairs. */<br class=""> 0 0 RETURN all * * fe80::f816:3eff:fe05:c1a3 ::/0 MAC FA:16:3E:05:C1:A3 /* Allow traffic from defined IP/MAC pairs. */<br class=""><b class=""> 6475 895K DROP all * * ::/0 ::/0 /* Drop traffic without an IP/MAC allow rule. */</b><br class=""><br class=""></div>We've tried creating new Security Groups that explicitly allow ports, but still no luck:<br class=""><br class="">Ingress IPv6 UDP 1 - 65535<br class="">Egress IPv6 UDP 1 - 65535<br class=""><br class=""><div class=""><div class=""><div class="">Any ideas?</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">Steve<br class=""></div><div class=""><br class=""><br class=""></div></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Sep 26, 2017 at 5:58 PM, Sterdnot Shaken <span dir="ltr" class=""><<a href="mailto:sterdnotshaken@gmail.com" target="_blank" class="">sterdnotshaken@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class="">Openstack version: Ocata</div><div class="">Mech driver: OVS</div><div class="">Security: Linuxbridge<br class=""></div><div class=""><br class=""></div><div class="">Hello! <br class=""></div><div class=""><br class=""></div><div class="">Anyone have any idea why DHCP for IPv4 works fine but DHCP for IPv6 doesn't? With Stateless or just SLAAC, the VM's calculate a correct IPv6 address from the IPv6 prefix I've assigned, but (for stateless) the instances doesn't get any of the options, like DNS, etc... Stateful doesn't work at all. I configure a stateful network using a command like this:</div><div class=""><br class=""></div><div class="">openstack subnet create --allocation-pool start=2604:ffff:ffff:ffff::2,e<wbr class="">nd=2604:ffff:ffff:ffff:ffff:ff<wbr class="">ff:ffff:ffff --ip-version 6 --ipv6-address-mode dhcpv6-stateful --ipv6-ra-mode dhcpv6-stateful --dns-nameserver 2620:0:ccc::2 --network cust01-v6_net0 --subnet-range 2604:ffff:ffff:ffff::/64 cust01-v6_sub0 <br class=""><br class=""></div>But none of the instances added to that network acquire a v6 address ever. I can statically assign the selected IPv6 address to the respective instance and it can then ping out using v6 just fine. I can also add IPv6 DNS addresses to resolv.conf and the instance can correctly resolve as well. This issue happens on both Linux and Windows instances...<br class=""><br class=""></div>Any ideas?<br class=""><br class=""></div>Thanks in advance!<br class=""><br class=""></div>Steve<br class=""></div>
</blockquote></div><br class=""></div></div></div><span class="">
______________________________<wbr class="">_________________<br class="">Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank" class="">http://lists.openstack.org/<wbr class="">cgi-bin/mailman/listinfo/<wbr class="">openstack</a><br class="">Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank" class="">openstack@lists.openstack.org</a><br class="">Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank" class="">http://lists.openstack.org/<wbr class="">cgi-bin/mailman/listinfo/<wbr class="">openstack</a><br class=""></span></div></blockquote></div><br class=""></div></div><br class="">______________________________<wbr class="">_________________<br class="">
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/<wbr class="">cgi-bin/mailman/listinfo/<wbr class="">openstack</a><br class="">
Post to : <a href="mailto:openstack@lists.openstack.org" class="">openstack@lists.openstack.org</a><br class="">
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/<wbr class="">cgi-bin/mailman/listinfo/<wbr class="">openstack</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>