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

[tom petch <[e-mail]>]

From: ipv6 <[e-mail]> on behalf of Tony Whyman <[e-mail]>
Sent: 19 November 2020 14:30

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 

<tp>
Yes about 500 e-mail messages ago!

You referenced unpeeling the onion and that is what is has felt like, bit by bit the requirements are revealed, most of which render irrelevant what has just been said or most of the preceding discussion even.  The IETF way of working revolves around I-Ds which tend to eliminate a lot of the comments that might otherwise be made, at least by those who have read the I-D, so while I am interested to learn of the use of OSI in production, it has, at times, felt more like a DoS attack:-(

Tom Petch











- 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$
> --------------------------------------------------------------------
>
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------