IETF Logo Mail Archive

Re: Metadata over IPv6

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 19 December 2019 14:25 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BD612083E for <ipv6@ietfa.amsl.com>; Thu, 19 Dec 2019 06:25:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd874bLOb0kr for <ipv6@ietfa.amsl.com>; Thu, 19 Dec 2019 06:25:40 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A5012082F for <ipv6@ietf.org>; Thu, 19 Dec 2019 06:25:39 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBJEPcf8006484 for <ipv6@ietf.org>; Thu, 19 Dec 2019 15:25:38 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2AFAE20431F for <ipv6@ietf.org>; Thu, 19 Dec 2019 15:25:38 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2047E204224 for <ipv6@ietf.org>; Thu, 19 Dec 2019 15:25:38 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBJEPchp021579 for <ipv6@ietf.org>; Thu, 19 Dec 2019 15:25:38 +0100
Subject: Re: Metadata over IPv6
To: ipv6@ietf.org
References: <eee1ebe3-dd1a-1a5b-21a8-739857995abf@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <87143a68-b68c-40b3-60f9-d41885191fa8@gmail.com>
Date: Thu, 19 Dec 2019 15:25:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
MIME-Version: 1.0
In-Reply-To: <eee1ebe3-dd1a-1a5b-21a8-739857995abf@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BHVSTKaGWgS1AAnZXqi-HgDYbq4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 14:25:43 -0000


Le 17/12/2019 à 17:41, Brian Haley a écrit :
> 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.

Do the ssh keys depend on IP address or not? (username@address, or 
something else).

Is the 'other conf info req'd to make it functional' something closer to 
IP layer or closer to app layer?

These could help think whether we look more towards an IP kind of 
solution (reserve ll address) or more like an upper layer service kind 
of solution.

Alex

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

v2.23.0 | Report a Bug | By Email