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

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

Brian,

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Tuesday, November 17, 2020 1:56 PM
> To: Templin (US), Fred L <[e-mail]>; Tony Whyman <[e-mail]>; [e-mail]
> Subject: Re: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
> 
> On 18-Nov-20 10:48, Templin (US), Fred L wrote:
> > 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.
> 
> Oh, Boeing was very interested then too, as you'll see if you read
> 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
> /60 is enough for an aircraft in, say, 2045.

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 

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