Re: Extending a /64 (The most welcome comment)

[Tony Whyman <[e-mail]>]

On 18/11/2020 03:30, Michael Richardson wrote:
> When we designed IPv6, we assumed that everyone would get some, even if they
> didn't connect.
>
>      > ULAs only have the first property.
>      > If a device doesn't need the second property, the device doesn't need a GUA.
>
> Again, what is this business of trying to ration IPv6?
> Do they really need 39 bits? I don't know.
>
> Our entire Ipv6 architecture ENCOURAGES entities to ask for the amount of space
> that they think they might need over the lifetime of their effort and NEVER
> COME BACK for more.
>
> That's why /64 for IIDs, and /48s for every site.

If there is another edition of RFC 8200 then the sentence beginning "Our 
entire.." should be copied to the front page of the new edition. Yes, we 
all get the idea that addressing plans should be as elegant as possible 
- but IPv4-think should have no place in this. But, perhaps the most 
important notion that comes through in the above is that each industry 
ultimately knows best when it comes to the compromises that have to be 
made to create an industry specific addressing plan.

Over the last few days, I have been happy to try and peel away the 
issues that lay behind our proposed IPv6 addressing plan and to use it 
as an opportunity to spread understanding of the ATN/IPS and the 
constraints under which we are working. However, there is one point that 
it seems to be too difficult for some to get their head around and that 
is that we are not starting with a "clean sheet of paper". We have to 
respect the constraints that we have and sometimes arguably poor 
decisions that were made in the past and the result is a compromise. It 
will offend those who demand purity - but purity is not the objective. 
The objective is to deploy a working IPv6 based system.

In the ICAO Working Groups, we are writing the 3rd edition of the 
ATN/IPS Manual. There were two earlier versions and both represent 
failed attempts to deliver an IPS based ATN. They failed - not 
necessarily for technical reasons - but because there was no business 
case. This is a very hard nosed industry and, unless its use is 
commanded by regulation, if a new technology does not deliver more 
passengers or raise the profit/passenger then it ain't going to happen.

Even now, I am hard pressed to see any business case for an ATN/IPS 
replacing the venerable ATN/OSI. The ATN/OSI is a CLNP overlay on top of 
an IPv4 network, it works, with some limitations, and will support the 
current generation of applications. With nugatory upgrades it could 
support the next generation. Some might point to presumed cost savings 
by replacing CLNP with something that is industry mainstream - but the 
truth is that the CLNP bits are, by and large, in systems that perform 
functions that are unique to civil aviation, while the rest is catalogue 
item routers.

However, looking to the long term, it will be increasingly difficult to 
develop new applications on the ATN/OSI base and we should seize the 
first opportunity that we can find to move on to an ATN/IPS.

A funding window has opened up with the European Space Agency (ESA) and 
the EU's SESAR research programme putting in the funds to develop a 
prototype SATCOM service for the ATN/IPS. This should just about extend 
to cover initial avionics on a single aircraft type (different 
generations of aircraft have different communication architectures and 
everything has to be type approved before it can be used). The funding 
should also cover a protocol gateway allowing the prototype to interwork 
with ATC Centres i.e. to at least demonstrate an operational service 
using the ATN/IPS.

Even stretching the funding envelope this far is optimistic. Adding in 
anything else like a new registration scheme for aircraft and lookup 
tables in the protocol gateway will kill the project financially. Yes, I 
know that these are not technically difficult, but when you work in an 
environment where every new function has to be subject to a hazard 
analysis, a safety case, a high end develop lifecycle and rigorous 
testing then, what looks like a simple function on paper, quickly gets 
replaced by a dollar sign followed by lots of digits.

To keep this project feasible, we have to have an addressing plan (for 
aircraft) that is canonical with the existing NSAP Address. You may 
prefer purity and demand that we have a perfect addressing plan. But you 
are not helping.

Our goal is to get a working ATN/IPS on to a single aircraft type with 
minimum change to the existing system. Once this has been demonstrated 
to be feasible and "industry mainstream" then the case can be made for 
rolling it out to other aircraft types and, may be, one day, even the 
ATC Centre's will get upgraded - but that will probably have wait until 
a new application provides the business case.

Perhaps another aphorism that could be put on the front page of a future 
version of RFC 8200 is "never let the perfect be the enemy of the good".

Regards

Tony Whyman, MWA

PS: we could always declare the ATN as a closed network and use our own 
addressing plan - but does not help make the "industry mainstream" case, 
does it.