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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 27 November 2020 17:35 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 C257B3A0AB8 for <ipv6@ietfa.amsl.com>; Fri, 27 Nov 2020 09:35:53 -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 4oFDmXprvaQc for <ipv6@ietfa.amsl.com>; Fri, 27 Nov 2020 09:35:52 -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 1D6753A0AB4 for <ipv6@ietf.org>; Fri, 27 Nov 2020 09:35:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A6F9D389F3 for <ipv6@ietf.org>; Fri, 27 Nov 2020 12:37:20 -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 I2kX-7k3qGta for <ipv6@ietf.org>; Fri, 27 Nov 2020 12:37:20 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2F449389F2 for <ipv6@ietf.org>; Fri, 27 Nov 2020 12:37:20 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DF22A1EA for <ipv6@ietf.org>; Fri, 27 Nov 2020 12:35:49 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
In-Reply-To: <CAKD1Yr01KFF47DgCx69E487_E_ZoNCMqoK-K9N-4uYXcnPDOvQ@mail.gmail.com>
References: <m1kiLjK-0000EaC@stereo.hq.phicoh.net> <7BB64BE0-6A62-4711-91E4-1393EDC0809E@employees.org> <m1kiaW6-0000IFC@stereo.hq.phicoh.net> <074a3f13-732a-a495-9a6f-5d2c2e1d7961@foobar.org> <CAKD1Yr01KFF47DgCx69E487_E_ZoNCMqoK-K9N-4uYXcnPDOvQ@mail.gmail.com>
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: Fri, 27 Nov 2020 12:35:49 -0500
Message-ID: <21547.1606498549@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/qYut5vtQbOgwLPvjcz-2E6GKIzA>
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: Fri, 27 Nov 2020 17:35:54 -0000

Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:
    >> You can't run a flexible address assignment protocol without a
    >> provisioning database. ND is typically implemented in o/s kernels, so
    >> interfacing this with user-mode radius is architecturally troublesome.
    >>
    >> As a separate issue, adding this level of complexity also goes against
    >> many of the design principals that ND was intended to fulfil.  It could
    >> be argued that these principals are already being infringed on, but a PD
    >> extension would take this several steps further.
    >>

    > I don't think that's the case. I'm sure there are residential broadband
    > deployments that use Framed-Ipv6-Prefix radius attribute to assign the
    > directly-connected IPv6 prefix to the customer. I once designed a network
    > like that many years ago, and the BNGs at that time already supported it.

Exactly.  It's just stupid to do it any other way.

Even if you really want dynamically assigned prefixes from a pool (with
forced nightly renumbering even), it's still smarter to do that in the radius
server rather than in the DHCPv6-PD server.   That's because you need the
audit logs, and you want the minute to minute persistant across power cycles of stuff.

If we could do *all* IPv6 assignment via PD (whether DHCPv6-PD, or some new
way), and never number the PPP link there are many gains to be had.

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