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

Bob Hinden <bob.hinden@gmail.com> Wed, 14 October 2020 05:37 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 8559E3A1392; Tue, 13 Oct 2020 22:37:53 -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 P8b3iekhUeYE; Tue, 13 Oct 2020 22:37:51 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 83FFC3A1391; Tue, 13 Oct 2020 22:37:51 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id e18so2171704wrw.9; Tue, 13 Oct 2020 22:37:51 -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=BmXY4No6zsjAsA0viWQoGGQ1KniWeM3bWt+nUclPwRM=; b=petGkX+72msBVcAQ7Zj6/K5fQc4vGZ8LKcnQSAwlID0CjFy9YT2bW8JlZWRwNFsyI3 2hshonkEHbwux203gbNupfmVkzVk18AmbS3Y54bzNiMDuBYGNqkyJGJgUmd1jl38ln5Q xoc9NzfQ7LVn4n4jxWD5NbzXKAgLuaOqxQR0KWYDqqyyCJbQH86nbM97CUyu8jCYBfxP FXVrg50zu/cPad5BrZye2k6YzhnpZ7rZhY8bp5IiO9na6okuuI9x+YotBxG0EdsL8Pi/ aW6/dMHTWmrx4K6LcHEYynHkYcBKqTni08N+0eF4QxGuOVRQrlacMeA98KFQ3jArpCY9 W4lw==
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=BmXY4No6zsjAsA0viWQoGGQ1KniWeM3bWt+nUclPwRM=; b=ASf6tIe/RQ3YMWJ0ve71wiTxk1DkCiQNLXg5Y807yYQHElM8KiPc8oHTGa5+j2DmrY BLIH8QWd+u9/BfPbaeIFE64SV/sy9YHiyD3iuEtqa64Ovn+wB44DQFQXt12tq3tJJ0PL YGeESi/662N385UuWfzL14kXjJJKT212BPse1H1MlTauMoFj0tv1vfsenp4N9W7i9vNP 7vueiZCiwfCKumAO4Idyz0x40YvoT4IZms8bQ00mKr+80eojXJA8s0k03VRDuMB1MUnf INRN5wzMpGG1XGoUp4hGE6ZaISAERpEI8wrwZ5am3PmP31CRMsllIymAFh7qj/elELXR cJ2Q==
X-Gm-Message-State: AOAM5326COcNgLK9VKRMBpM0D6TdMA2I+qfADgcAAoo3KzTVQbcQG3yV EqSoB57k0CHdlpzBrHVMlDBtoesaRgQ=
X-Google-Smtp-Source: ABdhPJzjUUhDAXSNHqFvxFI81m+UfX3a/7MtIr0QhvzFLxPtYYZ1x2ZWTVytUnPBqnUebGSPQu0syA==
X-Received: by 2002:adf:a405:: with SMTP id d5mr3289636wra.421.1602653869611; Tue, 13 Oct 2020 22:37:49 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:3480:340d:aa17:fc? ([2601:647:5a00:ef0b:3480:340d:aa17:fc]) by smtp.gmail.com with ESMTPSA id v8sm1980684wmb.20.2020.10.13.22.37.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 22:37:48 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <4F3C9AE3-50D7-43A3-85B6-CB020B0AC15F@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_73CD5B01-E4D5-44C8-88C0-6673F81013B1"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
Date: Tue, 13 Oct 2020 22:37:44 -0700
In-Reply-To: <301d22a813914f7c845b4715c4fdd628@boeing.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, 神明達哉 <jinmei@wide.ad.jp>, Robert Moskowitz <rgm@labs.htt-consult.com>, "atn@ietf.org" <atn@ietf.org>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: IPv6 List <ipv6@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> <2d9a93ce82be4364bf9004ca94812641@boeing.com> <CAJE_bqc1YKy2ZFrq92gQkbtvq2cvx9EHYwu6rakP1LoLE8_kSw@mail.gmail.com> <301d22a813914f7c845b4715c4fdd628@boeing.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/CDrtSZoPBjZy8CZ5ytFkZjkdZ-8>
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 05:37:54 -0000

I don’t support embedding extra information in IPv6 addresses.  RFC4291 is clear:

   2.5.  Unicast Addresses

     . . . . .

     Except for the knowledge of the subnet boundary discussed in the
     previous paragraphs, nodes should not make any assumptions about the
     structure of an IPv6 address.

As other have said Link Local Addresses are defined with 54-bits of zero in them:

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

Bob




> On Oct 13, 2020, at 4:16 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> Below:
> 
>> -----Original Message-----
>> From: 神明達哉 [mailto:jinmei@wide.ad.jp]
>> Sent: Tuesday, October 13, 2020 3:54 PM
>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>> Cc: Mark Smith <markzzzsmith@gmail.com>; Robert Moskowitz <rgm@labs.htt-consult.com>; 6man <ipv6@ietf.org>; atn@ietf.org
>> Subject: Re: [atn] Re: Embedding IP information in an IPv6 address (OMNI)
>> 
>> At Mon, 12 Oct 2020 13:15:09 +0000,
>> "Templin (US), Fred L" <Fred.L.Templin@boeing.com> wrote:
>> 
>>> Responding to this point again:
>>> 
>>> Ø  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
>>> 
>>> IPv6-over-foo documents already do place their own link-specific interpretations on
>>> link-local addresses. It happens in RFC2464, RFC2467, RFC2470, etc. Each of these specs
>>> gives its own link-specific representation of link-local addresses including a prefix
>>> length definition that does not appear in RFC4291. This is the way that link-locals are
>>> defined within the context of *that specific interface type*, and the addresses are
>>> not to be forwarded to other interface types. And, none of these documents say
>>> “updates RFC4291”.
>> 
>> These three RFC don't have to update the addressing architecture RFC
>> (which is, currently, RFC4291) in this regard in that all of them
>> specify the intermediate 54 bits are zeros and the interface
>> identifier length being 64 bits.  It's the same for other existing
>> link-specific RFCs I know of.
>> 
>> If a new link-specific specification wants to use a non-0 value in
>> that 54-bit field, it will have to formerly update RFC4291 so that all
>> relevant RFCs are still kept consistent.  That's the sense when we
>> revised SLAAC as described in Section 2 of RFC4862:
>> 
>>   interface identifier -  [...]  The
>>      exact length of an interface identifier and the way it is created
>>      is defined in a separate link-type specific document that covers
>>      issues related to the transmission of IP over a particular link
>>      type (e.g., [RFC2464]).  Note that the address architecture
>>      [RFC4291] also defines the length of the interface identifiers for
>>      some set of addresses, but the two sets of definitions must be
>>      consistent.
>> 
>> We had essentially the same type of discussion about 1.5 years ago,
>> where the char of the relevant WG declared we can't just publish a
>> link-type specific doc that would become inconsistent with RFC4291:
>> https://mailarchive.ietf.org/arch/msg/its/-OlXR-zYgsPcAioh58RObbigSp0/
>> 
>> I don't necessarily say such a change is never possible, but if
>> there's a lesson from that previous discussion, it would be that it's
>> not as easy/trivial as you might think.
> 
> What in your opinion would be easier - a) update RFC4291 to allow coding of
> the link-local address 54 zero bits, or b) update RFC4861 to allow routers to use
> site-local addresses instead of link-local?
> 
> We need a good answer for this - either a) or b). The benefit of what is being
> proposed by OMNI is too great to simply say no to both.
> 
> Thanks - Fred
> 
>> --
>> JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------