RE: [EXTERNAL] Re: [Iotops] Automatically connecting to stub networks...

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 07 December 2020 20:22 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 9B5063A0989; Mon, 7 Dec 2020 12:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2C9hU9fG-lP2; Mon, 7 Dec 2020 12:22:05 -0800 (PST)
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 3CF703A0964; Mon, 7 Dec 2020 12:22:05 -0800 (PST)
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 0B7KM3hn032499; Mon, 7 Dec 2020 15:22:04 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1607372524; bh=FPyzxw6WxsjH4mrFiQHwXD9CLKXmsdKsPdOYAGShLKU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=YTxV2fP8G+/rh5UTtbiCr6ss/oTg7x6STdysVpWtYL8CC5AkSBmQ6t+wSIGrMz+Fo AUvj1D1dWMb7iXShtYNqcgCIBtrGcdqlS9f9pCYunYbW/pvfUnD63Ebxs3OlNtPPBk tCmp9fuoJzOo/n3pGtk2j/t1MTX00di+bpPUWFxXX6VH1Mvu+cTqT8pfdgFx6BJlUq AlfCsvb6HiJ6NIZ5ZrIkXsL6hWgkzOX9+/vXbdNUQwzVwBkL/ch0ZoYpGougd2oIcW pufToVN2y3x3D+LoING8KcyHlg0vvfMlFLgFyInqjfaOL43MgAjX4X+QtNLReyfkOe JXrXno4Gq4xeg==
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 0B7KLnLx032253 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 7 Dec 2020 15:21:49 -0500
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; Mon, 7 Dec 2020 12:21:48 -0800
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; Mon, 7 Dec 2020 12:21:48 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Ted Lemon <mellon@fugue.com>
CC: "STARK, BARBARA H" <bs7652@att.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Ole Trøan <otroan@employees.org>, 6MAN <6man@ietf.org>, "iotops@ietf.org" <iotops@ietf.org>
Subject: RE: [EXTERNAL] Re: [Iotops] Automatically connecting to stub networks...
Thread-Topic: [EXTERNAL] Re: [Iotops] Automatically connecting to stub networks...
Thread-Index: AdbMz9OConAqMYjZtUCg6orRClX9igASGCKAABCw3JA=
Date: Mon, 07 Dec 2020 20:21:48 +0000
Message-ID: <5c230c43ab9540e1b16a3985e964e93f@boeing.com>
References: <2f1c1e67b96844ce934add51ef2c5f4d@boeing.com> <265D8AB0-82CF-47AE-BE47-B1207D40A3C5@fugue.com>
In-Reply-To: <265D8AB0-82CF-47AE-BE47-B1207D40A3C5@fugue.com>
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: C3B821F0FA432408F1241B1B954CC2B340F86296665AD64D6A321D18A9C3D1752000:8
Content-Type: multipart/alternative; boundary="_000_5c230c43ab9540e1b16a3985e964e93fboeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZFvGImRTEW5WSl_6v2nWDNF8NME>
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: Mon, 07 Dec 2020 20:22:08 -0000

>I’m sorry, Fred, but I’m just not seeing the point of this. Why not just do DHCPv6 PD?

Ted, there is a need to reduce the number of messages especially on low end
wireless links like those used for aviation. So, if a terse DHCPv6 PD exchange
can be piggybacked on-board the RS/RA exchange that already needs to be
there in any case then there is a tangible savings on messages over the air.
This is good for more than just aviation, too, and applicable for mobile use
cases such as intelligent transportation systems and urban air mobility; maybe
even for pedestrians too.

Fred

From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Monday, December 07, 2020 12:11 PM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: STARK, BARBARA H <bs7652@att.com>; Michael Richardson <mcr+ietf@sandelman.ca>; Ole Trøan <otroan@employees.org>; 6MAN <6man@ietf.org>; iotops@ietf.org
Subject: [EXTERNAL] Re: [Iotops] Automatically connecting to stub networks...


This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.




On Dec 7, 2020, at 2:38 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
It now places a fully-formed DHCPv6 message inside of an OMNI option in
RS/RA messages so the stub network node can do DHCPv6-PD at the same
time it does RS/RA (this is something I have talked about before). However,
right now it only allows for a small-message DHCPv6 exchange from within
each RS/RA, which should provide ample space for most stub network
DHCPv6-PD users. Does it look like enough, or should we support bigger?

I’m sorry, Fred, but I’m just not seeing the point of this. Why not just do DHCPv6 PD?