Subject: about that AERO /17 allocation justification

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Nov 2020 18:02:56 -0500

Starting a new thread.  I'll try to finish reading the existing, but probably
won't reply.

I'm still not sure where the document is arguing for this addressing
architecture is.  I'd sure like to be discussing a specific proposal.

I'm clicked off this "mornings" side meeting on OMNI. I just had to go to sleep.
But, I didn't intend to attempt to hijack that meeting: I thought this
discussion in intended to be in scope.

Tony Whyman <[email-masked]> wrote:
    > 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.

I thikn that you are bang on here.  IPv6 is not scarce, but doing it right
makes sense.  I think it is entirely reasonable that a large segment of the
transportation industry should receive an allocation large enough that they
never need to return for several decades to a century.

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

Let me repeat what I said elsewhere.
ULA has no whois, no RPSL, no RPKI and no reverse DNS.

An anecdote:  back in 1995 when the firewall company I helped found installed
a gateway at a semi-government organization (we call them Crown Corporation
here), our BCP38 alerts starting going on!  WTF were foreign *Internet*
addresses doing on the inside of the firewall?
This was back when class Bs were being handed out like candy.
We were rapidly able to determine who the traffic belonged to.
A small scandal ensued as it became clear that a supplier was running the
WANs for multiple entites on the same wires, in the days before VLANs, VRFs,
ATM or MPLS.   The injection of a default route into our client's network
leaked to other entities, and they did the obvious thing and tried to use it.
This experience beat into me the importance of being able to track addresses
back to network owners.  The proliferation of RFC1918 has been a serious
pain, and I am not unhappy that site local went away.
I am very much a proponent of a ULA-C concept.

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

Back in the late 1990s the proliferation of overlapping 10.x addresses caused
the Automotive Network Exchange to consider ways to do NAPT within VPNs.  I
don't know how it was ever resolved.  But, this was driven by the false
belief that networks that don't need *I*nternet shouldn't get pulic address
space.  Because "security".  This wasn't true 25 years ago, and it's still
not true today.

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

I agree.

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

While your point makes sense, I don't think that they understand the
objections that Brian Carpenter and a few others have made.

    > 4. Static vs Dynamic Allocation

I take your point, and I agree understand.
There are really three levels though:
 1) autoconfigured from ICAO ID (the way IPv6-LL+MAC-address worked
    pre-privacy issues)
 2) allocated during an onboarding process when the aircraft is (re)sold, and
    then nailed down.
 3) dynamically allocated during operation.

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

The 24-bit airplane ID... the ICAO identifier being statically allocated to
the aircraft (the DRIP guys say I should write airframe) makes total sense to
me.  And if the aircraft could just assume some ICAO /32 allocation and then
configure a /56 (32+24) prefix then this would make more sense to me.

But, this means each aircraft is its own /56 independantly of the airline's
allocation (within a /32).
But, as long as the airline's prefix has to be taken into account, then we
can't do (1) above anyway.  We can only do (2) or (3).

It seems that the 24-bit identifier size is not negotiable, but the airline
/15 is.  It seems that airlines could well go ask for /32s from RIRs, and
this is entirely doable and affordable.  It would probably help if there
were an RFC that explained things, and the RIRs could be asked to take into
account.

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

It could be great if you could point to the ATN/OSI mapping so that we'd
understand more.

What if the 15-bit field was not unique to airlines?
We don't have 32K airlines (do we?), and we only need to do this during the
transition (20 years?) overlap phase right?
What if the RIRs, allocating out of various 2000:/3 allocations could promise
that the 15-bits (bits 17-32) were unique?

Obviously that would easier (trivial) if there was a /17 set-aside for this.
I don't think that allocation of a /17 is a problem at all.
It's just a question of whether it should be allocated by IANA or via
negotiation among existing RIRs.

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

Why 16?  Where did the extra 1-bit come from? Is that to be able to allocate
for airports, etc...?

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

I think that an IETF RFC that instructed IANA to do the allocation, and which
was then ratified by ICAO would be the right process.

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

Thank you very much.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: George Michaelson <[email-masked]>
Date: Thu, 19 Nov 2020 10:46:43 +1000

> I think that an IETF RFC that instructed IANA to do the allocation, and which was then ratified by ICAO would be the right process.

I will repeat my plea from before.

There is an RIR liaison function. The "right process" here is to
include the RIR and have the IANA allocation routed through an RIR.
The IETF needs to talk to the liaison. I informed the NRO about this
conversation so it may come in from "the other side"

ICAO is based in Canada, but has offices worldwide. It can be done in
any RIR they nominate as their preferred home.

Please, can we respect the prior IAB/RIR agreement on global unicast
distribution methods?

-George

---

From: "Da Silva, Saulo" <[email-masked]>
Date: Thu, 19 Nov 2020 01:38:50 +0000

ICAO is already in the process of coordination with the RIR.
Informally as of today but preparing the documentation for an official request.
And it looks like it will be /16 based on the needs studies made so far. 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of George Michaelson
Sent: 18-Nov-20 7:47 PM
To: Michael Richardson <[email-masked]>
Cc: IPv6 <[email-masked]>
Subject: Re: about that AERO /17 allocation justification

There is an RIR liaison function. The "right process" here is to include the RIR and have the IANA allocation routed through an RIR.
The IETF needs to talk to the liaison. I informed the NRO about this conversation so it may come in from "the other side"

ICAO is based in Canada, but has offices worldwide. It can be done in any RIR they nominate as their preferred home.

Please, can we respect the prior IAB/RIR agreement on global unicast distribution methods?

-George

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://secure-web.cisco.com/1ENFbDHFB8vsDfhT37EaMG0l7cwFTHEyEWipaphkayMLzUdjiKt56Zdq1TSLwEEdP85djNIFw_Dc9jFpf2BE5Fge6P8n-LLeeqA9Q0nt9zy2seFEnbD9WzativVIlf7GqWpgKTV2u1eVJPObg5xHTWFacVeE45SADQIX4iQ7etbCmwDhuMziwZuALbEjbEawBEGnSa6nUwHc79pIIXoINlgFIhrSg0n9hQtEOWB5n009HyRr6wISz8iFhOgN6MLHZmyitxTebZJmO87oyw7ro5Pw4vTp3xA7WEm9-5xBFgfCTJDP_X7tk4oPFYQy7Tdw5/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6
--------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Nov 2020 02:20:31 -0500

George Michaelson <[email-masked]> wrote:
    >> I think that an IETF RFC that instructed IANA to do the allocation,
    >> and which was then ratified by ICAO would be the right process.

    > Please, can we respect the prior IAB/RIR agreement on global unicast

Thanks George, I didn't mean to overstep that.
I am mostly experienced with the IETF being able to write documents reserving
address space for things, like example networking.  We tell IANA, and they do
that.

{glad you read down that far!}