Re: Extending a /64

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

Excuse front posting:

> Whether or not the addresses used in the control systems of aircraft are announced to the Internet, it seems completely justified to use globally unique address space to address them.

I completely agree. That isn't where the issue lies. It's in the proposal to include 39 non-topological bits in the routeable prefix, which goes against 25 years of CIDR.
(28 years if we respect RFC1338 as the origin document.)

Regards
   Brian Carpenter

On 17-Nov-20 15:55, David Farmer wrote:
> 
> On Sun, Nov 15, 2020 at 2:56 PM Mark Smith <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>     On Mon, 16 Nov 2020, 07:19 Philip Homburg, <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         > Again, there are 35 trillion /48s in 2000::/3. How many would you
>         > need?
> 
>         It gets tight when you want the prefix to contain 39 bits to number around
>         half a million planes.
> 
> 
>     Why are half a million planes going to be on the Internet?
> 
> 
> Being on the Internet is not the only justification for the use of globally unique address space.
> 
> You mention that airplanes can fall out of the sky, it would be really bad if an airplane every fell out of the sky, or collided with another airplane, because of an address conflict. The proper used globally unique registered address space makes such a conflict almost impossible. Where the use of ULA makes such addressing conflicts statistically possible, even if unlikely. With half a million aircraft and the potential consequences of an address conflict, the ULA random selection algorithm is probably not a good idea for this use case.
> 
> Whether or not the addresses used in the control systems of aircraft are announced to the Internet, it seems completely justified to use globally unique address space to address them. Further, a single very large allocation something like a /16 or more to the international coordinating body for the aircraft industry, allowing them to make sub-allocations to aircraft operators, airport operators, navigational aid operators, etc... seems like a quite reasonable address management scheme to me.
> 
> There are several ways to accomplish this; the IETF could make a special allocation, a global policy could be coordinated through the RIRs and the ICANN ASO, or the entity could approach one of the RIRs for an allocation directly. As a past member of the ARIN AC, I know for a fact that ARIN IPv6 policy explicitly contemplates LIRs that are not necessarily connected to the Internet, and contemplates generous initial allocations of up to a /16 for LIRs when justified. Further, ARIN uses a sparse allocation methodology, reserving at least an additional nibble of address space for future expansion.
> 
> Honestly, given the importance of the use case discussed, I don't see the controversy, the allocation of a large address space allowing for the assignment of /48s or /56s to aircraft and /48 or larger to airports seems easily justified, and allocating it out of something other than 2000/3 seems quite reasonable as well, which would require IETF action. Further, the use of IIDs other than /64 is completely unnecessary.
> 
> Thinking even more broadly it might not be a bad idea to allocate a whole new /4 for transportation automation to cover aircraft, cars, trucks, intelligent roadways, etc... 
> 
> Thanks
> -- 
> ===============================================
> David Farmer               Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota  
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>