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

Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> Thu, 26 November 2020 18:11 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 47ECA3A15E4 for <ipv6@ietfa.amsl.com>; Thu, 26 Nov 2020 10:11:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 lM8M3zue1X5i for <ipv6@ietfa.amsl.com>; Thu, 26 Nov 2020 10:10:59 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666D93A15E3 for <ipv6@ietf.org>; Thu, 26 Nov 2020 10:10:58 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kiLjK-0000EaC; Thu, 26 Nov 2020 19:10:54 +0100
Message-Id: <m1kiLjK-0000EaC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
From: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.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> <87b38a166eac450db943e005611974bf@huawei.com> <m1khZRX-00001XC@stereo.hq.phicoh.net> <27311.1606325147@localhost> <m1kiFrc-0000ETC@stereo.hq.phicoh.net> <28088.1606410874@localhost>
In-reply-to: Your message of "Thu, 26 Nov 2020 12:14:34 -0500 ." <28088.1606410874@localhost>
Date: Thu, 26 Nov 2020 19:10:52 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xkZuv9E2yqR-cKU3lqQEvg2x5cA>
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: Thu, 26 Nov 2020 18:11:01 -0000

> yes, we could signal things that way, but:
>   1) can the CPE set this if a prefix won't be delegated? 

I assume an RS option that requests a prefix. If the upstream router doesn't
understand the option or does not want to delegate a prefix, then the
upstream router just assigns a /64 to the link.

>   2) what
>   method will be used to get the prefix?

I assume that the prefix will be delegated using a RA.

>      And, can use a /64 from within the /56,/48(whatever) that will
>      be delegated?

I assume the prefix delegation option in the RA will have a bit that
tells the downstream router whether the entire prefix is delegated or that
the first /64 used for other purposes.

> We really don't want it available on all link types, we want it
> available on PPP links.  This kind of modal RS as you describe
> would be a departure from current RS/RA.  An RS can currently be
> satisfied by a multicast RA, and an RS can be suppressed by seeing
> a multicast RA.

Indeed. However, using every /64 out of /48 seems to me like an optimization.

A router can just go ahead and send an RS with a prefix and the bit that
reserves the first /64.

What is best depends on operational reality. If some handset get confused
by a prefix option then it is better to wait for the handset to send an RS.

> Doing this kind of unicast request/response is PRECISELY what DHCPv6
> was created for.

I agree. The question is whether it actually good at this.

DHCPv6 has a very complex model. There can be multiple relays and multiple
DHCP servers. So a downstream router first has to collect offers and then
select one.

DHCP is separate from RA. So coordination is required between DHCP and RA
if we want to delegate the entire prefix.

Worse, we have trouble tying a DHCP PD to link state. 

So there is an opportunity to come up with a better way of doing prefix
delegation.

RA has the advantage that all information can be in a single RA, ensuring
consistency. We can also add mechanisms that the downstream node quickly
and reliably notices flash renumbering independent of link state.