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

otroan@employees.org Fri, 06 November 2020 09:05 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 6F46F3A0F47; Fri, 6 Nov 2020 01:05:58 -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 NhvW01lErw-7; Fri, 6 Nov 2020 01:05:57 -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 513F03A0F44; Fri, 6 Nov 2020 01:05:57 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:9724:70cb:de0f:506b:49d]) (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 481D44E11B47; Fri, 6 Nov 2020 09:05:56 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 3B3FD435497B; Fri, 6 Nov 2020 10:05:53 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
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: <CAD6AjGQPatbg5=OaMzxJXy5mGZai1bqLfg8f+9SUnfg=s1kADg@mail.gmail.com>
Date: Fri, 06 Nov 2020 10:05:53 +0100
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, draft-mishra-6man-variable-slaac@ietf.org, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE260932-A064-493E-8CD5-D92B2725F9E6@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>
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/NaRgdKYDTjm7IRjOrsrq8Eb3wA4>
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, 06 Nov 2020 09:05:58 -0000

Cameron,

>     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?

Best regards,
Ole