RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)

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

-----Original Message-----
From: Templin (US), Fred L 

> Bert, I appreciate the perspectives but we will want to use robust IID generation
capabilities such as RFC4941(bis) and RFC7217 without having to set the 24-bit ID
in each host's address.

This would only be for the front of the airplane, I take it. For passengers, it's not an issue. They can use SLAAC as is. Up front, I'd be using something more predictable than SLAAC anyway? Plus, another advantage of this, you would not need to request anything special, like a new /10 prefix, dedicated only to airplanes.

> Plus, the aircraft ID is the moral equivalent of a VIN; it is
not a MAC address, nor an OUI,

What is more similar to an auto's VIN than the Organizational Unit Identifier, plus a few more bits, of a MAC address? The MAC address identifies the manufacturer and the device itself, at least in principle, as VINs do. For this purpose, you only need to identify the aircraft, in a completely predicable way, I take it. The rest of the IID can be less deterministic. For instance, use DHCPv6, with the top 24 or 39 bits always the same.

> The aircraft ID is an identity, pure and simple.

So is the MAC address.

> And, if the aircraft can self-generate an MNP knowing only its ID, then it does
not have to ask the network to generate one for it.

And now, you are putting the burden of change on well-established global routing schemes, designed to aggregate routes, only for this airline example. That's really my point. I'm always in favor of looking for the path of least resistance.

Bert