Re: Extending a /64

On Thu, 12 Nov 2020, 06:45 Christopher Morrow, <christopher.morrow@gmail.com>
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"
>

The same desire could be applied to all fields in a packet. "They're my
packets so I decide what's in them."

That's fine if you only send packets to yourself, and pay all of the
implementation costs.

On the other hand, if you want to interoperate with others, and want to
them to share implementation and deployment costs, then what's in packets
is a shared decision, and the best and simplest compromise to try to suit
as many use cases as possible.

> On Wed, Nov 11, 2020 at 2:03 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>>
>> 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
>>
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------
>