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

["Templin (US), Fred L" <[e-mail]>]

Brian,

> -----Original Message-----
> From: Templin (US), Fred L
> Sent: Tuesday, November 17, 2020 1:48 PM
> To: 'Brian E Carpenter' <[e-mail]>; Tony Whyman <[e-mail]>; [e-mail]
> Subject: RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
> 
> Brian,
> 
> > 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.
> 
> 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.

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

> Thanks - Fred
> 
> > -----Original Message-----
> > From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> > Sent: Tuesday, November 17, 2020 1:33 PM
> > To: Tony Whyman <[e-mail]>; [e-mail]
> > 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.
> >
> >
> > Tony,
> >
> > Thanks for the example; very helpful. More in line...
> >
> > On 17-Nov-20 22:26, Tony Whyman wrote:
> > > On 17/11/2020 03:39, Brian E Carpenter wrote:
> > >> 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
> > >
> > > 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.
> >
> > 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).
> >
> > >
> > > 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.
> >
> > 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?
> >
> > > 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.
> >
> > On paper it's 2^15 = 32,768 prefixes where 5000 would do; not that those are
> > very large numbers in IPv6 terms.
> >
> > > 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.
> >
> > 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.
> >
> > > 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.
> >
> > 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?
> >
> > > 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.
> >
> > 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
> > > ------------
> > >
> > > 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.
> >
> > Exactly right, which is why I think the correct design is to put those
> > bits in the non-topological part of the address.
> >
> > > 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.
> >
> > 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.
> >
> > > 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).
> >
> > 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.)
> >
> > > 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.
> >
> > 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
> > >
> > > Regards
> > >
> > > Tony Whyman, MWA
> > >
> > >
> > >> On 17-Nov-20 15:55, David Farmer wrote:
> > >>> On Sun, Nov 15, 2020 at 2:56 PM Mark Smith <[e-mail] <mailto:[e-mail]>> wrote:
> > >>>
> > >>>
> > >>>      On Mon, 16 Nov 2020, 07:19 Philip Homburg, <[e-mail] <mailto:[e-mail]>>
> > wrote:
> > >>>
> > >>>          > Again, there are 35 trillion /48s in 2000::/3. How many would you
> > >>>          > need?
> > >>>
> > >>>          It gets tight when you want the prefix to contain 39 bits to number around
> > >>>          half a million planes.
> > >>>
> > >>>
> > >>>      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:[e-mail] <mailto:[e-mail]>
> > >>> Networking & Telecommunication Services
> > >>> Office of Information Technology
> > >>> University of Minnesota
> > >>> 2218 University Ave SE        Phone: [phone]
> > >>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> > >>> ===============================================
> > >>>
> > >>> --------------------------------------------------------------------
> > >>> IETF IPv6 working group mailing list
> > >>> [e-mail]
> > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > >>> --------------------------------------------------------------------
> > >>>
> > >> --------------------------------------------------------------------
> > >> IETF IPv6 working group mailing list
> > >> [e-mail]
> > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > >> --------------------------------------------------------------------
> > >>
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------