← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1495465] [NEW] RDNSS Option should be included in ICMPv6 Router Advertisements

 

Public bug reported:

The ICMPv6 Router Advertisements on an IPv6 subnet handled by Neutron
does not contain the Recursive DNS Server Option, even though the subnet
has been created with an appropriate "dns_nameservers" parameter. This
means that instances on a subnet using SLAAC does not learn any DNS
servers, and thus cannot resolve any hostnames after being provisioned.
That is likely to break lots of things, such as further provisioning of
applications to the instance.

The RDNSS option is documented in RFC 6106. It can be configured in
radvd.conf using the following syntax:

interface qr-foo {
  RDNSS server1 [server2 ...] {
    # this is optional, but prevents problems noted in the second bullet of
    # https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-02#appendix-B
    AdvRDNSSLifetime infinity;
  };
};

Observed on OpenStack Kilo.

Note: It might be that using DHCPv6 in some capacity would work around
this issue. I have not yet tested this, though.

** 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/1495465

Title:
  RDNSS Option should be included in ICMPv6 Router Advertisements

Status in neutron:
  New

Bug description:
  The ICMPv6 Router Advertisements on an IPv6 subnet handled by Neutron
  does not contain the Recursive DNS Server Option, even though the
  subnet has been created with an appropriate "dns_nameservers"
  parameter. This means that instances on a subnet using SLAAC does not
  learn any DNS servers, and thus cannot resolve any hostnames after
  being provisioned. That is likely to break lots of things, such as
  further provisioning of applications to the instance.

  The RDNSS option is documented in RFC 6106. It can be configured in
  radvd.conf using the following syntax:

  interface qr-foo {
    RDNSS server1 [server2 ...] {
      # this is optional, but prevents problems noted in the second bullet of
      # https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-02#appendix-B
      AdvRDNSSLifetime infinity;
    };
  };

  Observed on OpenStack Kilo.

  Note: It might be that using DHCPv6 in some capacity would work around
  this issue. I have not yet tested this, though.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1495465/+subscriptions


Follow ups