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 > -------------------------------------------------------------------- > >
- Embedding IP information in an IPv6 address (OMNI) Templin (US), Fred L
- RE: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: [atn] Embedding IP information in an IPv6 add… Robert Moskowitz
- Re: [atn] Embedding IP information in an IPv6 add… Templin (US), Fred L
- Re: [atn] Embedding IP information in an IPv6 add… Fred Baker
- RE: [EXTERNAL] Re: [atn] Embedding IP information… Templin (US), Fred L
- Re: [EXTERNAL] Re: [atn] Embedding IP information… Mark Smith
- RE: [EXTERNAL] Re: [atn] Embedding IP information… Templin (US), Fred L
- RE: [atn] [EXTERNAL] Re: Embedding IP information… Templin (US), Fred L
- Re: [EXTERNAL] Re: [atn] Embedding IP information… Mark Smith
- RE: [EXTERNAL] Re: [atn] Embedding IP information… Templin (US), Fred L
- Re: [atn] [EXTERNAL] Re: Embedding IP information… 神明達哉
- RE: [atn] [EXTERNAL] Re: Embedding IP information… Templin (US), Fred L
- Re: [atn] [EXTERNAL] Re: Embedding IP information… Bob Hinden
- Re: [atn] [EXTERNAL] Re: Embedding IP information… otroan
- RE: [atn] [EXTERNAL] Re: Embedding IP information… Templin (US), Fred L
- Re: [EXTERNAL] Re: [atn] Embedding IP information… Fernando Gont
- Re: Embedding IP information in an IPv6 address (… Fernando Gont
- RE: [EXTERNAL] Re: Embedding IP information in an… Templin (US), Fred L
- Re: [atn] [EXTERNAL] Re: Embedding IP information… otroan
- RE: [atn] [EXTERNAL] Re: Embedding IP information… Templin (US), Fred L
- Re: [atn] [EXTERNAL] Re: Embedding IP information… 神明達哉
- Re: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: [EXTERNAL] Re: Embedding IP information in an… Philip Homburg
- Re: [EXTERNAL] Re: Embedding IP information in an… Alexandre Petrescu
- Re: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- RE: [atn] [EXTERNAL] Re: Embedding IP information… Templin (US), Fred L
- Re: [atn] [EXTERNAL] Re: Embedding IP information… Philip Homburg
- RE: [atn] [EXTERNAL] Re: Embedding IP information… Templin (US), Fred L
- Re: [atn] [EXTERNAL] Re: Embedding IP information… otroan
- RE: [atn] [EXTERNAL] Re: Embedding IP information… Templin (US), Fred L
- Re: [atn] [EXTERNAL] Re: Embedding IP information… otroan
- Re: Embedding IP information in an IPv6 address (… Bob Hinden
- Re: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: Embedding IP information in an IPv6 address (… Bob Hinden
- Re: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: Embedding IP information in an IPv6 address (… Bob Hinden
- Re: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: Embedding IP information in an IPv6 address (… Bob Hinden
- Re: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- RE: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- RE: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: Embedding IP information in an IPv6 address (… Bob Hinden
- RE: [EXTERNAL] Re: Embedding IP information in an… Templin (US), Fred L
- Re: [EXTERNAL] Embedding IP information in an IPv… Bob Hinden
- RE: [EXTERNAL] Embedding IP information in an IPv… Templin (US), Fred L
- Re: [atn] [EXTERNAL] Re: Embedding IP information… Philip Homburg
- Re: Embedding IP information in an IPv6 address (… Behcet Sarikaya
- Re: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: Embedding IP information in an IPv6 address (… Ted Hardie
- RE: [EXTERNAL] Re: Embedding IP information in an… Templin (US), Fred L
- Re: [EXTERNAL] Re: Embedding IP information in an… Ole Troan
- RE: [EXTERNAL] Re: Embedding IP information in an… Manfredi (US), Albert E
- Re: [EXTERNAL] Embedding IP information in an IPv… Bob Hinden
- Re: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- RE: [atn] [EXTERNAL] Embedding IP information in … Templin (US), Fred L
- Re: [atn] [EXTERNAL] Embedding IP information in … Bob Hinden
- RE: [atn] [EXTERNAL] Embedding IP information in … Templin (US), Fred L
- RE: [atn] [EXTERNAL] Embedding IP information in … Vasilenko Eduard
- RE: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: [atn] [EXTERNAL] Embedding IP information in … Bob Hinden
- Re: Starlink --- "simpler than IPv6" Templin (US), Fred L
- RE: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: Starlink --- "simpler than IPv6" Behcet Sarikaya
- Re: Starlink --- "simpler than IPv6" Templin (US), Fred L
- Re: Starlink --- "simpler than IPv6" Behcet Sarikaya
- Re: Starlink --- "simpler than IPv6" Alexandre Petrescu
- Re: Starlink --- "simpler than IPv6" Alexandre Petrescu
- RE: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: Embedding IP information in an IPv6 address (… Bob Hinden
- RE: Starlink --- "simpler than IPv6" Templin (US), Fred L
- RE: [EXTERNAL] Re: Embedding IP information in an… Templin (US), Fred L
- Re: [atn] Embedding IP information in an IPv6 add… Michael Richardson
- RE: Embedding IP information in an IPv6 address (… Templin (US), Fred L
- Re: Starlink --- "simpler than IPv6" Behcet Sarikaya
- Re: Starlink --- "simpler than IPv6" Templin (US), Fred L
- Re: Embedding IP information in an IPv6 address (… Philip Homburg
- Re: Starlink --- "simpler than IPv6" Alexandre Petrescu
- RE: [EXTERNAL] Re: Starlink --- "simpler than IPv… Templin (US), Fred L
- Re: Starlink --- "simpler than IPv6" Behcet Sarikaya
- Re: Starlink --- "simpler than IPv6" Bob Hinden
- Re: [atn] Embedding IP information in an IPv6 add… Bob Hinden
- Re: Embedding IP information in an IPv6 address (… Michael Richardson
- RE: [EXTERNAL] Re: [atn] Embedding IP information… Templin (US), Fred L
- RE: [EXTERNAL] Re: Embedding IP information in an… Templin (US), Fred L
- Re: [EXTERNAL] Re: Embedding IP information in an… Philip Homburg
- RE: [EXTERNAL] Re: Embedding IP information in an… Templin (US), Fred L
- RE: [EXTERNAL] Re: Embedding IP information in an… Templin (US), Fred L
- Re: Starlink --- "simpler than IPv6" Behcet Sarikaya
- Re: Starlink --- "simpler than IPv6" Bob Hinden
- Re: Starlink --- "simpler than IPv6" Alexandre Petrescu
- Re: Starlink --- "simpler than IPv6" Alexandre Petrescu
- Re: Starlink --- "simpler than IPv6" Alexandre Petrescu
- Re: Starlink --- "simpler than IPv6" Alexandre Petrescu
- Re: Starlink --- "simpler than IPv6" Bob Hinden
- Re: [EXTERNAL] Embedding IP information in an IPv… Bob Hinden
- Re: Starlink --- "simpler than IPv6" Behcet Sarikaya
- Re: Starlink --- "simpler than IPv6" Bob Hinden
- Re: Starlink --- "simpler than IPv6" Alexandre Petrescu