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

otroan@employees.org Mon, 09 November 2020 07:19 UTC

Return-Path: <otroan@employees.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 236E73A0836; Sun, 8 Nov 2020 23:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 VtKEkVEKKJCm; Sun, 8 Nov 2020 23:19:02 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3BB3A0855; Sun, 8 Nov 2020 23:19:02 -0800 (PST)
Received: from astfgl.hanazo.no (201.51-175-101.customer.lyse.net [51.175.101.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id CB11D4E11AFF; Mon, 9 Nov 2020 07:19:01 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id D35664397961; Mon, 9 Nov 2020 08:18:57 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
From: otroan@employees.org
In-Reply-To: <CAD6AjGRXYqJhXL6ipbS_cWkE2mg3sU4tM5XCCvgiGvSALGfeeg@mail.gmail.com>
Date: Mon, 09 Nov 2020 08:18:57 +0100
Cc: 6man WG <ipv6@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, draft-mishra-6man-variable-slaac@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2E4ECDD-B712-407C-B254-1A2FB6A0F2FF@employees.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> <CAD6AjGQPatbg5=OaMzxJXy5mGZai1bqLfg8f+9SUnfg=s1kADg@mail.gmail.com> <FE260932-A064-493E-8CD5-D92B2725F9E6@employees.org> <CAD6AjGRXYqJhXL6ipbS_cWkE2mg3sU4tM5XCCvgiGvSALGfeeg@mail.gmail.com>
To: Ca By <cb.list6@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GQka3EFyDZFLleedjDME_tG-i5g>
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: Mon, 09 Nov 2020 07:19:06 -0000

> >     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.
> > 
> > Has any mobile provider deployed dhcpv6 pd?
> > 
> > Perhaps the mobile providers have seen what an operational nightmare dhcpv6 pd is and... are like nope. 
> > 
> > I am in favor of the ietf opening their eyes to a better solution. 
> > 
> > Rfc7278 is universally deployed because it is easy. 
> > 
> > Can we do better (more /64s) and easy ?
> 
> It's difficult to design a better solution without understanding what "operational nightmares" mean.
> Would you mind elaborating?
> 
> I believe running a dhcp server supporting 120M mobile subscribers would be a nightmare.  I believe dhcpv6 is a larger stateful database and a not very forgiving protocol... and client implementations are ... heterogeneous. ... and server failover.. messy
> 
> None of that exists today in mobile. I feel the effort and scale are daunting, so i am not going to do it. 
> 
> But, getting a knob in the gateway to set the RA to be 60 (or other) instead of 64 would be easy. And, that knob could be constrained to only compatible device type (chef’s kisses!)... it can be done

You could operate DHCP PD the exact same way.

cheers,
Ole