settingsLogin | Registersettings

[Openstack] DHCP for IPv6

0 votes

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-v6net0
--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
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
asked Sep 29, 2017 in openstack by Sterdnot_Shaken (900 points)   1 4 8

8 Responses

0 votes

Hi Steve!

I don’t remember if when I did all configurations here this combination was available (dhcpv6-stateful and dhcpv6-stateful). Anyway, I can tell I couldn't do dhcpv6 work well. I`m using Mitaka and dhcpv6-stateless - dhcpv6-stateless.

Everything works when configuring manually. The addresses works well here because I'm using prefix delegation and slaac generates them. However, the dhcpv6 options didnt work because virtual machines never ask for them. If I run dhcpv6 request manually, yes, it works. Ive asked for help in a topic about cloud-init but no fix, just another member with the same problem.

https://ask.openstack.org/en/question/107308/how-to-use-ipv6_ra_mode-dhcpv6-stateless-ipv6_address_mode-dhcpv6-stateless/

Test if your VMs are really asking for something! Maybe you have to use tcpdump inside "net ns ... namespace ... exec ... tcpdump etc” … Or not, because you are using linuxbridge.

Regards.

On 26 Sep 2017, at 20:58, Sterdnot Shaken sterdnotshaken@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-v6net0 --subnet-range 2604:ffff:ffff:ffff::/64 cust01-v6sub0

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
Post to : openstack@lists.openstack.org
Unsubscribe : 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
responded Sep 27, 2017 by Jorge_Luiz_Correa (900 points)   1 5 6
0 votes

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 sterdnotshaken@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-v6net0 --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
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
responded Sep 27, 2017 by Sterdnot_Shaken (900 points)   1 4 8
0 votes

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 sterdnotshaken@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 <sterdnotshaken@gmail.com sterdnotshaken@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-v6net0 --subnet-range 2604:ffff:ffff:ffff::/64 cust01-v6sub0

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
Post to : openstack@lists.openstack.org
Unsubscribe : 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

responded Sep 28, 2017 by Jorge_Luiz_Correa (900 points)   1 5 6
0 votes

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 correajl@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

Regards

On 27 Sep 2017, at 20:44, Sterdnot Shaken sterdnotshaken@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 <sterdnotshaken@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,e
nd=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-v6net0 --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
Post to : openstack@lists.openstack.org
Unsubscribe : 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


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
responded Sep 28, 2017 by Sterdnot_Shaken (900 points)   1 4 8
0 votes

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 <sterdnotshaken@gmail.com sterdnotshaken@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 <correajl@gmail.com correajl@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 <sterdnotshaken@gmail.com sterdnotshaken@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 <sterdnotshaken@gmail.com sterdnotshaken@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-v6net0 --subnet-range 2604:ffff:ffff:ffff::/64 cust01-v6sub0

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
Post to : openstack@lists.openstack.org openstack@lists.openstack.org
Unsubscribe : 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 openstack@lists.openstack.org
Unsubscribe : 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
responded Sep 28, 2017 by Jorge_Luiz_Correa (900 points)   1 5 6
0 votes

On 2017-09-28 20:29:38 -0300 (-0300), Jorge Luiz Correa wrote:
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.
[...]

To accommodate privacy extensions, we'd basically have to give up on
any assumptions as to what the viable source addresses originating
on a port could be (at least within the netmask). This filtering is
the primary mechanism for preventing address spoofing within a
shared network.

By comparison, RFC 4941 privacy extensions are primarily a
protection for desktop/mobile client systems and do little (if
anything) useful for a statically-addressed server. Disabling it
there makes a lot of sense to me, as a privacy/security-conscious
sysadmin.
--
Jeremy Stanley


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

responded Sep 29, 2017 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

Thanks for explain Jeremy! Very clear.

I think systems with cloud-init enabled, like most images, can be easily configured to disable this feature.

Thank you!
:)

On 28 Sep 2017, at 21:37, Jeremy Stanley fungi@yuggoth.org wrote:

On 2017-09-28 20:29:38 -0300 (-0300), Jorge Luiz Correa wrote:

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.
[...]

To accommodate privacy extensions, we'd basically have to give up on
any assumptions as to what the viable source addresses originating
on a port could be (at least within the netmask). This filtering is
the primary mechanism for preventing address spoofing within a
shared network.

By comparison, RFC 4941 privacy extensions are primarily a
protection for desktop/mobile client systems and do little (if
anything) useful for a statically-addressed server. Disabling it
there makes a lot of sense to me, as a privacy/security-conscious
sysadmin.
--
Jeremy Stanley


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


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
responded Sep 29, 2017 by Jorge_Luiz_Correa (900 points)   1 5 6
0 votes

BTW, the networking guide does mention this, found after Steve figure
out what the problem was.

https://docs.openstack.org/ocata/networking-guide/config-ipv6.html#configuring-interfaces-of-the-guest

-Brian

On 09/28/2017 08:49 PM, Jorge Luiz Correa wrote:
Thanks for explain Jeremy! Very clear.

I think systems with cloud-init enabled, like most images, can be easily configured to disable this feature.

Thank you!
:)

On 28 Sep 2017, at 21:37, Jeremy Stanley fungi@yuggoth.org wrote:

On 2017-09-28 20:29:38 -0300 (-0300), Jorge Luiz Correa wrote:

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.
[...]

To accommodate privacy extensions, we'd basically have to give up on
any assumptions as to what the viable source addresses originating
on a port could be (at least within the netmask). This filtering is
the primary mechanism for preventing address spoofing within a
shared network.

By comparison, RFC 4941 privacy extensions are primarily a
protection for desktop/mobile client systems and do little (if
anything) useful for a statically-addressed server. Disabling it
there makes a lot of sense to me, as a privacy/security-conscious
sysadmin.
--
Jeremy Stanley


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


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


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
responded Oct 2, 2017 by haleyb.dev_at_gmail. (880 points)  
...