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

[Tony Whyman <[e-mail]>]

The reasoning behind is explained somewhere back in the thread and 
probably more than once. I am wondering if an informational RFC is going 
to be needed to explain what is going on here - although I am not sure 
if I really want to volunteer myself to do this.

On 19/11/2020 14:24, Mudric, Dusan wrote:
> 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$
> --------------------------------------------------------------------
>
>