RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)

["Templin (US), Fred L" <[e-mail]>]

Brian,

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Tuesday, November 17, 2020 2:00 PM
> To: Templin (US), Fred L <[e-mail]>; Philip Homburg <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
> 
> On 18-Nov-20 10:54, Templin (US), Fred L wrote:
> > 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.
> 
> I can see the value of having it in the address, assuming you have some kind of authentication of the address. Why does it specifically
> need to be in the prefix?

It needs to be in the upper 60 bits, because the lower 68 bits are used for on-board
subnetting and assigning interface identifiers to on-board network nodes.

Fred

>    Brian
> 
> >
> > Fred
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[e-mail]]
> >> Sent: Tuesday, November 17, 2020 1:43 PM
> >> To: Templin (US), Fred L <[e-mail]>; Philip Homburg <[e-mail]>; [e-mail]
> >> 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:[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
> >>>> --------------------------------------------------------------------
> >>>
> >>>
> >