Next step? [Re: [v6ops] The bottom is /112]

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 21 November 2020 03:00 UTC

Return-Path: <brian.e.carpenter@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 96F783A1071; Fri, 20 Nov 2020 19:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level:
X-Spam-Status: No, score=-1.098 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, FREEMAIL_REPLY=1, 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 qunjaKtzOucJ; Fri, 20 Nov 2020 19:00:20 -0800 (PST)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 4460D3A106D; Fri, 20 Nov 2020 19:00:20 -0800 (PST)
Received: by mail-pf1-x430.google.com with SMTP id w6so9734836pfu.1; Fri, 20 Nov 2020 19:00:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ve5gle+j3fo16dTatGMn6v1+cVGcnJmbVzdyFne09Bs=; b=Doq201m5zPmoemq3ooYG9v1RuG/M0G1aqBKyB2EN8mWonQoumJNluGy1d5I4E67Rd9 cCrRCagzRzvwFrhNZdiWnPZJfF2P1fPe5LVdpOOnKCsyKZe2hkgvbuGvsqfnWrcjU/2j 60KAwVFoW+l4K6O5r2Jon7hKFjXql5tbKdVQPHgXIDgPilcMVr/scFxdaZ0X7Zz/AE5n 7rpGdKh4CCl+0KqpAMDaX0YzYjJVTEjYtqeAvvDy0da/puXry0/9EBpO9gRlDXVvmidl C83XAWaFSOBR3B9dFT1TF1S3kVWPEYjJ/hqpejDIiZku2iY7VA2GC3z58UomqsDvCrGQ y2vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ve5gle+j3fo16dTatGMn6v1+cVGcnJmbVzdyFne09Bs=; b=HK3pLVM7wAC7nGdcsDIRWM/PQ7lMx8G1jVA19rkY3V5NyxZH/fCg++YLhBp8nolvTr tI2s5ZWsOz2pnjwao9zOPKc8e6s8N0Bn3BK8k9pxlJaxUWlkOgcln1LO933b0Ipu/swz /aoop3nlS2AgtGYqnA4buVkk/jAmHBRvTAXtr14dwYzkeIkDmSBzleiGg+4JmXs70l2y idHSA90QuIZmmU7o37q688MMDTfZJ/31YdTSXHHYFxPBMH84sTT1znRkBTGMqD/LNQqd H5JhosMRBqXzU5UR5DvsnpcmeQMcvd4W8dYWDv+uA/cPEtWTZFRk3zFqBR3KJVddSTyS IxSQ==
X-Gm-Message-State: AOAM5324A3lmIUbCeKzZuXtVMD7XMde/TRSkJNkJdJM6cKWYqFDSSqN9 HNxU5Y2tHdC8UnQLgjr2ohrjKhECnzl+bQ==
X-Google-Smtp-Source: ABdhPJwIm6EjtcogNRDwR6y/WAICtJ7wQYsP8wE5QE0n+Eb1PySLuzTIQ2MO2sdyzPcTpN8wwLdXEg==
X-Received: by 2002:a17:90a:2c2:: with SMTP id d2mr13402259pjd.36.1605927619065; Fri, 20 Nov 2020 19:00:19 -0800 (PST)
Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id v7sm5177755pfu.39.2020.11.20.19.00.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2020 19:00:18 -0800 (PST)
Subject: Next step? [Re: [v6ops] The bottom is /112]
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: IPv6 Operations <v6ops@ietf.org>, 6MAN <6man@ietf.org>
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> <CABNhwV0TbS7Kiynb=jvczJFDyy=uMfd-he+d0ii7aU5AnsUKeA@mail.gmail.com> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <CABNhwV1pSiEuaOZGN5ErR=KETjD1fVb58YM1EEd+mf7RtOenQw@mail.gmail.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com>
Date: Sat, 21 Nov 2020 16:00:13 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZoQ8pWGpj3ikyLiXbRsitGYdUds>
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: Sat, 21 Nov 2020 03:00:23 -0000

Joel,

It seems to me that it's high time to draft a liaison statement to 3GPP,
observing that:

(1) There is a serious problem for the design and implementation of
5G-based IPv6 "hot spots" and CEs [which is where this conversation started];

(2) Although the best solution is not yet obvious, defining and
standardizing it will require a joint effort by the IETF and 3GPP.

Followed by a proposal to form an ad hoc joint design team.

Regards
   Brian Carpenter
On 21-Nov-20 14:46, Joel M. Halpern wrote:
> The nesting got me lost, so I will top post my take on the answer to the 
> one quesiton I could understand.
> 
> I believe you asked what I think would need to be changed to permit the 
> delegation.
> As with anything, the real things that need to change are the devices in 
> the network.
> 
> With regard to IETF standards, what is proposed is a change to RA. 
> There are several possible changes.  None of them require a change to 
> the IPv6 addressing archtiecture, as the addressing structure remains as 
> it is.
> As for the exact mechanism, at the moment I lean towards Ole's proposal 
> of using a new option in his generic option mechanism.  But I am not 
> wedded to that answer.
> 
> And of course, to get this supported in mobile environments we will have 
> to work with 3GPP and make sure there are no other hidden issues. 
> That's the way we do things.  Work together.
> 
> Changing the prefix length to /80 is technically also possible.  It does 
> a lot more violence to my understanding of the architecture and software 
> structures that go with it, and is a very limited and narrow solution to 
> the problem.
> 
> Yours,
> Joel
> 
> On 11/20/2020 7:58 PM, Gyan Mishra wrote:
>> Hi Joel
>>
>> In-line
>>
>> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern <jmh@joelhalpern.com 
>> <mailto:jmh@joelhalpern.com>> wrote:
>>
>>     Gyan, separate from Ole's comments about the difference between address
>>     assignment and delegation, I have another problem following the
>>     reasoning below.
>>
>>     Yes, the proposal for using shorter prefixes to enable UE to perform
>>     delegation will require changes to the UE. 
>>
>>      Gyan> Agreed.  So that change would be to RFC 4291 64 bit boundary 
>> to allow for longer prefix.  Do you agree?
>>
>> If you don’t agree what do think the change would be to allow the UE to 
>> accept shorter prefix from the 3GPP gateway?
>>
>>
>>     But I do not see how that is relevant to any choice we are trying to
>>     make.
>>     Any solution that enables UE to delegate addresses (in the sense that
>>     they lack the capability now) willr equire changes to the UE. 
>>
>>
>>
>>     Gyan> If the UE receives a /56 via RA it could delegate /64 to
>>     downstream devices.  No change needed to delegate  /64, however a
>>     change is needed to accept /56 via RA. 
>>
>>
>>      If 3GPP gateway supported PD - problem solved but that’s not the 
>> case and that does not sound like it will ever change even with 5G.
>>
>>     Gyan> The UE needs to be able to accept shorter prefix.  That’s the 
>> IPV6 specification change that requires removal of the 64 bit boundary.
>>
>>     Yoru
>>     proposed change to the SLAAC length if anything does more violence to
>>     the software (depending upon the exact software architecture.)
>>
>>
>>     Gyan> What violence to software.  There would be more violence to 
>> software if we removed the 64 bit boundary and allowed slaac to support 
>> any vlsm prefix lengths.
>>
>> My /80 proposal would just shift the boundary 16 bits to /80.
>>
>> Hosts on the same subnet with two different masks would not be on-net to 
>> each other as on different subnets.  The router would be configured with 
>> the two subnets /64 and /80 subnet to support the two device types.
>> The solution would be a simple RA PIO flag that is set and older hosts 
>> not upgraded would be backwards compatible and so would only support 64 
>> bit boundary by ignoring flag. Hosts upgraded to support would 
>> understand the flag and be able to support longer mask up to /80.
>>
>>
>>
>>     So I do not follow how you got to your conclusion.
>>
>>     Yours,
>>     Joel
>>
>>     On 11/20/2020 5:27 PM, Gyan Mishra wrote:
>>      >
>>      > (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/
>>     <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>
>>      >
>>     <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
>>     <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 <mailto:jmh@joelhalpern.com>
>>      > <mailto:jmh@joelhalpern.com <mailto: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>
>>      >     <mailto:otroan@employees.org <mailto:otroan@employees.org>>
>>      >      > <mailto:otroan@employees.org <mailto:otroan@employees.org>
>>     <mailto:otroan@employees.org <mailto:otroan@employees.org>>>> wrote:
>>      >      >
>>      >      >
>>      >      >
>>      >      >      > On 19 Nov 2020, at 14:58, Gyan Mishra
>>      >     <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>
>>     <mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>
>>      >      >     <mailto:hayabusagsm@gmail.com
>>     <mailto:hayabusagsm@gmail.com>
>>      >     <mailto: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
>>     <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g>
>>     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 <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/ <http://www.verizon.com/>
>>     <http://www.verizon.com/ <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 <mailto:v6ops@ietf.org>
>>     <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>>      >      > https://www.ietf.org/mailman/listinfo/v6ops
>>     <https://www.ietf.org/mailman/listinfo/v6ops>
>>      >     <https://www.ietf.org/mailman/listinfo/v6ops
>>     <https://www.ietf.org/mailman/listinfo/v6ops>>
>>      >      >
>>      >
>>      > --
>>      >
>>      > <http://www.verizon.com/ <http://www.verizon.com/>>
>>      >
>>      > *Gyan Mishra*
>>      >
>>      > /Network Solutions A//rchitect /
>>      >
>>      > /M 301 502-1347
>>      > 13101 Columbia Pike
>>      > /Silver Spring, MD
>>      >
>>      >
>>
>> -- 
>>
>> <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
>