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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 09 November 2020 09:39 UTC

Return-Path: <prvs=158289e994=jordi.palet@consulintel.es>
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 B95413A0DB4 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 01:39:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 QD2LYWdxddWh for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 01:39:27 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id C339F3A0DAB for <ipv6@ietf.org>; Mon, 9 Nov 2020 01:39:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1604914765; x=1605519565; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=GxN9LIdu ItyUQda+DOKYiQH7nTtwbC3DntmIW6WQ6ow=; b=XRxm0R02MM7l+IyK5XYu6eMn 5pFK/UIllGdf/KruMZW2/jSpxmlm3HZmPEqxTKVzubfBmFGKQgOla0o2VoddXVWv MwMrTt8opsgZYJrii3E/2IVee77S1tMrNZMyaV3uNFLWUC/lJ4sXfS2Mz5tzF6Fo WCXR63NsomL65STywrs=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 09 Nov 2020 10:39:25 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 09 Nov 2020 10:39:25 +0100
Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000458573.msg for <ipv6@ietf.org>; Mon, 09 Nov 2020 10:39:23 +0100
X-MDRemoteIP: 2001:470:1f09:495:d41d:ff88:9a6d:5019
X-MDHelo: [10.10.10.144]
X-MDArrival-Date: Mon, 09 Nov 2020 10:39:23 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=158289e994=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/16.42.20101102
Date: Mon, 09 Nov 2020 10:39:20 +0100
Subject: Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>
Message-ID: <3298C400-E393-4588-A703-BA9B4B09587F@consulintel.es>
Thread-Topic: I-D Action: draft-mishra-6man-variable-slaac-01.txt
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>
In-Reply-To: <e7938c0f-758c-1f90-814a-46f8b262a134@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RDNMVp9uxsyEZjgMvWTtgK6WKas>
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 09:39:29 -0000

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).

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.