Re: Extending a /64

["Templin (US), Fred L" <[e-mail]>]

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