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

[Alexandre Petrescu <[e-mail]>]

Le 23/11/2020 à 07:40, Gyan Mishra a écrit :
> 
> 
> On Sat, Nov 21, 2020 at 10:26 AM Joel M. Halpern <[e-mail]
>  <mailto:[e-mail]>> wrote:
> 
> As I understand it, the situation is not that 3GPP has not defined
> use of DHCP.  But rather than operators have uniformly declined to
> deploy it.  (3GPP has defined DHCP for 5G for fixed access.  We have
> heard here that even that is not what the operators want.)  As such,
> asking 3GPP why they didn't deploy it seems a bit odd.
> 
> 
> Gyan> One possible non technical factor is that Android which as of 
> 2019 statistical data below holds 87% of the global mobile market
> share and Apple 13% and Android is continuing to climb in 2020.
> Android adamantly refuses to change its position on support of
> DHCPv6.

At which point, one can wonder why Android refuses to support DHCPv6.

This has also been discussed other time.

There have been given reasons.  If I remember correctly, some of the
reasons had to do with the difficulty put on a user to manually
configure some matters exclusively related to DHCP; or maybe the 
difficulty of syncing between data received on RA vs DHCP; but I am not 
sure I remember ok.

Alex

PS: a colleague here ported a couple of open source DHCPv6(-PD) clients
to Android.  We stopped short from submitting these clients to the
respective store, because it required payment to accept them.  The
business model at the store assumes that an initial small investment
would be later covered by numerous paying uses of a DHCP app.
That problem (have to pay for acceptance) adds to the other problem of
blocking in the modem.  One could still use a DHCP client on the wifi
interface; or could use DHCP client on the 3gpp iface with a https
tunnel drilled through the modem (provided, of course, that PGW mounts a
SSL tunnel for DHCP purpose, or listens to 443 for DHCP - neither of
these is acceptable at operator, even if the DHCP-PD server software,
and https software, and SSL tunnel software are all present in that PGW.)

   I think
> that really shackles 3GPP carriers from supporting DHCPv6 is close to
>  100% of all mobile handsets won’t support it.
> 
> https://www.statista.com/statistics/272307/market-share-forecast-for-smartphone-operating-systems/
>  
> <https://www.statista.com/statistics/272307/market-share-forecast-for-smartphone-operating-systems/>
>
> 
> 
> 
> 
> Yours, Joel
> 
> On 11/20/2020 11:19 PM, Mark Smith wrote:
>> 
>> 
>> On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, 
>> <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] 
> <mailto:[e-mail]>>> wrote:
>> 
>> 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];
>> 
>> 
>> I think it is also important to find out why they haven't deployed 
>> DHCPv6 to solve this problem.
>> 
>> Don't they think DHCPv6 infrastructure will scale? Is it just
> that they
>> don't know how to scale it?
>> 
>> Is it a vendor / mobile operator / handset developer DHCPv6 
>> capability chicken-and-egg problem?
>> 
>> Is there an overriding business or industry reason?
>> 
>> The mobile industry has been resistant to tethering over the
> years, and
>> probably only came to begrudgingly accept it because they couldn't 
>> prevent phone vendors from implementing Wifi and NAT, and
> couldn't very
>> effectively stop their customers from using that capability (One
> trick
>> I've heard of to prevent tethering working was to check if an IPv4 
>> packet's TTL value was 64 when it arrived at the network, meaning
>> it originated from the directly attached handset. Packets from
>> tethered devices had a TTL of 63 so were dropped. Of course, you
>> could set
> the
>> default TTL on a tethered PC to 65 to get around that.)
>> 
>> I guess there might be a fairly strong mindset that there must be
> a fee
>> per device attached to the network in addition to a fee for
>> network utilisation. Providing multiple /64s would be formally
>> acknowledging that multiple devices can be attached and a fee per
>> device isn't and can't ever be charged, counter to the mindset.
>> 
>> Regards, Mark.
>> 
>> 
>> (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
>> <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>>>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[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/>>
>
> 
>>> 
>> 
> <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/>>>
>
> 
>>>> 
>>>> 
>> 
> <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/>>
>
> 
>>> 
>> 
> <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]>>
>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>>> <mailto:[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>
>> <mailto:[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]>>>
>>>>> <mailto:[e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>
> <mailto:[e-mail] <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>>>
>>>>>> <mailto:[e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>
> <mailto:[e-mail] <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>> <mailto:[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]>>>
>>>> <mailto:[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>>
>>>>>> <mailto:[e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>> <mailto:[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>>>>> <mailto:[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
> <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g>
> <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g
> <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>
> <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>>
> <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>
> <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/>>
>> <http://www.verizon.com/ <http://www.verizon.com/>
> <http://www.verizon.com/ <http://www.verizon.com/>>>
>>>> <http://www.verizon.com/ <http://www.verizon.com/>
> <http://www.verizon.com/ <http://www.verizon.com/>>
>> <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]>>
>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>> <mailto:[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>>
>>>> <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>>>
>>>>> <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>>
>>>> <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/>
> <http://www.verizon.com/ <http://www.verizon.com/>>
>> <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
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> 
>>>> <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>>
>>> 
>> 
>> 
> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list [e-mail]
>> <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 
> <https://www.ietf.org/mailman/listinfo/ipv6>
>> <https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>>
>> 
> --------------------------------------------------------------------
>> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail]
> <mailto:[e-mail]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 
> <https://www.ietf.org/mailman/listinfo/ipv6> 
> --------------------------------------------------------------------
> 
> --
> 
> <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] https://www.ietf.org/mailman/listinfo/v6ops
>