Nice! 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.
So, this way of creating the iptables rules need to be reviewed. Tks! > On 28 Sep 2017, at 20:23, Sterdnot Shaken <sterdnotsha...@gmail.com > <mailto:sterdnotsha...@gmail.com>> wrote: > > I really appreciate your help Jorge and David! > > 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! > > Thanks again for your help!! > > Steve > > On Wed, Sep 27, 2017 at 6:13 PM, Jorge Luiz Correa <corre...@gmail.com > <mailto:corre...@gmail.com>> wrote: > Hum, nice inspection. > > Try to create rules that pass the IPv6 Multicast addresses and ICMPv6 > protocol. These are the addresses used by IPv6. > > FF02:0:0:0:0:0:1:2 All-dhcp-agents > FF05:0:0:0:0:0:1:3 All-dhcp-servers > > I think all-dhcp-agents is sufficient. > > https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml > > <https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml> > > Regards > > >> On 27 Sep 2017, at 20:44, Sterdnot Shaken <sterdnotsha...@gmail.com >> <mailto:sterdnotsha...@gmail.com>> wrote: >> >> 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. >> >> The DHCPv6 packets seem to be getting dropped by the last IPTables Drop rule: >> >> Chain neutron-openvswi-sd36b2151-0 (1 references) >> pkts bytes target prot opt in out source >> destination >> 0 0 RETURN all * * 2604:ba00:ffff:fff2::b ::/0 >> MAC FA:16:3E:05:C1:A3 /* Allow traffic from defined IP/MAC >> pairs. */ >> 0 0 RETURN all * * fe80::f816:3eff:fe05:c1a3 >> ::/0 MAC FA:16:3E:05:C1:A3 /* Allow traffic from defined >> IP/MAC pairs. */ >> 6475 895K DROP all * * ::/0 ::/0 >> /* Drop traffic without an IP/MAC allow rule. */ >> >> We've tried creating new Security Groups that explicitly allow ports, but >> still no luck: >> >> Ingress IPv6 UDP 1 - 65535 >> Egress IPv6 UDP 1 - 65535 >> >> Any ideas? >> >> Thanks! >> >> Steve >> >> >> >> On Tue, Sep 26, 2017 at 5:58 PM, Sterdnot Shaken <sterdnotsha...@gmail.com >> <mailto:sterdnotsha...@gmail.com>> wrote: >> Openstack version: Ocata >> Mech driver: OVS >> Security: Linuxbridge >> >> Hello! >> >> 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: >> >> openstack subnet create --allocation-pool >> start=2604:ffff:ffff:ffff::2,end=2604:ffff:ffff:ffff:ffff:ffff: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 >> >> 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... >> >> Any ideas? >> >> Thanks in advance! >> >> Steve >> >> _______________________________________________ >> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack> >> Post to : openstack@lists.openstack.org >> <mailto:openstack@lists.openstack.org> >> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack> > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack> > Post to : openstack@lists.openstack.org > <mailto:openstack@lists.openstack.org> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack> > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
