Re: Extending a /64

[Tony Whyman <[e-mail]>]

Well, yes. And you may also register a care-of address at the same time 
- which is a true IPv6 address used as a locator.

Indeed, you could define mobility management as being the registration 
and  lookup of a name (the MNP) in order to determine the (care-of ) 
address.

Tony

On 16/11/2020 16:22, Templin (US), Fred L wrote:
> Tony, even when the aircraft ID is embedded in the IPv6 prefix when the aircraft
> registers the MNP with the ATN it needs to also provide some kind of network
> access identifier. One possibility is UUID, which can be used as an index for
> DHCPv6-PD verification of the MNP on the backhaul but without requiring
> DHCPv6-PD signaling over the air.
>
> Fred
>
>> -----Original Message-----
>> From: ipv6 [mailto:[e-mail]] On Behalf Of Tony Whyman
>> Sent: Monday, November 16, 2020 8:16 AM
>> To: Joel M. Halpern <[e-mail]>; [e-mail]
>> Subject: Re: Extending a /64
>>
>> 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
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------