[RFE] Support metadata service with IPv6-only tenant network

Bug #1460177 reported by Baodong (Robert) Li on 2015-05-29
This bug affects 15 people
Affects Status Importance Assigned to Milestone

Bug Description

EC2 metatdata service is supported by nova metadata service that is running in the management network. Cloud-init running in the instance normally accesses the service at Cloud-init can be configured with metadata_urls other than the default to access the service. But such configuration is not currently supported by openstack. In order for the instance to access the nova metadata service, neutron provides proxy service that terminates and forwards the request to the nova metadata service, and responds back to the instance. Apparently, this works only when IPv4 is available in the tenant network. For an IPv6-only tenant work, to continue the support of this service, the instance has to access it at an IPv6 address. This requires enhancement in Neutron to support it.

A few options have been discussed so far:
   -- define a well-known ipv6 link-local address to access the metadata service.
   -- enhance IPv6 RA to advertise the metadata service endpoint to instances. This would require standards work and enhance cloud-init to support it.
   -- define a well-known name for the metadata service and configure metadata_urls to use the name. The name will be resolved to a datacenter specific IP address. The corresponding DNS record should be pre-provisioned in the datacenter DNS server for the instance to resolve the name.

description: updated
Henry Gessau (gessau) on 2015-05-29
description: updated
summary: - Support metadata service with IPv6 only tenant network
+ Support metadata service with IPv6-only tenant network

I can't really recommend the use of a link-local address in a network without NATs; the use of (an IPv4 link-local address) depends on a NAT or a proxy. I can recommend a DNS SRV record (a well-known name), an RA option that advertises the relevant metadata server address, or an anycast address (http://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml).

Fred Baker (b-fred) wrote :

However, I'll support the need to deploy a metadata service. Anyone that is using metadata for IPv4 is likely to want to implement IPv6 the same way, and we already have people turning IPv4 off.

Ian Wells (ijw-ubuntu) wrote :

In the case of the DNS record, we can implement this in Openstack by ensuring that the record is in the local Openstack-administrated DNS server. The DNS server is already provided to the VMs by SLAAC. If the user overrides or turns off DNS they would be on their own recognisance (which is what happens today with DHCPv4).

In fact, if we use a SRV we require two records, the SRV and the AAAA for the hostname referred to by the SRV. Given that cloud-init takes a list of URLs and that I can't find anything that uses SRV in the resolution of URLs (*), we might instead just want to go with a well known hostname that will have a specific address assigned to it when used from within an Openstack cloud.

Unstated above is the aim that we don't just choose a well-known address for a v6 metadata server. Firstly, it's hard to choose one (the v4 metadata server is using an inappropriate address per v4 standards to get around the problem of accidentally stealing someone else's address away) and secondly there's no really appropriate address category we fall into. We could get a v6 anycast address assigned by IANA, but the service is not technically anycast.

(*) It seems that Chrome won't fix this and the Firefox bug for it is 15 years old. I admit I've not checked wget and curl, mind, but that's still quite a precedent.

Kyle Mestery (mestery) wrote :

I think we agree this feature is needed. Lets bike shed on the solution once Robert posts some devref documentation for it.

Changed in neutron:
status: New → Confirmed
Kyle Mestery (mestery) wrote :

Moving to Triaged, we discussed this in the neutron-drivers meeting and work can now proceed on this.

Changed in neutron:
status: Confirmed → Triaged
Sean M. Collins (scollins) wrote :

Before we get too far into this - let's remember that the metadata API is an Amazon EC2 compatibility feature.

We cannot make changes to this API - we do not own this API contract. Amazon is the owner of this API and their documentation and cloud is where this API is controlled. If we start making changes to this API, that are incompatible, or will be incompatible if/when Amazon decides to implement IPv6 on their cloud, we will have broken this contract with our users that OpenStack has a compatibility layer for apps that rely on AWS APIs - if we end up implementing it in a way that Amazon later chooses to implement differently.

In the case where OpenStack has innovated in ways that has beaten Amazon to the market (like, for instance, IPv6 functionality) we should not try and "fix" someone's API contract for them. Instead, we should provide compelling alternatives (such as Config-Drive) as the way to use metadata in IPv6 clouds.


Ian Wells (ijw-ubuntu) wrote :

Firstly, we have made changes to this API and we pass data in both the Amazon and now also Openstack formats (at the same time) - the cloud-init script in the VM can try to use either and gets the data in the form it expects.

Secondly, adding a new endpoint address for IPv6 does not stop us from keeping compatibility with EC2 in the future by adding whatever address they come up with to the endpoints in the future. But they don't have one so there's nothing here we can do right now other than invent for ourselves or do nothing at all, and I don't think either is wise.

We are fine with API compatibility as long as what we offer is a superset of EC2. Listening on another (IPv6) address is most definitely a superset.

James Page (james-page) on 2015-07-24
Changed in neutron (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
tags: added: rfe-approved
removed: rfe
Changed in neutron:
importance: Undecided → Wishlist
Sean M. Collins (scollins) wrote :

Frankly I'd vote this as WONTFIX due to issues discussed on the mailing list

Changed in neutron:
milestone: none → mitaka-1
Changed in neutron:
milestone: mitaka-1 → none
tags: removed: rfe-approved
Changed in neutron:
status: Triaged → Incomplete

I am not biased one way or the other and I can see both sides of the arguments. Based on the lack of consensus and in the absence of someone volunteering to resolve/define the course of action, I can't see how this can be targeted/approved.

James Page (james-page) on 2016-02-22
no longer affects: neutron (Ubuntu)
Ian Wells (ijw-ubuntu) wrote :

james-page: could you explain why?

Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
Henry Gessau (gessau) wrote :

More discussion is happening in the spec, https://review.openstack.org/315604

tags: added: rfe
summary: - Support metadata service with IPv6-only tenant network
+ [RFE] Support metadata service with IPv6-only tenant network
Changed in neutron:
status: Expired → Incomplete
tags: added: ipv6
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/315604
Reason: Comments on bug report seems to hint this effort has been abandoned. Please resume, if you intend to proceed.

Miguel Lavalle (minsel) on 2018-05-29
Changed in neutron:
status: Expired → Triaged
tags: added: rfe-triaged
removed: rfe
YAMAMOTO Takashi (yamamoto) wrote :

has the situation changed since the last time this has been discussed on the ML a few years ago?
in AWS, or cloud-init.

Brian Haley (brian-haley) wrote :

And I have another question. Say neutron and cloud-init can be upgraded to support an IPv6-only metadata request. Are there additional changes required to the API? For example, there is a local-ipv4 value today, is a local-ipv6 needed? I'm confused by the wording of the 'network/interfaces/macs/mac/ipv6s' field - "The IPv6 addresses associated with the interface. Returned only for instances launched into a VPC." - local-ipv4 doesn't mention VPC.

YAMAMOTO Takashi (yamamoto) wrote :


just because non VPC (EC2-Classic?) doesn't support ipv6?

Miguel Lavalle (minsel) on 2018-11-07
tags: added: rfe-postponed
removed: rfe-triaged
Romain Meillon (rmeillon) wrote :

With all my respect, don't you think it is time to go on this RFE ?
I cannot imagine how many cases are openned in openstack vendors because of this.
Config drive is not supported in major OS distributions.

Changed in neutron:
milestone: none → ussuri-1
Changed in neutron:
milestone: ussuri-1 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers