Re: Extending a /64

[Gyan Mishra <[e-mail]>]

In summary from all the threads thus far on the original "general variable
slaac draft & problem statement draft" - b1) steal the uplink /64
(64share)  - which steals the wan /64 &  performing a PD like delegation
function using RA for subtending to downstream devices.  So far this is the
leading option.

Initially we did look at longer prefix, but then the contentious debate on
"race to the bottom" - and technical issue with DHCPv6 PD not being
supported on 3GPP gateway to get a shorter prefix -  that the only
workaround to longer prefix is a shorter prefix via "B1" which gets around
the "race to the bottom".

Cameron's 64share v2 enlightenment on the possible solution shorter 64<
prefix idea via RA would require IETF + 3GPP concurrence to spec changes.

Downside in stealing WAN /64 is the ephemeral prefix nature & instability
issue similar to what we have with wired broadband BNG with flash
renumbering.
We are digging in on the v2 thread how to detect failure & signal to the CE
a renumbering event.  Is this really an issue or are we over thinking as
this is a mobile device not fixed.

With existing 64share stealing of the radio /64 has there been any reported
issues in deployment & instability from renumbering events?

For the shorter prefix we would not be able to do a similar trick I don't
think as was done with 64share with single /64 stealing.  Unless it was
multiple /64's sent in PIO to steal - trickery would that be possible RA
PD like delegation.

Has that ever been done before -  using 64share delegating multiple /64s
via RA in PIO with 3GPP?

Multiple /64s trickery would get around changing IETF or 3GPP
specifications.


Kind Regards

Gyan






On Wed, Nov 11, 2020 at 5:04 PM Gyan Mishra <[e-mail]> wrote:

> My last post  - I accidentally posted to the wrong thread - was supposto
> be on 64share v2 😃
>
> On Wed, Nov 11, 2020 at 4:23 PM Brian E Carpenter <
> [e-mail]> wrote:
>
>> On 12-Nov-20 08:44, Christopher Morrow wrote:
>> > it seems that this whole conversation is really:
>> >   https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05
>> >
>> > happening again.
>> >
>> > right? :) "I'd like to use all the bits in my address as I see fit for
>> my purposes"
>>
>> Except that it *explicitly* recommends against changing the /64 for SLAAC.
>>
>>    Brian
>>
>>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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