Re: Extending a /64

[Tony Whyman <[e-mail]>]

On 16/11/2020 15:53, Joel M. Halpern wrote:
> Tony you have given a very good answer as to why the identifer is 39 
> bits instead of something smaller.
>
> That is not what I was trying to ask.
> Why is the airplane identifier embedded in the IPv6 address at all. 
> That is not the purpose of an IPv6 address.  It is not the name of the 
> thing.
>
> Yours,
> Joel

I suppose the response is what else would be used? An MNP is always 
going to be some prefix followed by a unique identifier for the aircraft 
- so why not use an existing identifier rather than make up a new one? 
As I said in an earlier post, any strategy that relies on dynamic 
assignment (e.g. using DHCPv6 PD), even when the MNP is assigned on a 
very long lease,  carries with it a potential new hazard and it seems to 
make sense to design that out.

If you want to go back to first principles then a name is an object 
identifier devoid of location, while an address is a name that can be 
used as a parameter to some algorithm that can allow you to locate the 
named object. Hence, I have no problem using a name as part of an 
address when the result is an efficient and reliable way to meet the 
requirement.

Tony

>
> On 11/16/2020 10:26 AM, Tony Whyman wrote:
>> 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
>