Re: [**EXTERNAL**] Re: Extending a /64

["Mudric, Dusan" <[e-mail]>]

NOTE: Not familiar with the reasons to put aircraft IDs in the address, but something like that should be in a layer above IP. Any further extension of addresses, like variable prefix length, interfere with the original approach.

Dusan

On 2020-11-19, 9:11 AM, "ipv6 on behalf of Tony Whyman" <[e-mail] on behalf of [e-mail]> wrote:

On 18/11/2020 23:08, Michael Richardson wrote:
> Joel M. Halpern <[e-mail]> wrote:
>      > Tony, why are you embedding the 39 bit airplane ID into the IPv6
>      > address.
>
> Tony wrote:
>> 6. Legacy Issues
>>
>> We have a very significant legacy issue in the existing ATN/OSI which is in
>> wide-spread use in Europe. In order to avoid having to upgrade every ATC
>> Centre before the ATN/IPS can be introduced into Europe, the strategy is to
>> develop protocol gateways that protocol convert between the ATN/IPS and the
>> ATN/OSI. For these gateways to work, there has to be semantic equivalence
>> between the address spaces. That is, the ATN/IPS MNP must include the ICAO
>> 24-bit and an airline identifier (15 bits seems to be the minimum here).
> My reading of this is that he needs the information in each packet so that he
> can do stateless translation between different technologies.   It needs
> to be stateless so that it can scale horizontally (inverse multiplexing), and
> so that it can be n+1 redundant.
>
"Stateless" is certainly the objective but the reason for this has more 
to with the safety approval process than with scaling.

The protocol gateway will be a specially developed box and the Safety 
Engineering Requirements for this are well known in terms of the 
software development lifecycle, rigorous testing, etc. A simple 
stateless transform from one address format to another is an isolated 
function. The code can be eyeballed and exhaustively tested in 
isolation. The cost of doing this is quantifiable.

A lookup function on its own is not that much more difficult. The 
problem comes when you look at the source for the data in the table and 
how the table is maintained. This is when you jump down the rabbit hole.

We would need to develop the procedures and process for generating the 
"new" identifiers for each aircraft, how they are communicated to the 
aircraft and lookup table (in each protocol gateway) and how we ensure 
that these are kept in sync to the required high degree of confidence. 
Based on previous experience, I would expect the safety authority to 
demand two independent proofs that the lookup table contains the correct 
data.

One would probably be by direct communication between the 
airline/aircraft registration authority and the maintainer of each 
protocol gateway. The other would probably be via each aircraft.

On the aircraft side, we may need an update to the AEEC specification 
for the Aircraft Personality Module, a potential hardware upgrade (to 
every aircraft) and the procedures for properly configuring the new 
identifier into the aircraft. A new protocol would be required to 
communicate the binding between the new identifier and the airframe's 
24-bit id to the protocol gateway. And all this has to be subject to the 
certification and approvals process.

For the sake of a few addressing bits, there is really no justification 
for going down this (very expensive and time consuming) path and we 
don't have the funding anyway.

To continue the metaphor, the only reason for jumping down this Rabbit 
Hole seems to be a "Mad Hatter's Tea Party" where you have a big empty 
"table" that is the current address space and with a group down one end 
of the table shouting "no room".

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!OSsGDw!amQR_S0k-d_ulNPgDoV12BA0yBEIJyFZjymdWRxBDGZr8V-GxHzvtWy43NvQ$ 
--------------------------------------------------------------------