Re: Extending a /64

["Joel M. Halpern" <[e-mail]>]

Sure, I expect there to be a global digital ID for every aircraft.  And 
every Drone.  And ...

But why should that be embedded in the IPv6 address prefix assigned to 
the airplane.  Coupling identity with location is a major problem.  Why 
make it worse?

Yours,
Joel

On 11/16/2020 8:57 AM, Simon Hobson wrote:
> Philip Homburg <[e-mail]> wrote:
>>> 5. Address Management and Allocation
>>>
>>> A static address will have to be configured into each aircraft and
>>> that is a non-trivial problem given the regulatory control exercised
>>> over aircraft maintenance. There is an existing "personality module"
>>> in every aircraft that is there to hold the aircraft identity. This
>>> already includes information such as the aircraft's ICAO 24-bit
>>> identifier (a unique global identifier allocated to all aircraft
>>> flying in civilian controlled airspace). If you limit the construction
>>> of an MNP to static constants and the configuration data that
>>> already exists then you avoid a global programme to upgrade the
>>> Personality Module in all aircraft.
>>
>> This is just a technical choice. A choice that is mostly in conflict with
>> IPv6 address policies. So it makes sense to make a difference choice.
>>
>> I.e., the argument that you do not want to number aircraft in a dense way or map
>> an existing sparce identifier onto a densse space may not carry much weight in
>> RIR communities.
> 
> I think there's a piece of the puzzle you are not aware of, and to help, I'll recount an enlightening moment for me from a few years ago.
> 
> I used to own a share in a small (4 seats) aircraft. This was on the UK registry, but had in the past been on the US registry. While generally browsing around, found that it's entry in the US registry had an identifier allocated to it - which I thought strange given that it had been moved to the UK long before these were implemented. There was "a bit of discussion" on a mailing list - because I was thinking along the lines of "why not have dense allocation and lookup tables". But I was thinking only of air-ground communication and systems that would be able to do live lookups from some database - probably a hierarchical system like DNS is. And like you, I was thinking about this from an IT person's PoV.
> 
> Back then, these new fangled digital systems like TCAS were fairly new - and in part it was these that drove the requirement for every aircraft to have a globally unique digital identifier. These systems use digital identifiers, while pilots use callsigns or aircraft registry numbers. Furthermore, they need to be able to operate in the absence of external communications.
> So there are two approaches.
> One is to do dense allocation, and require EVERY device in the world to carry an up to date copy of the mapping - in it's entirety. Think about that for a moment - a table that lists the electronic ID and registry entry for EVERY aircraft in the world, and kept fully up to date. Some may remember when the internet was small enough to use a hosts file rather than DNS - and as I recall, that was abandoned as unworkable long before the number of hosts was even in the same ballpark as the number of aircraft in the world.
> The other method, and the one that was chosen, is for each state to use an algorithm to map between IDs and registry names. Thus each item of equipment just needs a number of algorithms and a lookup table between state identifier and algorithm. The required updates should be few and far between.
> 
> And so, this is why when I looked up my aircraft in the US registry, it had one of these identifiers - even though it had never used, and probably would never use, it.
> 
> 
> But, I can imagine you thinking, these aircraft have big avionics bays, satellite comms, etc, etc - so what's the problem with keeping tables up to date or even doing live lookups. Well that's the big bit of the jigsaw puzzle you've probably overlooked - those "big aircraft" are but a tiny proportion of the world's aircraft. There are orders of magnitude more aircraft where if it doesn't fit in the panel in front of the pilot, then it isn't getting fitted. And probably a similar number that have no electrical system, or only a small battery powered system - the norm with gliders where there's probably just a single radio and a vario, all run off a small battery.
> And it's not unusual to be operating these smaller aircraft outside of radio coverage - so no communications with the ground - and from sites with no infrastructure (such as grass field with a shed at one side). And don't forget that balloons are also aircraft - no electrical system in the wicker basket !
> 
> 
> But any air traffic control/management system has to be able to work with all of these aircraft - otherwise it doesn't work. As it is, there are still projects going on to work out how to get basic radio conspicuity devices into smaller aircraft - both from a cost PoV (it can cost a significant proportion of the value of an airframe to do an avionics upgrade) and a power/weight* PoV.
> * Weight is always an issue. The four seater I had a share in could not carry 4 people and full fuel, and in fact it could struggle for weight and balance with just two people my size - every bit of weight you add in electronics is a bit of weight you've taken off the payload. Some aircraft, if you fully load them, start to resemble an aviation joke about needing a very long runway and just waiting for the earth to curve away from under it on take-off :D
> 
> 
> So you have a situation where airborne equipment is severely restricted in size/weight/power consumption, and must be capable of operating air-air without ground communications being possible. So it makes sense to use the technique outlines above for mapping between human usable registry ID and electronic ID.
> IMO, it also makes sense to utilise the same ID in an IPv6 world of air-air and air-ground communications. That way, you avoid having to build a completely new and duplicate system, and for the reasons outlined, you cannot use a system that requires real-time lookups or the carriage of static lookup tables.
> 
> 
> And that is why, contrary to your suggestion, it makes absolutely no sense whatsoever to make a different choice.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>