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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 14 October 2020 18:28 UTC

Return-Path: <Fred.L.Templin@boeing.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 4CC8F3A0FBB; Wed, 14 Oct 2020 11:28:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=boeing.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 VsdB4wTZvGe4; Wed, 14 Oct 2020 11:28:01 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371BA3A0C7A; Wed, 14 Oct 2020 11:28:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09EIRtfg015478; Wed, 14 Oct 2020 14:27:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602700078; bh=m2ozLjIeSco4v95JpUCHAx51PA3fgupXI93mL15L0Qg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=nobDumYo+JLGA0G4No+a6xIf5CDc4F7elwiVbT1PFChCWTwjt9Vsefk/Ge2Ts6uGS oLWrd2zE0QdzPHy7hKIEAfMNj5x1mCydVPeYJtac2dmaYlsOLxYAc7NP3SYZolUlc8 mJbvBekOSZwn+dAivKNLlKoz0EWJbIzF6BjpeXKU7F6A6s64MOY819eXYE+is5AQxI 1N88HGUgedrQWKXabahlDH2uVBmuEgSn48Z4CheoExKwiYxobQuxM8WO4gK977MGXj 3Mpif1pTgBdFPCvFlhVjXOjVAccjZ4ayOUmIjmZI7NpqJ0h4P0aClxEOiXA175IFOS I7bGjixieu8qw==
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09EIRqlT015438 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 14 Oct 2020 14:27:53 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 14 Oct 2020 11:27:51 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 14 Oct 2020 11:27:51 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "otroan@employees.org" <otroan@employees.org>
CC: 神明達哉 <jinmei@wide.ad.jp>, Robert Moskowitz <rgm@labs.htt-consult.com>, 6man WG <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
Subject: RE: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
Thread-Topic: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
Thread-Index: AQHWoJm1AtWogmp2iUqGT24OuvvuX6mWm5KA//+O2ZCAAS+YAP//pZ2wgADYEYD//4x4sA==
Date: Wed, 14 Oct 2020 18:27:51 +0000
Message-ID: <6deb46274c034cabaee4ddd80fed3688@boeing.com>
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> <CE2F3208-2497-4EF7-9948-2E2000D49838@employees.org> <8c53ec2baafc4b1f827996d822ef67b8@boeing.com> <B95DF88A-25DD-454D-84F9-B7D244C3E13C@employees.org>
In-Reply-To: <B95DF88A-25DD-454D-84F9-B7D244C3E13C@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 3690B8982AA4047073BCA19E4D01A1D6846DFF913FBBD3F32F5098DDDC31E6A22000:8
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RwJTETJc5HReb0R3zV6mjcQ4L74>
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 18:28:03 -0000

Ole - see below for follow-up:

> -----Original Message-----
> From: otroan@employees.org [mailto:otroan@employees.org]
> Sent: Wednesday, October 14, 2020 10:45 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: 神明達哉 <jinmei@wide.ad.jp>; Robert Moskowitz <rgm@labs.htt-consult.com>; 6man WG <ipv6@ietf.org>; atn@ietf.org
> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> 
> Thanks Fred for the explanation.
> 
> >>> 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.
> >>
> >> It's unclear to me what the benfits are.
> >> Would you be able to summarize here, or point to the relevant paragraphs in the OMNI draft?
> >
> > The benefits include:
> >
> > + a means for configuring a unique IPv6 link-local address (i.e., the "OMNI LLA")
> >  that is known to be unique on the link without requiring SLAAC or MLD/DAD
> 
> Benefit is in the eye of the beholder.
> Manual configuration is a common cause of duplicate address. Why can't that happen here?
> If you the setup here is that you have "some" information pre-configured. Why not also the link-local address?

There are two possibilities - one that the client already has a pre-assigned IPv6 GUA
prefix and another that the client does not. For civil aviation, aircraft will be given a
pre-assigned 24-bit Identification number that is essentially the equivalent of an
automobile's Vehicle Identification Number (VIN). It is hard-coded into the aircraft,
and it stays with the aircraft throughout its lifetime. The addressing scheme for
aircraft creates an IPv6 GUA prefix that embeds the 24-bit ID in the prefix so that
the prefix is uniquely assigned per-aircraft. For example, the ID 0x010203 would be
embedded within an aviation service prefix such as "2001:db8::/32" to produce the
aircraft-unique prefix 2001:db8:0102:0300::/56 (note that this is just an example,
and will not be the actual aviation service prefix nor format that will occur in
operational practice). In this way, each aircraft receives a unique IPv6 GUA prefix,
and can form a unique OMNI LLA as fe80:2001:db8:0102:0300::.

In the second case, a client that does not have a pre-assigned IPv6 GUA nor
OMNI LLA needs to get one from the network. It issues an RS message with
"unspecified" source address (i.e., "::") and with a "DUID" option that contains
a unique ID for the client. A router on the OMNI link receives the RS and
(acting as a DHCPv6 "proxy") uses the DUID to solicit a prefix delegation from the
DHCPv6 server. The server returns an IPv6 GUA such as 2001:db8:5:6::/64, and
the "proxy" constructs an OMNI LLA as fe80:2001:db8:5:6::. The "proxy" then
returns an RA message to the client with destination set to fe80:2001:db8:5:6::
and with a Prefix Length indication. The client then discovers that its OMNI LLA
is fe80:2001:db8:5:6:: and that its IPv6 GUA prefix is 2001:db8:5:6::/64. This
information is guaranteed to be unique on the link since it came from an
authoritative and well-managed DHCPv6 server.

So, we get both prefix delegation and unique IPv6 link-local address
assignment that is managed for uniqueness.

> > + a means for asserting and/or receiving IPv6 GUA prefixes without explicit
> >   prefix delegation messaging over the wire
> 
> Implied prefix delegation by the implementation knowing that it should find it's prefix at bit position <n:m> in the packet... doesn't
> seem like following the principle of least astonishment.
> Likewise having the routing system glean information from RSs... is that really the level of adaptiveness you need from a routing
> system?
> 
> I'm not sure I get the motivation between these choices?
> As opposed to using existing IPv6 mechanisms for the same.

See above for the explanation. In terms of messaging, it would go like this:

Client  --- (RS) ---> Router ("Proxy")
Proxy --- (DHCPv6-PD Solicit) ---> DHCPv6 server
Proxy <--- (DHCPv6-PD Reply) --- DHCPv6 server
... Proxy adds route to the routing system...
Client <--- (RA) --- Router ("Proxy")

So, it becomes a way for the Client to initiate DHCPv6-PD but driven by the IPv6 ND
router discovery process. It allows for smaller messages on the Client<->Router link,
and can use security features available for IPv6 ND such as SEND, which would be an
improvement over the scant authentication features provided by DHCPv6.

It fits what we would like to do for civil aviation. I think it fits well for many other
use cases also.

Fred

> Best regards,
> Ole
> 
> >
> > So, for example, if a node has been pre-assigned an IPv6 GUA prefix 2001:db8:1:2::/64
> > then it can configure the OMNI LLA fe80:2001:db8:1:2:: (but note that this is not RFC4862
> > SLAAC; it is a simplified means of setting up an administratively-configured LLA that is
> > known to be unique on the link). The node can then assert its IPv6 GUA to the routing
> > system by sending an RS with fe80:2001:db8:1:2:: as the source address and with a
> > Prefix Length value 'N'.
> >
> > In a second example, if a node has no pre-assigned IPv6 GUA then it can send an RS
> > message with IPv6 address unspecified. When it gets back an RA, it can determine its
> > (delegated) IPv6 GUA prefix by examining the destination address. For example, if
> > the RA message has destination address fe80:2001:db8:3:4:: and the message includes
> > a Prefix Length 'N' and lifetime value, it can adopt fe80:2001:db8:3:4:: as its own
> > OMNI LLA and adopt 2001:db8:1:2::/N as its own IPv6 GUA prefix.
> >
> > There are also IPv4-compatible OMNI LLAs of the form fe80::ffff:[v4addr] and
> > "Service" OMNI LLAs of the form fe80::[32-bit ID]. All of these address forms
> > appear in Section 7 of the document, and their use is discussed throughout:
> >
> > https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/
> >
> > Thanks - Fred
> >
> >> Best regards,
> >> Ole=