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

Philip Homburg <> Thu, 26 November 2020 11:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E11CF3A1264 for <>; Thu, 26 Nov 2020 03:55:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8d_Na17m-kee for <>; Thu, 26 Nov 2020 03:55:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 534543A1263 for <>; Thu, 26 Nov 2020 03:55:06 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kiFrc-0000ETC; Thu, 26 Nov 2020 12:55:04 +0100
Message-Id: <>
Cc: Michael Richardson <>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <> <> <27311.1606325147@localhost>
In-reply-to: Your message of "Wed, 25 Nov 2020 12:25:47 -0500 ." <27311.1606325147@localhost>
Date: Thu, 26 Nov 2020 12:55:03 +0100
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Nov 2020 11:55:09 -0000

>A point of draft-richardson-6man-cpe-provisioning-00 (expired, rather immat=
>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=

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'

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.

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.