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

tom petch <ietfc@btconnect.com> Wed, 25 November 2020 17:03 UTC

Return-Path: <ietfc@btconnect.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 E53203A1AB7 for <ipv6@ietfa.amsl.com>; Wed, 25 Nov 2020 09:03:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 96QWREGw_y7b for <ipv6@ietfa.amsl.com>; Wed, 25 Nov 2020 09:03:09 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60112.outbound.protection.outlook.com [40.107.6.112]) (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 6B8723A1AB0 for <ipv6@ietf.org>; Wed, 25 Nov 2020 09:03:09 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KJcHolf8BnvZr4DeX+8RaB0c/nitdbVpN775jf5evJjn3HXlzNZYoMfs3GGAs96C8nPsOrBmFww+U3dW6HthldO4Y8y2slI3IzWImGY3RmLX8nrxVK4J/pLiMlx/azJBKVDVMtGJYsXVL0vPByJkCVYYFN0rZ6ohXf443hQwGBGqWzkTtQSyqSboGSHu+3pGwaNatasOFHABFtzw0G4DpT/xB4jOrveK+31OUvUaeiBfLGVVUSjU0zSQENCeFAJlwtxzKbxk91yBZ1byjJ15fK4cCkTSfC1PbOj9sLgEBB4+M8gydwmHOdhRzGE9NyU4nIElIu9nQAlS5s89o+Leug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G03nGBt+1zhpod57MLltmpOmHAYWjfVy3oFqVxI/Ul0=; b=d7r8RoKjj9h5nJOzRafGJtv9F6PAC5mtOJsFEMuGdYHazumsyTW8gkIT+EtnC3/dNsYVqPYI3EGHXQ2ok17ukAIZfYIW7ha7Pb18GxBOvrjiToGmc5goIkuuQErUECyUfMMiAnBN0O3Tr31NcA9vDRm+YtIxpTEcd0YDOv6J74y+ZnRecXmo9+mJA+ATDeF7zKA5uO7aDR8Nsybk5nUVOoA+EBhOyuuygboTZISgLSGR3tCW0VltYUrhx/1b556cDW5eXz2bR1DE6GGSbcMzjaO6XJinCzbug4EV49cvKoJhmjYA1n/aw7gKvJQ/AkpNRJNi+y2NUJT2eIdXoFgosA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G03nGBt+1zhpod57MLltmpOmHAYWjfVy3oFqVxI/Ul0=; b=TTYOKH7i8GXASi2AAaj6JGcxNqqvyhPkjn3QtiYTS6YVZhR7BdIeJLrGAZ8nc1+bXdhqG+SJnR2ICsNVXWB0xJ/G9QRIKS4v4rglm3k9+v53fApRuXpxj8n7pB2H4Mlyxiy5MYckuhgYl0qVrxvOrEdVl8wkPGDHIB+ggE+ntS4=
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM7PR07MB6325.eurprd07.prod.outlook.com (2603:10a6:20b:13e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.16; Wed, 25 Nov 2020 17:03:07 +0000
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804%7]) with mapi id 15.20.3611.016; Wed, 25 Nov 2020 17:03:06 +0000
From: tom petch <ietfc@btconnect.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, David Allan I <david.i.allan@ericsson.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "ipv6@ietf.org" <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: AdbCrBJZQpt+0a0wT/6DvMi5tarEVwABLiWgACFgsUAABXgFuw==
Date: Wed, 25 Nov 2020 17:03:06 +0000
Message-ID: <AM7PR07MB62482DCE11A0C839B648693FA0FA0@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: <d839b04e8c6840edaf042478964ce793@boeing.com> <BY5PR15MB37150A20A6CD1144A22A3F9AD0FB0@BY5PR15MB3715.namprd15.prod.outlook.com>, <3e8c14c4c3da4909b4642a84315299bb@boeing.com>
In-Reply-To: <3e8c14c4c3da4909b4642a84315299bb@boeing.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: boeing.com; dkim=none (message not signed) header.d=none;boeing.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.146.121.140]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c38197a5-55e4-4697-0443-08d89163fae2
x-ms-traffictypediagnostic: AM7PR07MB6325:
x-microsoft-antispam-prvs: <AM7PR07MB6325D2F9CADBD2AE422EA55BA0FA0@AM7PR07MB6325.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: h/6nwhmKNUq0JDC8H8Est/KVDVDlGXHr4bI6tJVGSJIVj1lto5fH8TcV47lxaJlkIy30x0Kpii0ves05MHn0g3hHtWPxFhGDbAonZ2qmyioXYZMIbkGMtXq3MG0KhlHfksBKJQh8VxwbuYddImlR19AGZUd7zQy5tchNGG6NxZtIlaYCcO+D9f0MdltpG9yU8suFw/87dP0gNx/tyQm2I9pnJUe1bRpj5YSLQQnio9uAbgZfqUiL+KdYHqwxSwHjPgY7MY+9RAFB/kIVoh/keGCJt1JKjrOjo2rSpWONsc/YDsFPAMKhfk/Zgf4qPO4mn/nT7gDIfho+rLPgsd3DLhXNo1fU+kLvJmSBYm0AgR3TyFejTbUWlIm4QeZ9j45X3gjvhP6+o81pHaVXzP/DVA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(136003)(39860400002)(366004)(396003)(966005)(76116006)(5660300002)(91956017)(71200400001)(55016002)(9686003)(478600001)(8936002)(316002)(66574015)(52536014)(110136005)(33656002)(83380400001)(53546011)(86362001)(8676002)(66446008)(2906002)(186003)(7696005)(26005)(66556008)(66476007)(64756008)(66946007)(6506007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?lAFz5jDe1xwRdwc4wLq5GPY9UMeLaJXIrqAJHACow56VCUgnwOB3mAO9vm?= =?iso-8859-1?Q?2ijZ+y66RB5QuA6816hfUPnbtQ3WL/bULuXLg0pw1lOLSA81EAQ5e4wwlz?= =?iso-8859-1?Q?LtqvRb4cZhI+wkltwt+nJqH9mwZWOvk43pJ5JmIfEfVmqAO439uDF8C8/U?= =?iso-8859-1?Q?wuzXFklrZBF3Iy28VOEscT5C1Kqj7qdoqUVSg/BqHRRKZlVJHGUV+EbevX?= =?iso-8859-1?Q?tnG/jFO/xNWIyRjP6hfOADnl8/dcNCsm+jfNVVyFL6HClIgtfoSTB2y+od?= =?iso-8859-1?Q?kw2v3JufQzFZr42gc8f12cbP4NHY5wGw1GHFqrntmLaVOzmqW9Neax1tgF?= =?iso-8859-1?Q?sym9PyxYuul+wwHRitlCZAVGTy6kLMxPsEwj8cuSO/dNCdQcMRfXBGeBj/?= =?iso-8859-1?Q?dr3cOE4NjwbVxmOlYSIdr45tD/bYnOQnYTZL0V3y2Rvb+A2gHhHwDypUOl?= =?iso-8859-1?Q?MSxozxYstfQPYiAb7u5Rgcs1WOxC5irzy4IMBzANB7jwbLZLo/i5XuPUlN?= =?iso-8859-1?Q?5umad3x9y6aBYGH3LkQjpP/86GcwqX+X9i/wFjxSg5/Kx5GXb+qRMkWkZh?= =?iso-8859-1?Q?k7RS6CN4PG735YtLrFjaYKgz9d18QttYvY/BZrqGsC1iaSwxGy73JvkF7C?= =?iso-8859-1?Q?B+nhUWuOtuHElT9JoowqjrTNgOaMZwkXSu1XtPOWWHnzVBVulLhjSo2NPn?= =?iso-8859-1?Q?LBfSDGg5hrLOoKzRLTWWqDdWK8PuFR6ri9jTlNGSMf5LHQwIAIKT/k8FLQ?= =?iso-8859-1?Q?jE+fq3ZKJfPrqgNDb4vq8IEI5O8/5ontfHKAG78GX4nfe3dRw271vFiKe6?= =?iso-8859-1?Q?AdIRRW+bwtzzv9KlpY7Ti/2A0wpFrbnxDlE5R+sdNgaa0pvMbR0A1OjsGT?= =?iso-8859-1?Q?L4X7hFQ31GnU3DmZwtul0Ee9xgXL48tBOC4IyhpZXswHl40m5t5d4u9PXV?= =?iso-8859-1?Q?onjMwRYaL+4ycESv+D6YSodge747YSzRXbxJLqNGtTgM/cF1I0qNoOZWVq?= =?iso-8859-1?Q?rQ7yl9DBhweaU7+mw=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c38197a5-55e4-4697-0443-08d89163fae2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2020 17:03:06.9144 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: q18P+H6D/e8UI7nU3LR0Xb8E3AS2ofhBnJbxwy+HhoHRstSOeb1jN2iL/CVYJjzts4T819LNd+hv8B4nN9rn3g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6325
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jTgJRTRpyyuOCGgSbXxXFt5CleU>
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, 25 Nov 2020 17:03:12 -0000

From: ipv6 <ipv6-bounces@ietf.org> on behalf of Templin (US), Fred L <Fred.L.Templin@boeing.com>
Sent: 25 November 2020 14:23
> -----Original Message-----
> From: David Allan I [mailto:david.i.allan@ericsson.com]
> Sent: Tuesday, November 24, 2020 2:29 PM

> FWIW for a 5G UE, the SMF assigns the interface ID used for LLA etc. as part of the PDU session setup.  See TS24.501 clause 9.11.4.10.

Wouldn't it be better if the interface ID contained a useful piece of information such
as a delegated prefix, instead of just a bag of bits?

<tp>
No!
An identifier should identify, be unique within its namespace, be easy to use in whatever manner it gets used.

Load it up with 'useful' semantics and it will become defective as some of the semantics change or aren't present in some cases.

Brian addressed this back in June.

Tom Petch

Fred

> Cheers
> D
>
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Templin (US), Fred L
> Sent: Tuesday, November 24, 2020 1:52 PM
> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>om>; ipv6@ietf.org
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
>
> Alex, see below:
>
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandre
> > Petrescu
> > Sent: Tuesday, November 24, 2020 1:33 PM
> > To: ipv6@ietf.org
> > Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> >
> >
> > Le 24/11/2020 à 17:44, Templin (US), Fred L a écrit :
> > > 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.
> >
> > YEs for 1), but for 2) one would also consider the IPv6CP part of ppp
> > and the PDP protocols.  These two protocols are also involved in the
> > negotiation of an IID, LLA or even a GUA some times, on that link.
>
> I assume this exchange happens even before the first IPv6 ND message exchange over the link? If so, then if the PDP protocols
> convey an OMNI LLA even before any IPv6 ND message exchange then the "PD" operation will already be complete since the OMNI
> LLA already contains the delegated prefix. Would that be a useful simplification?
>
> Thanks - Fred
>
> > Delegating a prefix is typically associated by an operation of
> > insertion of an entry in a routing table.  That entry should have a
> > next hop address.  That address could be an LL address or a GUA.
> > These are negotiated by these IPv6CP or PDP protocols.
> >
> > If it is too complicated to make IPv6-PD option to use the addresses
> > created by IPv6CP or by PDP as nexthop, then one could delegate a
> > prefix without pointing to a nexthop, but using that old p2p trick.
> >
> > Also, the suggestion of this draft of using another LL address comes
> > down to associating several LL addresses to an interface; because the
> > LL address made by PDP or IPv6CP is always there.  If such a 2nd LL
> > address is associated to an interface, but is not used in the Gateway
> > as a nexthop field, then one wonders why bothering forming it at all.
> > An interface must always have one LL address, and that is given by
> > IPv6CP or PDP, I think.
> >
> > I am not saying it is not a good idea, though.
> >
> > Alex
> >
> > >
> > > 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
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------