Re: Extending a /64 (ATN/IPS worked example)

[Brian E Carpenter <[e-mail]>]

On 18-Nov-20 09:39, Templin (US), Fred L wrote:
> Brian, due to mobility we need to consider all aircraft as always away from their home
> networks. And, so, we need scalable de-aggregation and that is exactly what we get
> with our adaptation of BGP:
> 
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/

This looks good, but surely it doesn't care how the aircraft's prefix
is assigned?

   Brian

> 
> Fred
> 
>> -----Original Message-----
>> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
>> Sent: Tuesday, November 17, 2020 12:00 PM
>> To: Philip Homburg <[e-mail]>; [e-mail]
>> Subject: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
>>
>> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
>> know that the content is safe.
>>
>>
>> On 18-Nov-20 04:55, Philip Homburg wrote:
>>> In your letter dated Tue, 17 Nov 2020 15:02:40 +0000 you wrote:
>>>>> This a clear example of a bad addressing plan. If you have 5000 airlines and
>>>>> the biggest has 1300 aircraft then you don't give all tiny airlines the
>>>>> same amount of space you need for the biggest.
>>>>>
>>>> It's only a "bad addressing plan" if your sole success criteria is dense
>>>> allocation. IPv6 should have liberated us from such a narrow success
>>>> criteria. The success criteria that I am invoking include cost of
>>>> administration and legacy support.
>>>
>>> 'should have' is an interesting concept. We can't really go back in time.
>>
>> To be clear, the IPv6 *fixed length* address model changes the parameters
>> of allocation practice because of moving from (say) 24 to (say) 64 bits
>> of routeable prefix, but in no way changes the philosophy of allocation
>> practice. IPv6 has ~64 topology bits instead of ~24; the actual numbers
>> in the H-ratio calculation change; the potential lifetime of the address
>> space expands enormously; the economic value of address space collapse
>> enormously. But all of that breaks if you start assigning address bits
>> non-topologically. That's why IPv6 and IPv4 share CIDR as the basis
>> for both prefix allocation and wide-area routing.
>>
>> To get away from that, we'd indeed have to jump into our time machines,
>> go back to a meeting that happened just outside O'Hare airport in early
>> 1994, and agree on a variable length addressing scheme.
>>
>>> Technically we can just do a complete overhaul of the IPv6 addressing
>>> architecture. But I doubt that people who now have existing IPv6 networks and
>>> products would be interested in that. Changing a widely adopted
>>> architecture also has a huge cost.
>>>
>>>> I also do not see the point in having a different (shorter) prefix
>>>> length for aircraft in smaller airlines compared with those in larger
>>>> airlines.
>>>
>>> Well, ISPs with few customers have a longer prefix than those with many
>>> customers. I guess you propose that we should have taken the shortest
>>> prefix needed for the largest ISP in the world, and then give the same
>>> prefix to every last tiny ISP as well?
>>
>> Exactly. An operator of any kind should get a prefix that matches their
>> current and projected requirements. That's what CIDR-based allocation
>> is all about. Airlines are no different.
>>
>>    Brian
>>
>>>
>>>> If you are arguing for dense allocation as a general rule then this
>>>> should apply to the whole /64 prefix. I assume that you are demanding
>>>> that ISPs allocate a /64 to all their users unless they can make the
>>>> case for multiple subnets and, even then, are parsimonious in their
>>>> attitude and push back hard against any user that wants more than a /60,
>>>> demanding proof that they have more than 256 subnets.
>>>
>>> You can make that argument, but is not part of the design of IPv6. The
>>> design of IPv6 is the endusers should always have enough space to number
>>> their networks.
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
>