Re: Metadata over IPv6

On 12/17/19 3:36 PM, Fred Baker wrote:
> Thanks for the question.
> 
> What comes quickly to mind is RFC 1546, which describes a local "Host Anycasting Service". Related, https://tools.ietf.org/html/rfc4291#section-2.6 and https://tools.ietf.org/html/rfc4291#section-2.7, which respectively talk about local anycast and scoped multicast (one of the scopes being "local").
> 
> The bit pattern of a link-local address might be useful. That said, I would want this to not be "one-of", known by a few that happen to use a proprietary service (AWS), but consistent with the IPv6 addressing architecture and openly documented. From that perspective, I should think I might want a short RFC (I can help with drafting, if you like) that identifies the bit pattern and talks about it a bit.
> 
> When documented in that way, one could imagine IANA picking it up. They do that.

Hi Fred,

So it seems you and Mark are of the same mindset that I should request a 
new anycast allocation for this, which I'm fine with because it becomes 
official, even if it does take more time.  It should be a very short draft.

And just for my own sanity, this anycast address would apply to an 
address of any scope, correct?  For example, given 7c is the next one 
available:

fe80::7c
2001:db8::7c

I just want to make sure I cover the case where there isn't any 
configured IPv6 address besides the link-local.

Thanks,

-Brian

>> On Dec 17, 2019, at 8:41 AM, Brian Haley <haleyb.dev@gmail.com> wrote:
>>
>> Hi ipv6-list,
>>
>> I was an IPv6 contributor many moons ago, and remembered this list when looking into something on a new project, was hoping to get some IPv6 advice (below).
>>
>> The current project I'm working on, Openstack Neutron, is an SDN networking project focused on delivering networking-as-a-service (NaaS) in virtual compute environments.
>>
>> One thing that happens when a virtual machine boots is it typically asks for metadata, thing like ssh keys, and other configuration information required to make it functional.  It does this via requests to the URL http://169.254.169.254/latest/meta-data/... ([0] has more complete info).  This link-local IPv4 address was defined by AWS and is widely used across all types of clouds.
>>
>> This works fine for dual-stack hosts, but more and more we're seeing IPv6-only networking scenarios that we don't support metadata with, so our community is looking to define an IPv6 address to use for this service.  My question to the list is - do you see a problem with us just defining an IPv6 link-local address for this same service?  Or do you think we need to propose a spec for it, in order to get IANA to reserve it?  We're trying to use a similar address, fe80::a9fe:a9fe (169.254.169.254 in hex - see [1] for more details), so it essentially looks the same.  We did think about using DNS to discover it, but for now just using a hard-coded link-local seems like a quicker way forward.
>>
>> Thanks for any comments or advice!
>>
>> -Brian Haley
>>
>> [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
>> [1] https://review.opendev.org/#/c/315604/
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 