Re: Extending a /64

Going this route allowing for shorter prefix <64 but not allowing the >64
due to the race to bottom contentious debate.  This would definitely solve
the issue at hand.

The variable slaac draft solution allows for both longer and shorter
prefixes.  I can update it so it only allows for shorter prefixes so this
draft can progress.

https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/

On Wed, Nov 11, 2020 at 1:51 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> For this to be idea to come to fruition we need buy in from both 3GPP
> architecture to allow  < 64 ra and IETF as well RFC 4291 and 4862.
>
> Cameron
>
> Would 3GPP architecture just have to update their code  to support shorter
> prefix RA, or is there anything else technical that has to change on the
> 3GPP end.
>
> On Tue, Nov 10, 2020 at 8:15 PM George Michaelson <ggm@algebras.org>
> wrote:
>
>> There is a liaison function between the RIR and the IETF, and the IETF
>> and IANA regarding address dispositions. When people reach a point
>> they believe there is a need for an unusual assignment from global
>> unicast space, the proper thing to do, is invoke the liaison function,
>> and have this dealt with respectfully across distinct process
>> boundaries regarding how addresses are managed and delegated.
>>
>> As long as the people who perform this liaison function are aware of
>> this conversation, nothing much else has to be said here. I would ask
>> that the WG chairs and AD keep that in mind.
>>
>> cheers
>>
>> -George
>>
>> On Tue, Nov 10, 2020 at 11:45 AM Michael Richardson
>> <mcr+ietf@sandelman.ca> wrote:
>> >
>> >
>> > Tony Whyman <tony.whyman@mccallumwhyman.com> wrote:
>> >     > In the end, we concluded that we could not bend the existing
>> standards
>> >     > to do this and did not have the desire to push for change. Hence,
>> we
>> >     > are in the process of asking IANA for a /16 for the global civil
>> >     > aviation community. Hopefully we will get this. However, an
>> argument is
>> >     > expected given that the current policies push back against such a
>> large
>> >     > allocation and demand a utilisation efficiency that we will never
>> >     > achieve. However, if we don't get a /16 and the standards stay as
>> they
>> >     > are, then a private address space and NAT at the boundaries may
>> be the
>> >     > only answer - not really what anyone wants.
>> >
>> > I think that it's pretty important that the IETF IPv6 community
>> understand
>> > your needs, and speak clearly in support of your needs.
>> >
>> > What would happen if you had a /18 or a /20?
>> >
>> > --
>> > Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
>> consulting )
>> >            Sandelman Software Works Inc, Ottawa and Worldwide
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
>
> <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