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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 17 November 2020 21:48 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEBC3A0A2E for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 13:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEmuhLakOC55 for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 13:48:27 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5F03A0CB9 for <ipv6@ietf.org>; Tue, 17 Nov 2020 13:48:23 -0800 (PST)
Received: from localhostlocalhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AHLmHAH007218; Tue, 17 Nov 2020 16:48:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1605649701; bh=Ukqe3ZUAuwAo45LXmMQiscnXOvsplSliMaLp1ZmMo3A=; h=From:To:Subject:Date:References:In-Reply-To:From; b=We/j7wvnF0DYCyYbW8Q6Q2nXatoDF6u6p1hxgnT1B8XwSpSd1UDLUXPhahh7FtGzy QtjqjMouMW1E+mNmGdXOUMN9DDVclzQa40IIcVgrCFZ+3TNzS9mxPwjh+hUfcNiwII f8PcYZy75Ue54QHteSHR5HupLpGwRWGThmLzZnFT84XMyvkzfZ9VkrIqJnfTz267x6 anoPh5bNSx2PgARBT2igMoBLQtOeo57lpvAZ8AseEllAJgJqzRFfQZMHnt2qk+8qOw UlhYUz/e0B37k1SUA/4ptxen//8U2+DeWx7C02qyBiR83f3yQLgVoaPUhiK7xG2gIj JzbRQkxNUHokA==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AHLmD7O007187 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 17 Nov 2020 16:48:13 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 17 Nov 2020 13:48:12 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 17 Nov 2020 13:48:12 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Tony Whyman <tony.whyman@mccallumwhyman.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
Thread-Topic: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
Thread-Index: AQHWvSlprTHHj3CB90CSr3DKTuAghanM21Mg
Date: Tue, 17 Nov 2020 21:48:12 +0000
Message-ID: <505489b6ff0e456685d73ceba47bd574@boeing.com>
References: <202011151920.0AFJKN9U003337@mail2.mwassocs.co.uk> <3d26bffe-b6c9-4ed7-6135-a515f9902fd7@gmail.com> <m1keOTi-0000EGC@stereo.hq.phicoh.net> <CAO42Z2wZkXryhw1u5WAFdtCvXHyyz1zeM22FP_gRxjurjsG-Jw@mail.gmail.com> <CAN-Dau2XTRJpR9S=ZXOXOD6PkxLTD7KAzN-CwoGhMUmSQTp0Zg@mail.gmail.com> <91d4b7d4-5477-50c0-fb34-5e7bbfdfb253@gmail.com> <ad5ee6e1-c402-f9d4-80a2-f9f0fd5c3da5@mccallumwhyman.com> <1cb21ff2-06f5-d92c-2e50-c93b4ee425a0@gmail.com>
In-Reply-To: <1cb21ff2-06f5-d92c-2e50-c93b4ee425a0@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 015812E416582B7A4DDD1DDFCC2DB335A21BA5809B003C95A672705C057F3AD12000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Tkmo0Z2PYLWsMxe5fB-AYcukFx0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2020 21:48:30 -0000

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.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: Tuesday, November 17, 2020 1:33 PM
> To: Tony Whyman <tony.whyman@mccallumwhyman.com>; ipv6@ietf.org
> 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 <markzzzsmith@gmail.com <mailto:markzzzsmith@gmail.com>> wrote:
> >>>
> >>>
> >>>      On Mon, 16 Nov 2020, 07:19 Philip Homburg, <pch-ipv6-ietf-6@u-1.phicoh.com <mailto:pch-ipv6-ietf-6@u-1.phicoh.com>>
> 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:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
> >>> Networking & Telecommunication Services
> >>> Office of Information Technology
> >>> University of Minnesota
> >>> 2218 University Ave SE        Phone: 612-626-0815
> >>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> >>> ===============================================
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------