Re: Extending a /64 (ATN/IPS worked example)

[Tony Whyman <[e-mail]>]

On 17/11/2020 03:39, Brian E Carpenter wrote:
> Excuse front posting:
>
>> Whether or not the addresses used in the control systems of aircraft are announced to the Internet, it seems completely justified to use globally unique address space to address them.
> I completely agree. That isn't where the issue lies. It's in the proposal to include 39 non-topological bits in the routeable prefix, which goes against 25 years of CIDR.
> (28 years if we respect RFC1338 as the origin document.)
>
> Regards
>     Brian Carpenter

Brian,

The "39 bits" does look like the focus of your objection and perhaps the 
best way to convince you that this is the right approach is to post a 
worked example. I have hung back from doing this before if only because 
the ICAO working group is still evaluating mobility schemes that aim to 
improve on Mobile IPv6. However, a simple example using Mobile IPv6, 
with multilink extensions and Basic NEMO should be good enough to 
illustrate our logic.

1. The Home Agents

The organisational model for the ATN/IPS pushes you quickly towards a 
view that each aircraft operator (e.g. airline) should be responsible 
for deploying a Home Agent for their aircraft. They may operate their 
own Home Agent or outsource it to one of the industry's service 
providers. Basically, they pay for the Home Agent and are responsible 
for ensuring that their aircraft each have a Home Agent.

2. The Home Network Prefix

Each aircraft operator could individually register (e.g.) a /32 with an 
RIR for their Home Network Prefix. However, there are more than 5,000 
airlines and if you want to have firewall rules that refer to "all 
uplink packets", an un-coordinated registration of Home Network Prefixes 
would lead to a big configuration maintenance problem for every firewall 
in the ATN/IPS. The preference has thus been to have a common ICAO 
prefix for "all aircraft MNPs" and to allocate a Home Network Prefix to 
each aircraft operator using this common prefix.

Our addressing plan allocates a /36 to each aircraft operator for use as 
a Home Network Prefix, including the 15 bits used to identify each 
airline. On paper, this is a more efficient use of the IPv6 address 
space than a free for all, which should be seen as a potential benefit 
of an ICAO administered scheme.

The /36 Home Network Prefixes should be normal routeable prefixes 
leading to the aircraft operator's Home Network. I would expect that 
each is advertised in the NLRI of a stable BGP route (leading to the 
Home Network) with aggregation to the common ICAO prefix at the ATN 
boundaries.

3. Binding Updates

This should be a textbook approach. Aircraft use Mobile IPv6 Binding 
Updates to register each currently active care-of address and their MNP 
with their Home Agent.

4. Forwarding to the Aircraft

An uplink packet addressed to an MNP relative destination address should 
be routed to the Home Network for the aircraft's aircraft operator and 
picked up by the Home Agent.

The Home Agent can now match registered MNPs against the packet's 
destination address, select the care-of address, encapsulate and forward 
the packet to the selected care-of address. The packet is received by 
the airborne router, decapsulated and forward to its final destination 
using normal forwarding procedures.

Analysis
------------

The MNP is necessarily non-topological to the underlying internet, which 
is why you need something like Mobile IPv6 to make the whole thing work. 
The only thing outstanding in the above is "how long a prefix is the MNP"?

Each MNP will be allocated using the aircraft's Home Network Prefix. The 
rest of the MNP is just going to be a number n-bits in length. There is 
no useful topological information that you can put there.

I believe that American Airlines currently has the largest fleet with 
about 1,300 aircraft. You would need a minimum of 11 bits for this fleet 
- rounded up to 12 for a nibble boundary.

You recently sent me a reference to a paper on prefix management and I 
presume that you would favour an approach where the Home Agent was 
responsible for automatically allocating an MNP to each aircraft, 
perhaps using DHCPv6 PD embedded in Mobile IP exchanges.

However, there is usually a strong preference in this environment for 
static allocations configured into (in this case) the aircraft. This is 
all down to limiting the number of possible hazards, providing proofs of 
correction configuration and so on. The regulators and safety 
authorities have the last call in this area.

A Home Agent based allocation scheme would also cause problems with our 
protocol gateways to legacy systems as there would need to be a 
mechanism to map these allocations to ICAO 24-bit aircraft ids - 
probably requiring some protocol to export the allocations from each 
Home Agent and then copy them to the protocol gateways.

The options for MNP allocation can be written down as:

1. Home Agent Allocation of a /48 (Home Network Prefix plus 12 bit 
aircraft identifier).

2. Airline Allocation of a /48 (Home Network Prefix plus 12 bit aircraft 
identifier) and configuration of the new 12 bit aircraft identifier into 
the Aircraft's Personality Module.

3. Allocation of a /60 (Home Network Prefix plus the ICAO 24-bit 
identifier already configured in the Aircraft's Personality Module).

The ICAO working group has gone for option 3 on the grounds that a 
24-bit identifier already exists and configured into the aircraft. It's 
as near as you get to free of charge. It also supports our protocol 
gateways to legacy systems without the need for mapping tables. Option 2 
adds extra cost in terms of configuration management and forces a lookup 
table into our protocol gateways to legacy systems and a need to provide 
for timely update of this lookup table. Option 1 introduces extra 
hazards due to additional protocol, ensuring that re-numbering does not 
take place during flight and an additional certification cost for Home 
Agents - and it also forces a lookup table into our protocol gateways to 
legacy systems plus a means to communicate the allocated MNPs.

For us, Option 3 was a "no brainer" on both cost and engineering 
considerations. A /60 is acceptable for an aircraft, and no one can 
identify a use case where a /60 won't do and a /48 is required. If you 
really think that this wasteful of a scarce resource then have a word 
with my ISP and ask them why they give me a /48 for a residential 
broadband service when all I need is a /64.

Hopefully this explains a few thing.

Regards

Tony Whyman, MWA


> On 17-Nov-20 15:55, David Farmer wrote:
>> On Sun, Nov 15, 2020 at 2:56 PM Mark Smith <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>
>>      On Mon, 16 Nov 2020, 07:19 Philip Homburg, <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>          > Again, there are 35 trillion /48s in 2000::/3. How many would you
>>          > need?
>>
>>          It gets tight when you want the prefix to contain 39 bits to number around
>>          half a million planes.
>>
>>
>>      Why are half a million planes going to be on the Internet?
>>
>>
>> Being on the Internet is not the only justification for the use of globally unique address space.
>>
>> You mention that airplanes can fall out of the sky, it would be really bad if an airplane every fell out of the sky, or collided with another airplane, because of an address conflict. The proper used globally unique registered address space makes such a conflict almost impossible. Where the use of ULA makes such addressing conflicts statistically possible, even if unlikely. With half a million aircraft and the potential consequences of an address conflict, the ULA random selection algorithm is probably not a good idea for this use case.
>>
>> Whether or not the addresses used in the control systems of aircraft are announced to the Internet, it seems completely justified to use globally unique address space to address them. Further, a single very large allocation something like a /16 or more to the international coordinating body for the aircraft industry, allowing them to make sub-allocations to aircraft operators, airport operators, navigational aid operators, etc... seems like a quite reasonable address management scheme to me.
>>
>> There are several ways to accomplish this; the IETF could make a special allocation, a global policy could be coordinated through the RIRs and the ICANN ASO, or the entity could approach one of the RIRs for an allocation directly. As a past member of the ARIN AC, I know for a fact that ARIN IPv6 policy explicitly contemplates LIRs that are not necessarily connected to the Internet, and contemplates generous initial allocations of up to a /16 for LIRs when justified. Further, ARIN uses a sparse allocation methodology, reserving at least an additional nibble of address space for future expansion.
>>
>> Honestly, given the importance of the use case discussed, I don't see the controversy, the allocation of a large address space allowing for the assignment of /48s or /56s to aircraft and /48 or larger to airports seems easily justified, and allocating it out of something other than 2000/3 seems quite reasonable as well, which would require IETF action. Further, the use of IIDs other than /64 is completely unnecessary.
>>
>> Thinking even more broadly it might not be a bad idea to allocate a whole new /4 for transportation automation to cover aircraft, cars, trucks, intelligent roadways, etc...
>>
>> Thanks
>> -- 
>> ===============================================
>> David Farmer               Email:[e-mail] <mailto:[e-mail]>
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE        Phone: [phone]
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>