RE: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 24 November 2020 16:44 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 BC4443A11EC for <ipv6@ietfa.amsl.com>; Tue, 24 Nov 2020 08:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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 YoBJ9957Lbly for <ipv6@ietfa.amsl.com>; Tue, 24 Nov 2020 08:44:33 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 071923A0934 for <ipv6@ietf.org>; Tue, 24 Nov 2020 08:44:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AOGiQBd014121; Tue, 24 Nov 2020 11:44:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1606236269; bh=n2y+BtEu2I8p/SNKGAvvF/7VpN5wHtW/mZcoyHRcu7A=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=LlBoeRzXH/frpeQCOMj77Lr3fpdKCE1bpCHLUMQAKyG+54LKjPmrOIO3XPlTMyay3 7s/P4z4KFNz2P5h/kDcsuCSscpeQbo9FbVxdcwFhY6PHqendy/QAeOfNXLEzPrX/HI DPLM6SkuGsnbqCU3XN0FhU29+ROFmjvVTrH0VWnkJkcdQ45e4F3nSsO9AdywY7vxe0 faaBkGVht9MqJIZCmRsx+WyYnQDcIo477Q/nxWOYq6lZ+M9hvGdGbjc6R0aRBw8/dR P6qv/FxBjDxofVTkuu+vtG8ZHxcSJy3B48zY3ZiSfxhTMExNn/Qg0uPOSJjKsotLyQ tmnqkzDlKaapw==
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AOGiDqi013896 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 24 Nov 2020 11:44:13 -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; Tue, 24 Nov 2020 08:44:12 -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; Tue, 24 Nov 2020 08:44:12 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, "otroan@employees.org" <otroan@employees.org>, Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Topic: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Index: AQHWwWyB4Lub7t3bVESvC0PbrYUO2KnWTGYAgABVowCAAGBbAIAAN2WT///PBICAADYay///2c0AgABDFEP//9FPAAAJPo8QAAC5FAA=
Date: Tue, 24 Nov 2020 16:44:11 +0000
Message-ID: <1b284a58699e4fa39b1602b8f3fede28@boeing.com>
References: <CABNhwV2-dH81CY4wSisV8BU-7H9m5a1xYMqTMecRxhNqZe=ApQ@mail.gmail.com> <CAKD1Yr1xV179LZ7Kxtk5mGruJcJ+BpGb2heBBy4ORtRU7bfvqw@mail.gmail.com> <CAMGpriWqnmL0qo0Hm=b+GbzcdCuXz6PM5aq8owE7-=ty5pDFsw@mail.gmail.com> <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org> <m1khXWs-00007wC@stereo.hq.phicoh.net> <47150D97-27D7-4AFD-8418-692D68D09828@employees.org> <m1khXol-0000MEC@stereo.hq.phicoh.net> <BD254B32-FAAE-4433-9CF5-2AF19275CA96@employees.org> <m1khZLr-0000IXC@stereo.hq.phicoh.net> <51F56897-AEE2-43E6-8FCC-BD9412B53675@employees.org> <ad4aa2ca83e743fb8d23026a7ad0649b@huawei.com>
In-Reply-To: <ad4aa2ca83e743fb8d23026a7ad0649b@huawei.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: 67A3E81422163D1E89B917F8B0249702401ECDD062DA63E174A15D262530C8FE2000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ik2Yx0IVQB_-Iau7ioeLezHAKgk>
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: Tue, 24 Nov 2020 16:44:35 -0000

Getting what I said earlier onto this thread, I think we should be discussing the
LLA-based PD scheme specified in:

https://datatracker.ietf.org/doc/draft-templin-6man-lla-type/

What is unique and compelling about this scheme is that it brings down two birds with
one stone; in a single RS/RA exchange, the mobile node receives both 1) an IPv6 PD,
and 2) an LLA that is guaranteed to be unique on the link without having to apply DAD.

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.

Questions?

Fred