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

otroan@employees.org Wed, 04 November 2020 08:45 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 3683B3A0D96; Wed, 4 Nov 2020 00:45:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 h0KY9i2edFrG; Wed, 4 Nov 2020 00:45:57 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::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 AAB233A0D95; Wed, 4 Nov 2020 00:45:57 -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 B21384E11B44; Wed, 4 Nov 2020 08:45:56 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 419794328F81; Wed, 4 Nov 2020 09:45:54 +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: <CABNhwV0LxM7EuKo2wNtVacjewsVqdhrmSiVBmB_EL-mqJYdU3A@mail.gmail.com>
Date: Wed, 04 Nov 2020 09:45:54 +0100
Cc: 6man WG <ipv6@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, draft-mishra-6man-variable-slaac@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CD9F9F09-2CBC-4A72-99C0-4A9A470357ED@employees.org>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.com> <CABNhwV3L7kz=cWu8s3X=djVf4MCwewzbEgx09TWaKzCULCjYUQ@mail.gmail.com> <9A9CE8E7-3552-4FD8-A50E-1BDCA2CB813F@employees.org> <CABNhwV0LxM7EuKo2wNtVacjewsVqdhrmSiVBmB_EL-mqJYdU3A@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/feVU0WJ40wBaVBepU9UvcEw8MaE>
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: Wed, 04 Nov 2020 08:45:59 -0000

Gyan,

> Are there any of the problems/use-cases that cannot be solved by assigning a shorter prefix than /64 to the end-user networks?
> 
>    Gyan> The issue here with 4G providers to be able to force providers to go with a shorter prefix is impossible and similar to the issue we see with the v6ops flash renumbering issue and even in light of BCOP RIPE-690 that broadband operator’s PD allocations is /64 and not /56 as recommended in BCOP and due to the impact of flash renumbering events we are now changing the VL PL to short timers to age our the stale prefix during a renumbering event.  So the standard on 4G and as it is the same standard for 5G handsets allocation, a /64, and 4G and even 5G operators for mobile handset provisioning do not plan to make it a shorter prefix.  So either customers end up suffering with flash renumbering events or you update the standard.  Same issue we are faced with here with wireless providers and forcing them to dole out shorter prefix.

I don't understand the coupling you make between the 64 bit boundary and flash renumbering.

> Fixed 5G replacement for broadband I mentioned, not to be confused with 5G mobile handset, would follow BCOP RIPE-690 and I believe will go in with larger allocation like a /56 or larger.  So the fixed 5G network slicing how it comes into play as a value proposition and massive benefit to customers, is it can now have the front haul 5G to tower and back haul tower to core now be provisioned to the fixed 5G with a normal BAU slice template for normal traffic and at the same time separate slices for special Enhanced VPN over SRv6 core SR-TE steered with dedicated resources and traffic  isolation and special QoS prioritization for applications such as IOT, E911 emergency services, or utilities etc.
> 
> https://www.internetsociety.org/blog/2017/10/ipv6-prefix-assignment-bcop-published-ripe-690/

OK, so the problem is:
"How do you connect an end-user network with multiple links to a provider who only allocates a /64 to the site.".

There is a conundrum here. A reason for the 64-bit boundary is that it forces the provider to give at least a /64.
That design decision seems to have had the intended effect. You don't see any providers assigning less address space than the /64.

If we were to relax that limitation, then there is a fear that providers will start assigning fewer addresses to end-users. Down to a single address like we see in IPv4.

The conundrum then is:
How do we ensure providers allocate at least a /64 of address space to end-users, and at the same time allow end-users to extend a network with only a /64 assigned to it.

Answer that and we can make progress.

Best regards,
Ole