Re: Extending a /64

[Tony Whyman <[e-mail]>]

On 16/11/2020 14:50, Joel M. Halpern wrote:
> Tony, why are you embedding the 39 bit airplane ID into the IPv6 
> address.  That seems to be the fundamental thing that then has you 
> need very short prefixes, and doing other difficult operations.
>
> And if the answer is "ICAO said so", then we have a problem of really 
> smart aviation engineers doing network engineering.
>
> Yours,
> Joel

Perhaps the best way to answer this question is to look at the alternative.

Aircraft MNPs are non-topological and hence could be densely allocated. 
However, if you want to go the distance and specify the minimum length 
identifier then:

1. You need to set up a new registration database for aircraft (in order 
to assign the new identifier) and one that is global rather than state 
based - which is the present approach.

2. You need to update the specification for the Aircraft Personality 
Module and organise the fleet wide upgrade necessary to ensure that 
every affected aircraft gets a new ICAO global Aircraft Identifier.

3. Safety Authorities will now identify a new hazard potentially 
resulting from a mis-match between the existing ICAO 24-bit identifier 
(which still has to be used for radar, ADS-B, TCAS, etc.), and the new 
airframe identifier.

4. We need to develop procedures and systems for mitigating the new 
hazard, assuming it is deemed serious enough.

5. The protocol gateways that are planned to avoid having to upgrade the 
existing ATC Systems in the same timeframe would now have to include a 
lookup table between the "old" NSAP Addresses and the "new" IPv6 Addresses.

6. The Safety Authority would identify a new hazard resulting from a 
table configuration/maintenance error and procedures/mitigations would 
be needed to counter the threat.

7. The address mapping would have to extend to the application protocols.

In other words - a lot of negatives each with a potentially large cost 
attached to them.

The next step is to accept that it is worth "wasting" a few more bits 
and using the existing ICAO 24-bit aircraft identifier instead of some 
new global aircraft identifier. This avoids issues 1 to 4 above.

In order to avoid 5, 6  and 7, we need to have a simple algorithm to 
convert between aircraft ATN/OSI NSAP Addresses and ATN/IPS IPv6 
Addresses. The existing (legacy) NSAP Address format for aircraft 
addresses starts off with some constant prefix and is then followed by 
an airline identifier, the ICAO 24-bit identifier, an 8 bit subnet id 
and a 48-bit End System id (it follows a structure originally proposed 
by NIST). The last two can be readily combined into a 64-bit host 
identifier. Indeed, if we based the MNP on the ICAO 24-bit then the only 
thing stopping a simple algorithm is the missing airline identifier part 
- this cannot be readily predicted from the ICAO 24-bit identifier 
without access to the registration database.

In order to avoid a lookup table in the protocol gateway, etc. we need 
to have an airline identifier in the MNP. 15 bits appears to be the 
minimum we can get away with (in order to avoid a new airline 
identifier, the proposal is to generate a 15-bit identifier by encoding 
the existing ICAO three character airline identifier using ITA-2 letter 
shift). Hence 24 +15 = 39.

The industry's network providers also regard embedding an airline 
identifier in the MNP as highly desirable. It is used in the existing  
system for diagnostic purposes and firewalls.

This is not an "ICAO says so" at all. This is practical engineering to 
deliver a new system as an evolution from an existing system and with 
limited budgets. Start with a clean sheet of paper and you could use a 
lot less that 39 bits. Unfortunately, we do not have that luxury.

Tony