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

Mark Smith <markzzzsmith@gmail.com> Tue, 13 October 2020 20:25 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 8A3BD3A112D; Tue, 13 Oct 2020 13:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.595
X-Spam-Level:
X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, 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 jKnNc0UNVmAG; Tue, 13 Oct 2020 13:25:42 -0700 (PDT)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 469F63A1110; Tue, 13 Oct 2020 13:25:42 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id e20so1282597otj.11; Tue, 13 Oct 2020 13:25:42 -0700 (PDT)
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=EYLIHesML8C9telz3CAigEarWxsvG3W9avOlCQpSV/I=; b=hQ3aEHMB3eXlhzwyXT4yJtHyjYuINipekGfq6RZEhDWqd5o6r5R43F3HlqMmuSlXEy UDuHKc+VLY220TWxj7cQ0N+pr00/+3YROghQnbVDOiLMMG6IBwkh5QW0fwftck5gkQrL 9aEEotvMyIRVEDLgxCdWFhHalOlcq1B7UcpNVKIG31jE/ByK9AfZ3Cqn3E0xdZFGBfRV wdpR3DHC1/G3mQm9k351QON7s4qfGjKiDmK7h11VpTi65EuSX3fN8L5nc/9/U3ygcbvs Tz4TIwFy1hedjkvTZl8miB47/kk6KVBmBvz0/oEPtPz598jYTNT/jNsn2fgfSdkbJc+L Br3w==
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=EYLIHesML8C9telz3CAigEarWxsvG3W9avOlCQpSV/I=; b=ETkYagUCIwkyMJBNuX/Um/0dk7n3oGJkv3vTLR2D7wkIZMgrtiNO5zgrqbMSI9Q71M DMi9RNsPcRP9pPD1iXcDCWG02gn8UojQfj9aajXCHRd1cZChLVzDvNKkRjDPL7S8F7I2 +3jdU5dPzhAo8kvONIJzsWjJ0bgdnNUUTsIBvHJQYnfcL0gN3vXHEoxZE30Dcn9SKICl u6JW6UYBTbKlmcqzPTKX8v4rQlZwR9oZufgY02H1WUET99un9BFQjBMFeA1Ro8xnb4uG QvOrqGTow4vv5FfRknHvHV8riT1Iq4yLKalAFQTcMyWYEgnJD1M/D28PRvtdU95RUrZq PFPA==
X-Gm-Message-State: AOAM533CMJQtNWuPShPHMc3lz+sMmWmqI3ZzckTMzjpEgiGM/hcLHtYS NAM7egG/MVtYPjIFoY3dWO/SxtC//1Za4QWmqrBP+d/F
X-Google-Smtp-Source: ABdhPJxX96TjYte5ShA9aOKI4BdT1uwIa/NF/I/3p7z2a9qdbSL+xo0yZyCZWrPwbars68GrTNDIoMg0AGzL1HWd/3Q=
X-Received: by 2002:a05:6830:2041:: with SMTP id f1mr962103otp.348.1602620741495; Tue, 13 Oct 2020 13:25:41 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <6c1b8260f1014b4bbcb05e618cb83aa3@boeing.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 14 Oct 2020 07:25:30 +1100
Message-ID: <CAO42Z2yaE-0tVjpn=bv6N5_LA-BbjGPAEFgaPs84+vm6_nwPhg@mail.gmail.com>
Subject: Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, 6man <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000001f23c05b1933812"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/goZ5_7-b6CSS_Yv7gzWAxg_20Co>
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, 13 Oct 2020 20:25:51 -0000

Hi Fred,

On Sun, 11 Oct 2020, 03:12 Templin (US), Fred L, <Fred.L.Templin@boeing.com>
wrote:

> Hi Mark,
>
>
>
> We want to use link-locals (fe80::/10) – else we would have to do a
> wholesale update
>
of key RFCs such as RFC4861. Plus, RFC4291 says:
>
>
>
>    Routers must not forward any packets with Link-Local source or
>
>    destination addresses to other links.
>
>
>
> and since the OMNI link is the only one on which the addresses would
> appear on
>
> the “wire” it should be possible to make a good use out of the
> otherwise-wasted
>
> 54 buts. All it takes is an “updates RFC4291” , for which we see many
> prior examples.
>

I don't think it is as easy as just updating RFC4291. There are literally
billions of deployed implementations of IPv6 that expect these bits to be
zero, and have for the past 25 years since the link-local prefix format was
defined in RFC1884.

These zero bits aren't wasted, their value is to fill out the space between
the high order link-local fe80::/10 prefix and the lower 64 bit IID to
align them, so that the link-local address is 128 bits long. "Waste" only
occurs when no useful value is gained from something, and if course field
alignment is useful.

You possibly will run into an issue with BSD IPv6 implementations, which
from what I understand, store information in these zero bits' position when
they hold a link-local address in memory.

It would be easier to reclaim these bits if they were 'reserved', and if
there was a statement such as "set to zero upon transmission, ignored upon
receipt" however I've never seen such a clause for the link-local
subnet-prefix (I think that sort of clause might only exist for flag bits
in multicast addresses). Since RFC1884, these bits have always been
specified as being set to zero, with no possible caveats or exceptions
being suggested.

If you need to have another address space that isn't forwarded off link,
then that can be specified as a requirement for the new address space (and
you could do some receiver enforcement using the Hop Count == 255 trick
that ND uses). Packets leaking off of a link that shouldn't is always a
risk, and already occurs with link-locals (packets with DA=ULA/GUA, SA=LLA
are known to leak off-link).

Regards,
Mark.




>
> Fred
>
>
>
> *From:* Mark Smith [mailto:markzzzsmith@gmail.com]
> *Sent:* Friday, October 09, 2020 4:30 PM
> *To:* Templin (US), Fred L <Fred.L.Templin@boeing.com>
> *Cc:* Fred Baker <fredbaker.ietf@gmail.com>; Robert Moskowitz <
> rgm@labs.htt-consult.com>; 6man <ipv6@ietf.org>; atn@ietf.org
> *Subject:* Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6
> address (OMNI)
>
>
>
> On Sat, 10 Oct 2020, 08:35 Templin (US), Fred L, <
> Fred.L.Templin@boeing.com> wrote:
>
> Fred,
>
> > The concept of embedding information in the 54 “must be zero” bits of
> the link local address is enticing, but may not prove
> > interoperable, given the “must be zero” definition of a link local
> address.
>
> Also good input, but given that these link-local addresses are defined and
> intended
> for the exclusive use of a specific IPv6-over-(foo) interface type, only
> interfaces that
> understand the address format will process the addresses and they will
> understand
> the usage of the 54 bits.
>
>
>
> Link specific versions of link-local addresses don't and won't comply with
> RFC4291 and all of its ancestors, because there is nothing that says the
> format of the link local address can be defined by link specific documents.
> These zero bits have always been zeros.
>
>
>
> Why the effort to shoehorn new functionality into existing and long
> defined IPv6 address spaces?
>
>
>
> Follow the ULA verses site-local example - if new functionality is
> considered different enough to justify updating existing, decades old and
> very widely deployed address formats, then I'd think the threshold of
> asking for new IPv6 address space for this functionality is passed. We have
> about 7/8ths of the IPv6 address space not defined for any purpose (it'd be
> a different story for new functionality in IPv4 addressing).
>
>
>
> With new address space there is no need to both update and be constrained
> within old address space definitions, and there is much less if any
> compatibility considerations and concerns with existing deployments.
>
>
>
> You could call your new address space OMNI Link-Local Addresses.
>
>
>
> Regards,
>
> Mark.
>
>
>
>
>
>
> Thanks - Fred
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>