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

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

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/

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
> --------------------------------------------------------------------