Re: Extending a /64

[Tony Whyman <[e-mail]>]

On 16/11/2020 00:11, Philip Homburg wrote:
>> If the need is shown, why would the aerospace industry not get the
>> address space?  /17 of address space for an entire industry with unified
>> networking goals doesn't seem especially unreasonable, i.e. it's very
>> large service provider size.  There aren't that many other equivalent
>> society / industry areas which have common networking goals in the same
>> way that the aerospace industry does.
> Of course this is more a discussion for the relevant RIR communities, but
> for example based on RIPE policies, I don't see how you could get a /17 for
> around 500000 internet connections. Even if you assume a couple of
> hundred passengers per plane and a /48 per passenger then it still doesn't
> add up.
>
> In what way is the aerospace large from a network point of view? 500000
> connections is not a lot. In most parts of the world that would be a smallish
> ISP.
>
Wow, I put up a 2 line post on a Sunday evening and it generated a real 
storm of responses. There is clearly interest in the subject and many 
points raised:

1. How scarce is the IPv6 Address Space?

In several earlier posts on this thread and related threads some have 
commented that the IPv6 Address Space is not scarce and that IPv4-think 
still influences too many decisions. Allocation density does seem to 
dominate RIR policies and comments such as those above also appear to 
follow the same logic i.e. that IPv6 addresses are valuable and should 
only be allocated to the most deserving.

On the other hand, only a small fraction of the total IPv6 address space 
has been allocated to date. While the address space is finite, other 
policy rules do not seem too worried about allocation density. For 
example, if you do worry about allocation density then on what 
justification should anything other than a single /64 be allocated to 
the average residential customer? If draft-mishra-6man-variable-slaac 
ever becomes a standard then there would seem to be few if any cases 
where a shorter prefix was needed. Even a Boeing 747 or Airbus A-380 
will follow the single gateway router model and could work within such a 
limit. Same should apply to Mobile Phones.

My own preference would be a prudent address allocation policy (i.e. /64 
is the default) while recognising that this should give you the head 
room to support address allocation policies that, where necessary, give 
a higher precedence to efficient routing and/or sub-allocation 
strategies - all of which lead to a lower address allocation density for 
those users that need to go down such a path.

2. Why not use RFC 4193 ULA?

This was my original proposal to the ICAO working group - and it got 
shot down :(

This is for the following reasons:

a. RFC 4193 is too prescriptive in that it wants a rigid boundary at a 
/48. Not a really a show stopper, but still a nuisance.

b. There are cases (e.g. drones) where there may be a requirement to 
inter-operate with the public internet.

c. A strong desire to "be part of the global IPv6 address space". A 
political/emotional motivation, but important nonetheless to some.

d. There will be other non-public internets to which the ATN/IPS will be 
interconnected (e.g. military) and ULAs could cause addressing issues at 
the border gateways.

I left the strongest justification until last. The global internet is 
not just the public internet, there will be other global and regional 
non-public internets, such as the ICAO ATN, military networks, and 
others that we haven't yet thought about. If any non-public internet 
goes down the path of ULAs then there is a high risk that address 
mapping (i.e. NAT) is required at the border gateways with any other 
internet that you need to internetwork with. The view was that it is 
much better to design out the problem by using globally unique IPv6 
addresses.

IMHO, RIR policies are often far too focussed on the public internet and 
forget about non-public internets and the value of common addressing 
plans between public and non-public internets.

3. Mobile Network Prefixes (MNPs) are non-topological addresses.

A minor point, but still one worth making. Each aircraft is assigned a 
unique MNP and which is only routeable when supported by a mobility 
management scheme. In theory this could support an argument for a high 
density allocation. However, that is before you bring in considerations 
of how mobility is supported. For example, if you go down a Mobile IP 
(or similar) path then you are going to want an MNP to be allocated from 
a Home Address Prefix - and you are not going to have a single Home 
Network for all aircraft in the world.

There are probably three main considerations when determining the 
addressing plan for aircraft MNPs.

a. The mobility management scheme

b. How address management is delegated to states and airlines.

c. Firewall strategies.

The last point demands that the rules for address management are clear 
and simple and respect natural groupings.

4. Static vs Dynamic Allocation

A static MNP allocation policy has been adopted by ICAO. There are many 
reasons for this. However, arguably the strongest of these is that if 
you do down a dynamic allocation route then there is a risk that an 
aircraft's (dynamic) MNP is changed in flight leading both to 
re-numbering on board the aircraft and having to report the new 
addresses to Air Traffic Control. All this results a significant comms 
outage - possibly at a critical phase of flight and will always be 
listed as a hazard in the Safety Analysis. In consequence, lots of 
testing, mitigation strategies, and so on.

It is far better to design out the problem by using a static addressing 
scheme.

5. Address Management and Allocation

A static address will have to be configured into each aircraft and that 
is a non-trivial problem given the regulatory control exercised over 
aircraft maintenance. There is an existing "personality module" in every 
aircraft that is there to hold the aircraft identity. This already 
includes information such as the aircraft's ICAO 24-bit identifier (a 
unique global identifier allocated to all aircraft flying in civilian 
controlled airspace). If you limit the construction of an MNP to static 
constants and the configuration data that already exists then you avoid 
a global programme to upgrade the Personality Module in all aircraft.

FYI, the 24-bit identifier is bigger than it might need be because it 
has at least two parts - a state registry identifier and an aircraft 
identifier. The state identifier is variable length and varies according 
to how big the aircraft registry is expected to be in that state.

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

Note: network addresses are also exchanged in end-to-end application 
messages. This is because when an aircraft first contacts ATC, it has to 
bind its Flight Identifier (callsign) to its airframe and network 
identity. For most scheduled airlines, a Flight  (e.g. BAW388) can be 
operated on a given day by any appropriate aircraft and the ATN has to 
be able to manage this fact safely. Indeed, as a wider issue, the 
binding of Flight Identifier to airframe identity (used for radar, ADS-B 
and datalink) is a key safety issue and not one that you mess around with.

7. We are boxed in

An ATN/IPS MNP needs to be statically allocated and to be formed from 
some initial prefix, a 39 bit aircraft identifier and some more bits for 
subnetting. This scheme also needs to be expandable to include other 
airspace users such as drones. If you assume 
draft-mishra-6man-variable-slaac then you could make do with an ICAO 
prefix that is a /20, but a /16 avoids making that assumption.

A /16 should be a small part of the unused IPv6 address space and it is 
difficult to see why a /16 should not be made available to what is one 
of the most important global non-public internets.

8. For legal reasons, the allocation of a /16 has to be made at the IANA 
level.

Finally, it is worth pointing out that ICAO standards have a different 
legal significance than, say, an RFC. The ICAO ratification process is 
slow but ends up with ICAO member states being asked to accept the 
standard as being annexed to the international civil aviation treaty. 
The ATN/IPS should become a mandatory standard for aircraft worldwide 
and so you can expect this to happen.

As a result, the standard effectively becomes part of international law 
and this will include publication of the addressing plan and the ICAO 
(/16) prefix. I am not an expert in international law. However, I 
suspect that would make it legally impossible for IANA to unilaterally 
revoke the /16 allocation. My guess is that the RIRs do not have the 
authority to give away a chunk of the address space in this way and that 
this has to be done at the IANA level.

Hopefully, the above helps give further background and I assume that 
there is interest in this subject given the response to last night's post.

Regards

Tony Whyman, MWA