Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso
Gyan Mishra <hayabusagsm@gmail.com> Fri, 20 November 2020 22:27 UTC
Return-Path: <hayabusagsm@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 C0D073A0ABC; Fri, 20 Nov 2020 14:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 J071vGl2vVof; Fri, 20 Nov 2020 14:27:24 -0800 (PST)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 AEDBA3A0AB9; Fri, 20 Nov 2020 14:27:24 -0800 (PST)
Received: by mail-pf1-x42b.google.com with SMTP id t8so9227926pfg.8; Fri, 20 Nov 2020 14:27:24 -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=MF+VbQm7YxmoAuwF53T0mNj3jYTNsrsf/Qj7HOyEfFs=; b=kDOZdlkaKzEFpZaffmBV+7Z8CCDjJ+RCbeK7bFbxXz837LhH+mdi6QdSy2y0OxIamv XvAD7QtDrLQZdNLWSSGNXLFh3bYkpE9Niyh0vv8B1YDUkqTBZ8uVgiMMs/yT4IjCVPud VKafzaCDIg6DxlHEAAAoHhhLHmnFL/CFfEG2YO6foQbyN8Qyce3zrLpOKlujgP969IOi j0X6AFSjIgY3X1ySaQmhgkbco2OVGG6s5ycPeHHim1lmuy+YffrtO1KfaEqMpa5aQu9h szVZxkFM3a6o73lOPR84UHZQiEZRX5ocGsStWJrP4PZBwDWbvSi1878Sdd+e3mBEMBfk 87DQ==
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=MF+VbQm7YxmoAuwF53T0mNj3jYTNsrsf/Qj7HOyEfFs=; b=YnY8Mr2tIeSzFTGrMvbeydOL6zeioq04YOBhAvgE6T4Vozt1MDz/Db5zlNlZX8ZVXn T5VSmNTI3XwaFYx1Ee0wxx3QIJhmHT+u98ndITAxqIAClFE+/YSjdjHBNOHURB0teFFq 9iHfWIgCPGDri23Ywg/yMvtxKjgsNJcZ1V80LW8iVYcsYb8CWJn96AKFYZxvw2QLXjK5 ypBSU+dNfMnkjFYTp8ENk3sSOmtDzm3mDVLTJherzQ3Jfe56vpjXSKmTZ1KZQlkvVuYL zFrkeaDsMulNPYXILMF+N0W1svSUK9sWfwiGPneKjIRCCHUckCuwc/1DRp0KI66i4Cgn qM+w==
X-Gm-Message-State: AOAM530ouU2wJfeQnDmFnZJSjTfcnawcFnDITk2eWeUyLDFYsX7wjvtp /SXfLBHSMfxdn+VqdUuUxdvcFe+t1J1/1RgGlTAPImv2t18=
X-Google-Smtp-Source: ABdhPJxvCxZ5K82hkN6sUp5dMR038852MP7JYV5WeCyLwxx/Numvj2ZdImDBIfwWIpBHA7rstSCYf3CHlKmBiBsv5f0=
X-Received: by 2002:a63:9d01:: with SMTP id i1mr6508941pgd.50.1605911243964; Fri, 20 Nov 2020 14:27:23 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV3fj-e9bEemivcNovnD3SZvKm8ZjFKp7BmusnPcgyznFQ@mail.gmail.com> <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <CABNhwV19neE3U_AisNp2nDUF4bWB8P8xHNEznDevZLE9amFTRA@mail.gmail.com> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <CABNhwV3bCss9y7cT6w2i+LKWBh1viPSXBM-CTaK+GVDyPS2D8w@mail.gmail.com> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <CABNhwV0-FZpPs84+RVB81=5H5QCEaxF0EUj9tcV+bdOu00RE2A@mail.gmail.com> <fb87c22c-388d-0492-1ea7-018655353f9b@joelhalpern.com>
In-Reply-To: <fb87c22c-388d-0492-1ea7-018655353f9b@joelhalpern.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 20 Nov 2020 17:27:13 -0500
Message-ID: <CABNhwV0TbS7Kiynb=jvczJFDyy=uMfd-he+d0ii7aU5AnsUKeA@mail.gmail.com>
Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: 6MAN <6man@ietf.org>, IPv6 Operations <v6ops@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, otroan@employees.org
Content-Type: multipart/alternative; boundary="0000000000003cc5a505b4915965"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2BJh4Ui9sPPqKiP6NHguJNj5FKk>
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, 20 Nov 2020 22:27:28 -0000
(top posting) As I would like to clear the air as well as get to the crux of the v6ops presentation development results as well as next steps for this draft and the 6man variable slaac solutions draft: This thread was in light of Lorenzo kindly pointing out that upgrading 3GPP is not all that needs be done for Cameron’s 64share v2 to work - as all mobile devices would stop working- as slaac would not would be effectively broken. The mobile device would receive a shorter prefix let’s say /56 but not know what to do with it since it’s expecting a /64. So that a major gap and the only solution is updating RFC 4291 removing the 64 bit boundary allowing for shorter prefix and now as well longer prefixes to work and in that respect now provide the much needed parity with static and DHCPv6 which can do any prefix length. So that is a drastic change to RFC 4291. However, in light of this development on the v6ops 109 call, my balancing act of best of both worlds and also to keep everyone happy to make this a WG effort for this change by proposing in the subject heading /80 fixed boundary and not a variable slaac change allowing all bits vlsm. Basically stealing 16 bits for network prefix out of the IID, still keeping the fixed boundary so longer than 80 would NOT be allowed. A /64 would now be equivalent to a /48 with now 64k /80’s. This /80 would keep the operators and law enforcement happy as now 16 bits less helps traceability but is still long enough for 48 bits of privacy to IP correlation by attackers. This /80 would be a nice optimal balance as it would keep wired broadband and mobile handset customers happy respecting their privacy as the 16 bits less of heuristics is minimal change that will impact IP correlation by attackers. The IID as it’s less than the current 64 bit cannot use MAC based EUI64 IID, which is not a problem as Mac based IID is not recommended as most all manufacturers use RFC 4941 and I believe Linux flavors some use stable IID RFC 7217. So now the 48 bit IID would require a random IID generation schema so can use either RFC 4941 privacy extension or RFC 7217 stable IID to generate the 48 bit IID. 3GPP subtending would now work issue mentioned in the problem statement draft without even having to use 64share as now longer prefixes up to /80 would be supported allowing for further segmentation of downstream devices. This also would help wired broadband and soon fixed 5G broadband proliferation where operators in light of BCP RIPE-690, are sill allocation via BNG gateways a /64, now operators can stay as-is, as the /64 would now be allowed to be further segmented supporting 64k /80s, way more then enough for SOHO. This would allow 64share if used by 3GPP operators to work and would not require the 3GPP specification to be updated. We don’t know even if the 3GPP architecture specification can be updated to support shorter prefixes and if the 3GPP consortium of operators would agree to it. So that is all theoretical of that change is possible. As with 5G with Enhanced VPN framework SR steering of high priority traffic, traffic isolation and Network slicing capabilities becomes mainstream and will soon be a real world reality and as fixed 5G broadband proliferation takes off and mobile 5G == the idea of a wearable /48 will really be many /48s. As this paradigm shift takes place, operators around the world will be clamoring after the RIR for massive blocks, I would say less than /8 more like a /5 or /4. If you do the math on the way high side a /10 yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is tiny number with the number of large size operators worldwide. With the massive proliferation of IOT devices and just about every home or office appliance on 5G, the problem now gets way exacerbated. As this evolution unfolds IANA will be scrambling to release all remaining /3 as well as all unallocated blocks to subvert RIR IPv6 address space depletion. Playing Monday night quarterbacking in hindsight we would never think this would happen in a million years, but we would see IPv6 on the verge of address space depletion. Unheard of but it can happen as the saying goes “when you build - they will come”. It is true as history has taught that very important lesson. The answer to this real world problem is in the subject heading of this thread. This would also fix the day 1 issue I mentioned allowing mix of slaac devices with static and DHCPv6 up to /80. The variable slaac solution draft proposes a new RA PIO flag that would be used to signal longer prefixes, and would provide backwards compatibility so that devices not supporting woud ignore the flag and devices on newer code supporting would use the flag. We definitely don’t want to impact any existing devices on the existing 64 bit slaac boundary standard. Dmytro has tested the solution on Linux kernel signaling RA PIO flag and was able to successfully test any length mask and random IID generation both RFC 4941 privacy extension as well as stable IID RFC 7217. https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ If everyone is in agreement with what I have stated on this thread, I would like to ask the chairs for WG adoption as this is a WG effort. I would like to garner support from all 6MAN members with full consensus to change the existing RFC 4941 /64 fixed boundary to /80 fixed boundary. Kind Regards Gyan On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern <jmh@joelhalpern.com> wrote: > I am missing something in your reasoning. > You seem to say at one point that (to paraphrase) "we can't do this > because it does not work with the existing UE software". > Any new solution where a UE delegates based on any change of any kind > (including lengthening the prefix, shortening the prefix, or magically > incanting new prefixes) requires that the UE be upgraded to know what to > do with the information. I do not see how that differentiates any of > the solutions. (Except "don't do anything", which I think we do not want > to take.) > > Yours, > Joel > > On 11/19/2020 5:03 PM, Gyan Mishra wrote: > > > > > > On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org > > <mailto:otroan@employees.org>> wrote: > > > > > > > > > On 19 Nov 2020, at 14:58, Gyan Mishra <hayabusagsm@gmail.com > > <mailto:hayabusagsm@gmail.com>> wrote: > > > > > > You would need a new option. It would likely be useful for the > > requesting router to indicate interest in the option. Even hinting > > at what prefix size it was expecting. > > > Now can you explain to me again the reasons why this approach is > > better than using the existing DHPCv6 protocol packets? > > > > > > 3GPP gateway does not support DHCPv6 > > > > 3GPP gateway doesn't support new option. What's your point? > > > > > > > > The point of the v6ops presentation and this email thread is how to > > “extend a /64” in the 3GPP use case in slide 1 of the deck you compiled > > a list of options and of the two I had highlighted in red were the > > 64share v2 Cameron’s option and the variable slaac option. So on the > > call this morning Lorenzo shot down 64share v2 shorter prefix option as > > even if the 3GPP architecture was updated to support longer prefixes and > > even is the 3GPP gateway was able to send a shorter prefix with A flag > > not set, all mobile devices per Lorenzo’s point would be broken as they > > would not accept the shorter let’s say /56 prefix to build the slaac 128 > > bit address. So the bottom line is the 64share v2 won’t work unless we > > update RFC 4291 and remove the 64 bit boundary. > > > > So we are back to square uno - no viable solution > > > > So now we had thrown out the longer >64 due to race to bottom worries > > which I and others believe is Fud and as described in slide 10 of the > > v6ops “race to the bottom slide”. > > > > So a happy medium /80 fixed boundary I came up with that I think solves > > a lot of the issue and not just the 3GPP initial segmentation of > > downstream devices problem statement. > > > > Since we have to update RFC 4291 for 64share v2 to work anyways to allow > > for shorter prefixes, why not instead create a new bottom at /80 giving > > 16 bits more of prefix length and shrinking the IID down to 48 bits. > > Doing so you would not even have to update the 3GPP architecture as I > > don’t know if that would fly or not. Also this solves a few other > > problems at the same time. > > > > > > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is > > mainstream for operators for static addressing on router and switch > > infrastructure and dhcpv6 subnets longer prefixes for network > > infrastructure appliance clusters, NFV/VNF virtualization and server > > farms. On host subnets where there is a chance of mix of slaac hosts > > with dhcpv6 devices the prefix length is stuck at /64. So on these mix > > addressing host subnets we cannot do longer prefixes following our ND > > cache hard limit mantra to prevent ND cache exhaustion issues as > > described in RFC 6164. > > > > So with the /80 new fixed boundary shifting prefix length 16 bits longer > > and shortening the IID by 16 bits gives resolved the 3GPP issue which > > 64share can work as is and subtending to downstream devices will now > > work as a /64 is now equivalent to a /48 with 64k /80s. Also BCP-690 > > for broadband not all operators have adopted the shorter prefix lengths > > /56 or /48 recommendations and now that’s not an issue as the /64 would > > now suffice. > > > > From an operators perspective that gain allows at least for 3GPP > > massive growth and subtending with a single /64 allows the operators > > such as Verizon with massive subscriber base worldwide can stay with > > current allocations and don’t have to ask for /10. > > > > As 5G gets rolled out with Enhanced VPN framework and Network slicing > > paradigm, the demand for shorter blocks and wearable multiple /48 will > > be our new reality. > > > > Making that 16 bit shift now to /80 making a /64 the new /48 will give > > broadband and 3GPP subscribers a ton of space to subtending their > > networks we would be set for the future. Especially with IOT the demand > > for subtending will continue to grow astronomically. > > > > Also IANA does not have to get start in allocating the other /3 and > > other available blocks. > > > > Lots of problems being solved here with a fixed /80 new boundary. > > > > Also with the existing random IID generation schemes which we have > > tested on Linux kernel can do longer p > <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>refixes > using RFC 4941 privacy > > extension or RFC 7217 stable IID. > > > > Win-Win for all. > > > > Ole > > > > -- > > > > <http://www.verizon.com/> > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- The bottom is /112 (was: RE: Extending a /64) -- … Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… JORDI PALET MARTINEZ
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… otroan
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gert Doering
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Alexandre Petrescu
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… JORDI PALET MARTINEZ
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… JORDI PALET MARTINEZ
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… otroan
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Joel M. Halpern
- Re: [v6ops] The bottom is /112 Brian E Carpenter
- Re: [v6ops] The bottom is /112 Bob Hinden
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Ole Troan
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Joel M. Halpern
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Joel M. Halpern
- Next step? [Re: [v6ops] The bottom is /112] Brian E Carpenter
- Re: Next step? [Re: [v6ops] The bottom is /112] Mark Smith
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Mark Smith
- Re: [v6ops] Next step? [Re: The bottom is /112] Ca By
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gert Doering
- Re: [v6ops] Next step? [Re: The bottom is /112] Ole Troan
- Re: Next step? Alexandre Petrescu
- Re: Next step? [Re: [v6ops] The bottom is /112] Joel M. Halpern
- Re: Next step? [Re: [v6ops] The bottom is /112] Joel M. Halpern
- RE: [EXTERNAL] Re: [v6ops] Next step? [Re: The bo… Templin (US), Fred L
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [v6ops] The bottom is /112 (was: RE: Extendin… Gyan Mishra
- Re: [EXTERNAL] Re: [v6ops] Next step? [Re: The bo… Mark Smith
- Re: [v6ops] Next step? [Re: The bottom is /112] Michael Richardson
- Re: [v6ops] The bottom is /112 Gyan Mishra
- Re: [v6ops] The bottom is /112 Gyan Mishra
- RE: [v6ops] The bottom is /112 Pascal Thubert (pthubert)
- Re: [v6ops] The bottom is /112 Gert Doering
- Re: [v6ops] Next step? [Re: The bottom is /112] Templin (US), Fred L
- Re: [v6ops] The bottom is /112 Alexandre Petrescu
- RE: [v6ops] Next step? [Re: The bottom is /112] Templin (US), Fred L
- Re: [v6ops] The bottom is /112 Brian E Carpenter
- Re: [v6ops] The bottom is /112 Brian E Carpenter