Re: Metadata over IPv6

Mark Smith <markzzzsmith@gmail.com> Tue, 17 December 2019 20:32 UTC

Return-Path: <markzzzsmith@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 D9F84120077 for <ipv6@ietfa.amsl.com>; Tue, 17 Dec 2019 12:32:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.747
X-Spam-Level:
X-Spam-Status: No, score=0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XrSULl4SLFic for <ipv6@ietfa.amsl.com>; Tue, 17 Dec 2019 12:32:36 -0800 (PST)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0A3120125 for <ipv6@ietf.org>; Tue, 17 Dec 2019 12:32:36 -0800 (PST)
Received: by mail-oi1-x22b.google.com with SMTP id x14so6401573oic.10 for <ipv6@ietf.org>; Tue, 17 Dec 2019 12:32:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VekoEqcgFeYwQfpuDE9WFlTKzhbTFICGYfFv5P0RMxI=; b=DAEkRi+FEDRJ+zOpKp2eiTcYqcm4kONXNtfUQc+INv0MJsk13WpI/fNewODBpn1kVa uH5G+e/afM3eGzIxc9BG5fBWDMlv+CXPHB9rF3cvhWtzCJi5R3NZsPe7Ik4TXZCH8OHR nfBGxQqyrL1ppNOb9W2ZWwyNsC/6DQGCiRA6njA5raWuPKVHcAjqTQwWzdbw+VypvZrH +cJSvc4UB4h5EDlh+uviGm0Pu42LFJ1NsTtNZ/l5yViGppsvZ3VLx2nXRuFxryYJ3rg9 bwgko8g0M99vjyetknjMr/NyWADHhQ5USKibAHrNTF5RP4daQ7Mis8onlK+Pbi+iRUkN Hx+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VekoEqcgFeYwQfpuDE9WFlTKzhbTFICGYfFv5P0RMxI=; b=tFvy1BBEJwqbYMA1xpsJGAxSMCRh7NbnTM0ttPUNYfU9Ugl3oOk8BZv0Ft0HnOMr6R ht0JGzHKzm+Iis7OM9LmeBkVtFG86UA5b+MaKPtfKchTiciKkRO5j0oTFLHjUcDuH2AV e0tq5CnJRydCRATMLQXcs9sk45D3btRrOqNLvsOVkK6f8KswZFIz1XHRcnRTiSSHZN6p AID4ncVTDrsAXHG31p4fJa/nnx+syiSGEDs69zMRU45ueESp7VBlL7rh4Z+3/x8PfRUk 3f3Pwxd6hSw8d6vdLegXWnE8VMBza0NLV6MlsdO2u5mZiVP1k3UGumG3xsWz0Y9GOkCb UU4Q==
X-Gm-Message-State: APjAAAWesBbJ4JcJUXIy9SDuH3dN5kDmnUWi/1VylYXUyS3SxGp/l5E+ OAvDwLsbr1jX08agYpWnzCXv36epqxU9Mjs+1z0=
X-Google-Smtp-Source: APXvYqyHwkeBcJMO7/AgJO6BRz6PSnZ3iDpSOWq15QZwDYXsCxBHCLHRz2fmUKkGReNj+mS5uPSQgMjAxugMLQGQ75A=
X-Received: by 2002:aca:d18:: with SMTP id 24mr2783878oin.38.1576614755900; Tue, 17 Dec 2019 12:32:35 -0800 (PST)
MIME-Version: 1.0
References: <eee1ebe3-dd1a-1a5b-21a8-739857995abf@gmail.com> <3dd249916fbe47d1a8979591814e7846@boeing.com> <228808147f9e4e068309176ce9365519@boeing.com> <d712c773-8a91-e0cb-f9bc-18eb6ce637ea@gmail.com> <2471d4ef8442471cb173f6977548d9f9@boeing.com> <f8105c77-59c4-1dda-c223-5c1b1ffc30d9@gmail.com>
In-Reply-To: <f8105c77-59c4-1dda-c223-5c1b1ffc30d9@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 18 Dec 2019 07:32:23 +1100
Message-ID: <CAO42Z2zccu17v0yX-jJdQvbgVZwO2p=QjU=Hyr2=ser-oeYN0Q@mail.gmail.com>
Subject: Re: Metadata over IPv6
To: Brian Haley <haleyb.dev@gmail.com>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007921950599ec3a89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VB-EEuuRYrT2l8J1PYjUHqae_9k>
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: Tue, 17 Dec 2019 20:32:39 -0000

On Wed, 18 Dec 2019, 06:55 Brian Haley, <haleyb.dev@gmail.com> wrote:

> On 12/17/19 2:38 PM, Templin (US), Fred L wrote:
> > Hi Brian,
> >
> >> -----Original Message-----
> >> From: Brian Haley [mailto:haleyb.dev@gmail.com]
> >> Sent: Tuesday, December 17, 2019 11:11 AM
> >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >> Cc: ipv6@ietf.org
> >> Subject: Re: Metadata over IPv6
> >>
> >> Hi Fred,
> >>
> >> Thanks for the response, I do have some questions.
> >>
> >> On 12/17/19 12:32 PM, Templin (US), Fred L wrote:
> >>>> For embedded IPv4 addresses/prefixes, however, we would use a modified
> >>>> IPv4-compatible encapsulation as follows:
> >>>>
> >>>>     fe80::ffff:a9fe:a9fe
> >>>
> >>> I'm sorry; I intended to say "modified IPv4-mapped encapsulation".
> "IPv4-compatible"
> >>> is deprecated by RFC 4291 and would contain all-zero's instead of
> 0x0000ffff in bits 64-95.
> >>> AERO uses IPv4-mapped for embedded IPv4 addresses and all-zero's for
> administratively
> >>> assigned AERO addresses.
> >>
> >> So in my case I don't think we want to define an IPv4-mapped
> >> encapsulation, just a new on-link anycast address that something on the
> >> link will answer to, it doesn't have to be the router since there might
> >> not actually be one.
> >
> > There is already a link-local Subnet Router Anycast address - it is
> fe80::.
>
> Ack.  In our case there might not be a router, a network can be
> completely isolated with only a DHCP server attached, which can also be
> used as a proxy to metadata - it would return a route to the fe80::$META
> address via itself in that case.
>
> >>> Also, fe80::ffff:a9fe:a9fe can be written as
> fe80::ffff:169.254.169.254 - the two address
> >>> representations are equivalent.
> >>
> >> I wouldn't mind using the AERO format, but reading the draft you listed
> >> it doesn't look like fe80::ffff/96 is being reserved by IANA?
> >
> > fe80::ffff/96 is a format that has significance on AERO links. AERO is
> an IPv6-over-foo
> > document that specifies the construction of link-local addresses used on
> the link. The
> > format may be useful for other applications and/or link types besides
> just AERO,
> > though, so it would probably make sense to adopt a consistent format.
> RFC7421
> > cites the AERO format.
>
> Ah, Ok.  So does everything on the link use the same address format?  We
> are dealing with pre-existing deployments where we can't change that.  I
> do like the fact that AERO basically has the format we're looking for,
> fe80::ffff:169.254.169.254, which make it obvious this is the metadata
> service IP.
>

I think it would be better to reserve a proper IPv6 anycast address for
this from within the upper 128 IID values, unless there is a specific
reason to tie it to the IPv4 address version of the service.

https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml

Coupling things to IPv4 ways, even just symbolically, increases momentum
against giving up IPv4.

It's better to do things the native "IPv6 way".

Amazon shouldn't be hijacking a IPv4 Link-Local addresses for special
purposes like that. If somebody else does the same thing, then there are
two unofficial meanings for the same address. The argument that Amazon has
already reserved that address doesn't fly when they actually officially
haven't. Amazon should have requested a properly reserved anycast address
from IANA.

People used 1/8 for that sort of thing. That caused problems when APNIC
started using it for its proper purpose - public Internet addressing.

Traffic in Network 1.0.0.0/8
http://www.potaroo.net/studies/1slash8/1slash8.html

Regards,
Mark.



> -Brian
>
>
> >> Just that
> >> "Relay, Server and Proxy AERO addresses are allocated from the range
> >> fe80::/96, and MUST be managed for uniqueness."
> >
> > You are referring to something different here that does not apply to the
> use case
> > of embedding an IPv4 address in an IPv6 address - so, this part of the
> AERO spec
> > is out of scope for what we are discussing here.
> >
> > Thanks - Fred
> >
> >> since we do control
> >> the MAC we could do this I suppose as we want this link-local on the
> >> proxy, but what we're doing isn't really akin to AERO (IMO).
> >>
> >> Thanks,
> >>
> >> -Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>