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

Mark Smith <markzzzsmith@gmail.com> Mon, 09 November 2020 11:05 UTC

Return-Path: <markzzzsmith@gmail.com>
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 998F93A0EBE for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 03:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UfK6wHjCWmwh for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 03:05:57 -0800 (PST)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D793A0F4A for <ipv6@ietf.org>; Mon, 9 Nov 2020 03:05:52 -0800 (PST)
Received: by mail-ot1-x32b.google.com with SMTP id y22so8505841oti.10 for <ipv6@ietf.org>; Mon, 09 Nov 2020 03:05:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KKI3IC/m5eh4wZ+u1Doc0RhtN5pgR24UAlh/p4IEZyk=; b=vgH7eC+Cxjetv2aBycEtWvbqOTrjzI78TnR1jT+Z89ty+AJA/2BTNeTVkcAQF64uF+ jVec23KEMAyNk5TlVXiYuBfiUZc0lucO5CHkq+zBvRhdnR2Z6GJCEFx5QXxzRrr7QUki JmQbW14z96r7S3N0OF/LEcGQHGuEYwEZA5Nh1rSNwWBy1EETOkUrB2xbkSmMz0aXtAon 9hLvWgOP6czV4skNtrkMOPAMtGqTGvkEzSaJk6a0fNRXHWXnXa4EKXB/M1LxTSm/GHfw prJ1gGv8Nxb3RVyrDTfwUJ1jUW6PEB5oBzqkO5vTM0sssYqADT1bgCIKd5c7oZdgMD2h 9rkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KKI3IC/m5eh4wZ+u1Doc0RhtN5pgR24UAlh/p4IEZyk=; b=KAnXuYn5ejWrj1yk7UhwwsjP8tLWiI4T7ZAVGshZnCfEEvdk215JOYDQ0+ssvCvhTH R3EXm4GlGR4K3WJwJ64H7RfQfh9/OfX4FxT+E2afAnzt9SxoHnA6Qeu6BmOm+4hGC5oj 2HXapv6p/qji+OokkRZBHs+O2I0GTzixWCthdrKTHwdVuOThVpDV1U49n08Z9JWcrZOt W2bkYinKDN60MS6dRPms7VGJ8RT9PfMXoon7qlTBhS2lG9XX9mkwpU8m6blwEXvOD98V zIGFgTP163HrywokR23ql7tvuna/k9EDqA8YVh/vi6Ruk9dsvckVqK1kXmn+9gAqBKKL YtnQ==
X-Gm-Message-State: AOAM533cPU3N2Vrtjr2mtfWbrXZ5v8A6u95xEQsUxmBDuiSzmoAscL3y SNS1w5PVjTupGDnf4g7le2iPJQwu+bf5xCEwSFo=
X-Google-Smtp-Source: ABdhPJxDsWjEOpraHkKhwW/Wb3oSS3YyeVNWbor3nmmrkZ7NPZk7tKzobEoacEMu3n35DMqMKMsoECEOzSaso9H+U0U=
X-Received: by 2002:a9d:a0d:: with SMTP id 13mr9372286otg.348.1604919951809; Mon, 09 Nov 2020 03:05:51 -0800 (PST)
MIME-Version: 1.0
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> <e7938c0f-758c-1f90-814a-46f8b262a134@gmail.com> <3298C400-E393-4588-A703-BA9B4B09587F@consulintel.es>
In-Reply-To: <3298C400-E393-4588-A703-BA9B4B09587F@consulintel.es>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 09 Nov 2020 22:05:41 +1100
Message-ID: <CAO42Z2xRowu35=nnrcqt2nA2On=hiWb3tEzrLmK=Rq+d_4OE3A@mail.gmail.com>
Subject: Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
To: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009ee05d05b3aa8be3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4DImAJroscMiqpJijQWbZZhXfSA>
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 11:06:00 -0000

On Mon, 9 Nov 2020, 20:39 JORDI PALET MARTINEZ, <jordi.palet=
40consulintel.es@dmarc.ietf.org> wrote:

> I think there is some performance testing done in ISC KEA, which allows
> distributed DHCPv6 (including PD) servers, HA features, etc. I don't think
> this should be a different problem than the fact that they need to run many
> APNs, authentications servers, billing, DPI, firewalling, etc., for the
> same number of hundreds of millions of customers (in the bigger cases of
> cellular networks).
>

HFC cable networks would have run large scale DHCPv4 for decades now. As an
example of their scale, I remember one if the large US ones wanting IPv6
just for cable modem management, because they'd run out of RFC1918
addresses.

 It's not a new problem.

Regards,
Mark.



> Regards,
> Jordi
> @jordipalet
>
>
>
> El 9/11/20 2:26, "ipv6 en nombre de Brian E Carpenter" <
> ipv6-bounces@ietf.org en nombre de brian.e.carpenter@gmail.com> escribió:
>
>     On 09-Nov-20 13:00, Ca By wrote:
>     >
>     >
>     > On Fri, Nov 6, 2020 at 1:05 AM <otroan@employees.org <mailto:
> otroan@employees.org>> wrote:
>     >
>     >     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?
>     >
>     >
>     > 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
>
>     Of course. You would have to run thousands of DHCPv6 servers out in
> the wild. Certainly there would need to be some distributed address pool
> management too. Just handing out a /56 to each PDP context would be so much
> better.
>
>         Brian
>
>     >
>     > 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
>     >
>     >
>     >
>     >     Best regards,
>     >     Ole
>     >
>     >
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > ipv6@ietf.org
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
>     >
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>