Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)

Fernando Gont <fgont@si6networks.com> Wed, 14 October 2020 14:47 UTC

Return-Path: <fgont@si6networks.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 3FF2C3A0EAD; Wed, 14 Oct 2020 07:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Level:
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 XQz3bBj7NKm0; Wed, 14 Oct 2020 07:47:17 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00A83A0E7D; Wed, 14 Oct 2020 07:47:00 -0700 (PDT)
Received: from [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18] (unknown [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 758BD280BB6; Wed, 14 Oct 2020 14:46:52 +0000 (UTC)
Subject: Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Mark Smith <markzzzsmith@gmail.com>
Cc: Robert Moskowitz <rgm@labs.htt-consult.com>, 6man <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
References: <7af0ab36-4a6b-cb44-609c-6e81b364a01c@labs.htt-consult.com> <8009C8E3-E654-4623-BDC8-F794346C33B1@gmail.com> <026e1f94f9d646f38e6912174998b929@boeing.com> <CAO42Z2x7B3sjaV-v1Ox8Vojjv6Vcfpn58PYUOp5jj6iixJau7A@mail.gmail.com> <6c1b8260f1014b4bbcb05e618cb83aa3@boeing.com> <CAO42Z2yaE-0tVjpn=bv6N5_LA-BbjGPAEFgaPs84+vm6_nwPhg@mail.gmail.com> <c9a68a4c52104e809d208f903b2a25c0@boeing.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <7345db80-ae20-d5b0-a41d-e8ebf15dc934@si6networks.com>
Date: Wed, 14 Oct 2020 10:35:59 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <c9a68a4c52104e809d208f903b2a25c0@boeing.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PhE5SpxkSnqdEtaSCQGclnhPM-Y>
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: Wed, 14 Oct 2020 14:47:26 -0000

Hi, Fred,

On 13/10/20 17:58, Templin (US), Fred L wrote:
> Mark, see my follow-up message. There is no problem with an 
> IPv6-over-foo spec
> 
> defining its link-local address format. Almost all of the existing 
> IPv6-over-foo specs  define an interface-specific interpretation of link-locals with a prefix 
> length (fe80::/64) that does not appear in RFC4291, and none of them update RFC4291. All 
> that is said in RFC4291 is “fe80::/10”, which does not agree with the IPv6-over-foo 
> specs. I hear your point about the BSD hack of writing data into the 54 “unused” bits 
> in memory, but I am not sympathetic to that approach when what is being offered 
> here is a brand-new interface type that does not already exist in widely-deployed
> implementations, so it is a chance for a fresh start for all 
> implementations.

Without having given a lot of thought about the context, it would seem 
to me that things like ND proxy might make addresses from one link 
visible in another.

Based on the (BSD) deployed code, if I had to do anything that would 
require using the zero bits in fe80::/64, I would probably consider 
using a different prefix altogether.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492