Re: [v6ops] Next step? [Re: The bottom is /112]
"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 23 November 2020 16:24 UTC
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CBC3A098A; Mon, 23 Nov 2020 08:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.218
X-Spam-Level:
X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[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 omYq1aOLmvx8; Mon, 23 Nov 2020 08:24:37 -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 5D9CE3A0989; Mon, 23 Nov 2020 08:24:35 -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 0ANGOWZX007131; Mon, 23 Nov 2020 11:24:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1606148674; bh=Uv47T3t/4XIhtm/GgOx0hRIwhZckvZRlUnvbDwr2iZ0=; h=From:To:CC:Subject:Date:From; b=NO7u9Y+FY1C0EAttivy1F5aBZ6L/sKQjD6ZCZS5qTglLv3sJt+V1Dlm7OVUkxB7Ht 5ymf0Q2SYbopOpC2IlxsW03tkCPZM0uaqcuhHl+Ub/1rKrhrhaCrlmtqaefXiDse7h 0g0ZIqUt0zj8nYkFkS2mPRB/mG1fZBwvH2Cu3btaqvFLMQlgIyailxTuxResCPs3wE EKAPTxKN6ud2+AynhunlHxAs9kem3ZsTh6KDgF/xiuLuxNHZXmImPw7x77omBf0KfB ReYqH/OOW7P54m5fVEGoNrD23WADbPMtx5H0hMoOUVAmFErPmeTxYii8dFVdM2Z1G4 Z4pwGOedgMf6A==
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0ANGOKNO006986 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 23 Nov 2020 11:24:20 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 23 Nov 2020 08:24:18 -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, 23 Nov 2020 08:24:18 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Mark Smith <markzzzsmith@gmail.com>
CC: Ca By <cb.list6@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, IPv6 Operations <v6ops@ietf.org>, 6MAN <6man@ietf.org>
Thread-Topic: [v6ops] Next step? [Re: The bottom is /112]
Thread-Index: AdbBs7DABd4VOkfZTvWrxcKqAP+vAg==
Date: Mon, 23 Nov 2020 16:24:18 +0000
Message-ID: <fe44a5687f864e24a10f917fa9015156@boeing.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: 847C8425E398F9A135BC47C9001614344AF737243A057B537A43C4A55C8D2BA32000:8
Content-Type: multipart/alternative; boundary="_000_fe44a5687f864e24a10f917fa9015156boeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LDm-JY95fyYOXtkGh5C5MUgyTcw>
Subject: Re: [v6ops] Next step? [Re: The bottom is /112]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Nov 2020 16:24:39 -0000
Mark, my initial description was purposefully light on details but to get the full picture you can have a look at the following draft: https://datatracker.ietf.org/doc/draft-templin-6man-lla-type/ The idea for this LLA-based PD scheme is as follows: 1) The requesting router creates a temporary LLA using RFC4941(bis) and sets a prefix length indication inside the LLA itself. The RR then uses the LLA as the IPv6 source address of an RS message to send to the delegating router. 2) When the delegating router receives the RS, it sees that the IPv6 source is an RFC4941(bis) address with a non-zero prefix length indication. The DR then coordinates with the DHCPv6 server to request a PD of the length indicated by the RR. 3) When the DR receives the PD from the DHCPv6 server, it creates an OMNI LLA by embedding the delegated prefix in the IID of fe80::/64, e.g., as fe80::2001:db8:1:2. The DR then sets a prefix length indication in the OMNI LLA, and sets the LLA as the destination address of an RA message to send back to the RR. 4) When the RR receives the RA message, it sees that the destination is an OMNI LLA with a non-zero prefix length. The RR then uses the embedded prefix within the OMNI LLA as its delegated prefix, and regards the Router Lifetime as the time at which the delegated prefix needs to be renewed. You also asked about the long-lived usage of unique LLAs, and I think what we need to consider is that IPv6 interfaces may configure multiple LLAs of multiple different types. The types need to be coordinated so that they do not collide with one another and cause duplication. All of this is explained in the draft cited above. Thanks - Fred From: Mark Smith [mailto:markzzzsmith@gmail.com] Sent: Sunday, November 22, 2020 12:10 PM To: Templin (US), Fred L <Fred.L.Templin@boeing.com> Cc: Ca By <cb.list6@gmail.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; IPv6 Operations <v6ops@ietf.org>; 6MAN <6man@ietf.org> Subject: Re: [EXTERNAL] Re: [v6ops] Next step? [Re: The bottom is /112] 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 Mon, 23 Nov 2020, 01:59 Templin (US), Fred L, <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote: Hi, I believe the AERO/OMNI approach to prefix delegation would be good for the 3GPP case also. The approach is predicated on the router returning an RA with an IPv6 link-local destination address determined by the delegated prefix. The link-local address is formed by writing the most significant 64 bits of the delegated prefix into the interface ID of the prefix fe80::/64. For example, if the delegated prefix were 2001:db8:1:0::/56 then the IPv6 link-local destination address is fe80::2001:db8:1:0. This provides at least two important operational advantages. 1) It conveys the delegated prefix in the IPv6 destination address of the RA so that no PIOs inside the RA need to be used for prefix delegation. In my operational experience it is far better to make things explicit in packets rather than implicit. See RFC8469 for an example of where what was implicit in packets has caused so many problems that now being explicit has become the recommendation. (Absence of this in a wholesaler's network caused us and a customer months of troubleshooting for unusual performance problems, and is now costing us service outages for many customers at once while they put it in place.) 2) It supplies the mobile node with a guaranteed-unique link-local address that it can use for future communications without the need to perform DAD. So the RA DA is carries both delegated prefix information and with link-local address configuration too? How does a node know to use the RA DA as its link-local address? With the rise of wireless we need to care about the global traceability of link-local addresses too. Persistent, globally unique link-local IIDs have the same privacy implications as persistent globally unique WiFi MAC addresses and Bluetooth MAC addresses. Have a look at https://wigle.net and the Android app for collecting the data. A similar app focused on Bluetooth is Ramble. Neither of these apps require a hacked phone, the can just be installed and run by anybody from the Google app store. Again, the proposal comes from the AERO/OMNI use case, but I believe is also good for 3GPP and really any other wireless use case where a lightweight prefix delegation capability is desired. Fred
- [v6ops] The bottom is /112 (was: RE: Extending a … Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… JORDI PALET MARTINEZ
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… otroan
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gert Doering
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Alexandre Petrescu
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… JORDI PALET MARTINEZ
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… JORDI PALET MARTINEZ
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… otroan
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Joel M. Halpern
- Re: [v6ops] The bottom is /112 Brian E Carpenter
- Re: [v6ops] The bottom is /112 Bob Hinden
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Ole Troan
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Joel M. Halpern
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Joel M. Halpern
- [v6ops] Next step? [Re: The bottom is /112] Brian E Carpenter
- Re: [v6ops] Next step? [Re: The bottom is /112] Mark Smith
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Mark Smith
- Re: [v6ops] Next step? [Re: The bottom is /112] Ca By
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gert Doering
- Re: [v6ops] Next step? [Re: The bottom is /112] Ole Troan
- Re: [v6ops] Next step? [Re: The bottom is /112] Mark Smith
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Alexandre Petrescu
- Re: [v6ops] Next step? [Re: The bottom is /112] Joel M. Halpern
- Re: [v6ops] Next step? [Re: The bottom is /112] Joel M. Halpern
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Mark Smith
- Re: [v6ops] [EXTERNAL] Re: Next step? [Re: The bo… Templin (US), Fred L
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] [EXTERNAL] Re: Next step? [Re: The bo… Mark Smith
- Re: [v6ops] Next step? [Re: The bottom is /112] Michael Richardson
- Re: [v6ops] Next step? [Re: The bottom is /112] Gyan Mishra
- Re: [v6ops] Next step? [Re: The bottom is /112] Gyan Mishra
- Re: [v6ops] The bottom is /112 Gyan Mishra
- Re: [v6ops] The bottom is /112 Gyan Mishra
- Re: [v6ops] The bottom is /112 Pascal Thubert (pthubert)
- Re: [v6ops] Next step? [Re: The bottom is /112] Vasilenko Eduard
- Re: [v6ops] The bottom is /112 Gert Doering
- Re: [v6ops] Next step? [Re: The bottom is /112] Templin (US), Fred L
- Re: [v6ops] Next step? [Re: The bottom is /112] Alexandre Petrescu
- Re: [v6ops] Next step? [Re: The bottom is /112] Templin (US), Fred L
- Re: [v6ops] The bottom is /112 Brian E Carpenter
- Re: [v6ops] The bottom is /112 Brian E Carpenter