yahoo-eng-team team mailing list archive

["Sean M. Collins" <sean@xxxxxxxxxxxxx>]

** Changed in: neutron
       Status: New => Opinion

** Tags added: ipv6

-- 
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:
  Opinion

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