RE: [EXTERNAL] Re: Extending a /64

["Manfredi (US), Albert E" <[e-mail]>]

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