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

Brian, like Behcet said it is really the logical equivalent of host routes. Only, our
"host routes" are /60's and not /128's. For many reasons though, it is good if we
can have a portion of the prefix based on a unique identifier that travels with
the aircraft. It is not a MAC address, however; it is the moral equivalent of an
automobile VIN with no addressing semantics at any layer.

Fred

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Tuesday, November 17, 2020 1:43 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>; ipv6@ietf.org
> Subject: Re: Extending a /64 (ATN/IPS worked example)
>
> 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:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> >> Sent: Tuesday, November 17, 2020 12:00 PM
> >> To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>; ipv6@ietf.org
> >> 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
> >>> 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
> >> --------------------------------------------------------------------
> >
> >