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

Ole

In-line

On Fri, Nov 20, 2020 at 5:41 PM Ole Troan <[e-mail]> wrote:

>
>
> > On 20 Nov 2020, at 23:27, Gyan Mishra <[e-mail]> wrote:
> >
> > 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.
>
> I am sorry, but I don’t follow how you got to that conclusion.
> Address assignment != prefix delegation.


    3GPP Gateway does not support PD

    I summarized in the last email.

   We can start with the subject line that you had in the email you had
sent a earlier “extending a /64” as that is the main issue and is part of
the problem statement draft.

This is in the context of 3GPP gateway proving a via RA a /64 so how can
the UE segment the /64 to downstream devices.

3GPP gateway does not support PD and can only send a /64.

We can extend a single /64 via PD RA 64share technique but the UE need more
then a /64 for downstream devices since a /64 cannot be segmented.

Even if we were able to get 3GPP architecture to send shorter prefix, we
would still need mobile devices to accept /56 via RA since PD is not
supported.

So this would require updating RFC 4291 removing the 64 bit boundary so
that slaac shorter prefix will work.

>
>
> In the plethora of emails I have lost track. Would you be able to
> reiterate the sets of technical problems you desire solved?
>
> Cheers,
> Ole

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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