IETF Logo Mail Archive

RE: Metadata over IPv6

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 17 December 2019 19:38 UTC

Return-Path: <Fred.L.Templin@boeing.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 DFAB412086E for <ipv6@ietfa.amsl.com>; Tue, 17 Dec 2019 11:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 y_nPew0C3OuC for <ipv6@ietfa.amsl.com>; Tue, 17 Dec 2019 11:38:30 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 77F59120864 for <ipv6@ietf.org>; Tue, 17 Dec 2019 11:38:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id xBHJcNEP002923; Tue, 17 Dec 2019 14:38:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1576611507; bh=6gA3XXlgibzFwLZ8NLXtXbPu31Nx+MiqLhOHgZQgczs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WP1e8Ld6IuqliUcbhWbBnkV4/KAsZ/B3Jana6rGdfmI6trKbrtwWKLyZIyaeLQAZg IjGzVGsFyj461Pmw7kdNN1VcYxu4r9IiZ8punI8Ac36x1gDljaHt8C8LNwjShkKNuX zFbONnpqBvBSEvysK1tBZ+lNhmyNh6w6BPcDqpj1Mi3jNkBhkiiDctJ2zkBeuz4hBU TsMFL5y8LwnL6yy/sPSFINbVcZ3/zvJasn/iamMAAWRQzGTVSosRGfQFb85vnDY1kO yP8JS1q+um32X1CSt1N5TOTpVNHmBnBsDsP9oTeZ+9KMJkfrh+ipF3pnaQHygBuGDk 1xleqQixsMc4A==
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id xBHJcLbi001995 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 17 Dec 2019 14:38:21 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1779.2; Tue, 17 Dec 2019 11:38:20 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.1779.002; Tue, 17 Dec 2019 11:38:20 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Brian Haley <haleyb.dev@gmail.com>
CC: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: Metadata over IPv6
Thread-Topic: Metadata over IPv6
Thread-Index: AQHVtPj3T+OZPldxtkuenz6jEYpTbKe+jIDggAAH+iCAAKMuAP//fsKQ
Date: Tue, 17 Dec 2019 19:38:19 +0000
Message-ID: <2471d4ef8442471cb173f6977548d9f9@boeing.com>
References: <eee1ebe3-dd1a-1a5b-21a8-739857995abf@gmail.com> <3dd249916fbe47d1a8979591814e7846@boeing.com> <228808147f9e4e068309176ce9365519@boeing.com> <d712c773-8a91-e0cb-f9bc-18eb6ce637ea@gmail.com>
In-Reply-To: <d712c773-8a91-e0cb-f9bc-18eb6ce637ea@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 0B3830824038C7F6109D311A3910E7380C5A3D6AFCA5600495DC5C8C5147305D2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/AAZzVMSeTikTDsapfsMH7BDW1hI>
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 19:38:33 -0000

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

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

> 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

v2.23.0 | Report a Bug | By Email