Re: Extending a /64

[Philip Homburg <[e-mail]>]

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

'Most deserving' sounds like a value judgement.

IPv6 address space is not as scarce as IPv4 space, but if we waste huge
amounts if space, then we can infact run out. So IPv6 addresses can be
allocated to all deserving parties.

We won't run out if we number things. If we number endsites as /48s then we
don't run out. 

In short, the IPv6 space is big enough to number everything, but not big 
enough to waste lots of bits.

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

The design of IPv6 is 64+64. Of course we can try to go back to the 90s and
say that 64 bits is not enough to number all prefixes because we feel the need
to waste lots of bits.

Those proposals we around when IPv6 was designed. They were rejected. 

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

It seems that the current proposal for aviation has very little do with 
efficient routing.

In fact, it can be said that the current proposal to number all plane from
a single prefix goes very much against efficient routing.

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

What I know about RIR policies is that they are focussed on allocating a
reasobale amount of space to ISPs. Reasonable is enough to number all
customers of the ISP (assuming IPv6, this obviously doesn't work anymore
for IPv4) and small enough that not a lot of space is wasted.

For RIR it doesn't matter if the prefix is connected to the internet or not.
The thing that matters is that there a single shared address space that is
allocated. So RIRs are tasked with preserving the space to make sure we
don't run out while at the space time provide enough space to ISPs to number
customer networks.

In other words, from an allocation point of view, there is no difference between
public and non-public networks.

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

This is just a technical choice. A choice that is mostly in conflict with
IPv6 address policies. So it makes sense to make a difference choice.

I.e., the argument that you do not want to number aircraft in a dense way or map
an existing sparce identifier onto a densse space may not carry much weight in
RIR communities.

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

Again this is just a technical choice. You can map between a dense space and
a sparce space using a simple table. You could also put the extra bits in
an IPv6 destination option.

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

I see a tendency to put everthing in the network layer. A network layer
is not designed to manage names of objects. So if there is the need to bind
the flight identifier and other intermation to a particular prefix, then 
just design an application layer protocol for that.

In particular REST APIs over HTTPS are very good for that kind of stuff.

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

By definition there are only slightly more then 65000 /16s in the entire
IPv6 space. If we use one /16 to number around 500000 planes, then wat it
stopping other communities from requesting the same?

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

Or go back to the drawing board.

If, for legal reasons you need something that cannot happen then it is time
to look for a different solution.

IANA is not free to allocate address space to random parties. IANA allocates
space to RIRs. In addition, the IETF can direct IANA to allocate space that
has specific technical uses.

Numbering planes of obvious something that falls under the scope of RIRs.

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

Why do you think IANA is more suitable than RIRs?

In particular, do you think IANA has a mandate to directly enter a contract
with a standards organisation?