IETF Logo Mail Archive

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

Bob Hinden <bob.hinden@gmail.com> Thu, 15 October 2020 19:24 UTC

Return-Path: <bob.hinden@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 DAB7E3A1328; Thu, 15 Oct 2020 12:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: 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 EhI8p5PDyzaX; Thu, 15 Oct 2020 12:24:16 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 487183A1326; Thu, 15 Oct 2020 12:24:16 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id d3so141463wma.4; Thu, 15 Oct 2020 12:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mGlWX2yogwz8N2wAawSqdH0XLZaOGdYvmovPNIlCo44=; b=J7K5j5lmVXe51D4GTJvKze15xzKcsWWHRlWMaKdxvgk/OsLXuW12oFGdz1BIp49/pJ eE0RCKY88AAuzHXXj3H8CEH4zoPr2CLLZabumwuidRT8b1+29VtkVK6eYnMn5uJgPCWt /Ia5GFV8Yt03i0S1A7mVwQUGfuQ5R/Rp3saGJ31Dr1w7zvhVauWqFyMeEY5h/XfPeuvG aphKfPH3RUQxy3Ol/1JvVT3Xuo1uofvEiXKrE/EN1O4R4kJWTdcXj89F0pdIk6txfbWr NvIvex9RMC2/cJ+5FR3fw+eIVUsgYIkN0ZwhJz4gwXDKpKa5gg/9w95b00IuNW8aYXBg I0tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mGlWX2yogwz8N2wAawSqdH0XLZaOGdYvmovPNIlCo44=; b=X27BraSCDMvYhInK3ZpDEhCCPcA/Futo0f7d5YcAfoWq8brOdJ9wQQt0owNxwPqGyL S4HLVDvFcqZgxrx72IZSGMpPn1wEBx/Q/XC6Zkqg3o3slS2VkNW0YVAT7it4N+ObFmB0 +ljb75m7nA4SkpckJfH/TfAbmgB0A193Zfk04F0sYcM4oKhwl96taUHBBoRH2GH8fRVw wrsJoDhotbWXnsgFLB9fEaQH3WbuVl/D6TF1shGBDuuXP9wkpaUzOM+ZhMbuPwvOHn9G iFDVHkcZ4IdtqPVbtkGpM8WGl15xeShPSYVYy5pVzMWsCtXx73sOkFvkE8tmnhxg9b/l mOQA==
X-Gm-Message-State: AOAM530ntVVGBe5hk552X2xob2d73jqrILgMkyX9KIlGjbAMoeu5GgQI Gy97wtkj8HIyoBsZN7JkDrg=
X-Google-Smtp-Source: ABdhPJz5WPQtP0zIgONE5Uh4BsRG3ihTkVvmXlDK0Qi7cFL2Kp6QsYKASGtHKPR8L+ALYAQktmE7/w==
X-Received: by 2002:a1c:b18a:: with SMTP id a132mr175096wmf.59.1602789854779; Thu, 15 Oct 2020 12:24:14 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:59b8:8ba2:9f23:c336? ([2601:647:5a00:ef0b:59b8:8ba2:9f23:c336]) by smtp.gmail.com with ESMTPSA id i126sm32597wmi.0.2020.10.15.12.24.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2020 12:24:14 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <EE3709A2-B8F7-40FE-BCF1-BB86749D70CC@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F2C418D6-BE25-452A-A4FB-12B058FFE5AD"; 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 12:24:09 -0700
In-Reply-To: <95763ccac7f64f0fa61bfe72c5bfd926@boeing.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Ole Trøan <otroan@employees.org>, IPv6 List <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
References: <95763ccac7f64f0fa61bfe72c5bfd926@boeing.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QdgQpSy1J3-jXb1V6sepjxgzf5k>
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: Thu, 15 Oct 2020 19:24:18 -0000

Fred,

> On Oct 15, 2020, at 12:10 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> Bob,
> 
>> -----Original Message-----
>> From: Bob Hinden [mailto:bob.hinden@gmail.com]
>> Sent: Thursday, October 15, 2020 11:43 AM
>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>> Cc: Bob Hinden <bob.hinden@gmail.com>; Ole Trøan <otroan@employees.org>; IPv6 List <ipv6@ietf.org>; atn@ietf.org
>> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
>> 
>> Fred,
>> 
>>> On Oct 15, 2020, at 11:40 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
>>> 
>>>>>>> 
>>>>>> 
>>>>>> The use of site locals also sets limitations of addressing/routing in the underlay.
>>>>> 
>>>>> This is rather about addressing/routing in the *overlay*.
>>>>> 
>>>>>> With regards to performance. Is the conversion between SLA/LLA something you do per packet?
>>>>>> If not, I'm unsure I see why optimising that is beneficial.
>>>>> 
>>>>> Per-packet - a simple bit-flip changes the address from SLA to LLA or vice-versa.
>>>> 
>>>> Umm, that would break the transport protocol checksum.
>>> 
>>> Good point, and that brings into focus the need for RFC2473 encapsulation.
>>> If you want a packet with IPv6 link-local addresses (LLAs) to go more than
>>> one hop, encapsulate it in an IPv6 header with the same LLAs and then
>>> flip the bit to turn them into SLAs. Then, present the (encapsulated) packet
>>> to the IPv6 overlay routing system.
>> 
>> If you want the packets to go more than one hop, then don’t use link-local addresses.
> 
> 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.

Bob

v2.23.0 | Report a Bug | By Email