RE: [EXTERNAL] Re: [v6ops] Next step? [Re: The bottom is /112]

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Sun, 22 November 2020 14:59 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 80C2C3A17A3; Sun, 22 Nov 2020 06:59:45 -0800 (PST)
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 F-1QPScJTiwz; Sun, 22 Nov 2020 06:59:44 -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 899B73A17A2; Sun, 22 Nov 2020 06:59:43 -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 0AMExedR032392; Sun, 22 Nov 2020 09:59:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1606057181; bh=GMJq8DaA4B4gXtc5THFXdkh4zkQGZ8TtHmAbqRf6JY8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=qsvAR4NpER97Epmvf71tuCX/OsOsNwjYMwL32MVUuZp5C0Jh8sgAnTwAGeJC9JZ/H kZ+a2YZp1lKRCsuW8SwmrgPQ6vfIp0104fgZfuzGlw5DuAaUdFz41wJ/DzCOFl+sjd /P55gPWM4++2JHJ2tV0zk9RMxzRc6253kqNca2GFYI8/1LielA2RqpiEC5KFjJcqn6 kqpNhJVODBANFoouxJOjkqPVVvp+XDJAoKEjeT9eaiq6qqe8v9qEr5hSHKyOS2sL2w W9ac96RvwCziTHfTIrcH1OYpCkrmlPwqBLYbl5MQY72NxUdeMpmYzt1+Ok5OLh0SNf dF3F5OvD9/3hw==
Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AMExbod032384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Sun, 22 Nov 2020 09:59:37 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Sun, 22 Nov 2020 06:59:36 -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; Sun, 22 Nov 2020 06:59:36 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Ca By <cb.list6@gmail.com>, Mark Smith <markzzzsmith@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: IPv6 Operations <v6ops@ietf.org>, 6MAN <6man@ietf.org>
Subject: RE: [EXTERNAL] Re: [v6ops] Next step? [Re: The bottom is /112]
Thread-Topic: [EXTERNAL] Re: [v6ops] Next step? [Re: The bottom is /112]
Thread-Index: AQHWv81t/98QWONPeUCYw3+yMRkiTanUO2mA
Date: Sun, 22 Nov 2020 14:59:35 +0000
Message-ID: <e9b3d9e654c14020bebd83d3156c7d2c@boeing.com>
References: <CABNhwV3fj-e9bEemivcNovnD3SZvKm8ZjFKp7BmusnPcgyznFQ@mail.gmail.com> <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <CABNhwV19neE3U_AisNp2nDUF4bWB8P8xHNEznDevZLE9amFTRA@mail.gmail.com> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <CABNhwV3bCss9y7cT6w2i+LKWBh1viPSXBM-CTaK+GVDyPS2D8w@mail.gmail.com> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <CABNhwV0-FZpPs84+RVB81=5H5QCEaxF0EUj9tcV+bdOu00RE2A@mail.gmail.com> <fb87c22c-388d-0492-1ea7-018655353f9b@joelhalpern.com> <CABNhwV0TbS7Kiynb=jvczJFDyy=uMfd-he+d0ii7aU5AnsUKeA@mail.gmail.com> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <CABNhwV1pSiEuaOZGN5ErR=KETjD1fVb58YM1EEd+mf7RtOenQw@mail.gmail.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> <CAO42Z2yvXCfn8bxxk7mT7MozmCyexmVKNCOvktf2sV-S7WPxig@mail.gmail.com> <CAD6AjGQCm4U06huxns6qGKPAa-MqbeaHpjZAhpBuv-S13xo44Q@mail.gmail.com>
In-Reply-To: <CAD6AjGQCm4U06huxns6qGKPAa-MqbeaHpjZAhpBuv-S13xo44Q@mail.gmail.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: CBB39D98A7F4556C91331739F299DFD8CBD0C061E89EF61F6708529AF2B69A432000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TouF2efYKk_-MtYZ11HX5zJy-bU>
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: Sun, 22 Nov 2020 14:59:46 -0000

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.

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.

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