Subject: Extending a /64

From: [email-masked]
Date: Sun, 8 Nov 2020 11:25:27 +0100

Starting a new thread.

A problem described in variable-slaac is:

"It should be possible to extend an end-user network that is only assigned a /64"

I believe that is a problem worth looking at.
This problem is not only restricted to the mobile access case, think connecting a host with VMs to a link.

The address delegation to a site problem is intertwined with the autonomous networking problem of the site itself. The IETF solution is DHCPv6 PD + HNCP. The expectation of addressing of a network is that the addresses are long-lived.

There are many potentional solutions:

a1) ask the network operator for more address space.
a2) change provider
a3) introduce government regulation
b1) steal the uplink /64 (64share)
b2) steal multiple /64s from uplink
c) overlay. use e.g. LISP to tunnel across the access ISP to connect to an ISP that support multi-homing and larger address space.
d) MultiLink Subnet Routing. I.e. let a single /64 span multiple links. draft-thubert-6man-ipv6-over-wireless, draft-ietf-ipv6-multilink-subnets
e) NAT
f) P2P Ethernet. Hosts are not on the same physical link, so let's stop pretending they are. A consequence of that is that links don't need subnets. Only assign addresses to hosts. draft-troan-6man-p2p-ethernet-00
g) extend the /64 bit boundary. HNCP implementations do /80s I think (forces DHCP for address assignment)

Requirements:
R-1: Permissionless. Not require an action on the network operator
R-2: Arbitrary topology
R-3: Long-lived address assignments
R-4: Support bad operational practice: flash renumbering / ephemeral addressing

Is there interest to work on this problem?
If so, suggestions for next steps?

Best regards,
Ole (without any particular hat on)

---

From: Tony Whyman <[email-masked]>
Date: Sun, 8 Nov 2020 13:00:40 +0000

The problem of the /64 limit came up in ICAO working groups earlier this 
year when developing a global addressing plan for the ATN/IPS and there 
would be strong support here for allowing subnet prefixes to go beyond 
the /64 boundary.

Our problem is that we wanted to define an addressing plan that uses 39 
bits to identify each aircraft, allows for a minimum of 4 more bits for 
subnetting and works within the existing standards. I'll give some 
background below for those interested in why 39 bits, but the problem is 
that if you are going to allocate a /64 (deriving from a /60 MNP) to 
each subnet on an aircraft then you need a /21 as your initial 
allocation - and this is before you start thinking about other ATN/IPS 
users such as drones.

In order to avoid a potential problem getting a sufficient address 
allocation, we did look at extending into the "other 64 bits" of an IPv6 
address for subnet IDs, which was looking very "unused". After all, you 
can only cram in a handful of systems into the avionics bay of even the 
biggest aircraft and, if you extend the addressing scheme into the back 
cabin, passengers can only bring on so many mobile phones, tablets and 
laptops in their hand luggage. 64 bits is an overkill for the host 
identifier and, if only we could have allocated (e.g.) a /96 for each 
aircraft subnet, then the problem would just go away.

In the end, we concluded that we could not bend the existing standards 
to do this and did not have the desire to push for change. Hence, we are 
in the process of asking IANA for a /16 for the global civil aviation 
community. Hopefully we will get this. However, an argument is expected 
given that the current policies push back against such a large 
allocation and demand a utilisation efficiency that we will never 
achieve. However, if we don't get a /16 and the standards stay as they 
are, then a private address space and NAT at the boundaries may be the 
only answer - not really what anyone wants.

I would certainly support raising the existing limit. A hard limit of a 
/96 would seem to be a good idea to stop ISPs going too far. It's 
probably also worth noting that perhaps one day every home on the planet 
may require an IPv6 Prefix. That is perhaps over a billion given the 
world's population. With densely packed address allocation that still 
requires 30 or so bits. Once you take into account any kind of 
geographical sub-allocation then you will need a lot more. A /96 would 
seem to be much easier to live with than a /64.

Tony Whyman, MWA

Background
-----------------

For operational reasons, the ATN/IPS address allocation should allow for 
a common prefix for all aircraft operated by the same airline. Network 
diagnostics and firewall rules are often cited in support of such a 
requirement. It is also highly desirable that there should be a common 
prefix for all airline IPv6 Address Prefixes. Again this is to support 
simple firewall rules. Resisting DoS attacks is extremely important in 
our environment and these include firewall rules that prevent packets 
from external sources being sent to aircraft unless authorised, if only 
to minimise the risk of overloading limited capacity wireless 
subnetworks. If every airline and ATC Centre has a different address 
prefix then managing these rules will be an almost impossible task if 
they all have unrelated prefixes. A common ICAO prefix is thus highly 
desirable as are common prefixes for each category of address space user.

It is believed that 15 bits is the minimum necessary to sub-allocate a 
prefix to each airline registered with ICAO. This leverages an existing 
registration scheme and allows for a reasonable degree of growth.

There are also very good reasons for using the existing ICAO 24-bit 
aircraft identifier as part of an aircraft''s /60 MNP i.e. to 
sub-allocate each airline's address space to each of their aircraft. For 
very good safety reasons, ATC Centre Flight Data Processors need to 
correlate datalink messages (callsigns and 24-bit), surveillance reports 
(radar and ADS-B - which also use the 24-bit scheme), voice  messages 
(using callsigns) and Flight Plans. Basically, you don't want to 
introduce yet another identifier into the mix and the use of overlapping 
schemes improves confidence in the overall result.

There is also the small matter of backwards compatibility with the 
existing ATN/OSI CLNP addressing scheme. This also uses an airline 
identifier/24-bit approach to address allocation and if we keep to the 
same address semantics then it becomes feasible to introduce the ATN/IPS 
with minimum impact on the high certification environment of the Flight 
Data Processor. Any alternative will cost a lot more and put back 
deployment for several years.

So, we really are boxed in and 39 bits + 4 bits for aircraft subnets is 
the minimum needed for assignment of a /64 to each aircraft subnet. 
Hence, the need for at least a /21, which ends up as a request for a /16 
when you add in other users and a desire for nibble boundaries.

On 08/11/2020 10:25, [email-masked] wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Philip Homburg <[email-masked]>
Date: Sun, 08 Nov 2020 14:18:17 +0100

> I believe that is a problem worth looking at.  This problem is not
> only restricted to the mobile access case, think connecting a host
> with VMs to a link.

I don't quite understand the problem statement.

We can distinguish inter-site prefix delegation from intra-site prefix
delegation.

For inter-site prefix delegation we have DHCP PD. This is widely supported
on landlines but not on mobile. It seems that it is not supported on mobile
because they never bothered to implement it.

For intra-site prefix delegation we have homenet and as a fallback DHCP PD.
Both options work fine for connecting VMs to a link. DHCP PD within a site
is supported by CPEs but not widely used. Homenet doesn't have a lot of 
traction, but seems to provide a full solution for this problem.

So it seems that the problem statement is that the mobile world doesn't
want to do DHCP PD. 

Of course we can just change every last IPv6 implementation in the world
to support what the mobile world broke. But does that really make sense?

---

From: Philip Homburg <[email-masked]>
Date: Sun, 08 Nov 2020 14:37:11 +0100

> Our problem is that we wanted to define an addressing plan that
> uses 39 bits to identify each aircraft, 

It seems to me that using 39 bits to number aircraft would violation
allocation density policies. See for example Section 2.8 and Section 5.2.2
of ripe-738 (https://www.ripe.net/publications/docs/ripe-738)

(unless there are 100 billion aircraft in the world).

IF the IETF directs IANA to grant this for aircraft, what happens if the
ITU shows up and wants a prefix for phone numbers?

---

From: [email-masked]
Date: Sun, 8 Nov 2020 14:57:11 +0100

Philip,

> I don't quite understand the problem statement.

The problem is from the perspective of an end-user.
What should an end-user do if the only thing available on that link is a /64.

That problem isn't just restricted to mobile operators.
For example if I connect a host with VMs to my employer's network, I cannot extend it. No DHCPv6-PD is supported. Nor HNCP.
This works "perfectly" fine for IPv4.

While I think it's perfectly fine to not accept that this is a problem, and require all network operators be it Enterprise or SPs to support DHCPv6-PD and HNCP.
It might be worth taking a second look at that.

And note that extending the /64 boundary doesn't really solve this. At least not in a very non-hackish way.

Best regards,
Ole

---

From: [email-masked]
Date: Sun, 8 Nov 2020 15:04:42 +0100

Tony,

I intended for this thread to explore if there was interest in exploring other solutions than longer prefixes than /64.
Although also including that one.
Just doing longer prefixes doesn't solve the "permissionless extension" problem either.

Btw, nothing stop you from not supporting SLAAC. You can make your addressing plan any which way you like.

Best regards,
Ole

> On 8 Nov 2020, at 14:00, Tony Whyman <[email-masked]> wrote:
> 
> The problem of the /64 limit came up in ICAO working groups earlier this year when developing a global addressing plan for the ATN/IPS and there would be strong support here for allowing subnet prefixes to go beyond the /64 boundary.
> 
> Our problem is that we wanted to define an addressing plan that uses 39 bits to identify each aircraft, allows for a minimum of 4 more bits for subnetting and works within the existing standards. I'll give some background below for those interested in why 39 bits, but the problem is that if you are going to allocate a /64 (deriving from a /60 MNP) to each subnet on an aircraft then you need a /21 as your initial allocation - and this is before you start thinking about other ATN/IPS users such as drones.
> 
> In order to avoid a potential problem getting a sufficient address allocation, we did look at extending into the "other 64 bits" of an IPv6 address for subnet IDs, which was looking very "unused". After all, you can only cram in a handful of systems into the avionics bay of even the biggest aircraft and, if you extend the addressing scheme into the back cabin, passengers can only bring on so many mobile phones, tablets and laptops in their hand luggage. 64 bits is an overkill for the host identifier and, if only we could have allocated (e.g.) a /96 for each aircraft subnet, then the problem would just go away.
> 
> In the end, we concluded that we could not bend the existing standards to do this and did not have the desire to push for change. Hence, we are in the process of asking IANA for a /16 for the global civil aviation community. Hopefully we will get this. However, an argument is expected given that the current policies push back against such a large allocation and demand a utilisation efficiency that we will never achieve. However, if we don't get a /16 and the standards stay as they are, then a private address space and NAT at the boundaries may be the only answer - not really what anyone wants.
> 
> I would certainly support raising the existing limit. A hard limit of a /96 would seem to be a good idea to stop ISPs going too far. It's probably also worth noting that perhaps one day every home on the planet may require an IPv6 Prefix. That is perhaps over a billion given the world's population. With densely packed address allocation that still requires 30 or so bits. Once you take into account any kind of geographical sub-allocation then you will need a lot more. A /96 would seem to be much easier to live with than a /64.
> 
> Tony Whyman, MWA
> 
> Background
> -----------------
> 
> For operational reasons, the ATN/IPS address allocation should allow for a common prefix for all aircraft operated by the same airline. Network diagnostics and firewall rules are often cited in support of such a requirement. It is also highly desirable that there should be a common prefix for all airline IPv6 Address Prefixes. Again this is to support simple firewall rules. Resisting DoS attacks is extremely important in our environment and these include firewall rules that prevent packets from external sources being sent to aircraft unless authorised, if only to minimise the risk of overloading limited capacity wireless subnetworks. If every airline and ATC Centre has a different address prefix then managing these rules will be an almost impossible task if they all have unrelated prefixes. A common ICAO prefix is thus highly desirable as are common prefixes for each category of address space user.
> 
> It is believed that 15 bits is the minimum necessary to sub-allocate a prefix to each airline registered with ICAO. This leverages an existing registration scheme and allows for a reasonable degree of growth.
> 
> There are also very good reasons for using the existing ICAO 24-bit aircraft identifier as part of an aircraft''s /60 MNP i.e. to sub-allocate each airline's address space to each of their aircraft. For very good safety reasons, ATC Centre Flight Data Processors need to correlate datalink messages (callsigns and 24-bit), surveillance reports (radar and ADS-B - which also use the 24-bit scheme), voice  messages (using callsigns) and Flight Plans. Basically, you don't want to introduce yet another identifier into the mix and the use of overlapping schemes improves confidence in the overall result.
> 
> There is also the small matter of backwards compatibility with the existing ATN/OSI CLNP addressing scheme. This also uses an airline identifier/24-bit approach to address allocation and if we keep to the same address semantics then it becomes feasible to introduce the ATN/IPS with minimum impact on the high certification environment of the Flight Data Processor. Any alternative will cost a lot more and put back deployment for several years.
> 
> So, we really are boxed in and 39 bits + 4 bits for aircraft subnets is the minimum needed for assignment of a /64 to each aircraft subnet. Hence, the need for at least a /21, which ends up as a request for a /16 when you add in other users and a desire for nibble boundaries.
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Nov 2020 01:40:30 +1100

If you're worried about DoS attacks, why are these critical aircraft
systems being attached to the public Internet in the first place?

A aircraft only public /16 might make firewalling easier for you, it's also
a permanent and easy target. DoS attacks can take out firewalls too.

The RFC4193 ULA address space seems like it would be the right address
space for these aircraft critical systems. The ULA address space has been
used in electricity smart meter networks I'm familiar with, and they're
nearly if not as critical.

If you want to provide Internet access on the plane itself, treat that as a
separate non-critical problem and a separate network.

Regards,
Mark.

On Mon, 9 Nov 2020, 00:01 Tony Whyman, <[email-masked]>
wrote:

> > The address delegation to a site problem is intertwined with the
> autonomous networking problem of the site itself. The IETF solution is
> DHCPv6 PD + HNCP. The expectation of addressing of a network is that the
> addresses are long-lived.
> >
> > c) overlay. use e.g. LISP to tunnel across the access ISP to connect to
> an ISP that support multi-homing and larger address space.
> > d) MultiLink Subnet Routing. I.e. let a single /64 span multiple links.
> draft-thubert-6man-ipv6-over-wireless, draft-ietf-ipv6-multilink-subnets
> > e) NAT
> > f) P2P Ethernet. Hosts are not on the same physical link, so let's stop
> pretending they are. A consequence of that is that links don't need
> subnets. Only assign addresses to hosts. draft-troan-6man-p2p-ethernet-00

---

From: Tony Whyman <[email-masked]>
Date: Sun, 8 Nov 2020 15:11:22 +0000

> (unless there are 100 billion aircraft in the world).
I would agree with that point and was why I am doubtful about whether 
the /16 application will be granted. Hence why extending beyond the /64 
boundary looks so attractive.
> ITU shows up and wants a prefix for phone numbers?
If they had a good enough case, why not?

---

From: Philip Homburg <[email-masked]>
Date: Sun, 08 Nov 2020 16:43:00 +0100

> The problem is from the perspective of an end-user.  What should
> an end-user do if the only thing available on that link is a /64.
> 
> That problem isn't just restricted to mobile operators.  For example
> if I connect a host with VMs to my employer's network, I cannot
> extend it. No DHCPv6-PD is supported. Nor HNCP.  This works
> "perfectly" fine for IPv4.
> 
> While I think it's perfectly fine to not accept that this is a
> problem, and require all network operators be it Enterprise or SPs
> to support DHCPv6-PD and HNCP.  It might be worth taking a second
> look at that.
> 

I guess the issue is that with NAT we got used to being able to hide
an entire IPv4 network behind a single address. Of course, that also
works with IPv6, but we don't want to do that.

With IPv6 we are doing a new thing, and the net result is that it is a bit
chaotic:
- relavtively short prefixes are typically distributed using DHCPv6 PD.
  Such a prefix can be split into one or more /64s.
- /64s are used to number subnets and can be split using L2 bridging
- a /64 can also be split into smaller prefixes and then DHCP IA_NA can be
  used on those (though it techincally violates the address architecture)

So what you can do today is allocate addresses within VMs using DHCP IA_NA.

On IPv4 every network runs DHCPv4 because that is what is needed. On IPv6
every network has RA because that is what is needed.

We are now at a stage where DHCPv6 PD is needed, but too many network don't
support is.

I guess replacing one protocol that is not deployed with a future protocol
that also needs to be deployed doesn't make a lot of sense.

In the case of a VM, typically a host is connected to a multi-access network.
So the /64 of the subnet cannot be subdivided by the host. It would require
changes on the router to have a unique /64 per host.

In that case why not implement DHCP PD?

---

From: Ca By <[email-masked]>
Date: Sun, 8 Nov 2020 08:04:53 -0800

> b2) steal multiple /64s from uplink

As discussed on the other thread with Joel, b2 appears to solve the problem
in mobile.

RA sending a < 64 off-link prefix allows the UE to have a number of 64s
effectively delegated to it, for which the UE can assign to down stream
connected interfaces or even further delegate via dhcp-pd

This way, my provider gateway can give /60 via RA to the 5G UE, the UE
acting as a dhcpv6-pd server can pass a /61 to the google wifi PD client.

> c) overlay. use e.g. LISP to tunnel across the access ISP to connect to an
> ISP that support multi-homing and larger address space.

---

From: Tony Whyman <[email-masked]>
Date: Sun, 8 Nov 2020 16:24:52 +0000

> systems being attached to the public Internet in the first place?
My preference is for a closed network and for air gaps between any 
ground systems directly connected to it and systems connected to the 
public internet. However, it is not feasible to demand this. The ATN is 
a global communications network with no centralised control. There will 
be many different participants e.g. Airlines, ATC Centres, Met Sources, 
Airports and so on. All have some degree of access to the public 
internet and we cannot prevent this. A strategy is needed that accepts 
that there will be points of interconnection with the outside world and 
the ATN and that some egress points may have mis-configured firewalls 
that could enable an attacker to inject packets into the ATN. We have to 
have strength in depth to counter this. Typically, firewalls at every 
interconnection point and the firewall rules need to be as simple as 
possible in order to minimise the risk of mis-configuration or using 
out-of-date information.
>
> A aircraft only public /16 might make firewalling easier for you, it's 
> also a permanent and easy target. DoS attacks can take out firewalls too.
Security through obscurity has its uses, but we should not rely on this.
> space for these aircraft critical systems. The ULA address space has 
> been used in electricity smart meter networks I'm familiar with, and 
> they're nearly if not as critical.

You seem to be following the same path that I did when proposing 
alternatives. I tried to propose ULAs earlier this year but got push 
back from those that wanted public internet access for some classes of 
drones. But, if we get blocked by IANA then this is a route we may have 
to go down.

My original point though is that enabling a subnet if > 64 bits is a 
really good idea.

>
> If you want to provide Internet access on the plane itself, treat that 
> as a separate non-critical problem and a separate network.
Are you talking about the back cabin? This is always a separate problem 
to the front cabin where if you are have internet and rely on it then it 
must be a critical problem.
>
> Regards,
> Mark.
>
> On Mon, 9 Nov 2020, 00:01 Tony Whyman, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     uses 39
>     On 08/11/2020 10:25, [email-masked]
>     <mailto:[email-masked]> wrote:
>     > Starting a new thread.
>     >
>     > This problem is not only restricted to the mobile access case,
>     think connecting a host with VMs to a link.
>     >
>     autonomous networking problem of the site itself. The IETF
>     solution is DHCPv6 PD + HNCP. The expectation of addressing of a
>     network is that the addresses are long-lived.
>     >
>     > c) overlay. use e.g. LISP to tunnel across the access ISP to
>     connect to an ISP that support multi-homing and larger address space.
>     > d) MultiLink Subnet Routing. I.e. let a single /64 span multiple
>     links. draft-thubert-6man-ipv6-over-wireless,
>     draft-ietf-ipv6-multilink-subnets
>     > e) NAT
>     > f) P2P Ethernet. Hosts are not on the same physical link, so
>     let's stop pretending they are. A consequence of that is that
>     links don't need subnets. Only assign addresses to hosts.
>     draft-troan-6man-p2p-ethernet-00
>     > g) extend the /64 bit boundary. HNCP implementations do /80s I
>     think (forces DHCP for address assignment)
>     >
>     >
>     > Requirements:
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Nov 2020 11:46:20 -0500

> connecting a host with VMs to a link.

    Gyan> Agreed.  This problem is not restricted to mobile and really
exists for any address allocation use case that involves SLAAC where you
want to segment a /64.  Enterprises have been wanting to do this for
decades to extend their allocation schemes but have been shackled by the 64
bit boundary.

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: [email-masked]
Date: Sun, 8 Nov 2020 18:32:52 +0100

Cameron,

> As discussed on the other thread with Joel, b2 appears to solve the problem in mobile. 
> 
> RA sending a < 64 off-link prefix allows the UE to have a number of 64s effectively delegated to it, for which the UE can assign to down stream connected interfaces or even further delegate via dhcp-pd 
> 
> This way, my provider gateway can give /60 via RA to the 5G UE, the UE acting as a dhcpv6-pd server can pass a /61 to the google wifi PD client. 

Right, although quite a bit of work would be required to make b2 a robust solution.
Not unlikely the end result would be not too dissmilar to DHCP PD. ;-)

I think we all agree that we want to avoid link-specific behaviour. E.g. that an RA and its contents have a different meaning on 3GPP mandated links versus all other datalink types.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 19:41:21 +0100

Ole,

> g) extend the /64 bit boundary. HNCP implementations do /80s I think (forces DHCP for address assignment)

I suggest to add:
h) Variable SLAAC (openbsd and linux implementations)
i) Mobile IP with NEMO extensions.
j) IP encapsulation and a VPN gateway

> R-4: Support bad operational practice: flash renumbering / ephemeral addressing

I would like to suggest a requirement R-5: do not use encapsulation and 
do not use VPN gateways or Home Agent services.  The reason is twofold: 
these rdv points represent additional single points of failure. The 
second reason comes from an observation of current work situation: very 
often in these electronic virtual meetings the involvement of VPN 
gateways induces latencies and breaks audio, or reduces its quality.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 08 Nov 2020 20:23:20 +0100

IANA can't directly allocate to ISPs or end-users, unless the IETF documents a special case, which I don't think is required because it can perfectly follow the existing policies in the relevant RIR.

You need to follow the process with the relevant RIR, according to their existing policies. I understand that in the case of ICAO, it will be ARIN.

Even allocating a /48 to each possible human in the earth, there is not any problem. See slide 6 at:

https://www.ietf.org/proceedings/103/slides/slides-103-v6ops-ipv6-address-assignment-to-end-sites-00

Regards,
Jordi
@jordipalet

El 8/11/20 14:01, "ipv6 en nombre de Tony Whyman" <[email-masked] en nombre de [email-masked]> escribió:

    Tony Whyman, MWA

    Background
    -----------------

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 8 Nov 2020 21:17:45 +0000

Tony Whyman wrote:

>> The RFC4193 ULA address space seems like it would be the right address space for these aircraft critical systems. The ULA address space has been used in electricity smart meter networks I'm familiar with, and they're nearly if not as critical.
>
> You seem to be following the same path that I did when proposing alternatives. I tried to propose ULAs earlier this year but got push back from those that wanted public internet access for some classes of drones. But, if we get blocked by IANA then this is a route we may have to go down.
>
> My original point though is that enabling a subnet if > 64 bits is a really good idea.

And, even with this idea of > 64-bit prefixes, you'd still have to worry whether DHCPv6-PD is scrupulously providing the same 64-bit prefix(es) you need for that given mobile platform, on any modem reboot, from any Internet provder. The flurry of different goals and worries evident, in this thread, and the obvious difficulty in satisfying everyone, and the need to get stuff accomplished in a reasonable length of time, leads me back to some form of NAT. This can solve all problems, without having to ask permission, or wait for blessings.

ULAs inside, some of these firewalled, or even air gapped, as required, and "basic NAT." A short interruption in excomm, or a longer interruption if the platform was given the wrong prefix(es), causes no glitch inside. SLAAC as currently written works fine. Freedom in how the inside networks are configured. No IETF action requested or needed.

Right or wrong, IPv4 and IPv6 are being used in ways the original designers may not have predicted. The NAT approach solves every problem stated in these threads, except for the one more or less religious mantra, that "we don’t want to do that."

Bert

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Nov 2020 08:24:25 +1100

On Mon, 9 Nov 2020, 08:18 Manfredi (US), Albert E, <
[email-masked]> wrote:

> alternatives. I tried to propose ULAs earlier this year but got push back
> from those that wanted public internet access for some classes of drones.
> But, if we get blocked by IANA then this is a route we may have to go down.
> >
> And, even with this idea of > 64-bit prefixes, you'd still have to worry
> whether DHCPv6-PD is scrupulously providing the same 64-bit prefix(es) you
> need for that given mobile platform, on any modem reboot, from any Internet
> provder. The flurry of different goals and worries evident, in this thread,
> and the obvious difficulty in satisfying everyone, and the need to get
> stuff accomplished in a reasonable length of time, leads me back to some
> form of NAT. This can solve all problems, without having to ask permission,
> or wait for blessings.
>
> ULAs inside, some of these firewalled, or even air gapped, as required,
> and "basic NAT." A short interruption in excomm, or a longer interruption
> if the platform was given the wrong prefix(es), causes no glitch inside.
> SLAAC as currently written works fine. Freedom in how the inside networks
> are configured. No IETF action requested or needed.
>
> Right or wrong, IPv4 and IPv6 are being used in ways the original
> designers may not have predicted. The NAT approach solves every problem
> stated in these threads, except for the one more or less religious mantra,
> that "we don’t want to do that."
>

See RFC2993.

See also the 3 part "The Trouble With NAT" articles, using network
operation criteria.

https://blog.apnic.net/author/mark-smith/

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 8 Nov 2020 21:45:27 +0000

From: Mark Smith <[email-masked]> 

> See RFC2993.
>
> See also the 3 part "The Trouble With NAT" articles, using network operation criteria.
>

With IPv6, network prefix translation only (NPT), at the platform's interfaces with the ISPs.

"The fundamental constraint of NAT is that it prevents IP nodes attached to the same network from acting as peers of each other."

How so? I'm saying, these NAT problems, mostly experienced with NAPTs, either won’t happen, or can be managed in a platform with well-managed internal architecture. Is it a problem if state has to be maintained in such NAT (NPT) devices? I'd rather have that, than rely on the fixed ISPs, no? Plus, I'm not even using the NAT to provide some sort of inherent security benefit. Just using it to solve every single problem mentioned in these related threads. End to end connectivity can be retained.

Yes, the NPT boxes have to be managed reliably, but in these scenarios, that's preferable to expecting wither the end systems or the ISPs, to do everything predictably.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Nov 2020 10:50:19 +1300

You need

R-5: Preserve existing security solutions
R-6: Preserve existing privacy solutions
R-7: Preserve e2e transparency

Regards
   Brian

On 08-Nov-20 23:25, [email-masked] wrote:
> .

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Nov 2020 19:28:56 -0500

One of the major benefits of IPv6 is that IPv6 scarcity is non existent of
address space  exhaustion and thus the need for NAT eliminated.

There are still special use cases for security hide NAT to hide internal
space or dual homing.

As IPv4 is limited in registered space the use of RFC1918 and NAT is much
more widespread as compare to IPV6 use of ULA with NAT as the use cases are
far less due to v6 scarcity being non existent.

As we know all the pains of NAT from IPv4 and NAT ALG complexities
learnings and NAT for IPV6 should be an absolute last resort if no other
option is available.  Also DNS NAT complexity it’s best to stay clear of
NAT on CPE.

I would put changing slaac to prefer longer prefixes to be preferred well
over NAT66.

One other point to make is that even if ISPs race  to the bottom
hypothetically which would never happen as IPv6 space will never be
exhausted, but hypothetically we would only this unique situation which
would never happen do Port address translation PAT  /127 outbound interface
overload to extend IPv6 downstream devices.

So by thinking to do NAT now as an optimal best solution is no different
then the race to bottom FUD we are fearful of and are doing exactly that
scenario of NAT66 to extend IPv6 to downstream devices.

We might as well pretend we are at the race to the bottom now and have the
ISP not wait for actual race to bottom  and  give us only a /127 wan IP now
so can desperately use NAT as the optimal solution to extend IPV6 to our
downstream devices.

Gyan

On Sun, Nov 8, 2020 at 4:46 PM Manfredi (US), Albert E <
[email-masked]> wrote:

> "The fundamental constraint of NAT is that it prevents IP nodes attached
> to the same network from acting as peers of each other."
>
> How so? I'm saying, these NAT problems, mostly experienced with NAPTs,
> either won’t happen, or can be managed in a platform with well-managed
> internal architecture. Is it a problem if state has to be maintained in
> such NAT (NPT) devices? I'd rather have that, than rely on the fixed ISPs,
> no? Plus, I'm not even using the NAT to provide some sort of inherent
> security benefit. Just using it to solve every single problem mentioned in
> these related threads. End to end connectivity can be retained.
>
> Yes, the NPT boxes have to be managed reliably, but in these scenarios,
> that's preferable to expecting wither the end systems or the ISPs, to do
> everything predictably.
>
> Bert
-- 

*Gyan Mishra*

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Nov 2020 13:30:29 +1100

> There are still special use cases for security hide NAT to hide internal

RFC4864.

---

From: [email-masked]
Date: Mon, 9 Nov 2020 08:21:33 +0100

Brian,

> R-7: Preserve e2e transparency

Yes. Although I'm a little unsure what you think of regarding R-5?

Cheers,
Ole

---

From: [email-masked]
Date: Mon, 9 Nov 2020 08:26:02 +0100

Gyan,

So far the only technical/relevant to protocols problem I have managed to extract from these discussions is the one I stated starting this thread.

"The problem of an end-user that has been allocated only a /64; how can she extend her network with multiple links".

Do you concur with that?

Best regards,
Ole

> On 9 Nov 2020, at 01:28, Gyan Mishra <[email-masked]> wrote:
> 
> 
> One of the major benefits of IPv6 is that IPv6 scarcity is non existent of address space  exhaustion and thus the need for NAT eliminated.  
> 
> There are still special use cases for security hide NAT to hide internal space or dual homing.  
> 
> As IPv4 is limited in registered space the use of RFC1918 and NAT is much more widespread as compare to IPV6 use of ULA with NAT as the use cases are far less due to v6 scarcity being non existent.
> 
> As we know all the pains of NAT from IPv4 and NAT ALG complexities learnings and NAT for IPV6 should be an absolute last resort if no other option is available.  Also DNS NAT complexity it’s best to stay clear of NAT on CPE.
> 
> I would put changing slaac to prefer longer prefixes to be preferred well over NAT66.  
> 
> One other point to make is that even if ISPs race  to the bottom hypothetically which would never happen as IPv6 space will never be exhausted, but hypothetically we would only this unique situation which would never happen do Port address translation PAT  /127 outbound interface overload to extend IPv6 downstream devices. 
> 
> So by thinking to do NAT now as an optimal best solution is no different then the race to bottom FUD we are fearful of and are doing exactly that scenario of NAT66 to extend IPv6 to downstream devices.
> 
> We might as well pretend we are at the race to the bottom now and have the ISP not wait for actual race to bottom  and  give us only a /127 wan IP now so can desperately use NAT as the optimal solution to extend IPV6 to our downstream devices.
> 
> Gyan 
> 
> On Sun, Nov 8, 2020 at 4:46 PM Manfredi (US), Albert E <[email-masked]> wrote:
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Nov 2020 11:30:45 +0100

>Yes. Although I'm a little unsure what you think of regarding R-5?

One thing to consider, though I don't know how to formulate that as a
requirement is that if we change the lenght of IIDs, does that render all
devices that only support 64 bit IIDs obsolete?

I.e., should we make changes to IPv6 that render all currently conforming
implementations obsolete?

Of course we can create a nice bit of operatial chaos if we make shorter IIDs
an optional feature.

So the requirement should be something to the effect that a change to the
IPv6 standard that affect all hosts requires use cases that cannot be
solved without updating all hosts.

---

From: [email-masked]
Date: Mon, 9 Nov 2020 11:38:42 +0100

Hi Philip,

> solved without updating all hosts.

Right. Take the following solution:

 - there is no subnet prefix / on-link prefix.
 - hosts are assigned single addresses via DHCPv6

The whole concept of interface-id's then become quite abstract.
And you could argue that the concept of interface-id's only exist within the constraints of subnet-prefixes and SLAAC.

Is it a requirement that solutions support SLAAC (or current SLAAC)? I would argue no.

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Nov 2020 12:01:56 +0100

>  - there is no subnet prefix / on-link prefix.  - hosts are assigned
>  single addresses via DHCPv6
> 

Assuming current deployments with shared access links, then in my experience,
a router needs to know the subnet prefix. 

> And you could argue that the concept of interface-id's only exist
> within the constraints of subnet-prefixes and SLAAC.

So I'd argue no, on a shared access link you have, explictly or implictly a
subnet prefix and therefor interface ID's

> Is it a requirement that solutions support SLAAC (or current SLAAC)?

In the past some people have argued quite strongly against single addresses
via DHCPv6. 

The lack of addresses problem associated with IA_NA could be solved with IA_PD.

However, if we say that we solve the problem with some combination of IA_NA
and IA_PD, then we have come full circle and solve problem that comes from a
lack of PD with more PD.

That may still work if the lack of PD is at an administrative boundary and
then within the client network we solve the lack of address problem with
IA_PD and IA_NA.

---

From: [email-masked]
Date: Mon, 9 Nov 2020 12:29:23 +0100

> a router needs to know the subnet prefix. 

It's easier for the purpose of a undigressed thread of logic if you accept the premise. ;-)
It's uncommon that data-links are multi access anymore.
For the purpose of the argument let's assume routing on each port.
Ref: draft-troan-6man-p2p-ethernet-00
Even if you actually had a shared network, you obviously don't need a subnet prefix.
That's equivalent to L=0.

> subnet prefix and therefor interface ID's

But you agree that interface ID's cease to exist if there is no subnet prefix?

> then within the client network we solve the lack of address problem with

DHCP IA or PD is not a solution to general permissionless extensions of a link.
They might be building blocks.

E.g. you could use HNCP to divvy up a /64 into DHCP pools that HNCP assigns to the participating routers.
Where no links has a subnet prefix (apart from fe80::/10 obviously). And hosts gets addresses assigned via DHCP.
Nodes that further wants to extend the network does that by participating in HNCP.

You could imagine doing this with a DHCP "God" box (and relays or discovery) too. Regardless you would need some sort of routing, static or dynamic.

The building blocks are already all there and you can extend a /64 network, without changing or breaking the IPv6 addressing architecture.

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Nov 2020 14:17:57 +0100

> you accept the premise. ;-) 

Indeed :-)

> It's uncommon that data-links are multi
> access anymore.  For the purpose of the argument let's assume
> routing on each port.  

That is nice to assume. Maybe it will become operational reality in 10
years.

> Ref: draft-troan-6man-p2p-ethernet-00 Even
> if you actually had a shared network, you obviously don't need a
> subnet prefix.  That's equivalent to L=0.

L=0 is not enough.

> But you agree that interface ID's cease to exist if there is no

We have 3 interface ID concepts:
1) SLAAC
2) L=1
3) routers forwarding traffic to a subnet

No SLAAC and L=0 means that the first two are gone. To remove the third one
the router should consider the subnet is unnumbered (and will only do ND
for link local addresses). No SLAAC means that all hosts have to do 
some kind of DHCP. Unnumbered subnets mean that all hosts have to do
IA_PD or homenet.

> E.g. you could use HNCP to divvy up a /64 into DHCP pools that HNCP
> assigns to the participating routers.  Where no links has a subnet
> prefix (apart from fe80::/10 obviously). And hosts gets addresses
> assigned via DHCP.  Nodes that further wants to extend the network
> does that by participating in HNCP.

Indeed.

> The building blocks are already all there and you can extend a /64
> network, without changing or breaking the IPv6 addressing architecture.

A literal reading of the address architecture suggests that hosts are on
subnets, and subnets have 64-bit IIDs. 

To get around that, get rid of hosts. A network that consists of routers
only doesn't need subnets.

To get rid of the subnet concept, a router would have to send traffic
to the host's link local address. Conceptually that significantly changes
the semantics. It makes that relays need to maitain persistent state
(or hosts need to be part of routing protocol or hosts need to be able
to find out that soft state has been lost).

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 10:41:32 -0500

On Mon, Nov 9, 2020 at 2:26 AM <[email-masked]> wrote:

> Gyan,
>
> So far the only technical/relevant to protocols problem I have managed to
> extract from these discussions is the one I stated starting this thread.
>
> "The problem of an end-user that has been allocated only a /64; how can
> she extend her network with multiple links".
>
> Do you concur with that?

    Agreed.  The use case could be any use case where you are given a /64
by the service provider and have a requirement to further segment to
multiple downstream devices.

    Here is a second major issue below.

    Please see this thread with subject “ SLAAC, Static & DHCPv6 day 1
interoperability issue”.

 I just responded to Brian Carpenter on the thread.

> > One of the major benefits of IPv6 is that IPv6 scarcity is non existent
> of address space  exhaustion and thus the need for NAT eliminated.
> >
> > As IPv4 is limited in registered space the use of RFC1918 and NAT is
> much more widespread as compare to IPV6 use of ULA with NAT as the use
> cases are far less due to v6 scarcity being non existent.
> >
> > We might as well pretend we are at the race to the bottom now and have
> the ISP not wait for actual race to bottom  and  give us only a /127 wan IP
> now so can desperately use NAT as the optimal solution to extend IPV6 to
> our downstream devices.
> >
> > Gyan
> >

*Gyan Mishra*

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2020 20:45:43 -0500

Tony Whyman <[email-masked]> wrote:
    > to do this and did not have the desire to push for change. Hence, we
    > are in the process of asking IANA for a /16 for the global civil
    > aviation community. Hopefully we will get this. However, an argument is
    > expected given that the current policies push back against such a large

I think that it's pretty important that the IETF IPv6 community understand
your needs, and speak clearly in support of your needs.

What would happen if you had a /18 or a /20?

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2020 20:48:43 -0500

Philip Homburg <[email-masked]> wrote:
    >> Our problem is that we wanted to define an addressing plan that uses
    >> 39 bits to identify each aircraft,

    > allocation density policies. See for example Section 2.8 and Section
    > 5.2.2 of ripe-738 (https://www.ripe.net/publications/docs/ripe-738)

I think that the allocation density policies are not terribly sensible and
still suffer from IPv4 scarcity thinking.
Anyway, the reason they need to skip RIPE/ARIN/etc. and go to IANA is because
of the international aspect of this.

    > (unless there are 100 billion aircraft in the world).

Over the lifetime of the human race's use of IPv6.
(The 100 billion aircraft don't exist concurrently)
And probably not including UAS, because there is a different allocation
request for that coming from the DRIP WG.

    > IF the IETF directs IANA to grant this for aircraft, what happens if
    > the ITU shows up and wants a prefix for phone numbers?

Sounds good for me.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2020 20:51:12 -0500

> systems being attached to the public Internet in the first place?

Because using IPv6 doesn't mean a default route, and it's stupid to have to
build provisioning domains and putting all that crap into every application
is dumb.

Devices *on* the aircraft will talk to the Internet and also talk to the
airframe, and yes, there are plenty for firewalls.

    > they're nearly if not as critical.

I disagree.  This smells of RFC1918 all over again.
They are not auditable.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2020 20:56:02 -0500

JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
    > IANA can't directly allocate to ISPs or end-users, unless the IETF
    > documents a special case, which I don't think is required because it
    > can perfectly follow the existing policies in the relevant RIR.

I believe that this is exactly what Tony is here to do.

    > You need to follow the process with the relevant RIR, according to
    > their existing policies. I understand that in the case of ICAO, it will
    > be ARIN.

I don't believe that ARIN (or any of the RIRs) is allowed to allocate address
space that won't be used in it's region.
So while it might be reasonable for an *airport* to go to it's local RIR, the
rest of the infrastructure moves all over the place.

ICAO essentially needs to be a RIR of sorts.

    > any problem. See slide 6 at:

Sure.  I don't know if ICAO needs a /16 (vs a /18 or /22).
This is something we should debate on the basis of engineering trade offs.
If we won't give people the address space they need, then they will push the
/64 boundary.

(And Ole, sorry to continue off of your intended thread. But, your question
is too big)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2020 21:01:10 -0500

> For inter-site prefix delegation we have DHCP PD. This is widely
    > supported on landlines but not on mobile. It seems that it is not
    > supported on mobile because they never bothered to implement it.

They didn't implement it because for single smartphone "terminals", there was
no implementations, and IPv6 sharing is too new.  But, a smartphone can
easily take it's /64, and pass out pieces on the "WiFi" via RA using onlink=false.
Plus Proxy-ND.
It's doable, although the mess in the stack that this would cause (see
Lorenzo's NetDev talk...) makes me embarassed.

The place where we get into trouble is that LTE is being used for fixed
wireless, and in that case, it's a real Home Router at the other end, and the
operators have no idea how to do things, because they didn't really think
things through.  {I experienced this at my cousin's farm in Alberta}

    > Of course we can just change every last IPv6 implementation in the
    > world to support what the mobile world broke. But does that really make
    > sense?

No.

While Barbara makes good point in another thread about how we whack on
operators a lot: there are an awful lot of really good clueful ones.
They just don't come to the IETF (or NANOG or RIPE or Apricot), I think.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2020 21:09:39 -0500

> b1) steal the uplink /64 (64share)

I don't know this term "64share"
Is there a draft to go with this, or is it just what I wrote in another email?
(onlink=false, plus Proxy-ND)

I wrote draft-richardson-6man-cpe-provisioning in 2019 based upon discussion
earlier.  There are too many TBD.

A few people from 6man had said that they would help, but we were all too
busy, and then pandemic.   I expected to chatting it up at meeting this year
in person.

The concept was that if we can do a capabilities negotiation/announcement
early enough (such as in IP6CP for PPP links), then we can avoid putting the
single /64 on the PPP link, but instead route all of it to the device.

That solves 90% of the smartphone has nothing to share, and probably solves
90% of the fixed LTE mobile use cases.
Yes, any ISP clueful enough to implement this could also implement DHCPv6-PD,
and perhaps that's really the point: it a bit of bait and switch on the clueless.

    > hosts. draft-troan-6man-p2p-ethernet-00

In the WiFi WPA3 world, every device gets their own WEP keys, and they can
never communicate without going through (hairpin) the AP.
So, WiFi now is totally hub and spoke.  There are significant performance
savings if we stop pretending L2 multicast really works.

This is where we should go.
This is a BIG DEAL, even though conceptually it's quite simple.
We need to make sure that we are not pushing string here though.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2020 22:01:38 -0500

> They just don't come to the IETF (or NANOG or RIPE or Apricot), I think.

I missed a not.

It is the bad ones that we need to talk to more, and unfornately, they just
don't come to the IETF (or NANOG or RIPE or Apricot), I think.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2020 06:19:55 +0000

Absolutely!

RFC 8929 when published will describe the operation that the phone could use. The proxy ND operation would be routing proxy.

Since RFC 8505 is not (yet) implemented by the major stacks, we could reverse the model and consider that the phone’s WiFi network is the backbone and the 3GPP link is the wireless access.

Happy to help document this if the group is interested.

Regards,

Pascal

> Le 10 nov. 2020 à 03:02, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Nov 2020 10:57:54 +0100

No, this is wrong ...

All the RIRs allow to have part of the allocation used in other regions. How much depend on each RIR policies.

For example, LACNIC needs 50% used in LAC, but as I recall, for ARIN and RIPE, they don't require how many addresses are being used there, and if that was a problem, with a justified case, it can be changed - it just a matter of a policy proposal.

A policy proposal to allow IANA to allocate directly bypassing the RIR, will need a global policy proposal, maybe also something at the IETF level. This will take much longer and will need consensus in all the 5 RIRs with the same text.

I don't think this effort is justified/needed, because *today* many international organizations are *already* getting (big) blocks even if they are used in many regions.

This "problem" seems to me a non-problem, maybe just lack of understanding about how policies work in all the 5 RIRs.

Regards,
Jordi
@jordipalet

El 10/11/20 2:49, "ipv6 en nombre de Michael Richardson" <[email-masked] en nombre de [email-masked]> escribió:

    Sounds good for me.

---

From: George Michaelson <[email-masked]>
Date: Wed, 11 Nov 2020 11:14:58 +1000

There is a liaison function between the RIR and the IETF, and the IETF
and IANA regarding address dispositions. When people reach a point
they believe there is a need for an unusual assignment from global
unicast space, the proper thing to do, is invoke the liaison function,
and have this dealt with respectfully across distinct process
boundaries regarding how addresses are managed and delegated.

As long as the people who perform this liaison function are aware of
this conversation, nothing much else has to be said here. I would ask
that the WG chairs and AD keep that in mind.

cheers

-George

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Nov 2020 01:51:16 -0500

For this to be idea to come to fruition we need buy in from both 3GPP
architecture to allow  < 64 ra and IETF as well RFC 4291 and 4862.

Cameron

Would 3GPP architecture just have to update their code  to support shorter
prefix RA, or is there anything else technical that has to change on the
3GPP end.

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Nov 2020 02:02:44 -0500

Going this route allowing for shorter prefix <64 but not allowing the >64
due to the race to bottom contentious debate.  This would definitely solve
the issue at hand.

The variable slaac draft solution allows for both longer and shorter
prefixes.  I can update it so it only allows for shorter prefixes so this
draft can progress.

https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/

*Gyan Mishra*

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Nov 2020 14:44:21 -0500

it seems that this whole conversation is really:
  https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05

happening again.

right? :) "I'd like to use all the bits in my address as I see fit for my
purposes"

On Wed, Nov 11, 2020 at 2:03 AM Gyan Mishra <[email-masked]> wrote:

>> Would 3GPP architecture just have to update their code  to support
>> shorter prefix RA, or is there anything else technical that has to change
>> on the 3GPP end.
>>

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Nov 2020 07:05:57 +1100

> right? :) "I'd like to use all the bits in my address as I see fit for my

The same desire could be applied to all fields in a packet. "They're my
packets so I decide what's in them."

That's fine if you only send packets to yourself, and pay all of the
implementation costs.

On the other hand, if you want to interoperate with others, and want to
them to share implementation and deployment costs, then what's in packets
is a shared decision, and the best and simplest compromise to try to suit
as many use cases as possible.

---

From: [email-masked]
Date: Wed, 11 Nov 2020 21:16:52 +0100

> On 11 Nov 2020, at 20:44, Christopher Morrow <[email-masked]> wrote:
> 
> right? :) "I'd like to use all the bits in my address as I see fit for my purposes"

Possibly but you replied to the wrong thread.
This thread is about how exploring the solution space for how to extend a network allocated only a /64, without changing the 64 bit boundary.

You are not the only one hijacking threads, so don't feel bad. ;-)

Ole.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Nov 2020 15:41:23 -0500

> This thread is about how exploring the solution space for how to extend a network allocated only a /64, without changing the 64 bit boundary.

oh! it seemed (to me) like the same problem... Something gets you a
/64, you need to provide a subnet'd experience to the things behind
you.
the upstream doesn't care what you do with the /64, you SHOULD be able
to do what you want with the bits in the lower /64... including
subnetting.

Yes, as mark notes: "and then things like RA and interface-id have to
be sorted out"
yes, they do...

> You are not the only one hijacking threads, so don't feel bad. ;-)

:)
ok! back to other thoughts then :) thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2020 10:23:33 +1300

> right? :) "I'd like to use all the bits in my address as I see fit for my purposes"

Except that it *explicitly* recommends against changing the /64 for SLAAC.

   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Nov 2020 17:04:47 -0500

My last post  - I accidentally posted to the wrong thread - was supposto be
on 64share v2 😃

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Nov 2020 17:45:06 -0500

In summary from all the threads thus far on the original "general variable
slaac draft & problem statement draft" - b1) steal the uplink /64
(64share)  - which steals the wan /64 &  performing a PD like delegation
function using RA for subtending to downstream devices.  So far this is the
leading option.

Initially we did look at longer prefix, but then the contentious debate on
"race to the bottom" - and technical issue with DHCPv6 PD not being
supported on 3GPP gateway to get a shorter prefix -  that the only
workaround to longer prefix is a shorter prefix via "B1" which gets around
the "race to the bottom".

Cameron's 64share v2 enlightenment on the possible solution shorter 64<
prefix idea via RA would require IETF + 3GPP concurrence to spec changes.

Downside in stealing WAN /64 is the ephemeral prefix nature & instability
issue similar to what we have with wired broadband BNG with flash
renumbering.
We are digging in on the v2 thread how to detect failure & signal to the CE
a renumbering event.  Is this really an issue or are we over thinking as
this is a mobile device not fixed.

With existing 64share stealing of the radio /64 has there been any reported
issues in deployment & instability from renumbering events?

For the shorter prefix we would not be able to do a similar trick I don't
think as was done with 64share with single /64 stealing.  Unless it was
multiple /64's sent in PIO to steal - trickery would that be possible RA
PD like delegation.

Has that ever been done before -  using 64share delegating multiple /64s
via RA in PIO with 3GPP?

Multiple /64s trickery would get around changing IETF or 3GPP
specifications.

Kind Regards

Gyan

On Wed, Nov 11, 2020 at 5:04 PM Gyan Mishra <[email-masked]> wrote:

> My last post  - I accidentally posted to the wrong thread - was supposto
> be on 64share v2 😃
>

-- 

*Gyan Mishra*

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Nov 2020 09:22:56 +0100

> Except that it *explicitly* recommends against changing the /64 for SLAAC.

This is the text in the draft.

It recommends against changing whileat the same time it says there is no 
reason to recommend so.  What should a reasonable reader conclude?

draft-bourbaki-6man-classless-ipv6-05:
> 5.  Recommendations
> 
>    For historical reasons, when a prefix is needed on a link, barring
>    other considerations, a /64 is recommended [RFC7136].
> 
>    The length of the Interface Identifier in Stateless Address
>    Autoconfiguration [RFC4862] is a parameter; its length SHOULD be
>    sufficient for effective randomization for privacy reasons.  For
>    example, 48 bits might be sufficient.  But operationally we
>    recommend, barring strong considerations to the contrary, using
>    64-bits for SLAAC in order not to discover bugs where 64 was hard-
>    coded, and to favor portability of devices and operating systems.
> 
>    Note that OpenBSD ships with SLAAC for lengths longer than /64.
> 
>    Nonetheless, there is no reason in theory why an IPv6 node should not
>    operate with different interface identifier lengths on different
>    physical interfaces.  Thus, a correct implementation of SLAAC must in
>    fact allow for any prefix length, with the value being a parameter
>    per interface.  For instance, the Interface Identifier length in the
>    recommended (see [RFC8064]) algorithm for selecting stable interface
>    identifiers [RFC7217] is a parameter, rather than a hard-coded value.
[end of citation from draft.]

Alex

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2020 12:03:07 +0100

>issues in deployment & instability from renumbering events?

In my opinion it would be bad to have a standards track document that
only considers one link type when there are a lot more uses for the defined
functionality. I.e., if we were to define a 'PD' bit, then we need to consider
what would happens on other links. 

I think it would be different if it would be an informational RFC that
defines no additional protocol bits. I.e. a PIO with all flags clear currently
has no semantics.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 12 Nov 2020 13:04:16 +0100 (CET)

> defines no additional protocol bits. I.e. a PIO with all flags clear currently

If we say the link type is "point to point" and that's the only 
definition, it'd be applicable to PPP(oE), GTP, the 
point-to-point-ethernet proposal, possibly some other deployment model 
where it can be guaranteed that there is only a single recipient of 
packets. Other tunnel types also comes to mind.

It isn't hard to imagine other media types being designed with this in 
mind going forward...

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2020 13:16:13 +0100

>It isn't hard to imagine other media types being designed with this in 

In my opinion if we do anything standards track, we have include protocol
elements and requirements that allow a downstream router to verify that the
prefix is still valid. I.e., in my opinion we need to move away from
lifetimes, and link state is a signal but might be an unreliable signal.

So just like ND has NUD to verify that a neighbor is still there, we need
something to verify that prefix is still there. Ideally we can extend that
to SLAAC and DHCP PD and have a model where changes in an upstream link
can propagate downstream realiably.

Real point to point protocols (such as ppp) are in some sense 'easy' in that
you know there is only one other party at the other end. Point-to-point
ethernet is a lot more complex. It would be nice to support point-to-point
ethernet but it might require quite a bit of work to get all corner cases
right.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 12 Nov 2020 13:25:38 +0100 (CET)

On Thu, 12 Nov 2020, Philip Homburg wrote:

> In my opinion if we do anything standards track, we have include 
> protocol elements and requirements that allow a downstream router to 
> verify that the prefix is still valid. I.e., in my opinion we need to 
> move away from lifetimes, and link state is a signal but might be an 
> unreliable signal.
>
> So just like ND has NUD to verify that a neighbor is still there, we 
> need something to verify that prefix is still there. Ideally we can 
> extend that to SLAAC and DHCP PD and have a model where changes in an 
> upstream link can propagate downstream realiably.

If we do PIO-X you can send RS if you're unsure if other end still is 
there. If you get same PIO-X as last time, that's confirmation.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2020 13:29:40 +0100

>there. If you get same PIO-X as last time, that's confirmation.

Yes, we can write for example that a user of a PIO-X SHOULD send an RS
every minute and verify that the received RAs still contain the prefix.

That would be perfectly fine with me.

---

From: [email-masked]
Date: Thu, 12 Nov 2020 13:31:41 +0100

Philip,

> lifetimes, and link state is a signal but might be an unreliable signal.

Agree with regards to lifetimes.
Addressing != Routing.
You shouldn't use a change in reachability to renumber your network.
Imagine what happens if that link flaps once a second.

> can propagate downstream realiably.

The reachability check verifies that the next-hop router has a forwarding entry for our route.
It does not guarantee anything else.
e.g. in a multi-prefix multi-homed network, the host is the only entity that can verify end to end reachability, and it has to do it by probing (with all combinations of SA/DA).
The host stack must treat addresses as candidates, where all have potential different reachability.
Therefore, having stale addresses doesn't so much matter.

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2020 14:08:44 +0100

> Agree with regards to lifetimes.  Addressing != Routing.  You
> shouldn't use a change in reachability to renumber your network.

As a consumer, by and large Addressing = Routing. If I move to a different
ISP, my address(es) will change. If I take my devices from home to work
and back, address will change. If my phone connects to wifi then typically
it drops the mobile connection and addresses change. If I multi-home I 
will have two (or more) set of addresses, each tied to a specific uplink.

So by and large, for a consumer if routing changes, addressing also changes.

I link flags once a second, then there is something wrong with that link.
DAD takes longer than one second. 

I'm not saying that address should change when a link drops and gets
re-established. I'm saying that from a software point of view, if a link
drops, the software has to be prepared to receive new addresses when the
link is re-established.

If take Fernando's example in renumbering, even equipment permanent installed
in a datacenter may see a link getting moved from one vlan to another.

> The reachability check verifies that the next-hop router has a
> forwarding entry for our route.  It does not guarantee anything
> else.  e.g. in a multi-prefix multi-homed network, the host is the
> only entity that can verify end to end reachability, and it has to
> do it by probing (with all combinations of SA/DA).  The host stack
> must treat addresses as candidates, where all have potential
> different reachability.  Therefore, having stale addresses doesn't
> so much matter.

This kind of probing is extremely tricky. The easiest way to do happy eyeballs
is to just set up parallel connections to every possible address. Hosts have
more than enough resources to do that.

This was quickly rejected by content providers who don't want to see the
number of connects double. Instead happy eyeballs tries IPv6 first and only
tries IPv4 after some time. 

For this reason, it is important to weed out broken addresses locally. If
we can't use a shotgun approach to try all addresses at once, then we have
to void trying the ones that don't work anyhow.

---

From: [email-masked]
Date: Thu, 12 Nov 2020 14:17:40 +0100

Philip,

> So by and large, for a consumer if routing changes, addressing also changes.

I think that statement is in the general wrong.

> DAD takes longer than one second. 

DAD isn't triggered on a downstream interface if an upstream interface flaps.
Withdrawing the addresses learnt from the upstream interface from all downstream interfaces would break all sessions.
Even for just a 1s link-flap. Implying that using a reachability event to withdraw addressing is a poor idea.

> drops, the software has to be prepared to receive new addresses when the

I doubt there is a general correlation there.
A host stack needs to be prepared for a new address at any point in time.
And in most cases the host will not even see l2 indications. Although that could be part of the heuristics to detect that the reachability of your current address set is in doubt.

> more than enough resources to do that.

Yes, and that's typically how a more advanced transport layer would work. Ref MP-TCP.

> to void trying the ones that don't work anyhow.

If a host has an address that has no reachability it has no cost to the far end destination that the host tries it. The packet gets dropped quickly anyway.

In the multi-prefix multi-home case you cannot weed out all "broken" addresses.
Some applications also wants to optimize for the best path, and that requires using all available paths and measure. And if you think about the multi-homing problem you will realise that it has overlapping solutions with the renumbering case.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2020 15:06:12 +0100

> DAD isn't triggered on a downstream interface if an upstream
> interface flaps.  Withdrawing the addresses learnt from the upstream
> interface from all downstream interfaces would break all sessions.
> Even for just a 1s link-flap. Implying that using a reachability
> event to withdraw addressing is a poor idea.

To the extent that a link flap is normal, the router can wait with withdrawing
prefixes until the new link is established (or after some timeout).

In just about all contexts a flapping link is considered broken and should
not be used. If local connectivity is desired in the context of a broken 
link then there is ULA. We have enough ULA space that we can use ULA
recursively if desired. 

> Yes, and that's typically how a more advanced transport layer would

That's not clear. If a device simultanously connects over IPv4 and IPv6
using MP-TCP then it might be quite expensive for a content provider to
route both flows to the same endpoint. 

The same applies if a device has addresses from different ISPs. If there
are local caches at the ISPs then it is very unlikely that the two flows
meet.

> If a host has an address that has no reachability it has no cost
> to the far end destination that the host tries it. The packet gets
> dropped quickly anyway.

The cost is time. Applications will wait some time for connection to establish
before moving on to the next address.

The other problem here is API support. There is no practical way for an 
application to iterate over all local addresses. Find out all address is an
operating system specific mess.

But it seems that you saying that Fernando's work on renumbering is a waste
of time because applications should just iterate over all addresses.

> In the multi-prefix multi-home case you cannot weed out all "broken"
> addresses.  Some applications also wants to optimize for the best
> path, and that requires using all available paths and measure. And
> if you think about the multi-homing problem you will realise that
> it has overlapping solutions with the renumbering case.

There is no point for applications to try addresses that can't even reach a 
first hop router. 

By and large we have failed to solve the multi-homing problem. However we can
improve the renumbering problem. What we can do at the network level is
weed out bad addresses that don't work at all.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 15 Nov 2020 06:43:41 -0800

Hi Tony,

I'll disclose that I am affiliated with a RIR.

At 05:00 AM 08-11-2020, Tony Whyman wrote:
>The problem of the /64 limit came up in ICAO working groups earlier 
>this year when developing a global addressing plan for the ATN/IPS 
>and there would be strong support here for allowing subnet prefixes 
>to go beyond the /64 boundary.
>
>39 bits to identify each aircraft, allows for a minimum of 4 more 
>bits for subnetting and works within the existing standards. I'll 
>give some background below for those interested in why 39 bits, but 
>the problem is that if you are going to allocate a /64 (deriving 
>from a /60 MNP) to each subnet on an aircraft then you need a /21 as 
>your initial allocation - and this is before you start thinking 
>about other ATN/IPS users such as drones.
>
>allocation, we did look at extending into the "other 64 bits" of an 
>IPv6 address for subnet IDs, which was looking very "unused". After 
>all, you can only cram in a handful of systems into the

There were proposals to assign a /56 MNP for an aircraft.  That 
"drone" user looks like something different from an aircraft for 
address assignment purposes.

The procedure for global allocation registration is listed at 
http://r.elandsys.com/r/51238

Regards,
S. Moonesamy

---

From: Tony Whyman <[email-masked]>
Date: Sun, 15 Nov 2020 19:20:18 +0000

We originally allocated 8 bits for subnetting - hence a /56. That got squeezed down to 4 (and a /60) in order to meet all user requirements while avoiding asking for an impossibly short prefix.Tony Whyman, MWA
-------- Original message --------From: S Moonesamy <[email-masked]> Date: 15/11/2020  14:53  (GMT+00:00) To: Tony Whyman <[email-masked]>, [email-masked] Subject: Re: Extending a /64 Hi Tony,I'll disclose that I am affiliated with a RIR.At 05:00 AM 08-11-2020, Tony Whyman wrote:>The problem of the /64 limit came up in ICAO working groups earlier >this year when developing a global addressing plan for the ATN/IPS >and there would be strong support here for allowing subnet prefixes >to go beyond the /64 boundary.>>Our problem is that we wanted to define an addressing plan that uses >39 bits to identify each aircraft, allows for a minimum of 4 more >bits for subnetting and works within the existing standards. I'll >give some background below for those interested in why 39 bits, but >the problem is that if you are going to allocate a /64 (deriving >from a /60 MNP) to each subnet on an aircraft then you need a /21 as >your initial allocation - and this is before you start thinking >about other ATN/IPS users such as drones.>>In order to avoid a potential problem getting a sufficient address >allocation, we did look at extending into the "other 64 bits" of an >IPv6 address for subnet IDs, which was looking very "unused". After >all, you can only cram in a handful of systems into theThere were proposals to assign a /56 MNP for an aircraft.  That "drone" user looks like something different from an aircraft for address assignment purposes.The procedure for global allocation registration is listed at http://r.elandsys.com/r/51238Regards,S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Nov 2020 08:50:14 +1300

What's "impossibly short"?

Again, there are 35 trillion /48s in 2000::/3. How many would you need?

Regards
   Brian

On 16-Nov-20 08:20, Tony Whyman wrote:
> We originally allocated 8 bits for subnetting - hence a /56. That got squeezed down to 4 (and a /60) in order to meet all user requirements while avoiding asking for an impossibly short prefix.
> 
> Tony Whyman, MWA
> 
> -------- Original message --------
> From: S Moonesamy <[email-masked]>
> Date: 15/11/2020 14:53 (GMT+00:00)
> To: Tony Whyman <[email-masked]>, [email-masked]
> Subject: Re: Extending a /64
> 
> Hi Tony,
>

---

From: Philip Homburg <[email-masked]>
Date: Sun, 15 Nov 2020 21:18:25 +0100

> Again, there are 35 trillion /48s in 2000::/3. How many would you

It gets tight when you want the prefix to contain 39 bits to number around
half a million planes.

---

From: Mark Smith <[email-masked]>
Date: Mon, 16 Nov 2020 07:55:42 +1100

> It gets tight when you want the prefix to contain 39 bits to number around

Why are half a million planes going to be on the Internet?

Supposedly only some drones needed (really?) to be on the Internet. How did
that turn into every plane?

Can somebody post a link to the draft that tries to justify this idea?

Has a security threat model been done?

>From what I've read here, there seems to be a belief that if the network
firewall checkbox is ticked, all security threats have been addressed.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Nov 2020 10:15:23 +1300

> It gets tight when you want the prefix to contain 39 bits to number around

I don't understand that statement at all. Why would such a constraint exist?
If there is such a constraint, that sounds like a design error of some kind.
(2^39-1 is 536,870,911, so there's some leeway anyway.)

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 15 Nov 2020 21:18:45 +0000

> Why are half a million planes going to be on the Internet?

Flipping this around, why would we think that most or all planes in the 
next 50 years would be off-grid?

/39 is seems very little for an entire sector of human enterprise. Why 
wouldn't we allocate more?  Or at least create an allocation that had 
plenty of room for expansion.

Nick

---

From: Mark Smith <[email-masked]>
Date: Mon, 16 Nov 2020 08:26:22 +1100

> next 50 years would be off-grid?

Because they can fall out of the sky and 100s of people can die.

Just because you can do something doesn't mean you should.

This risk isn't taken with electricity smart meter networks, they use ULAs.

> plenty of room for expansion.

Why do all planes have to come from a single prefix. A single prefix makes
an easy DoS target.

The right DoS may take out all planes at once.

DoSs have already reached multiple terabits. Diversity if targets, rather
than a single one, such as a single prefix, is a useful mitigation.

2.3 Tbps:

 https://www.thesslstore.com/blog/largest-ddos-attack-in-history/

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 15 Nov 2020 21:31:40 +0000

Mark Smith wrote on 15/11/2020 21:26:
> Why do all planes have to come from a single prefix.

GUAs are assigned from 2000::/3. Does this concentrate the attack 
profile on a specific address range?

It seems likely that the airline industry is capable of handling their 
security requirements without the IETF jumping in and telling them how 
to run things.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Sun, 15 Nov 2020 22:32:29 +0100

>plenty of room for expansion.

Not a /39. It seems that there is an existing 39-bit identifier for planes.
Somebody has decided that it would be a good idea to include that into the
prefix.

So if you want to give each plane a /56 then you need a /17 prefix.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 15 Nov 2020 16:44:30 -0500

Hi Jordi

>From the end allocation model standpoint as standard procedure is for ISPs
to go to RIR for their allocations and not directly to IANA.

https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

Typically the ISP generic allocation size has been a /32 but that is pretty
small as it yields only 64k /48s.

What is the typical allocation size to ISPs?

I was  trying to find?

My guess is for most RIRs the standard is /24 per ISP and /32 for large
enterprises.

A /24 would yield 11.7 million /48s which is way low for ISPs for /48 per
human

The allocation for ISPs has to be at least /22 or /20 for really large ISPs
to do a /48 per human.

https://www.ripe.net/publications/docs/ripe-699

What are the chances that in the future additional blocks will free up by
IANA to RIR so that the large ISPs can be more like a /16 which would give
4.2 billon /48s per ISP.

The caveat is if you go down to /16 that only gives 13 bits in total down
to /3 split up between the RIRs so not feasible now until IANA releases
more blocks.

I think what would make sense is a /3 per RIR and then each ISP could get a
/16 in theory but even then 13 bits is pretty small as it definitely won’t
cover all the ISPs in a region.

I am trying to wrap up “race to bottom” slide for v6ops presentation this
week.

Thanks

Gyan

On Sun, Nov 8, 2020 at 2:23 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> documents a special case, which I don't think is required because it can
> perfectly follow the existing policies in the relevant RIR.
>
> You need to follow the process with the relevant RIR, according to their
> existing policies. I understand that in the case of ICAO, it will be ARIN.
>
> El 8/11/20 14:01, "ipv6 en nombre de Tony Whyman" <[email-masked]
> en nombre de [email-masked]> escribió:
>
> this
> 39
> IPv6
> are
>     > c) overlay. use e.g. LISP to tunnel across the access ISP to connect
> to an ISP that support multi-homing and larger address space.
>     > f) P2P Ethernet. Hosts are not on the same physical link, so let's
> stop pretending they are. A consequence of that is that links don't need
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
-- 

*Gyan Mishra*

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Nov 2020 10:49:39 +1300

> Somebody has decided that it would be a good idea to include that into the

Sigh. Somebody who has no idea how Internet routing works, apparently.

> So if you want to give each plane a /56 then you need a /17 prefix.

No, you need to learn how Internet routing works.

     Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 15 Nov 2020 17:03:19 -0500

> Why are half a million planes going to be on the Internet?

No, not "Internet"
"internet" --- as in, uses IPv6.
How and if it connects to the DFZ is not really any of our business.

Because thinking that you can put ALG gateways and NATs and other crap in the
way to keep stuff off the internet is IPv4 think.

If our answer to requests for IPv6 address space involves IPv4-style
justification, then we might as well give up and go for triple-NATed CGN.

Now, I don't understand how 39bits are needed to number log_2(10^6) = 20bits
of airplane.  It seems to leave more than 16-bits for subnets on each
airplane, which is still a lot.

Remember that it might be 2^19 concurrent airplanes, but the address plan
would be expected to last a hundred years or so.

    > that turn into every plane?

Because every plane has electronics that speak IPv6.

    > Has a security threat model been done?

Who cares?  Firewalls work regardless of what address space is used.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 15 Nov 2020 23:29:52 +0100

>would be expected to last a hundred years or so.

Assuming 16 billion people in the year 2100, then a 39 bit number for planes
has space for 34 planes for each person alive.

Maybe that is overdoing it a bit. Or if we have that number of planes, maybe
a single prefix is a bit silly.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Nov 2020 11:43:36 +1300

> a single prefix is a bit silly.

It's more than that. It's just wrong and doesn't match how Internet WAN routing works.

We might as well admit that 3GPP/5G gets worldwide mobile connectivity right and the Internet doesn't.

We should also remember that experience has taught us that embedding unique IDs in addresses is a very bad idea, even in the Interface Identifier, let alone in the routing prefix. Those 19 bits have no business in a prefix, ever.

   Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 15 Nov 2020 23:49:17 +0100

It depends on what you justify.

In all the RIRs it is need based justification.

The first think to understand is the difference between and ISP and end-user from the perspective of the RIRs. An ISP get an allocation so they can “assign” to customers. While end-users (corporations, universities, etc.), only get an assignment and can’t sub-assign to others (others in the sense of different organizations, even not sub-organizations).

Typically, every site, for end-users will get from the RIR an assignment for a /48. A corporation with multiple sites, will get n*/48.

Most of the RIRs start for ISPs, allocating /32.

In the case of RIPE NCC, ISPs, can request an allocation of /29 instead of /32 for each LIR account (a single company can justify multiple LIR accounts).

In all the RIRs, beside what I’ve summarized above, if you justify a need for more, you get it, no trouble.

For example, if an ISP has 5.000.000 subscribers, and they make an addressing plan for /48 to each subscriber, they will get the prefix that can hold all those. In this case it will be probably a /25.

I think there are some cases in EU, of bit ISPs with /19, or /20.

There are several European governments that got also /24-/26 or so.

The /48 is not per-human, it is per site. I did “per-human” in the rfc6177-bis slides, just to set an example of how big is the IPv6 space.

There is a global policy for covering the release of /12 for each RIR that is close to exhaust their existing pools. That’s the reason, if I recall correctly, why RIPE NCC and ARIN already got a 2nd /12. So, this is not a problem at all, never mind an ISP needs a /12, /16 or whatever, if it is justified according to the policies (which is really easy). If an ISP needs a /11 and it is justified, I believe the RIR will get 2 extra /12 from IANA for covering that.

If we want to change that (the way IANA provides the /12 to the ISPs), it needs a global policy, which means the same “text” need to be approved by the community of all the 5 RIRs. Originally, instead of /12, it was /23, and we changed that once the IPv6 commercial deployment started.

Both IANA and the RIRs do sparce allocation, so if you got a /12 and need another one, actually you just get one extra bit, not a new prefix. For an ISP that got a /28 (for example), instead of a new prefix (if it justifies the need to grow the actual prefix), will get one extra bit, so it will be the same prefix, but /27.

Regards,

Jordi

@jordipalet

El 15/11/20 22:44, "Gyan Mishra" <[email-masked]> escribió:

Hi Jordi 

>From the end allocation model standpoint as standard procedure is for ISPs to go to RIR for their allocations and not directly to IANA.

Typically the ISP generic allocation size has been a /32 but that is pretty small as it yields only 64k /48s.

I was  trying to find?

My guess is for most RIRs the standard is /24 per ISP and /32 for large enterprises. 

A /24 would yield 11.7 million /48s which is way low for ISPs for /48 per human 

The allocation for ISPs has to be at least /22 or /20 for really large ISPs to do a /48 per human.

What are the chances that in the future additional blocks will free up by IANA to RIR so that the large ISPs can be more like a /16 which would give 4.2 billon /48s per ISP.  

The caveat is if you go down to /16 that only gives 13 bits in total down to /3 split up between the RIRs so not feasible now until IANA releases more blocks.

I think what would make sense is a /3 per RIR and then each ISP could get a /16 in theory but even then 13 bits is pretty small as it definitely won’t cover all the ISPs in a region.  

I am trying to wrap up “race to bottom” slide for v6ops presentation this week.

Thanks 

Gyan

On Sun, Nov 8, 2020 at 2:23 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Regards,
Jordi
@jordipalet

    Tony Whyman, MWA

    Background
    -----------------

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 15 Nov 2020 23:12:17 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter

That's a little bit apples and oranges. You expect many, many more addressable devices, not to mention routers and subnets, on any large platform, than you would on a "person." I don't think it's logical to associate address space with number of people. Not directly, anyway. (Maybe eventually, when we all have hundreds on embedded medical sensors in our bodies, people and platforms will be more similar?)

Amen.

> We might as well admit that 3GPP/5G gets worldwide mobile connectivity right and the Internet doesn't.

Amen to that too. Although it doesn't go far enough, right? We're hauling along intranets now, not just one /64.

Also, I work with ships rather than planes. I can guarantee that a single ship would not be happy with one /60, if we are to assume that IIDs are 64 bits wide. Not even close, and this has next to nothing to do with how many souls are on board.

It's also not clear why a single platform should be fed off a single prefix. In fact, different onboard nets are administered by different organizations, so that the normal case would be, each organization assigns its own prefixen.

In practice, I'd say, we should not assume that excomm and interior communications would be managed the same way. In fact, they are not.

Bert

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 15 Nov 2020 18:28:53 -0500

Hi Jordi,

This is really helpful for the "race to the bottom" slide I am putting
together.

This really helps run the numbers of maximum number of /48 subscribers
possible given the RIR allocation

For the massive block allocations for ISPs is it tiered like this
/32 - General Starting point for ISP allocation
/24-26 - Medium to Large
/19-20 - Exceptions and rare

Since allocations are done block wize and not linearly you have to account
for future growth so generally over allocate for growth next 20 years.  So
with that the much larger allocations.

With that being said let's say for a typical large ISP /24 - that would
yield 16M /48s.  That still is small since most large ISPs like, we Verizon
we want to scale to a billion as right now we have 150M and that's just
domestic not worldwide.  Safe best for large ISPs is we want to scale to
the number of humans on the planet so 7 Billion is a good number.  Also
that does not account for broadband.  So for Verizon as an example /48  per
human is not possible.

I think /48 per user site is sensible for the much smaller ISPS with few
million subscriber base  but I think an impossibility at least for the
larger Verizon size ISP's.

Looking on IAIA allocation link I don't see too many RIRs getting a /12

2400:0000::/12 APNIC 2006-10-03 whois.apnic.net https://rdap.apnic.net/
ALLOCATED 2400:0000::/19 was allocated on 2005-05-20. 2400:2000::/19 was
allocated on 2005-07-08. 2400:4000::/21 was allocated on 2005-08-08.
2404:0000::/23 was allocated on 2006-01-19. The more recent allocation
(2006-10-03) incorporates all these previous allocations.
2600:0000::/12 ARIN 2006-10-03 whois.arin.net https://rdap.arin.net/registry
http://rdap.arin.net/registry ALLOCATED 2600:0000::/22, 2604:0000::/22,
2608:0000::/22 and 260c:0000::/22 were allocated on 2005-04-19. The more
recent allocation (2006-10-03) incorporates all these previous allocations.

2630:0000::/12 ARIN 2019-11-06 whois.arin.net https://rdap.arin.net/registry
http://rdap.arin.net/registry ALLOCATED
2800:0000::/12 LACNIC 2006-10-03 whois.lacnic.net
https://rdap.lacnic.net/rdap/ ALLOCATED 2800:0000::/23 was allocated on
2005-11-17. The more recent allocation (2006-10-03) incorporates the
previous allocation.
2a00:0000::/12 RIPE NCC 2006-10-03 whois.ripe.net https://rdap.db.ripe.net/
ALLOCATED 2a00:0000::/21 was originally allocated on 2005-04-19.
2a01:0000::/23 was allocated on 2005-07-14. 2a01:0000::/16 (incorporating
the 2a01:0000::/23) was allocated on 2005-12-15. The more recent allocation
(2006-10-03) incorporates these previous allocations.
2a10:0000::/12 RIPE NCC 2019-06-05 whois.ripe.net https://rdap.db.ripe.net/
ALLOCATED
2c00:0000::/12 AFRINIC 2006-10-03 whois.afrinic.net
https://rdap.afrinic.net/rdap/
http://rdap.afrinic.net/rdap/ ALLOCATED

Thanks

Gyan

On Sun, Nov 15, 2020 at 5:50 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> The first think to understand is the difference between and ISP and
> end-user from the perspective of the RIRs. An ISP get an allocation so they
> can “assign” to customers. While end-users (corporations, universities,
> etc.), only get an assignment and can’t sub-assign to others (others in the
> sense of different organizations, even not sub-organizations).
>
>
>
> Typically, every site, for end-users will get from the RIR an assignment
> for a /48. A corporation with multiple sites, will get n*/48.
>
>
>
> In the case of RIPE NCC, ISPs, can request an allocation of /29 instead of
> /32 for each LIR account (a single company can justify multiple LIR
> accounts).
>
>
>
> For example, if an ISP has 5.000.000 subscribers, and they make an
> addressing plan for /48 to each subscriber, they will get the prefix that
> can hold all those. In this case it will be probably a /25.
>
>
>
> The /48 is not per-human, it is per site. I did “per-human” in the
> rfc6177-bis slides, just to set an example of how big is the IPv6 space.
>
>
>
> There is a global policy for covering the release of /12 for each RIR that
> is close to exhaust their existing pools. That’s the reason, if I recall
> correctly, why RIPE NCC and ARIN already got a 2nd /12. So, this is not a
> problem at all, never mind an ISP needs a /12, /16 or whatever, if it is
> justified according to the policies (which is really easy). If an ISP needs
> a /11 and it is justified, I believe the RIR will get 2 extra /12 from IANA
> for covering that.
>
>
>
> If we want to change that (the way IANA provides the /12 to the ISPs), it
> needs a global policy, which means the same “text” need to be approved by
> the community of all the 5 RIRs. Originally, instead of /12, it was /23,
> and we changed that once the IPv6 commercial deployment started.
>
>
>
> Both IANA and the RIRs do sparce allocation, so if you got a /12 and need
> another one, actually you just get one extra bit, not a new prefix. For an
> ISP that got a /28 (for example), instead of a new prefix (if it justifies
> the need to grow the actual prefix), will get one extra bit, so it will be
> the same prefix, but /27.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> I think what would make sense is a /3 per RIR and then each ISP could get
> a /16 in theory but even then 13 bits is pretty small as it definitely
> won’t cover all the ISPs in a region.
>
>
>
> *Network Solutions Architect *
>
>
>

-- 

*Gyan Mishra*

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2020 00:58:49 +0100

>That still is small since most large ISPs like, we Verizon
>the number of humans on the planet so 7 Billion is a good number.  

This is subject to RIR policies. I.e., does a RIR accept expenential growth
over 20 years as a basis for an allocation request. Does an RIR want to
allocate space for 7 billion connections when an ISP now has 150 million
customers.

The five RIRs together form the NRO. In theory, they could reach out to the
IETF if address space policies don't fit in the space allocated.

Or we could look at the rate at which IANA allocates /12s to RIRs. See for
example https://www.nro.net/wp-content/uploads/NRO-Statistics-2020-Q2-FINAL.pdf
for the current state.

The current trent is that 2000::/3 is big enough that we can provide endusers
with /48s for a very long time. From an allocation point of view, there 
doesn't seem to be any reason to move the 64-bit boundary.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 16 Nov 2020 00:01:31 +0000

> Somebody has decided that it would be a good idea to include that into the

sigh, helps to read previous messages more thoroughly.  Thank you for 
correcting this.

> So if you want to give each plane a /56 then you need a /17 prefix.

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.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2020 01:11:58 +0100

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

---

From: Tony Whyman <[email-masked]>
Date: Mon, 16 Nov 2020 10:04:33 +0000

> connections is not a lot. In most parts of the world that would be a smallish
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

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2020 12:05:05 +0100

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

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

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

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 16 Nov 2020 11:06:03 +0000

> interconnected (e.g. military) and ULAs could cause addressing issues at 

second / third party interconnection arrangements provide reasonable 
justification for global address space. The only other relevant question 
is the size of any allocation.

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

It may be difficult to argue this point, given the precedent that any 
existing ipv4 space is delegated from internic / the rirs.

Nick

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 16 Nov 2020 12:36:48 +0100

[Jordi] This is incorrect. All the RIR policies are, on purpose, "ignorant" if you use the resources in the public Internet or non-public internets. If you justify that you have a need for a non-public /16, you get it.

[Jordi] Similarly, RIR policies don't ask you to have an addressing plan tied to topology, geography or anything similar. You can justify your needs depending on your own case. Same for many other of your points.

    7. We are boxed in

[Jordi] I understand that this is technical issue and because we have sufficient space, it should be possible to justify it to the relevant RIR and get a /16, or a /11 or whatever you need. There is no issue at all.

[Jordi] I don't understand the legal reasons for that. What court will tell you that it is right? IETF is responsible of the standards, and has given the mandate to IANA for allocating the space to the RIRs. IANA can't do that unless the IETF allows that, and/or there is a global policy that allows that.

   However, I
   suspect that would make it legally impossible for IANA to unilaterally
   revoke the /16 allocation. 

[Jordi] What court will have power on that?

    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.

[Jordi] This is incorrect, I've explained it already in previous emails, maybe you didn't saw them. Any of the RIRs can easily allocate the space never mind it is a /16 or a /11. You just need to justify the need. Have you tried it?

[Jordi] It is true that some RIRs, such LACNIC and AFRINIC, require that the space is used in their region (LACNIC ask for more than 50%), however, others not, and any international/multinational organization may request an allocation for example in RIPE NCC. Again, have you tried that? If you need help, I can put you in touch with the relevant people.

---

From: Simon Hobson <[email-masked]>
Date: Mon, 16 Nov 2020 13:57:09 +0000

> an existing sparce identifier onto a densse space may not carry much weight in

I think there's a piece of the puzzle you are not aware of, and to help, I'll recount an enlightening moment for me from a few years ago.

I used to own a share in a small (4 seats) aircraft. This was on the UK registry, but had in the past been on the US registry. While generally browsing around, found that it's entry in the US registry had an identifier allocated to it - which I thought strange given that it had been moved to the UK long before these were implemented. There was "a bit of discussion" on a mailing list - because I was thinking along the lines of "why not have dense allocation and lookup tables". But I was thinking only of air-ground communication and systems that would be able to do live lookups from some database - probably a hierarchical system like DNS is. And like you, I was thinking about this from an IT person's PoV.

Back then, these new fangled digital systems like TCAS were fairly new - and in part it was these that drove the requirement for every aircraft to have a globally unique digital identifier. These systems use digital identifiers, while pilots use callsigns or aircraft registry numbers. Furthermore, they need to be able to operate in the absence of external communications.
So there are two approaches.
One is to do dense allocation, and require EVERY device in the world to carry an up to date copy of the mapping - in it's entirety. Think about that for a moment - a table that lists the electronic ID and registry entry for EVERY aircraft in the world, and kept fully up to date. Some may remember when the internet was small enough to use a hosts file rather than DNS - and as I recall, that was abandoned as unworkable long before the number of hosts was even in the same ballpark as the number of aircraft in the world.
The other method, and the one that was chosen, is for each state to use an algorithm to map between IDs and registry names. Thus each item of equipment just needs a number of algorithms and a lookup table between state identifier and algorithm. The required updates should be few and far between.

And so, this is why when I looked up my aircraft in the US registry, it had one of these identifiers - even though it had never used, and probably would never use, it.

But, I can imagine you thinking, these aircraft have big avionics bays, satellite comms, etc, etc - so what's the problem with keeping tables up to date or even doing live lookups. Well that's the big bit of the jigsaw puzzle you've probably overlooked - those "big aircraft" are but a tiny proportion of the world's aircraft. There are orders of magnitude more aircraft where if it doesn't fit in the panel in front of the pilot, then it isn't getting fitted. And probably a similar number that have no electrical system, or only a small battery powered system - the norm with gliders where there's probably just a single radio and a vario, all run off a small battery.
And it's not unusual to be operating these smaller aircraft outside of radio coverage - so no communications with the ground - and from sites with no infrastructure (such as grass field with a shed at one side). And don't forget that balloons are also aircraft - no electrical system in the wicker basket !

But any air traffic control/management system has to be able to work with all of these aircraft - otherwise it doesn't work. As it is, there are still projects going on to work out how to get basic radio conspicuity devices into smaller aircraft - both from a cost PoV (it can cost a significant proportion of the value of an airframe to do an avionics upgrade) and a power/weight* PoV.
* Weight is always an issue. The four seater I had a share in could not carry 4 people and full fuel, and in fact it could struggle for weight and balance with just two people my size - every bit of weight you add in electronics is a bit of weight you've taken off the payload. Some aircraft, if you fully load them, start to resemble an aviation joke about needing a very long runway and just waiting for the earth to curve away from under it on take-off :D

So you have a situation where airborne equipment is severely restricted in size/weight/power consumption, and must be capable of operating air-air without ground communications being possible. So it makes sense to use the technique outlines above for mapping between human usable registry ID and electronic ID.
IMO, it also makes sense to utilise the same ID in an IPv6 world of air-air and air-ground communications. That way, you avoid having to build a completely new and duplicate system, and for the reasons outlined, you cannot use a system that requires real-time lookups or the carriage of static lookup tables.

And that is why, contrary to your suggestion, it makes absolutely no sense whatsoever to make a different choice.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Nov 2020 09:10:47 -0500

Sure, I expect there to be a global digital ID for every aircraft.  And 
every Drone.  And ...

But why should that be embedded in the IPv6 address prefix assigned to 
the airplane.  Coupling identity with location is a major problem.  Why 
make it worse?

Yours,
Joel

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2020 15:30:13 +0100

> Well that's the big bit of the jigsaw puzzle you've probabl
>y overlooked - those "big aircraft" are but a tiny proportion of the world's air
>craft. There are orders of magnitude more aircraft where if it doesn't fit in th
>e panel in front of the pilot, then it isn't getting fitted. And probably a simi
>lar number that have no electrical system, or only a small battery powered syste
>m - the norm with gliders where there's probably just a single radio and a vario
>, all run off a small battery.
>And it's not unusual to be operating these smaller aircraft outside of radio cov
>erage - so no communications with the ground - and from sites with no infrastruc
>ture (such as grass field with a shed at one side). And don't forget that balloo
>ns are also aircraft - no electrical system in the wicker basket !

We talking about a table that has 500k entries. It is hard to imagine how
tiny the silicon is that is needed to store such a table. Same thing for
power requirements. By the time you have a device that can talk IPv6 over
radio, you have the space and energy budget to store such a table.

However, this seems to be a case of doing things at the wrong level. If aircaft
use IPv6 to communicate then obvious they need unique IPv6 addresses. However,
each plane only needs to know its own address. Any time a plane communicates
with an unknown plane, they can exchange higher level identities.

So, before take off, a pilot can install an up-to-date list of all aircraft. Even
if you would use technology of 20 years ago, that would take only a tiny amount
of space.

However, in any sensible protocol, aircaft would only need to know the mapping
for their own registration number at take off and then learn about other planes
during the flight. So the table would be installed/updated when the aircrafts
identity is installed/updated.

I don't understand your remark about balloons. If balloons have no electrical
systems, how do they run IPv6? 

In any case, if you would need a complete table, then that would get updated
before take off. For example, you put an up-to-date table on a phone, connect
the phone to the communications module in the plane and transfer the table.

---

From: Tony Whyman <[email-masked]>
Date: Mon, 16 Nov 2020 14:38:40 +0000

This discussion seems to have gone off in the wrong direction. There are 
no ICAO applications that foresee aircraft to aircraft communication 
using datalink. The underlying set of applications is:

1. Controller to Pilot Datalink Communication (CPDLC) - the name says it all

2. Automatic Dependent Surveillance (ADS) - allows an ATS Provider to 
monitor an aircraft's position and intent.

3. Flight Information Services (FIS) - allows a pilot to pull 
information (e.g. on runway conditions).

TCAS also exists as a collision avoidance system and this does use 
air-to-air communication. However, this is a rider on the Mode S 
surveillance radar and is not IP based.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Nov 2020 09:50:01 -0500

Tony, why are you embedding the 39 bit airplane ID into the IPv6 
address.  That seems to be the fundamental thing that then has you need 
very short prefixes, and doing other difficult operations.

And if the answer is "ICAO said so", then we have a problem of really 
smart aviation engineers doing network engineering.

Yours,
Joel

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Nov 2020 15:55:07 +0100

Le 16/11/2020 à 15:38, Tony Whyman a écrit :
> using datalink.

Eh?  Maybe with LDACS? draft-ietf-raw-ldacs-05 "5.2.2.  Air-to-Air 
Extension for LDACS"

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Nov 2020 15:57:29 +0100

> smart aviation engineers doing network engineering.

I suspect one would not oppose embedding a 39bit airplane ID into an ULA 
prefix, at which point the arguments about id/loc split might not 
disallow airplane ID into GUA either.  Because routing towards ULA and 
GUA addresses happen in the same way.

Alex

>> This discussion seems to have gone off in the wrong direction. There 
>> are no ICAO applications that foresee aircraft to aircraft 
>> communication using datalink. The underlying set of applications is:
>>

---

From: "Da Silva, Saulo" <[email-masked]>
Date: Mon, 16 Nov 2020 15:05:04 +0000

Tony.
The evolution of the aviation system towards increasing capacity and acess of what we call new entrants (drones, high level operations, supersonic acft, etc) through strategic and tactical self separation do need air-to-air comm. The concept of management by trajectory instead of isolated clearances do need air-to-air. The aviation industry is working towards that direction.

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Tony Whyman
Sent: 16-Nov-20 9:39 AM
To: [email-masked]
Subject: Re: Extending a /64

This discussion seems to have gone off in the wrong direction. There are no ICAO applications that foresee aircraft to aircraft communication using datalink. The underlying set of applications is:

2. Automatic Dependent Surveillance (ADS) - allows an ATS Provider to monitor an aircraft's position and intent.

3. Flight Information Services (FIS) - allows a pilot to pull information (e.g. on runway conditions).

TCAS also exists as a collision avoidance system and this does use air-to-air communication. However, this is a rider on the Mode S surveillance radar and is not IP based.

On 16/11/2020 14:30, Philip Homburg wrote:
> However, this seems to be a case of doing things at the wrong level. 
> If aircaft use IPv6 to communicate then obvious they need unique IPv6 
> addresses. However, each plane only needs to know its own address. Any 
> time a plane communicates with an unknown plane, they can exchange higher level identities.

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

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2020 16:16:10 +0100

> I suspect one would not oppose embedding a 39bit airplane ID into
> an ULA prefix, at which point the arguments about id/loc split
> might not disallow airplane ID into GUA either.  Because routing
> towards ULA and GUA addresses happen in the same way.

Using ULA with an airplane ID is technically a violation of RFC 4193,
Section 3.2.1:
"Locally assigned Global IDs MUST be generated with a pseudo-random
"algorithm consistent with [RANDOM].

(In theory there is also ULA-C, but that doesn't allow it either)

---

From: Tony Whyman <[email-masked]>
Date: Mon, 16 Nov 2020 15:26:36 +0000

On 16/11/2020 14:50, Joel M. Halpern wrote:
> address.  That seems to be the fundamental thing that then has you 
> need very short prefixes, and doing other difficult operations.
>

Perhaps the best way to answer this question is to look at the alternative.

Aircraft MNPs are non-topological and hence could be densely allocated. 
However, if you want to go the distance and specify the minimum length 
identifier then:

1. You need to set up a new registration database for aircraft (in order 
to assign the new identifier) and one that is global rather than state 
based - which is the present approach.

2. You need to update the specification for the Aircraft Personality 
Module and organise the fleet wide upgrade necessary to ensure that 
every affected aircraft gets a new ICAO global Aircraft Identifier.

3. Safety Authorities will now identify a new hazard potentially 
resulting from a mis-match between the existing ICAO 24-bit identifier 
(which still has to be used for radar, ADS-B, TCAS, etc.), and the new 
airframe identifier.

4. We need to develop procedures and systems for mitigating the new 
hazard, assuming it is deemed serious enough.

5. The protocol gateways that are planned to avoid having to upgrade the 
existing ATC Systems in the same timeframe would now have to include a 
lookup table between the "old" NSAP Addresses and the "new" IPv6 Addresses.

6. The Safety Authority would identify a new hazard resulting from a 
table configuration/maintenance error and procedures/mitigations would 
be needed to counter the threat.

7. The address mapping would have to extend to the application protocols.

In other words - a lot of negatives each with a potentially large cost 
attached to them.

The next step is to accept that it is worth "wasting" a few more bits 
and using the existing ICAO 24-bit aircraft identifier instead of some 
new global aircraft identifier. This avoids issues 1 to 4 above.

In order to avoid 5, 6  and 7, we need to have a simple algorithm to 
convert between aircraft ATN/OSI NSAP Addresses and ATN/IPS IPv6 
Addresses. The existing (legacy) NSAP Address format for aircraft 
addresses starts off with some constant prefix and is then followed by 
an airline identifier, the ICAO 24-bit identifier, an 8 bit subnet id 
and a 48-bit End System id (it follows a structure originally proposed 
by NIST). The last two can be readily combined into a 64-bit host 
identifier. Indeed, if we based the MNP on the ICAO 24-bit then the only 
thing stopping a simple algorithm is the missing airline identifier part 
- this cannot be readily predicted from the ICAO 24-bit identifier 
without access to the registration database.

In order to avoid a lookup table in the protocol gateway, etc. we need 
to have an airline identifier in the MNP. 15 bits appears to be the 
minimum we can get away with (in order to avoid a new airline 
identifier, the proposal is to generate a 15-bit identifier by encoding 
the existing ICAO three character airline identifier using ITA-2 letter 
shift). Hence 24 +15 = 39.

The industry's network providers also regard embedding an airline 
identifier in the MNP as highly desirable. It is used in the existing  
system for diagnostic purposes and firewalls.

This is not an "ICAO says so" at all. This is practical engineering to 
deliver a new system as an evolution from an existing system and with 
limited budgets. Start with a clean sheet of paper and you could use a 
lot less that 39 bits. Unfortunately, we do not have that luxury.

Tony

---

From: Tony Whyman <[email-masked]>
Date: Mon, 16 Nov 2020 15:37:21 +0000

On 16/11/2020 14:55, Alexandre Petrescu wrote:
>> communication using datalink.
>

Quoting from the internet draft

"Direct A2A communication between aircrafts in terms of ad-hoc data
    networks is currently considered a research topic since there is no
    immediate operational need for it, although several possible use
    cases are discussed (digital voice, wake vortex warnings, and
    trajectory negotiation) [BEL2019].  It SHOULD also be noted that
   currently deployed analog VHF voice radios support direct voice
    communication between aircraft, making a similar use case for digital
    voice plausible.

    LDACS direct A2A is currently not part of standardization."

The key phrases are "research topic" and "not part of standardization".

My understanding is that this extension is for line of sight 
communication and no internet functionality is required. You are also 
looking at applications that are naturally multicast. For example, 
existing analogue voice is broadcast and A2A LDACS voice would need to 
be similar in characteristic.

>>> If aircaft

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Nov 2020 16:42:36 +0100

> "algorithm consistent with [RANDOM].

'pseudo-random'...

But I meant this text from RFC4193 ULAs:
>    This document defines a specific local method to allocate Global IDs,
>    indicated by setting the L bit to 1.  Another method, indicated by
>    clearing the L bit, may be defined later.
> [end of partial citation from RFC]

> (In theory there is also ULA-C, but that doesn't allow it either)

I dont know what is ULA-C... and why does it disallow airplane ID in a 
prefix.

Whereas I fully agree IPv6 addresses must be allocated by a central 
authority, I disagree with over specifying even the ULA contents.  I 
thought one was free to do whatever one wanted in ULA space.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 16 Nov 2020 09:43:43 -0600

Folks,

> It gets tight when you want the prefix to contain 39 bits to number around

I think concerns like this are behind all recent efforts to increase the
prefix size even larger than 64.
It seems such concerns are superfluous and maybe  design error like Brian
said.

Good luck 6man.

Behcet

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2020 16:47:19 +0100

> (which still has to be used for radar, ADS-B, TCAS, etc.), and the
> new airframe identifier.
> 
> 4. We need to develop procedures and systems for mitigating the
> new hazard, assuming it is deemed serious enough.
> 
> 5. The protocol gateways that are planned to avoid having to upgrade
> the existing ATC Systems in the same timeframe would now have to
> include a lookup table between the "old" NSAP Addresses and the
> "new" IPv6 Addresses.
> 
> 6. The Safety Authority would identify a new hazard resulting from
> a table configuration/maintenance error and procedures/mitigations
> would be needed to counter the threat.

I find it fascinating that telco's can associate phone numbers with IMSIs for
billions of phones. Governments can associate license plates with VINs for
millions of cars, but somehow the aviation industry cannot associate IPv6
addresses with existing aircraft identifiers.

An IPv6 address is a locator, not an identifier. Using IPv6 addresses as stable
identifiers or embedding stable identifiers in IPv6 addresses is an abuse of 
the protocol. 

Basically, go back to the drawing board and don't do any of those two things.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Nov 2020 10:53:54 -0500

Tony you have given a very good answer as to why the identifer is 39 
bits instead of something smaller.

That is not what I was trying to ask.
Why is the airplane identifier embedded in the IPv6 address at all. 
That is not the purpose of an IPv6 address.  It is not the name of the 
thing.

Yours,
Joel

---

From: Tony Whyman <[email-masked]>
Date: Mon, 16 Nov 2020 15:55:27 +0000

I take your point - but these considerations are not (to my knowledge) 
in the scope of the work being undertaken by Working Group I. You are 
looking here a future concepts and these should be all limited to line 
of sight.

Currently, any air-to-air routing is out of scope. If you want to bring 
air-to-air routing in scope then we need to discuss.

Tony

---

From: Tony Whyman <[email-masked]>
Date: Mon, 16 Nov 2020 16:16:01 +0000

> That is not the purpose of an IPv6 address.  It is not the name of the 

I suppose the response is what else would be used? An MNP is always 
going to be some prefix followed by a unique identifier for the aircraft 
- so why not use an existing identifier rather than make up a new one? 
As I said in an earlier post, any strategy that relies on dynamic 
assignment (e.g. using DHCPv6 PD), even when the MNP is assigned on a 
very long lease,  carries with it a potential new hazard and it seems to 
make sense to design that out.

If you want to go back to first principles then a name is an object 
identifier devoid of location, while an address is a name that can be 
used as a parameter to some algorithm that can allow you to locate the 
named object. Hence, I have no problem using a name as part of an 
address when the result is an efficient and reliable way to meet the 
requirement.

Tony

>>> And if the answer is "ICAO said so", then we have a problem of 
>>> really smart aviation engineers doing network engineering.
>>>
>>> Yours,
>>> Joel
>>
>> Aircraft MNPs are non-topological and hence could be densely 
>> allocated. However, if you want to go the distance and specify the 
>> minimum length identifier then:
>>
>> 1. You need to set up a new registration database for aircraft (in 
>> order to assign the new identifier) and one that is global rather 
>> than state based - which is the present approach.
>>
>> resulting from a mis-match between the existing ICAO 24-bit 
>> identifier (which still has to be used for radar, ADS-B, TCAS, etc.), 
>> and the new airframe identifier.
>>
>> include a lookup table between the "old" NSAP Addresses and the "new" 
>> IPv6 Addresses.
>>
>> table configuration/maintenance error and procedures/mitigations 
>> In other words - a lot of negatives each with a potentially large 
>> cost attached to them.
>>
>> and using the existing ICAO 24-bit aircraft identifier instead of 
>> some new global aircraft identifier. This avoids issues 1 to 4 above.
>>
>> addresses starts off with some constant prefix and is then followed 
>> by an airline identifier, the ICAO 24-bit identifier, an 8 bit subnet 
>> id and a 48-bit End System id (it follows a structure originally 
>> proposed by NIST). The last two can be readily combined into a 64-bit 
>> host identifier. Indeed, if we based the MNP on the ICAO 24-bit then 
>> the only thing stopping a simple algorithm is the missing airline 
>> identifier part - this cannot be readily predicted from the ICAO 
>> 24-bit identifier without access to the registration database.
>>
>> In order to avoid a lookup table in the protocol gateway, etc. we 
>> need to have an airline identifier in the MNP. 15 bits appears to be 
>> the minimum we can get away with (in order to avoid a new airline 
>> identifier, the proposal is to generate a 15-bit identifier by 
>> encoding the existing ICAO three character airline identifier using 
>> ITA-2 letter shift). Hence 24 +15 = 39.
>>
>> This is not an "ICAO says so" at all. This is practical engineering 
>> to deliver a new system as an evolution from an existing system and 
>> with limited budgets. Start with a clean sheet of paper and you could 
>> use a lot less that 39 bits. Unfortunately, we do not have that luxury.
>>
>> Tony
>

---

From: Tony Whyman <[email-masked]>
Date: Mon, 16 Nov 2020 16:32:55 +0000

> addresses with existing aircraft identifiers.

Perhaps the point that you are missing is that you have identified 
examples where there is a central administrator managing a database. On 
the other hand, there is no central administrator for civil aviation, it 
is all devolved to individual states.

In principle as well as technically, it would be possible to aggregate 
all the databases - although the example of "herding cats" does come to 
mind. But you have to ask the question: is it worth it?

In many ways, an MNP is a name and the mobility routing problem is to 
first register a care-of address for that name and then to provide a 
means of looking up the (care-of) address for a given MNP (name).

This is also not the only example of an IPv6 Address being used as an 
identifier rather than a locator. For example, the type 4 SRH using IPv6 
Addresses as policy identifiers.

---

From: "Da Silva, Saulo" <[email-masked]>
Date: Mon, 16 Nov 2020 16:35:16 +0000

You are right.
This is not WG-I discussions. But it is under discussion in other groups of experts.

-----Original Message-----
From: Tony Whyman [mailto:[email-masked]] 
Sent: 16-Nov-20 10:55 AM
To: Da Silva, Saulo <[email-masked]>; [email-masked]
Subject: Re: Extending a /64

I take your point - but these considerations are not (to my knowledge) in the scope of the work being undertaken by Working Group I. You are looking here a future concepts and these should be all limited to line of sight.

Currently, any air-to-air routing is out of scope. If you want to bring air-to-air routing in scope then we need to discuss.

Tony

On 16/11/2020 15:05, Da Silva, Saulo wrote:
>> addresses. However, each plane only needs to know its own address. 
>> Any time a plane communicates with an unknown plane, they can exchange higher level identities.
> Administrative Requests: 
> https://secure-web.cisco.com/1Ttb6AZE6VAf8slZg6Up2Wbc-yRRw1bRFNxq3xFe0
> rvxo57JW3EORgd4Y26YVF1A3xJsGZYRey0b4EIYy8ftofcyCu7BKkGwioWSLWoCYbTzIMk
> nfOy-InoUgJYGfaqD7b1PlyjfOs8ZkaaScuic6BjfH5hTsbJpBV2VmzoNDG6f7CoPZtjQq
> wXQ19FQu3evxWz0PTffaVTwtvvzpf9p9kkX8LX_mM4wx3g_jmYCK195bx7bKPQ0K0yoQzr
> ihSnUSf7IQpTyfWp1zyNnknt4KbOeHobj8oxycxJAY6QC3ckVxhuUM85Vly6EtrO37uaUL
> /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2020 17:58:45 +0100

>mind. But you have to ask the question: is it worth it?

I don't see why individual countries would want to maintain the mapping 
to IPv6 addresses. In theory one of the RIR communities could just
ask the RIR to do that for the entire world.

Even if it needs to be per country, just allocate a separate prefix to each
country and have a slightly bigger list of prefixes to filter in firewalls.
It is not as if firewalls would care about a couple of hundred prefixes.

>Addresses as policy identifiers.

And if you read the discussion regarding this, then there are quite a number
of operators who don't see the point of using IPv6 addresses for that purpose.

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Nov 2020 06:17:00 +1100

> "internet" --- as in, uses IPv6.

Asking for GUA space implies attached to the big-I Internet when the ULA
space exists for non-Internet connected devices.

If a single /48 ULA isn't big enough, generate more.

It is when GUAs are being requested, and the RFC4291 address format is
being ignored. It's not IPv6 and can't be called "IPv6" if it doesn't
comply with the IPv6 specifications.

GUAs have two properties:

- globally unique address
- provide potential global reachability to any and all global Internet
destinations

ULAs only have the first property.

If a device doesn't need the second property, the device doesn't need a GUA.

The security principle of least privilege demands that devices aren't given
the second property when they don't need it.

> way to keep stuff off the internet is IPv4 think.

A management platform or system that controls and aggregates data from ULA
addressed devices is perfectly compliant with the IPv6 architecture,
because the management system is built with hosts. No NAT, no ALGs, the
transport connections are end host to end host within the distinct network.

Outside access to that would be via multi-homing one or more of the hosts
in the management system. Specifically, forwarding between the hosts'
interfaces is not enabled. The multihomed host(s) are relaying data between
these two networks at the application layer and as part of the application
architecture.

This is how the IPv6 smart meter network I've seen works - and actually,
were IPv6 only on the meter side, and only IPv4 on the outside.

The reason NATs and ALGs cause problems is they're not proper and distinct
RFC8200 hosts or routers. They're a mutant half way between - do more than
dumb packet forwarding (routing), but don't properly do all of what the
host and application processing does. They "half" participate in the end to
end protocols.

If you can't or don't want to for security reasons provide direct host to
host connectivity within a single network, you partition the network into
two with a multihomed host or hosts and have an application architecture
that suits that. Anything less than that i.e. NATs or ALGs, doesn't comply
with the device roles in RFC8200, and suffers from the well known problems
caused by "more than routers, but not full hosts".

Regards,
Mark.

> Who cares?  Firewalls work regardless of what address space is used.

I

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Nov 2020 06:24:57 +1100

> Addresses as policy identifiers.

Be wary of using SRH as an example of what to do. SIDs don't comply with
RFC4291, which very explicitly says that unicast IPv6 addresses are
interface identifiers.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Nov 2020 09:20:57 +1300

On 17-Nov-20 04:26, Tony Whyman wrote:
> Aircraft MNPs are non-topological 

Thank you for that clear statement. Internet routing *is* topological.
Therefore, you cannot use bits in the routing prefix for non-topological
information. Therefore, you cannot put 39 magic bits into the routing
prefix; the Internet doesn't work like that. End of story. Back to the
drawing board.

This is so badly conceived that I suggest an IETF liaison statement to
ICAO may be needed.

There's nothing to stop you putting those 39 bits into the Interface
Identifier of the aircraft's IPv6 addresses. That would need a slightly
different version of RFC7217, but would still allow 25 entropy bits.

However, you should be aware that IP addresses are intrinsically
forgeable. I'm not sure I would want to fly on an aircraft whose
identity might be trivially forged. Also, it would be trivial for
an attacker to observe that a particular address belongs to a
particular aircraft.

One more comment below...

> and hence could be densely allocated. 
> Addresses. 

Are you aware that we already "solved" that in 1996 (https://tools.ietf.org/html/rfc1888), and scrapped it in 2005?

Regards
   Brian

> The existing (legacy) NSAP Address format for aircraft

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 16 Nov 2020 20:43:01 +0000

Brian,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Monday, November 16, 2020 12:21 PM
> To: Tony Whyman <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Why this is broken [was Re: Extending a /64]
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> 
> 

This actually works; the routing system is described here:

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/

The MNPs do not need to be topologically-fixed, because the nodes are
mobile at all times and frequently change their topological attachments.
True, the MNPs are non-aggregateable but that just means there will be
one prefix per mobile node represented in the BGP routing system, and
we have shown how BGP can handle lots of MNPs as long as the amount
of churn can be minimized.

> This is so badly conceived that I suggest an IETF liaison statement to

We have  a liaison statement that could be expanded on if necessary.
But, I don't see the problem since we already have this working well.

> an attacker to observe that a particular address belongs to a

The ATN/IPS will be a secured network with no connections to the Internet
and open only to authorized users. An enterprise network for civil aviation,
if you will. Unauthorized users will not have access to the network, and even
for authorized users the multi-layered security services will ensure secured
communications.

Fred

---

From: Matthew Petach <[email-masked]>
Date: Mon, 16 Nov 2020 12:58:05 -0800

> Brian,

[...]

> for authorized users the multi-layered security services will ensure

If it is truly an isolated network, with no connections to the Internet,
can't you define your addressing within it as freely as you want?
Surely you don't need IETF approval to do strange and unusual
addressing schemes within your own internal networks that never
connect to the rest of the Internet.  Lord knows I never asked the
IETF for approval before performing unusual acts of discontiguous
addressing within my lab networks.   ;)

If it really is completely isolated and can never connect to the
wider Internet, you can define your addressing and your
protocols in any way you like; and in fact, making them
not entirely compatible with the rest of the Internet may
help ensure there's no accidental leakage, by making the
two schemes dissimilar enough that they can't cross-communicate
accidentally.

Matt

---

From: Tony Whyman <[email-masked]>
Date: Mon, 16 Nov 2020 23:17:24 +0000

> This is so badly conceived that I suggest an IETF liaison statement to

The basic problem of mobility is that a mobile node must keep the same 
IP Address while it moves its location in an internet. In the ATN, we 
complicate this by making our mobile node a mobile platform with one or 
more onboard subnets, and require that an aircraft can make concurrent 
use of multiple air/ground subnetworks. We can assign an MNP to each 
aircraft, but that cannot be a locator in the normal sense in that it 
does not relate to anything around it at any given time.

In the ATN/OSI, we did try to make the equivalent aircraft address 
prefix routeable by using IDRP as the routing protocol and declaring 
each aircraft to be a routing domain. At least this allowed routes to 
the aircraft to be advertised throughout the ground internet. However, 
this led to obvious scaleability problems (there are mitigation 
strategies but this post is not about them). The distributed routing 
also made it difficult to communicate the very different routing 
policies that the ATC Providers required.

This approach did lead to the semantic equivalent of our "39 magic bits" 
being a routeable address prefix, and there was a limited form of 
aggregation possible from the fact that there was a common airline 
prefix to the aircraft MNP.

In the ATN/IPS we first have a legacy problem - for reasons I keep 
explaining - which make it very difficult to define an MNP that does not 
include an airline identifier and the ICAO 24 bit identifier. However, 
that does not stop us wanting to overcome the scaleability issues and 
routing policy issues that we have with the legacy system.

We are considering various mobility management systems but, in the end, 
they all come back to the same ideas.

1. There is a routable care-of address assigned to each aircraft 
interface to an air/ground subnetwork.

2. The mobility routing problem for routing to an MNP relative IP 
Address is to determine the care-of address of the aircraft interface 
that best matches the routing policy requirements.

3. Forward the packet to the care-of address using normal internet routing.

Here, the MNP is being used as a "name" and the mobility routing problem 
is solved by looking up the care-of address associated with the MNP 
(name). Once the packet gets to the aircraft then the destination 
address becomes a routeable address, etc.

It's not as if this approach is that novel. In LISP, for example, a 
destination IP address (an EID) is used to lookup a corresponding RLOC 
IP address and the packet is then encapsulated and forwarded to the 
RLOC. Once there, the EID is routeable.

So, I really don't see why you are so worked up about the 
identifier/locator duality in an MNP. There is nothing that magic about 
the 39 bits. They are just a unique identifier for the aircraft. Perhaps 
it is because they contain redundant information that you find this 
offensive - but that is primarily a legacy problem which we cannot 
easily walk away from.

Constructive contributions are always welcome and if you want to send a 
liaison statement to ICAO then it should be addressed to the secretary 
of the Communications Panel and for the attention of Working Group I. If 
you want access to the working papers then the usual protocol is to go 
through your national CAA.

> different version of RFC7217, but would still allow 25 entropy bits.
Possible, but what do you gain? You still need a unique MNP for each 
aircraft. Also, we need the full 64-bits to map to the remaining parts 
of the legacy NSAP Address.
> an attacker to observe that a particular address belongs to a
True, which is why we have end-to-end authentication, authenticated 
logins and continuous peer entity authentication  over each air/ground 
subnetwork, and a trust model under which all routing and MNP/care-of 
address bindings are exchanged on the ground. Personally, I am not a fan 
of "security through obscurity" and prefer to use strong encryption instead.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 16 Nov 2020 23:21:57 +0000

From: ipv6 <[email-masked]> On Behalf Of Mark Smith

> A management platform or system that controls and aggregates data from ULA addressed devices is perfectly compliant with the IPv6 architecture, because the management system is built with hosts. No NAT, no ALGs, the transport connections are end host to end host within the distinct network.
>
> Outside access to that would be via multi-homing one or more of the hosts in the management system. Specifically, forwarding between the hosts' interfaces is not enabled. The multihomed host(s) are relaying data between these two networks **at the application layer and as part of the application architecture**.
>
> This is how the IPv6 smart meter network I've seen works - and actually, were IPv6 only on the meter side, and only IPv4 on the outside.

Indeed. This is a practical approach, and it separates and reduces the mobility problem, to many fewer nodes. With no reason to assume that the mobility aspect must use statically assigned IP addresses, with semantics which trivially identify the platform. Plus, no problem with having to redefine address architectures, or anything else.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Nov 2020 13:45:05 +1300

Tony,

Thanks for the explanations.

I'm not disputing that you can make practically anything work in a private 
network. As I heard the late Dave Sincoskie say in an IAB discussion of the
Internet as it was in about 1994, "just buy an ****ing big CAM and you can
make anything work." Nor am I disputing that aircraft present an especially
hard case of mobility. (Isn't that why cell phones are mainly forbidden
on planes?)

But at Internet scale, we just can't do that. Routing prefixes need
to aggregate. This isn't an aesthetic consideration; it's fundamental
to why we have enough IPv6 prefixes to last for hundreds of years,
and why the backbone routers are able to keep up with growth.

If the first step is using the well-known IPv6 address to map to
a c/o address for mobility, why does the non-topological identfier
need to be in the prefix? The natural place for non-topological
bits in IPv6 is in the Interface Identifier.

Regards
   Brian Carpenter

---

From: David Farmer <[email-masked]>
Date: Mon, 16 Nov 2020 20:55:02 -0600

> 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:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Nov 2020 16:39:36 +1300

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

On 17-Nov-20 15:55, David Farmer wrote:
> 
> On Sun, Nov 15, 2020 at 2:56 PM Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     On Mon, 16 Nov 2020, 07:19 Philip Homburg, <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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:[email-masked] <mailto:[email-masked]>

---

From: Tony Whyman <[email-masked]>
Date: Tue, 17 Nov 2020 09:26:38 +0000

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

---

From: Tony Whyman <[email-masked]>
Date: Tue, 17 Nov 2020 09:44:23 +0000

On 17/11/2020 02:55, David Farmer wrote:
> ou 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. 

I should probably make it clear that irrespective of whatever addressing 
plan we come up with - this will never happen. There is strength in 
depth in the system.

1. There are application level checksums that bind the aircraft identity 
and flight identity to the message and these would have to fail before 
any mis-addressed message even made it into the cockpit. Address 
conflicts should always result in lost messages rather than 
mis-delivered messages. The safety case already assumes that some 
messages will be lost and includes procedures to recover the situation 
using voice communication.

2, An instruction that was received by the wrong aircraft would have to 
make sense to the pilot in their current context if they were to action 
it without query.

3. There are automatic surveillance systems on the ground that are 
constantly monitoring aircraft movements and trying to predict any 
possible collisions or near misses - and these are in addition to Air 
Traffic Controllers themselves constantly monitoring each aircraft. 
Aircraft are instructed to take evasive action in the event of any 
possible conflict.

4. Aircraft are equipped with TCAS. This is an autonomous system that 
alerts pilots to the proximity of other aircraft and advises each pilot 
on the correct course of action to avoid any possible collision.

---

From: Tony Whyman <[email-masked]>
Date: Tue, 17 Nov 2020 10:07:46 +0000

> hard case of mobility. (Isn't that why cell phones are mainly forbidden

I believe that there are two problems that cause problems with cell 
phones and aircraft. One is that older aircraft can have poorly screened 
radios and headphones used for ATC voice comm (AM double side band in 
the VHF spectrum) with a risk that the cell phones can interfere with 
voice communication. The other is that when you are up in the air, you 
can see an awful lot of "cells" on the ground and an aircraft full of 
active mobile phones can overload each of those "cells" simultaneously.

Assuming that the first problem is solved, a pico cell on board the 
aircraft should keep down the transmission power of the active phones. 
SATCOM can provide you with the backhaul service for the pico cell. Cell 
phones are a simpler problem if only because they are not deemed to be 
flight critical.

> and why the backbone routers are able to keep up with growth.
In another post, I have given a worked example and hopefully explained 
that our MNPs are allocated from a /36 that does comply with this model. 
Our only argument is really over the allocation of the remaining MNP 
bits. This will always be a non-topological identifier given then nature 
of a mobile platform.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Nov 2020 12:39:05 +0100

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

This a clear example of a bad addressing plan. If you have 5000 airlines and
the biggest has 1300 aircraft then you don't give all tiny airlines the 
same amount of space you need for the biggest.

---

From: Tony Whyman <[email-masked]>
Date: Tue, 17 Nov 2020 15:02:40 +0000

> same amount of space you need for the biggest.
It's only a "bad addressing plan" if your sole success criteria is dense 
allocation. IPv6 should have liberated us from such a narrow success 
criteria. The success criteria that I am invoking include cost of 
administration and legacy support.

I also do not see the point in having a different (shorter) prefix 
length for aircraft in smaller airlines compared with those in larger 
airlines.

If you are arguing for dense allocation as a general rule then this 
should apply to the whole /64 prefix. I assume that you are demanding 
that ISPs allocate a /64 to all their users unless they can make the 
case for multiple subnets and, even then, are parsimonious in their 
attitude and push back hard against any user that wants more than a /60, 
demanding proof that they have more than 256 subnets.

---

From: David Farmer <[email-masked]>
Date: Tue, 17 Nov 2020 09:48:43 -0600

> plan we come up with - this will never happen. There is strength in

I don't actually think something as simple as an address conflict would
ever be the primary cause of an aircraft incident. However, it is not that
difficult to conceive of situations where such an address conflict, causing
a communication failure, could be a contributory cause to an incident. If
you combined a communications outage with multiple other human or systems
failures it is difficult to exclude the possibility of such an issue being
a contributory cause of an incident. So, it would seem inappropriate to
have an addressing scheme like ULA were the possibility, however small, of
an address conflict is part of normal operation.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Nov 2020 16:55:01 +0100

>administration and legacy support.

'should have' is an interesting concept. We can't really go back in time.

Technically we can just do a complete overhaul of the IPv6 addressing 
architecture. But I doubt that people who now have existing IPv6 networks and
products would be interested in that. Changing a widely adopted
architecture also has a huge cost.

>length for aircraft in smaller airlines compared with those in larger 

Well, ISPs with few customers have a longer prefix than those with many
customers. I guess you propose that we should have taken the shortest
prefix needed for the largest ISP in the world, and then give the same
prefix to every last tiny ISP as well?

>demanding proof that they have more than 256 subnets.

You can make that argument, but is not part of the design of IPv6. The
design of IPv6 is the endusers should always have enough space to number
their networks.

---

From: Tony Whyman <[email-masked]>
Date: Tue, 17 Nov 2020 17:19:32 +0000

On 17/11/2020 15:48, David Farmer wrote:
>
>
> On Tue, Nov 17, 2020 at 3:44 AM Tony Whyman 
> <[email-masked] 
> I don't actually think something as simple as an address conflict 
> would ever be the primary cause of an aircraft incident. However, it 
> is not that difficult to conceive of situations where such an address 
> conflict, causing a communication failure, could be a contributory 
> cause to an incident. If you combined a communications outage with 
> multiple other human or systems failures it is difficult to exclude 
> the possibility of such an issue being a contributory cause of an 
> incident. So, it would seem inappropriate to have an addressing scheme 
> like ULA were the possibility, however small, of an address conflict 
> is part of normal operation.
>
>
David,

This is an interesting subject and covered at length in the Safety and 
Performance Requirements (SPR) for ATN Baseline 2. This is a joint 
RTCA/Eurocae document (ref DO-350A/ED228A). The SPR is intended to be a 
complete hazard analysis for all the ATS Applications in order to 
identify the Safety Objectives and to allocate them to various 
functions. All Safety Objectives have to be satisfied in order to gain 
Safety Approval for operational use.

The Safety Objective for the Network itself is expressed as an 
availability requirement and a confidence level to which it must be 
shown that the availability requirement is met. The end-to-end 
availability requirement for the current generation of ATS Applications 
is that in high density airspace (lots of aircraft) there has to be a 
99.9% probability that a message is delivered to its intended recipient 
and the response returned, without loss of integrity and within the 
required transaction time and per Flight Hour.

Using the wrong network address will result in mis-delivery, a discarded 
packet and is one of the many possible reasons that can result in a 
failure to meet the availability requirement.

The confidence level at present is required to be appropriate for what 
is known as a Severity Class 4 hazard. This is defined as a hazard which 
if realised implies:

“A slight reduction in separation or slight reduction in air traffic 
control capability. Significant increase in air traffic controller 
workload. There may also be a Slight Increase in workload for the flight 
crew resulting from having to perform tasks that may have otherwise been 
automated."

You translate that as "if the data comms goes down, the airspace has to 
be re-configured to reflect the lower airspace capacity due to having to 
revert to using voice comms only" i.e. aircraft have to fly around 
circles, stay or the ground or get diverted until ATC is ready to cope 
with them. Generally, this does not take that long and it is something 
they train for. You don't want it to happen too often given the 
resulting flight delays, but these kind of problems should not result a 
serious incident.

In order to demonstrate that an SC4 hazard has been mitigated to the 
required confidence level, you need to demonstrate that the acceptable 
risk that the availability target has not been met is less than 1 in 
10^-3. This is just about feasible with black box testing, but still 
takes a lot of effort. Its also why mainstream COTS network nodes are so 
important a resource given that "in service experience" can get you a 
long way to demonstrating correct operation.

When it comes to ensuring that you are using the correct Network 
Address, as you would expect, this part of the system is subject to 
considerable analysis, testing and audit given the SC4 hazard level. At 
present, two independent proofs (that you have the correct network 
address for a given Flight) are required. One is provided by the 
aircraft when it reports its Flight Identifier/Network Address binding 
and the other is in the Flight Plan provided separately by the airline's 
Flight Despatcher.

At the core of the ATC Centre's Flight Data Processor is a function that 
brings this all together and validates the identity of an aircraft. This 
a key safety function and is subject to considerable analysis and 
testing. And long term testing is required to demonstrate the necessary 
confidence level.

This is also why, in the migration to the ATN/IPS, no one wants to 
propose any semantic change to the addressing plan that would force a 
revision of this function. The IPv6 address of an application on board 
an aircraft has to be canonical with the existing NSAP Address if we are 
to avoid any change.

Those arguing for a "better" addressing plan really do not appreciate 
how saving a few bits could result in years of delay in introducing the 
ATN/IPS. This is not just a consequence of the time it takes to test out 
such a function, but if you look at any ATC Centre's system development 
plan, they will have mapped out a plan for a whole sequence of 
improvements, and if you want a change to any function, you have to slot 
in to the current development plan - they might not even start work on 
this for a few years.

The next generation of applications will probably require a higher 
confidence level appropriate for Severity Class 3. How to achieve this 
with COTS networks is an active research area for myself and is taking 
me down the path of having more than one end-to-end independent (no 
common failure modes) internetwork between aircraft and the ATC Centre. 
But that is another story.

Regards

Tony

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Nov 2020 11:48:07 -0600

On Mon, Nov 16, 2020 at 2:43 PM Templin (US), Fred L <
[email-masked]> wrote:

> > This message was sent from outside of Boeing. Please do not click links
> or open attachments unless you recognize the sender and

Actually what Fred is saying here is that they use host routes.
So each airplane since it is moving  constantly changing networks they
don't change its address, these are what Fred calls MNP.
So they keep so many host routes in their routing table.

It is how they handle their routing table given these so many extra entries
in it.
I think they developed some good techniques to handle it.

Behcet

> order
> the
> > Are you aware that we already "solved" that in 1996 (
> https://tools.ietf.org/html/rfc1888), and scrapped it in 2005?
> >
> > Regards
> >    Brian
> >
> >
> >

---

From: Simon Hobson <[email-masked]>
Date: Tue, 17 Nov 2020 17:52:28 +0000

> systems, how do they run IPv6? 

Handheld portable device - powered by internal batteries. One step down from (e.g.) gliders where there is a very basic electrical system connecting batteries to radio & vario.
As it happens there are also some powered aircraft where the electrical/comms system comprises of a battery powered handheld in a bracket.

Tony Whyman <[email-masked]> wrote:

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

Out of curiosity mainly, but what is the proposal to handle the potentially many thousands (millions ?) of very small operators ?

As I mentioned in an earlier message, typically technology tends to filter down to individual private owners over time - c.f. Mode-S now mandated in some airspace, and I know individuals with TCAS in small aircraft. It's not unimaginable that the sort of system you are talking about will become mandatory in certain bits of airspace - just like Mode-S is now.

While it's a bit tongue in cheek to mention balloons, I can see that sooner or later any system would need to cope with "many small operators". As pointed out, having a fixed allocation size means you'd quickly run out.

Simon

---

From: Simon Hobson <[email-masked]>
Date: Tue, 17 Nov 2020 18:00:53 +0000

Tony Whyman <[email-masked]> wrote:

> I believe that there are two problems that cause problems with cell phones and aircraft. One is that older aircraft can have poorly screened radios and headphones used for ATC voice comm (AM double side band in the VHF spectrum) with a risk that the cell phones can interfere with voice communication.

It's worse than that. "A bit of buzz" in the comms is obvious and as long as it's not too serious/prolonged can be worked around.
It's the rest of the systems - whether internal systems that control the aircraft, or the navigational radios (that indirectly control the aircraft) - that are more of a concern. If one of those is affected then it might not be obvious until it's too late - a system that wasn't designed with that sort of interference in mind might not be designed with the sort of error detection that goes with it.

Newer aircraft are generally designed with this sort of interference in mind - and I believe some carriers do now have small cells on-board with satellite comms as a backhaul.

Simon

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 17 Nov 2020 18:36:32 +0000

“Host routes” is a correct analogy, yes, with the only difference being that the routes
will be /60 and not /128. Instead of host routes, an expression I have used is “scalable
deaggregation”, since BGP is capable of handling millions of de-aggregated routes as
long as routing churn is kept in balance. The global Internet is already proof that BGP
scales well under those conditions, and the BGP topology I have specified in this
document is far simpler and far less prone to BGP update storms.

Fred

From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 9:48 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Tony Whyman <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [EXTERNAL] Why this is broken [was Re: Extending a /64]

This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.

On Mon, Nov 16, 2020 at 2:43 PM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Brian,

> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E Carpenter
> To: Tony Whyman <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Actually what Fred is saying here is that they use host routes.
So each airplane since it is moving  constantly changing networks they don't change its address, these are what Fred calls MNP.
So they keep so many host routes in their routing table.

It is how they handle their routing table given these so many extra entries in it.
I think they developed some good techniques to handle it.

Behcet

Fred

> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Nov 2020 12:55:52 -0600

> document is far simpler and far less prone to BGP update storms.

Yes, MNP is Mobile Node Prefix (?) so you keep/60 prefixes of each node in
the routing table and leave the detail of handling them to BGP.

This is what I referred to as "good technique" below.

Behcet

> Fred
>
>
>
> *From:* Behcet Sarikaya [mailto:[email-masked]]
> *Sent:* Tuesday, November 17, 2020 9:48 AM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* Brian E Carpenter <[email-masked]>; Tony Whyman <
> [email-masked]>; Joel M. Halpern <[email-masked]>;
> [email-masked]
> *Subject:* Re: [EXTERNAL] Why this is broken [was Re: Extending a /64]
>
>
>
> This message was sent from outside of Boeing. Please do not click links or
> open attachments unless you recognize the sender and know that the content
> is safe.
>
>
>
>
>
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Nov 2020 06:33:21 +1100

On Tue, 17 Nov 2020, 14:39 Brian E Carpenter, <[email-masked]>
wrote:

> unique address space to address them.
>
> I completely agree.

I think of that approach as the IPv4 one because RFC1918s weren't unique.

As ULAs are pseudo globally unique, I see very little reason if any to use
GUA space for private disconnected networks.

I haven't looked at router spec sheets in a while, however typical core
routers can do 1 million IPv4 routes, so assuming a quarter of that for
IPv6, 250 000 /48 ULAs or 16 billion /64s.

Regards,
Mark.

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.

> >     On Mon, 16 Nov 2020, 07:19 Philip Homburg, <
> [email-masked] <mailto:[email-masked]>>
> wrote:
> >
> >         > Again, there are 35 trillion /48s in 2000::/3. How many would
> you
> >         > need?
> >
> > You mention that airplanes can fall out of the sky, it would be really
> > 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
> > 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,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Nov 2020 08:59:56 +1300

> 'should have' is an interesting concept. We can't really go back in time.

To be clear, the IPv6 *fixed length* address model changes the parameters
of allocation practice because of moving from (say) 24 to (say) 64 bits
of routeable prefix, but in no way changes the philosophy of allocation
practice. IPv6 has ~64 topology bits instead of ~24; the actual numbers
in the H-ratio calculation change; the potential lifetime of the address
space expands enormously; the economic value of address space collapse
enormously. But all of that breaks if you start assigning address bits
non-topologically. That's why IPv6 and IPv4 share CIDR as the basis
for both prefix allocation and wide-area routing.

To get away from that, we'd indeed have to jump into our time machines,
go back to a meeting that happened just outside O'Hare airport in early
1994, and agree on a variable length addressing scheme.

> prefix to every last tiny ISP as well?

Exactly. An operator of any kind should get a prefix that matches their
current and projected requirements. That's what CIDR-based allocation
is all about. Airlines are no different.

   Brian

---

From: Matthew Petach <[email-masked]>
Date: Tue, 17 Nov 2020 12:24:13 -0800

On Mon, Nov 16, 2020 at 3:17 PM Tony Whyman <[email-masked]>
wrote:

[...]

> RLOC. Once there, the EID is routeable.

Please forgive me for asking what seems to be prima facie a completely dumb
question--
but why *not* use LISP for this, as it seems like a good fit for a
situation in which you
need to use different RLOCs to reach a given EID.  Simply include the 39
bits of
information identifying the aircraft in the mapping lookup, and you've
moved the
problem space out of the addressing arena into the 'updating your mapping
table'
arena, which decades of advancement has shown is far cheaper to scale than
internet routing hardware.

If you need a unique 39 bit identifier, great.  Just treat it as an
identifier, rather
than a locator, and separate out that requirement from the locator
requirement,
and the problem seems much easier to address, if you'll pardon the pun.

The only reason I see in this discussion for trying to cram it all into the
address
is this sentence:

>> to have an airline identifier in the MNP.

Why such an aversion to having a lookup table?  LISP has demonstrated
that lookup tables aren't that painful to use, as has DNS for decades
before
that.

There's a reason we currently do name-to-address lookups in hosts, rather
than routers;
it's much more cost effective to keep the flexible name-to-address lookup on
hosts that scale better than routers, and leave the routers to forward
packets
as quickly as they can.

I get it--you have a legacy protocol you're trying to carry forward into
the future.
We've all been there.  DECnet, SNA, Novell, Appletalk, Vines--the road
behind
us is littered with legacy protocols.  And what do we do when we want to
carry
them over the Internet?  We encapsulate them.  We don't try to bludgeon
them
directly into the IP framework itself.

Much of this discussion feels like trying to hammer a square peg into a
round
hole; the peg isn't going to be terribly happy about it, and that hole is
never
going to be the same ever again.

Matt

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 17 Nov 2020 20:36:58 +0000

Matthew, LISP has been proposed as one of the aviation mobility solution candidates
but so have AERO/OMNI and IMHO provide a better alternative:

https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/
https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/

Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Matthew Petach
Sent: Tuesday, November 17, 2020 12:24 PM
To: Tony Whyman <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: Why this is broken [was Re: Extending a /64]

On Mon, Nov 16, 2020 at 3:17 PM Tony Whyman <[email-masked]<mailto:[email-masked]>> wrote:

[...]

Please forgive me for asking what seems to be prima facie a completely dumb question--
but why *not* use LISP for this, as it seems like a good fit for a situation in which you
need to use different RLOCs to reach a given EID.  Simply include the 39 bits of
information identifying the aircraft in the mapping lookup, and you've moved the
problem space out of the addressing arena into the 'updating your mapping table'
arena, which decades of advancement has shown is far cheaper to scale than
internet routing hardware.

If you need a unique 39 bit identifier, great.  Just treat it as an identifier, rather
than a locator, and separate out that requirement from the locator requirement,
and the problem seems much easier to address, if you'll pardon the pun.

The only reason I see in this discussion for trying to cram it all into the address

Why such an aversion to having a lookup table?  LISP has demonstrated
that lookup tables aren't that painful to use, as has DNS for decades before
that.

There's a reason we currently do name-to-address lookups in hosts, rather than routers;
it's much more cost effective to keep the flexible name-to-address lookup on
hosts that scale better than routers, and leave the routers to forward packets
as quickly as they can.

I get it--you have a legacy protocol you're trying to carry forward into the future.
We've all been there.  DECnet, SNA, Novell, Appletalk, Vines--the road behind
us is littered with legacy protocols.  And what do we do when we want to carry
them over the Internet?  We encapsulate them.  We don't try to bludgeon them
directly into the IP framework itself.

Much of this discussion feels like trying to hammer a square peg into a round
hole; the peg isn't going to be terribly happy about it, and that hole is never
going to be the same ever again.

Matt

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Nov 2020 10:33:28 +1300

Tony,

Thanks for the example; very helpful. More in line...

> for ensuring that their aircraft each have a Home Agent.

Yes, that makes sense (assuming there are strong provisions for what
happens when an airline ceases operations or gets taken over, since
I assume that having an aircraft orphaned while in flight would be
unacceptable).

> each aircraft operator using this common prefix.

That's a rather naive approach IMHO. Firstly, as has been pointed out, it
mismatches the entire design and history of IPv6 prefix allocation (which
regards 5000 as a very small number). Secondly, it's hard to believe that
this would be a significant part of firewall maintenance; there will surely
be a need for fine-grained configuration anyway, for what I mentioned
above: creation of new airlines, mergers, discontinuations. It certainly
wouldn't be acceptable from a security viewpoint to have a "default allow"
for any address that purports to indicate a previously unknown airline.
So how could you safely have fewer than 5000 firewall rules that are
continuously subject to updates?

> of an ICAO administered scheme.

On paper it's 2^15 = 32,768 prefixes where 5000 would do; not that those are
very large numbers in IPv6 terms.

> Home Network) with aggregation to the common ICAO prefix at the ATN 

If I understand that correctly, it would recreate what I've always
seen as the main problem in the model for LISP/Internet interworking,
namely a finite number of bottleneck routers. (And that's regardless
of where you put the MNP bits.) If you don't have such a shared
prefix, those bottlenecks disappear.
 
> Updates to register each currently active care-of address and their MNP 

As I understand it you want one home address for each active address
on each aircraft? That's to say that if 500 devices were active on
a given aircraft, they'd each need their own home address?

> using normal forwarding procedures.

But that can work equally well if the MNP bits are in (say) bits 64 to 63+n.
They don't need to be in the topology bits at all.

> Analysis

Exactly right, which is why I think the correct design is to put those
bits in the non-topological part of the address.
 
> perhaps using DHCPv6 PD embedded in Mobile IP exchanges.

No, I can see why you want it to be a constant. But precisely because
it's a constant, it should not be in the topology bits.

> identifier already configured in the Aircraft's Personality Module).

You're missing:

4. Allocation of whatever CIDR prefix is suitable plus embedding
the ICAO 24-bit identifier in all on-board Interface IDs.

(I'm not saying that works out of the box with passengers'
laptops and smartphones.)

> broadband service when all I need is a /64.

Saying that a /60 is acceptable is assuming that things won't change
and the 16 subnets is enough for all aircraft for all time. Well, I
just looked back at the input to IPng design from a Boeing source
[RFC1687], and it doesn't even mention IPng on aircraft. (It does mention
compatibility with ICAO usage of CLNP, however.) Shows how good we
are at prediction.

But that issue goes away if airlines just get a prefix the same way as
any other enterprise, with the ability to get another one later if
required.

> Hopefully this explains a few thing.

It does. It also convinces me that this discussion belongs in
the IETF Routing Area.

Regards
   Brian

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 17 Nov 2020 21:48:12 +0000

Brian,

> compatibility with ICAO usage of CLNP, however.) Shows how good we

That document was published long before I came to Boeing, and the views
expressed there have faded into the past. The aviation industry is very much
interested in IPv6 now, Boeing included.

Thanks - Fred

> Sent: Tuesday, November 17, 2020 1:33 PM
> To: Tony Whyman <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
> 
> >>> 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.
> >>> 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
> >>> --

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Nov 2020 10:56:23 +1300

> interested in IPv6 now, Boeing included.

Oh, Boeing was very interested then too, as you'll see if you read
the RFC. My point was more about the idea that we can say in 2020 that
/60 is enough for an aircraft in, say, 2045.

    Brian

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 17 Nov 2020 22:02:05 +0000

Brian,

> From: Templin (US), Fred L
> Sent: Tuesday, November 17, 2020 1:48 PM
> To: 'Brian E Carpenter' <[email-masked]>; Tony Whyman <[email-masked]>; [email-masked]
> Subject: RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
> 
> Brian,
> 

I should be more careful in my phrasing. I actually think that document stood
the test of time in many ways, and some of it still applies today. However,
the civil aviation industry is on track to embrace IPv6 in the modern era.

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 17 Nov 2020 22:12:34 +0000

Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, November 17, 2020 1:56 PM
> To: Templin (US), Fred L <[email-masked]>; Tony Whyman <[email-masked]>; [email-masked]
> Subject: Re: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
> 
> the RFC.

Right, I hope my note that I sent at about the same time as yours came
out struck a better balance. No disrespect was intended.

> My point was more about the idea that we can say in 2020 that

I spoke passionately for RFC6177 where we could hope for at least a /56
or even as much as a /48, but I have to say that Tony's messages have
given me pause to think that there may be substance behind what is
being proposed.

Fred

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2020 22:30:36 -0500

> space exists for non-Internet connected devices.

No, This is JUST SO WRONG. This is IPV4 SCARCITY THINK.

IPv6 is for all users, not just those in some entities routing table.

ULA is second class in many ways: no reverse, no RPKI, no whois, etc.
ULA-C would be slightly less wrong.   Would you support doing that?

    > - provide potential global reachability to any and all global Internet

- show up in databases like whois
- can have RPKI credentials
- can have RPSL policies attached
- can be announced in BGP to consenting peers without prior arrangement

When we designed IPv6, we assumed that everyone would get some, even if they
didn't connect.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2020 22:43:53 -0500

> administration and legacy support.

You are both right.

Picking a median size and then allowing for multiple allocations to the
larger entities probably is a better plan.
Small airlines grow and bigger airlines fail, or merge, etc.

If tweaking the number of bits here could move us from 39 bits
(which I don't yet understand the math on), to say, 32 bits, then it might
work out better.

    > I also do not see the point in having a different (shorter) prefix length for
    > aircraft in smaller airlines compared with those in larger airlines.

    > If you are arguing for dense allocation as a general rule then this should
    > apply to the whole /64 prefix. I assume that you are demanding that ISPs
    > allocate a /64 to all their users unless they can make the case for multiple
    > subnets and, even then, are parsimonious in their attitude and push back hard
    > against any user that wants more than a /60, demanding proof that they have
    > more than 256 subnets.

This.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2020 22:51:42 -0500

> for both prefix allocation and wide-area routing.

ISPs that try to allocate their IPv6 residential customers based upon strict
geographical/network topology find two things:
  1) they have the wrong amount of space in the wrong place at the wrong time.
  2) they force users to renumber needlessly when they have to split
     customers in a neighbour among two routers/CMTS/BMS.

So I claim that in the 16 bits between /32 to /48 within an ISP, that there
is little in the way of network topology.  Yes, some structure, with some
layers of abstraction... when possible... but OSPFv3 deals.

I've heard that in the future that Smart ISPs will use some kind of
address allocation/management autonomic service agent over a secure autonomic
control plane.

So, instead of thinking of this as a non-topological address plan, think of
this as the internals of a really large confederated airline ISPs.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2020 22:55:36 -0500

> difficult to conceive of situations where such an address conflict,

I was reading that: The address conflict confuses a human.  Who does the wrong thing.

---

From: Tony Whyman <[email-masked]>
Date: Wed, 18 Nov 2020 09:33:43 +0000

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 18 Nov 2020 10:42:37 -0600

On Tue, Nov 17, 2020 at 2:24 PM Matthew Petach <[email-masked]>
wrote:

>
>
> On Mon, Nov 16, 2020 at 3:17 PM Tony Whyman <
> [email-masked]> wrote:
>
> [...]
>
>

I second Matt!

Behcet

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Nov 2020 09:10:09 +1300

Tony,

I don't like the argument that people are arguing for either "purity"
or "perfection". That is not the issue. The issue is doing something
that matches how IPv6 wide-area routing actually works, and that is
by CIDRised prefix allocation.

Now you have peeled back the onion to this point:

> we have to have an addressing plan (for 
> aircraft) that is canonical with the existing NSAP Address.

I understand that as a perceived requirement; it's more or less why
we wrote RFC1888, although mapping US GOSIP addresses was the target
then. I don't know how the ICAO lays out its NSAPA addresses, but I
imagine that the aircraft ID is towards the low-order bits?
That's where it should be in an IPv6 address, IMNSHO.

The current proposal seems to be limited to 16 subnets on an
aircraft and that is highly likely to come back and bite you.

Regards
   Brian Carpenter

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 18 Nov 2020 20:11:26 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Tony Whyman

is that we are not starting with a "clean sheet of paper".

That is what I've come to understand, from your explanations. Which is why something that should be quite straightforward, nothing more than standard mobile IPv6, becomes difficult. It will require perhaps a new set of prefixes from IANA, as well as an overlay to make the scheme actually work, because it is not the way IP is set up. Neither IPv4, nor IPv6, work this way.

The way I would be proposing to continue, assuming they insist on using IPv6 (which is *not mandatory*, of course), is to make a small adjustment in the philosophy of where the airplane ID should go. Or say it another way, wink-wink, pretend we are extending the prefix, when in fact, we are pre-assigning some of the upper IID bits. (But don't tell them that.)

1. Use straight out of the box mobile IPv6. Even use the convention so many care about, that IIDs must be 64 bits wide. (Path of least resistance.)

2. The prefix of each address is a prefix that belongs to the home country of the airline. This is because the home address, in mobile IP, must be routable.

3. Each airplane is allocated at least a /56 (for the front cabin and machinery), or even better, a /48.

4. The top 40 or 48 bits of the IID are used as airplane ID.

5. Addresses for these machinery devices are either assigned statically, or they are assigned using DHCP cum the "client identifier" option. By doing this, you will not need a DNS inside the airplane.

6. Anyone wanting to initiate a session with anything inside the cabin would reach the home agent first, and then either the packets are relayed to the current c/o address of the airplane, by the home agent, or the source encapsulates the packets and sends directly to the c/o address, per standard mobile IP.

Always a problem when those in charge try to reinvent wheels. Unfortunately.

Bert

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Nov 2020 15:39:16 -0500

> Just because you can do something doesn't mean you should.

And yet, we allow banks, hospitals and governments to use TCP/IP.

---

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

Joel M. Halpern <[email-masked]> wrote:
    > address.

Tony wrote:
> 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).

My reading of this is that he needs the information in each packet so that he
can do stateless translation between different technologies.   It needs
to be stateless so that it can scale horizontally (inverse multiplexing), and
so that it can be n+1 redundant.

---

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

> prefix; the Internet doesn't work like that. End of story. Back to the

The airline identifier (the prefix /17 + 15bits airline number = /32) is
topological.

Traffic from whatever peers the aircraft needs to talk to goes through the
airline "HQ" (but: of course, physically attached in many places thanks to
BGP), and then through the mobile IPv6 system to get to the aircraft.   Each
airline has that 24-bit wide mapping table to get the data there over the
OMNI/RAW/etc. link.

    > an attacker to observe that a particular address belongs to a

This is an irrelevant non-sequitor.  We have multiple technologies at multiple levels to
protect against this kind of forgery: 802.1x, MACsec, IPsec, BCP38.

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Nov 2020 12:21:35 +1100

Hi Michael,

> No, This is JUST SO WRONG. This is IPV4 SCARCITY THINK.

No, it is safety and security thinking.

Some things should have no or extremely little possibility of working
over the Internet even if they're attached to it accidentally. I think
planes are one of those things, because if they're attacked in one way
or another and they fall out of the sky people can die.

ULA space isn't intended to work on the Internet, and the people
running Internet routing aren't trying to make ULAs work over the
Internet.

"Private" GUA space has more likelihood of working over the Internet
should the devices with it be attached to the Internet, because people
are trying to make GUA routing work as well as it possibly can.

At work, if I'm told a GUA prefix can't be reached over the Internet,
that's a fault until I find out otherwise. I will work on fixing an
apparent routing fault.

On the other hand, if I'm told a ULA prefix can't be reached over the
Internet, I'll say immediately "Of course, it isn't isn't supposed to.
No fault found, working as intended."

> ULA-C would be slightly less wrong.   Would you support doing that?

Yes, although I think for large private networks something like this,
the RFC4193 ULA-Cs might not be the correct format because they can't
be aggregated at a prefix length shorter than a /48.

I'd be thinking something like a new "large private network" ULA
address space from a different /8 prefix than fc::/7, where the a
shorter global ID is managed by the registry or registries rather than
being pseudo random per RFC4193 and say between /32s and /40s are
provided, requiring typical RIR justification and annual fees. That
would provide 24 bits of /32s or 16 million, which I think would be
enough for the foreseeable number of large private networks that would
be willing to register and pay annual fees for this large private
address space.

(Or perhaps the current ULA-C format could be redefined with a shorter
Global ID and registry ID management since current ULA-C isn't in
use.)

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Nov 2020 16:22:58 +1100

> And yet, we allow banks, hospitals and governments to use TCP/IP.

TCP/IP != Internet.

Guess the RFC:

With the proliferation of TCP/IP technology worldwide, including
   outside the Internet itself, an increasing number of non-connected
   enterprises use this technology and its addressing capabilities for
   sole intra-enterprise communications, without any intention to ever
   directly connect to other enterprises or the Internet itself.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Nov 2020 11:30:40 +0000

the key phrase is:

Mark Smith wrote on 19/11/2020 05:22:
> [...] without any intention to ever

If the ICAO can guarantee that ipv6 assignments to aircraft will never 
be used to directly connect to other third party networks, then ULA will 
work fine. I doubt that this is a safe assumption.

Nick

---

From: Tony Whyman <[email-masked]>
Date: Thu, 19 Nov 2020 14:10:53 +0000

> so that it can be n+1 redundant.
"Stateless" is certainly the objective but the reason for this has more 
to with the safety approval process than with scaling.

The protocol gateway will be a specially developed box and the Safety 
Engineering Requirements for this are well known in terms of the 
software development lifecycle, rigorous testing, etc. A simple 
stateless transform from one address format to another is an isolated 
function. The code can be eyeballed and exhaustively tested in 
isolation. The cost of doing this is quantifiable.

A lookup function on its own is not that much more difficult. The 
problem comes when you look at the source for the data in the table and 
how the table is maintained. This is when you jump down the rabbit hole.

We would need to develop the procedures and process for generating the 
"new" identifiers for each aircraft, how they are communicated to the 
aircraft and lookup table (in each protocol gateway) and how we ensure 
that these are kept in sync to the required high degree of confidence. 
Based on previous experience, I would expect the safety authority to 
demand two independent proofs that the lookup table contains the correct 
data.

One would probably be by direct communication between the 
airline/aircraft registration authority and the maintainer of each 
protocol gateway. The other would probably be via each aircraft.

On the aircraft side, we may need an update to the AEEC specification 
for the Aircraft Personality Module, a potential hardware upgrade (to 
every aircraft) and the procedures for properly configuring the new 
identifier into the aircraft. A new protocol would be required to 
communicate the binding between the new identifier and the airframe's 
24-bit id to the protocol gateway. And all this has to be subject to the 
certification and approvals process.

For the sake of a few addressing bits, there is really no justification 
for going down this (very expensive and time consuming) path and we 
don't have the funding anyway.

To continue the metaphor, the only reason for jumping down this Rabbit 
Hole seems to be a "Mad Hatter's Tea Party" where you have a big empty 
"table" that is the current address space and with a group down one end 
of the table shouting "no room".

---

From: Tony Whyman <[email-masked]>
Date: Thu, 19 Nov 2020 14:21:04 +0000

On 19/11/2020 11:30, Nick Hilliard wrote:
> be used to directly connect to other third party networks, then ULA 
> will work fine. I doubt that this is a safe assumption.
>
> Nick
>
Correct, this is not a safe assumption. Also, a 40-bit global ID does 
not allow us enough remaining bits. We could set the L bit to 0 and then 
use our own format - but happens if an internet (e.g. a military one) 
wants to do the same, or another RFC comes along and defines a new ULA 
format with L=0? All that we would really be doing is to squat on a 
portion of the global address space and this is not what we should be doing.

---

From: "Mudric, Dusan" <[email-masked]>
Date: Thu, 19 Nov 2020 14:24:06 +0000

NOTE: Not familiar with the reasons to put aircraft IDs in the address, but something like that should be in a layer above IP. Any further extension of addresses, like variable prefix length, interfere with the original approach.

Dusan

On 2020-11-19, 9:11 AM, "ipv6 on behalf of Tony Whyman" <[email-masked] on behalf of [email-masked]> wrote:

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!OSsGDw!amQR_S0k-d_ulNPgDoV12BA0yBEIJyFZjymdWRxBDGZr8V-GxHzvtWy43NvQ$ 
--------------------------------------------------------------------

---

From: Tony Whyman <[email-masked]>
Date: Thu, 19 Nov 2020 14:30:32 +0000

The reasoning behind is explained somewhere back in the thread and 
probably more than once. I am wondering if an informational RFC is going 
to be needed to explain what is going on here - although I am not sure 
if I really want to volunteer myself to do this.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Nov 2020 14:55:51 +0000

Tony,

address management and assignment policies are issues that affect all 
organisations to some degree or another.  What you're describing here 
can be paraphrased as:

- we've found out that address assignment management is hard, 
particularly given the constraints that we find ourselves in and the 
architecture we've chosen. As the IETF has lots of ipv6 space, it would 
make our lives much easier if we had an allocation large enough to embed 
our own persistent identifiers in the locator of the ipv6 address.

The IETF's position is approximately:

- an ip address consists of a topology locator and a network identifier. 
This definition does not acknowledge that persistent identifiers managed 
by other organisations are a legitimate part of the justification for 
bit space.

> of the table shouting "no room".

If you look at this from the other point of view, if the IETF opens up 
ipv6 address space to allow third party persistent identifiers to become 
part of how you can justify bit space in an addressing allocation, where 
does that end?  Other than in exhaustion of any addressing scheme that 
the ietf could ever devise?

I hope you can appreciate that this isn't a mad hatter's tea party 
situation, but a consequence of a long-term decision made by rational 
actors who had the benefit of hindsight when making that choice.

Nick

---

From: tom petch <[email-masked]>
Date: Thu, 19 Nov 2020 17:05:21 +0000

From: ipv6 <[email-masked]> on behalf of Tony Whyman <[email-masked]>
Sent: 19 November 2020 14:30

The reasoning behind is explained somewhere back in the thread and
probably more than once. I am wondering if an informational RFC is going
to be needed to explain what is going on here 

<tp>
Yes about 500 e-mail messages ago!

You referenced unpeeling the onion and that is what is has felt like, bit by bit the requirements are revealed, most of which render irrelevant what has just been said or most of the preceding discussion even.  The IETF way of working revolves around I-Ds which tend to eliminate a lot of the comments that might otherwise be made, at least by those who have read the I-D, so while I am interested to learn of the use of OSI in production, it has, at times, felt more like a DoS attack:-(

Tom Petch

- although I am not sure

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Nov 2020 05:23:10 +1100

> work fine. I doubt that this is a safe assumption.

I'm sure insurance companies and aviation authorities will have the
controlling say in this.

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Nov 2020 06:56:34 +1100

On Fri, 20 Nov 2020, 01:21 Tony Whyman, <[email-masked]>
wrote:

> use our own format

- but happens if an internet (e.g. a military one)
> wants to do the same,

Both of you would be ab using both ULAs and ignoring IPv6 specifications.

What makes you think that once you have a high order prefix, you have the
freedom to arbitrarily define the format and semantics of any of the low
order bits?

If you do that, you'll be ignoring many IPv6 specifications including the
main IPv6 addressing architecture RFC, have to have custom implementations,
and may encounter problems that nobody else encounters.

Why would you want to shoot yourself in the foot like that?

or another RFC comes along and defines a new ULA

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Nov 2020 22:27:08 +0000

Mark Smith wrote on 19/11/2020 19:56:
> What makes you think that once you have a high order prefix, you have 
> the freedom to arbitrarily define the format and semantics of any of the 
> low order bits?

the cart needs to go before the horse.

If Tony is saying that ipv6 assignments to aircraft could - even 
possibly - be used to directly connect to other third party networks, 
then ULA is inappropriate and we can park that discussion.  This leaves 
GUA or something else from other IANA-reserved address space.

Thing is, if an organisation feels that their needs for ip address 
allocation are sufficiently different from everyone else's in the world 
that they need to bypass the RIRs and apply for a direct IANA 
reservation - whether that be in GUA space or not - then the 
organisation needs to make a case which justifies this ask.

Obviously there's no problem discussing ideas on 6man to get the lay of 
the land, but bypassing the RIRs for addressing requirements seems to be 
an extraordinary ask, and an extraordinary request will need 
extraordinary justification.

Nick

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 19 Nov 2020 22:41:01 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Nick Hilliard

I agree with the sentiment. It's not at all obvious why the airplane ID must, of absolute necessity, belong in the prefix of an IPv6 address. This seems to have been an assumption based on previous ideas, on how one might use NSAPAs. If I got that history right. So, if that's what we expected in NSAPAs, we'll do the same thing with IPv6. Why?

Also, it seems immaterial whether these networks will ultimately be reachable from "the Internet," or not. That's an orthogonal discussion, getting into safety matters and other such. The goal of reaching mobile platforms seems to be feasible, and scalable, with plain vanilla mobile IP, as far as I've understood the problem. But for that, the IPv6 address architecture has to be used.

When cars, buses, trains, etc., also want IPv6 mobility, I would not expect them to be requesting such extraordinary accommodations?

Yes.

Bert

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Nov 2020 13:49:27 +1100

On Fri, 20 Nov 2020, 09:27 Nick Hilliard, <[email-masked]> wrote:

> then ULA is inappropriate and we can park that discussion.

ULAs are specifically designed to allow interconnecting to other ULA
networks without resorting to renumbering or IPv6 NAT.

That is why the Global ID is required to pseudo-random, so that when two
ULA networks are interconnected, there is no overlapping or duplicate
address space. Subnet prefixes and therefore the hosts attached to them
already have globally unique addresses, even though they don't have global
reachability or access.

This was one of the problems with site-locals. Merging two site-local
address spaces would have involved renumbering or NAT.

This leaves

---

From: Philip Homburg <[email-masked]>
Date: Fri, 20 Nov 2020 11:19:51 +0100

>already have globally unique addresses, even though they don't have global

If a separate ULA /48 is allocated for echt aircraft then that may
significantly increases the collision risk. If all aircraft are numbered
from a single /16 taken from ULA, then the risk of collisions is very high.

For ULA to work you need to have only a few /48s that connect.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 20 Nov 2020 16:26:37 +0000

> networks without resorting to renumbering or IPv6 NAT.

Mark,

yep, we know what ULAs are.  What makes them unsuitable is their 
specification as address ranges "with high probability of uniqueness".

Earlier in the thread you expressed concerns about risk management, 
including images of planes falling out of the sky and invocation of 
insurance risk and regulatory involvement.  If risk is a concern here, 
then addressing models with a "high probability of uniqueness" are not 
going to be viable, because this risk can be eliminated with a low 
outlay by using registered address space.

Can we now park this aspect of the discussion?

Nick