[RFE] DHCP agent should provide ipv6 RAs for isolated networks with ipv6 subnets

[Ihar Hrachyshka]

Currently, if there is no router attached to a subnet, then instances cannot walk thru IPv6 address assignment because there is nothing on the network that multicasts RAs that would provide basic info about how ipv6 addressing is handled there. We can have DHCP agent to run radvd in that case. Then instances would be able to receive IPv6 addresses on isolated networks too.

We could try to rely on https://tools.ietf.org/html/rfc4191.

[Carl Baldwin (carl-baldwin)]

I'm now thinking that Router Lifetime option here [1] might be the way to go. Set it to 0 and the DHCP server shouldn't be used as a default route.

[1] https://tools.ietf.org/html/rfc4861#section-4.2

[Armando Migliaccio (armando-migliaccio)]

Ack. We'll discuss at the drivers meeting

[Armando Migliaccio (armando-migliaccio)]

I guess we never did (discuss this), even though seems trivial enough.

[Ihar Hrachyshka (ihar-hrachyshka)]

First discussion in IRC: http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-09-23.log.html#t2015-09-23T15:49:47

[Sean M. Collins (scollins)]

Nice digging Ihar :)

So yeah it's just about seeing if Carl's idea works (router lifetime of 0)

[Brian Haley (brian-haley)]

I wonder whether you can tweak the dnsmasq startup line to do what we want, as it can already support DHCPv6, which will help not involving radvd in this isolated network case.

It should just be a few small changes - adding 'slaac' as the <mode> argument in the --dhcp-range line, adding '--enable-ra', and specifying '--ra-param=low,0,0' to get a zero lifetime from my reading of the man page.

Just a thought.

[Armando Migliaccio (armando-migliaccio)]

Based on the discussion [1], I'd say this should be given the go ahead in principle, but it also feels like it's not an RFE (hoping the code fix looks rather clean).

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-15-15.01.log.html

[Ihar Hrachyshka (ihar-hrachyshka)]

I believe the bug should be retargeted to N. It's not something we should rush in M since it's not a critical issue, and someone may say it's a new feature.

[Ihar Hrachyshka (ihar-hrachyshka)]

I am sorry but I probably won't have time for that, so I unassigned myself. Anyone interested can grab the bug.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/393007

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/393007
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=11c3f0cafd62f9f9b46fd494f9cc6c372f77b1c9
Submitter: Jenkins
Branch: master

commit 11c3f0cafd62f9f9b46fd494f9cc6c372f77b1c9
Author: Dustin Lundquist <email address hidden>
Date: Wed Nov 2 16:50:04 2016 -0700

    DHCP agent: advertise SLAAC prefixes

    Advertise IPv6 SLAAC prefixes via router advertisements with router
    lifetime of zero so prefix can be discovered on isolated networks.
    Since the router lifetime of these RAs is zero, they will not be used as
    a next hop. Implementing this now so Octavia can use an isolated IPv6
    network.

    Change-Id: I4a9c2018606d1729465612206f8e8e2fc4922516
    Closes-bug: #1498987
    Related-bug: #1407573

[Ihar Hrachyshka (ihar-hrachyshka)]

We revert the patch since it broke CentOS installations. Reopening the bug.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 10.0.0.0b2 development milestone.

[Dr. Jens Harbott (j-harbott)]

A dhcp agent is no router, so IMO it should not be sending router advertisements. If people want slaac to work on an isolated network, why can't they just attach a router without a gateway? We could then fix the l3 code to set the router lifetime to zero if the router has no gateway set (if that should not yet be the case).

[Ihar Hrachyshka (ihar-hrachyshka)]

Indeed it's just a matter of convenience. We may have punted it.

The reason why I suggested to send RAs in isolated networks is that we also serve other services for those networks, like metadata, even though you could argue that should not have worked either. Since RAs may be central to instance configuration, I felt like it's worth exploring sending them in all tenant topologies.

[Lajos Katona (lajos-katona)]

As I see the history we can close this with won't fix if you think please reopen this RFE