Re: Embedding IP information in an IPv6 address (OMNI)

Bob Hinden <> Thu, 15 October 2020 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9792C3A0B59; Thu, 15 Oct 2020 15:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f3koCF_8o_Oj; Thu, 15 Oct 2020 15:41:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17FB33A0B4E; Thu, 15 Oct 2020 15:41:58 -0700 (PDT)
Received: by with SMTP id y12so418904wrp.6; Thu, 15 Oct 2020 15:41:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mcydGApQE4OqW423liyClH4UHOmD7u3Gdyv44w1OFNo=; b=tneigt4ZXTp8QgJzMybntzAuZLVeXw3TwJ1Yk/bdJLrHXR5+3bFHYU6c1/DrbLFWUZ VDC81GsVsZ4M+dhIEcbl4sANr3ek7vT3u9+2hykswDuv6mk7OnKMhEdZ8lHmJpyq9H9y b4rb+qtEZCDqNFgyAH6pn0+rUOeEE0J0c8MgMJrGX7NPNPnewDubUl7q9N1Rw65SeoQA wio9l8rS/OMOBVn8l21/eb+O18HTZ7rXPUywdfkjwtfPA/OkNoLbBBjo5/YMenpjNGfZ 5ExIZlVTrCHpY07NptMLOcuxevuBCRWExWZ+FPF+KQhBfBwjJdhFXKKfMsoz90Fx0IeJ ih5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mcydGApQE4OqW423liyClH4UHOmD7u3Gdyv44w1OFNo=; b=n2jOv14UXBYqMs9F6UFnSbCSP13Csv2/pEEfWTfHb7TNApZ7R9PlPu+E3f6OXvobe6 9N+BBdCDsPQ5Nmi9k/kRBNMG7MNeET3rXDGHJuc2x+Gmnz1Mu9iQLMFDjEoLFOQyLPjc HVs30NP5iSA0ShOKEfKnE0IlN6zjBIBdyP6TG5ORS0LPtKVI7xUoYqIBI9BTDQl1t5Fs 41hxx2A0aW1tO7id65EZTnn/QklPYj/c4Ru1aKEOwP8isq2EJulphoH3sgXq7VgJ0wGt id5/5mtlnd5q7IfVevv3AMeRLYyroq1V4oa5SuJ06A7akXP17a78Y2CCFENrFl3XN2pe zbXg==
X-Gm-Message-State: AOAM533iuCprgdrXSFN1jYM33uPSDQa3yQI3ac8DBo+tSAOprApAeA8j EO2Fgkg5uuP8RRDmywqe/50=
X-Google-Smtp-Source: ABdhPJyv+bMd8tnpJLL5Zug2cVIAx65AlecQtJidZ15GgCoTanK+9dWwvdaT4Vn07HVMiNdrH/YQRw==
X-Received: by 2002:a5d:5344:: with SMTP id t4mr442693wrv.267.1602801716471; Thu, 15 Oct 2020 15:41:56 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:59b8:8ba2:9f23:c336? ([2601:647:5a00:ef0b:59b8:8ba2:9f23:c336]) by with ESMTPSA id n3sm568845wmn.28.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2020 15:41:55 -0700 (PDT)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_BBFCC869-1CDD-4AF5-A3A5-E1AE1DDBB8C5"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: Embedding IP information in an IPv6 address (OMNI)
Date: Thu, 15 Oct 2020 15:41:52 -0700
In-Reply-To: <>
Cc: Bob Hinden <>, =?utf-8?Q?Ole_Tr=C3=B8an?= <>, IPv6 List <>, "" <>
To: "Templin (US), Fred L" <>
References: <>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Oct 2020 22:42:01 -0000


> On Oct 15, 2020, at 1:58 PM, Templin (US), Fred L <> wrote:
> Bob,
>> -----Original Message-----
>> From: Bob Hinden []
>> Sent: Thursday, October 15, 2020 1:29 PM
>> To: Templin (US), Fred L <>
>> Cc: Bob Hinden <>om>; Ole Trøan <>rg>; IPv6 List <>rg>;
>> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
>> Fred,
>>> On Oct 15, 2020, at 12:40 PM, Templin (US), Fred L <> wrote:
>>>>> That circles us right back to the subject of how RFC4861 is intrinsically tied to
>>>>> the use of link-local address and the fact that all IPv6 interfaces are required
>>>>> to configure a unique link-local address. It would be a bear to try to change
>>>>> that, so OMNI employs RFC2473 encapsulation instead of trying to override
>>>>> the bedrock IPv6 standards. The use of RFC2473 encapsulation also brings
>>>>> other important benefits.
>>>> Right, that how ND works.   Seems to me that you are proposing many changes to IPv6 for some degree of optimization.   It’s
>> unclear
>>>> to me that the benefit outweighs the cost.
>>> Rather than repeating them again here, I would invite you to go back over the
>>> message exchanges I had with Ole yesterday (10/14/2020) where I outlined the
>>> benefits.
>> I read that, but was not convinced that the benefits were sufficient to justify what you are proposing.
> I think that may be due to the fact that we have only examined a few fundamental
> aspects of the architecture, and there is more to it than what has been discussed
> so far - a *lot* more.  For instance, the reason for wanting both LLAs and SLAs is so
> that we can use overlay "L2 bridging" to join disjoint Internetworks together as
> though they were one big bridged campus LAN. For example, in civil aviation there
> are many network service providers including ARINC, SITA, Inmarsat and others and
> each runs their own networks as an independent entity. But, an aircraft connected
> to ARINC may need to communicate with an air traffic controller in SITA. OMNI then
> views each of the providers as a link *segment* and bridges the segments using
> RFC2473 encapsulation with SLAs and BGP router peerings between the providers.
> The IPv6 layer then sees this bridged arrangement as a single, connected IPv6 link
> and the aircraft and ATC can communicate as peers on the link even though they
> are located in different provider networks in the underlay.

I think this is a bad idea, that is trying to make a set of networks with a whole range of characteristics (i.e., speed, delay, drop rates, errors, cost, etc.) look like a single "big bridged campus LAN”.   Most people have stopped buildings “big bridged campus LANs” a long while ago, what your are proposing is much harder given the different characteristics of the networks you mention.

I think a better approach is to treat the networks separately and use transport protocols techniques to use them efficiently separately and concurrently.   Likely the transport protocols and applications above them will need to be aware of the underlying networks.

>>> About changes to IPv6, all that has been asked so far is for the OMNI
>>> interface to define its own link-local addresses - having that, none of the IPv6
>>> standards like RFC4861, RFC8200 etc. are changed.
>> The OMNI draft updated RFC1191, RFC3879, RFC4291, RFC4443, and RFC8201.
> When I said "all that has been asked for *so far*", I meant in terms of what has
> been discussed on the list up to now. Up to now, the only aspects of OMNI we
> have touched on are the LLAs and SLAs, and it is only RFC3879 and RFC4291 that
> are in question. So, until we get around to discussing the OAL let's put the other
> RFCs aside for now.

I disagree, you are clearly proposing a lot of changes, discussing them separately doesn’t change that.