Subject: Re: Extending a /64 (ATN/IPS worked example)

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

Brian, like Behcet said it is really the logical equivalent of host routes. Only, our
"host routes" are /60's and not /128's. For many reasons though, it is good if we
can have a portion of the prefix based on a unique identifier that travels with
the aircraft. It is not a MAC address, however; it is the moral equivalent of an
automobile VIN with no addressing semantics at any layer.

Fred

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, November 17, 2020 1:43 PM
> To: Templin (US), Fred L <[email-masked]>; Philip Homburg <[email-masked]>; [email-masked]
> Subject: Re: Extending a /64 (ATN/IPS worked example)
>
> On 18-Nov-20 09:39, Templin (US), Fred L wrote:
> > Brian, due to mobility we need to consider all aircraft as always away from their home
> > networks. And, so, we need scalable de-aggregation and that is exactly what we get
> > with our adaptation of BGP:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/
> 
> This looks good, but surely it doesn't care how the aircraft's prefix
> is assigned?
> 
>    Brian
> 
> >
> > Fred
> >
> >> -----Original Message-----
> >> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> >> Sent: Tuesday, November 17, 2020 12:00 PM
> >> To: Philip Homburg <[email-masked]>; [email-masked]
> >> Subject: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
> >>
> >> 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 18-Nov-20 04:55, Philip Homburg wrote:
> >>> In your letter dated Tue, 17 Nov 2020 15:02:40 +0000 you wrote:
> >>>>> 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.
> >>>>>
> >>>> 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.
> >>>
> >>> '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.
> >>
> >>> 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.
> >>>
> >>>> 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.
> >>>
> >>> 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?
> >>
> >> 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
> >>
> >>>
> >>>> 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.
> >>>
> >>> 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.
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> [email-masked]
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [email-masked]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Nov 2020 11:00:20 +1300

> automobile VIN with no addressing semantics at any layer.

I can see the value of having it in the address, assuming you have some kind of authentication of the address. Why does it specifically need to be in the prefix?

   Brian

---

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

Brian,

> Sent: Tuesday, November 17, 2020 2:00 PM

It needs to be in the upper 60 bits, because the lower 68 bits are used for on-board
subnetting and assigning interface identifiers to on-board network nodes.

Fred

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 17 Nov 2020 22:30:35 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Templin (US), Fred L

IMO, it's always going to be difficult to assume so many changes to existing practice and existing conventions, all at once.

Doing this is a more conventional way, you could request a /48 or a /56 (at least) for each airplane, as their home address. That prefix could belong to the country home base of the airline, for example, exactly as one would expect. Without taking away prefix bits to identify an airplane.

Use the 16 or 8 bits for on board subnetting. Use up, say, 24 or 39 bits of the IID in each subnet for whatever airplane identifier. Now you have only one fight on your hands: an IID that is not purely random.

I'm with Brian. The natural location of non-topological bits is in the IID. No surprise, as they were originally thought to incorporate the MAC address. Which is non-topological, and incorporates 24 bits of OUI.

Bert

---

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

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. Plus, the aircraft ID is the moral equivalent of a VIN; it is
not a MAC address, nor an OUI, nor any other layer 2 addressing information
that would typically go into an IID. The aircraft ID is an identity, pure and simple.
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.

Thanks - Fred

> From: Manfredi (US), Albert E
> Sent: Tuesday, November 17, 2020 2:31 PM
> To: Templin (US), Fred L <[email-masked]>; [email-masked]
> Subject: RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
> 
> Doing this is a more conventional way, you could request a /48 or a /56 (at least) for each airplane, as their home address. That prefix
> could belong to the country home base of the airline, for example, exactly as one would expect. Without taking away prefix bits to
> identify an airplane.
> 
> Use the 16 or 8 bits for on board subnetting. Use up, say, 24 or 39 bits of the IID in each subnet for whatever airplane identifier. Now
> you have only one fight on your hands: an IID that is not purely random.
> 
> I'm with Brian. The natural location of non-topological bits is in the IID. No surprise, as they were originally thought to incorporate the
> MAC address. Which is non-topological, and incorporates 24 bits of OUI.
> 
> Bert

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Nov 2020 23:59:22 +0100

>Plus, the aircraft ID is the moral equivalent of a VIN; 

One way to look at this discussion is that to make aircraft ID part of an IPv6
address is like making the VIN part of a car's license plate number.

For cars it is obvious why we don't do that. For IPv4 it is clear why we 
would not do that. It seems that IPv6 enough bits to promote 'creativity'.
Same as putting IID generation types in link-local addresses. Clearly
the link local prefix has too many bits and should have been a /64.

---

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

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

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

---

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Tuesday, November 17, 2020 2:59 PM
> To: [email-masked]
> Cc: Templin (US), Fred L <[email-masked]>

That's why I said "moral" equivalent, and not "exact" equivalent; car VINs
are these big, long things that are far too long to embed in conventionally
sized containers. Aircraft IDs are only 24-bits - a much more workable size.

> would not do that. It seems that IPv6 enough bits to promote 'creativity'.

If by "creativity" you mean "usefulness" then I agree. IPv6 packets are
going to tote around 128bit addresses, so we might as well pack them
with useful information.

Fred

---

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

Bert,

> Sent: Tuesday, November 17, 2020 3:03 PM
> 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.

Front of the airplane (i.e., safety domain), yes.

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

No, no burden on routing protocols - simply an overlay of a few lightweight
BGP routers (could even be VMs in the cloud) doing exactly what BGP is
intended to do and without polluting any routing tables in the underlay.

Fred