Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

Mark Andrews <marka@isc.org> Sun, 08 November 2020 23:58 UTC

Return-Path: <marka@isc.org>
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 3828A3A1003; Sun, 8 Nov 2020 15:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, 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 8Q4ITAtmyPiS; Sun, 8 Nov 2020 15:58:37 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 61FD93A0FF3; Sun, 8 Nov 2020 15:58:37 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 7D6C43AB0D2; Sun, 8 Nov 2020 23:58:34 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 71B29160083; Sun, 8 Nov 2020 23:58:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 48FF8160082; Sun, 8 Nov 2020 23:58:34 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KLpiUWR3fEio; Sun, 8 Nov 2020 23:58:34 +0000 (UTC)
Received: from [1.0.0.3] (n114-75-120-99.bla3.nsw.optusnet.com.au [114.75.120.99]) by zmx1.isc.org (Postfix) with ESMTPSA id 535DA160081; Sun, 8 Nov 2020 23:58:33 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Subject: Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CABNhwV13gggo9XfRvrR31bCUptZuAiosK5ebMmnzDdinKqmrBw@mail.gmail.com>
Date: Mon, 09 Nov 2020 10:58:30 +1100
Cc: Lorenzo Colitti <lorenzo@google.com>, draft-mishra-6man-variable-slaac@ietf.org, 6man <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7B3091C-92E0-482A-8D16-AD6DCFD1E714@isc.org>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.com> <CAKD1Yr0vvyQnTGRoSh4qa4He1gq5HXXRaKU3pVLtCtDUzcwL_w@mail.gmail.com> <CABNhwV13gggo9XfRvrR31bCUptZuAiosK5ebMmnzDdinKqmrBw@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JnyP6u0A28i50230WEyARQk_LnE>
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: Sun, 08 Nov 2020 23:58:39 -0000


> On 5 Nov 2020, at 02:54, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> On Wed, Nov 4, 2020 at 3:51 AM Lorenzo Colitti <lorenzo@google.com> wrote:
> On Tue, Nov 3, 2020 at 4:27 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
> It's hard to see why this draft is needed anyway. All that is needed
> is to remove the "64 bit" statement from the addressing architecture,
> which the WG has consistently failed to reach consensus about.
> 
>     Gyan>  This topic has come up many times over the years in heated debate and this is another instance of that.  Agreed.  However, what makes this instance different is that we have a major problem to be solved with 4G  &  now as 5G is rolled out, segmentation is of utmost importance.  I think in the past we have not had a major problem to be solved and so this change being proposed did not gain traction,  but now as 5G becomes the "norm" as it will compete directly with broadband that customers will start using 5G in SOHO as well as other environments.   This is a major issue that has come up with the ramp up for 5G IPv6 only deployments.
> 
> There is already a solution to this: use DHCPv6 PD on 5G networks. It's been supported since 3GPP release 10 several years ago.
> 
>    Agreed.  Fixed 5G broadband agreed would use the current wired broadband DHCPv6 PD and would follow the BSOP RIPE-690 and I think would use the recommended shorter prefix like a /56.  As fixed 5G would take advantage of the value added at a premium network slicing capabilities for the front haul and backhaul I can see Broadband 5G getting even a /48.  The issue mentioned in the draft is related to 4G as well as 5G “mobile handsets” and getting a /64 allocation which has been the standard which cannot be segmented by the Subscriber customer end.

This is a failure of imagination, not a technical impossibility. There is nothing preventing cell phones from being a router that hands out /64s to other routers than people with lack of imagination.  Cell phones have more than enough capacity to do this.  It’s not like the cell phone are incapable of handling /56 or /48 responses these days.  10 years ago there where some that fell over but given the attrition rate of cell phones and that there are newer images that do correctly handle shorter than /64 should have reconciled this to history.

Even in Africa the cost of a /56 per customer per year is well under 0.01USD as is the initial allocation fee.

                Allocation fee Membership
Small	/32	$2,500	       $2,500
Large	>/32	$20,000	       $20,000

$2500/(2^(56-32))
.00014
$20000/(2^(56-31))
.00059
$20000/(2^(56-28))
.00007

I think most of this comes down to can I save $18000 per year over a customer base of > 16 million.  Penny pinching at its extreme.

> I don’t see the mobile handset /64 prefix being going any shorter even for 5G.  For 5G the business driver for larger allocation is for the value added network slicing capabilities and the is relevant only for fixed broadband 5G which will replace wired broadband.  Mobile handset 5G will not get network slicing capabilities as it would use the front hall handset to tower backhaul tower to core Normal RAN Radio VPN.  Compared to Fixed 5G broadband which would have capabilities of being provisioned for high priority network slice Enhanced VPN with resource isolation and dedicated resource characteristics.

> -- 
> 
> 
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org