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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 26 November 2020 17:14 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 10C943A1505 for <ipv6@ietfa.amsl.com>; Thu, 26 Nov 2020 09:14:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NZ_VdfAbaKxj for <ipv6@ietfa.amsl.com>; Thu, 26 Nov 2020 09:14:37 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CECB3A14FF for <ipv6@ietf.org>; Thu, 26 Nov 2020 09:14:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 43560389EE; Thu, 26 Nov 2020 12:16:02 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xjSJHKOh1ubU; Thu, 26 Nov 2020 12:16:01 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B3AA389EA; Thu, 26 Nov 2020 12:16:01 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9C82826C; Thu, 26 Nov 2020 12:14:34 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>, ipv6@ietf.org
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
In-Reply-To: <m1kiFrc-0000ETC@stereo.hq.phicoh.net>
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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 26 Nov 2020 12:14:34 -0500
Message-ID: <28088.1606410874@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Qk_jdbp7fX2ko5zr0GM5ZnXG4ro>
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 17:14:39 -0000

Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> wrote:
    >> A point of draft-richardson-6man-cpe-provisioning-00 (expired, rather immat=
    >> ure),
    >> was to allow the downstream device to declare what they were, and how they
    >> wanted to get addresses.   I was imagining an IP6CP option that would simply
    >> advise what the downstream is, and what the upstream could support.
    >> This avoids assigning a /64 (and running RA) to the link if it makes no sen=
    >> se.

    > A bit in RS could say 'no need to number the uplink if a prefix is delegated'
    > and a bit in the RA could say 'here is a prefix, but don't use the first /64'

yes, we could signal things that way, but:
  1) can the CPE set this if a prefix won't be delegated?
  2) what method will be used to get the prefix?
     And, can use a /64 from within the /56,/48(whatever) that will be delegated?

I agree that it can be solved, but it feels really awkward.

    > That should be enough for most practical purposes. An IP6CP has the advantage
    > that the information is at the router before the first RA is sent. Putting
    > the information in the RS has the advantage that information does not have to
    > cross different layers and is avaiable on all link types.

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.

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

    > Of course, the /64 of the upstream could be taken form a completely different
    > prefix. This would waste a /64 per link, but we have enough of those.

Yes, we have lots of /64, but ISPs tend to prefer to not waste more FIB
entries than they need to.  Getting the /64 from within a bigger block that
will be routed to the customer is a win.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide