Public bug reported:
A newly created instance on an IPv6 subnet is provisioned with the
following ip6tables chain on the hypervisor:
tore@node-a3-02:~$ sudo ip6tables -vL neutron-openvswi-sb6a851ba-e
Chain neutron-openvswi-sb6a851ba-e (1 references)
pkts bytes target prot opt in out source destination
8869 1298K RETURN all any any
2001:db8:200:f020:f816:3eff:fea7:b27d anywhere MAC
FA:16:3E:A7:B2:7D /* Allow traffic from defined IP/MAC pairs. */
23 1820 DROP all any any anywhere anywhere
/* Drop traffic without an IP/MAC allow rule. */
This blocks outbound traffic from the instance sourced from addresses
other than the one mentioned in the RETURN rule. (Inbound traffic does
work fine though, and can can be observed in a tcpdump session on the
VM. Also ICMPv6 appears to be allowed elsewhere, so ping6 works.)
The logic appears to be based on a faulty assumption, namely that an
IPv6 node on a SLAAC subnet will only have a single IPv6 address, and
that this address has an EUI-64 based Interface ID.
That is, however, quite simply not how IPv6 works; when a host receives
an ICMPv6 Router Advertisement containing a /64 Prefix Information
Option with the Autonomous flag set, this essentially informs the host
that it can freely use *any* arbitrary address inside that /64 (provided
that it performs the Duplicate Address Detection algorithm). The host is
under no obligation to use the EUI-64 algorithm in order to constructs
its Interface ID. Even if it does use EUI-64, there is no requirement
that prevents it from at the same time self-configuring other addresses
using a different Interface ID generation algorithm.
This bug breaks the algorithms defined in RFC4941, RFC6877, RFC7217, I-D
.ietf-v6ops-siit-dc-2xlat, as well as any other application or use case
that requires multiple IPv6 addresses. See also I-D.ietf-v6ops-host-
addr-availability.
The fix should be trivial, namely to mask the source address in the
RETURN rule with a /64. (In the example above, it should have been
2001:db8:200:f020::/64 rather than
2001:db8:200:f020:f816:3eff:fea7:b27d. (Note that the ip6tables binary
will do so automatically if it is being given an address such as
"2001:db8:200:f020:f816:3eff:fea7:b27d/64".)
Tore
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1495433
Title:
IPv6 packets from non-EUI-64 addresses dropped on SLAAC subnets
Status in neutron:
New
Bug description:
A newly created instance on an IPv6 subnet is provisioned with the
following ip6tables chain on the hypervisor:
tore@node-a3-02:~$ sudo ip6tables -vL neutron-openvswi-sb6a851ba-e
Chain neutron-openvswi-sb6a851ba-e (1 references)
pkts bytes target prot opt in out source
destination
8869 1298K RETURN all any any
2001:db8:200:f020:f816:3eff:fea7:b27d anywhere MAC
FA:16:3E:A7:B2:7D /* Allow traffic from defined IP/MAC pairs. */
23 1820 DROP all any any anywhere anywhere
/* Drop traffic without an IP/MAC allow rule. */
This blocks outbound traffic from the instance sourced from addresses
other than the one mentioned in the RETURN rule. (Inbound traffic does
work fine though, and can can be observed in a tcpdump session on the
VM. Also ICMPv6 appears to be allowed elsewhere, so ping6 works.)
The logic appears to be based on a faulty assumption, namely that an
IPv6 node on a SLAAC subnet will only have a single IPv6 address, and
that this address has an EUI-64 based Interface ID.
That is, however, quite simply not how IPv6 works; when a host
receives an ICMPv6 Router Advertisement containing a /64 Prefix
Information Option with the Autonomous flag set, this essentially
informs the host that it can freely use *any* arbitrary address inside
that /64 (provided that it performs the Duplicate Address Detection
algorithm). The host is under no obligation to use the EUI-64
algorithm in order to constructs its Interface ID. Even if it does use
EUI-64, there is no requirement that prevents it from at the same time
self-configuring other addresses using a different Interface ID
generation algorithm.
This bug breaks the algorithms defined in RFC4941, RFC6877, RFC7217,
I-D.ietf-v6ops-siit-dc-2xlat, as well as any other application or use
case that requires multiple IPv6 addresses. See also I-D.ietf-v6ops-
host-addr-availability.
The fix should be trivial, namely to mask the source address in the
RETURN rule with a /64. (In the example above, it should have been
2001:db8:200:f020::/64 rather than
2001:db8:200:f020:f816:3eff:fea7:b27d. (Note that the ip6tables binary
will do so automatically if it is being given an address such as
"2001:db8:200:f020:f816:3eff:fea7:b27d/64".)
Tore
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1495433/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
