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

Ca By <cb.list6@gmail.com> Mon, 09 November 2020 16:13 UTC

Return-Path: <cb.list6@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 CBD2E3A1193 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 08:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 jsFm3m3qV8At for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 08:13:21 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 A86E63A1188 for <ipv6@ietf.org>; Mon, 9 Nov 2020 08:13:21 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id o11so10329210ioo.11 for <ipv6@ietf.org>; Mon, 09 Nov 2020 08:13:21 -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=dTelZv9jTsJyvBGfd08/nKqc2+Ae3Vvckxrg11quHI4=; b=t1gbwQNfiLOlZwAyH91H6V9V6kUKqmQu/EA5cF8ZvWMrbMwLbl4q9qf7XM07WQpOHr cu4ILeDGP6m83wRutj3PmLuV/5iuvEus9nKQjVXmXVSUH/xs22wOvf2aPqO8I5ple+3q Kqq18iCuqAo7DLDfxcZXu1aN0fgL95HDBoHVpPmK55ndY9Z5cZyW+fBZ5GDwW0JyGACp wRt27ohyItLoOg3eGGx9yv6AFJAaoBkLjd3gRwtW5TBP6lqR72EikdHkedoVvGynmRA4 qzARacb8Onb4idlhx5Iv+CvK6AJUfhJg+Y5ee+9j8EsRKGYk63n7oxRyWlVJ1cMj3B1G J6cg==
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=dTelZv9jTsJyvBGfd08/nKqc2+Ae3Vvckxrg11quHI4=; b=s1BRfvKeR18rqQjrSboD6ANfwy6IPwB+eaadUoLXK0x28qSTY0fHJr/2adB3QDhrhe UsYEjzNuHpJM9IrcrUHT9V+WFITEviBsW40HsizIptFd+WK8K9rv+OP+Ftg2mkGh9BKZ 0NCvNgBotEmBGd6+RpidlVsfrVGu0++Ye9YP9JG7rpdJKcFkxR8rbu4QlRvmL0EEuMjC 2otCKFxHkJhRwrxe8I0AIp0UH62MU5BJ/41DjOcipD+rTjpNXfCw5ao+ZXjsgobXLQvN U7pJIdlMGGBAX4d39p52jfNRb1OgVBMAxdc9gdq0nBSphiPKWEvga2zqXAgXqBzeHJrE 0pbA==
X-Gm-Message-State: AOAM532JWjTLv2zyeehMEOsqyL+9/9L61Qp8UUS3Ooe9NUDaWAiGJgpw 8vkkSupDG/WP7JMOg3Nwj5cJAXeQ937GJl7H5oOsAXzR
X-Google-Smtp-Source: ABdhPJy8p67RoZ6t+poOXx95pU0SJD/2SNp1DR72OBQNA7lH9a6O9tHC9XTxnspcTmlVHmMYMRWYPdfDac0S6pR5c+g=
X-Received: by 2002:a05:6602:20c7:: with SMTP id 7mr10284893ioz.170.1604938401019; Mon, 09 Nov 2020 08:13:21 -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: Ca By <cb.list6@gmail.com>
Date: Mon, 09 Nov 2020 08:13:10 -0800
Message-ID: <CAD6AjGTLdFPSmUKUHUSS6rf4ewiteoa27D-zK3amyGvo7sWswQ@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="000000000000477c2d05b3aed7f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/DjoxwAf_Dlbf2Nj2FkZ1Okfj4I4>
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 16:13:24 -0000

On Mon, Nov 9, 2020 at 1:39 AM 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).
>
> Regards,
> Jordi
> @jordipalet
>
>
All those things you mentioned above (billing,  dpi, ...)  are working today

Dhcpv6 is not. Has not. Will not.

Just like the story of 464xlat, we can deploy ipv6 if we listen to what
mobile operators in the ietf are saying.

Just like back then, the ietf simply said use dual-stack, no need for
464xlat. Same story now, folks say use dhcpv6. Not helpful.


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