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 <[e-mail]>]

On Fri, Nov 20, 2020 at 8:46 PM Joel M. Halpern <[e-mail]> wrote:

> The nesting got me lost, so I will top post my take on the answer to the
> one quesiton I could understand.


   Gyan> Thank you

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


    Gyan> Agreed

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


    Gyan> Agreed

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


    Gyan>ok

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


    Gyan> Yes Agreed.  Thank you

>
>
> Changing the prefix length to /80 is technically also possible.


     Gyan>

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


    Gyan> Understood.  This is a multi faceted problem and may require a
multi faceted solution.  Thank you.

>
>
> 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 <[e-mail]
> > <mailto:[e-mail]>> 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
> >     <[e-mail] <mailto:[e-mail]>
> >      > <mailto:[e-mail] <mailto:[e-mail]>>> 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 <[e-mail]
> >     <mailto:[e-mail]>
> >      >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >      > <mailto:[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>> wrote:
> >      >      >
> >      >      >
> >      >      >
> >      >      >      > On 19 Nov 2020, at 14:58, Gyan Mishra
> >      >     <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >      >     <mailto:[e-mail]
> >     <mailto:[e-mail]>
> >      >     <mailto:[e-mail]
> >     <mailto:[e-mail]>>>> 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
> >      >      > [e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >      > 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
> >
> >
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD