Why this is broken [was Re: Extending a /64]
Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 16 November 2020 20:21 UTC
Return-Path: <brian.e.carpenter@gmail.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 3ECBC3A13BD for <ipv6@ietfa.amsl.com>; Mon, 16 Nov 2020 12:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=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=gmail.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 HqglSb2qrRbX for <ipv6@ietfa.amsl.com>; Mon, 16 Nov 2020 12:21:05 -0800 (PST)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40E03A13CD for <ipv6@ietf.org>; Mon, 16 Nov 2020 12:21:03 -0800 (PST)
Received: by mail-pf1-x432.google.com with SMTP id w6so15254410pfu.1 for <ipv6@ietf.org>; Mon, 16 Nov 2020 12:21:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=G9Me5H4HxnlcM5ww7eSanprfKug7S4ARY4NwlnZPOcw=; b=V8rLstBCBIUzpXaCHi1fbvnDYdc6PbZiX+8wz960QLN2NVfxocRmlOvfSS0wxtHPKL dgwb/sSu1E7UpPyUl52iyIxPBUEz1YiRR35sjsaP6oBoheP1mGIGU+UvDiyD84Nhe9bV H6q9ab26+gjZvPQ38aMSc0RSh+H1LGK0McHyacJWrEGxpy/NiBBtknNfI+gsEnCyIlak mCluhl7eVPIoHrr1qi8m5auh0CydXgcuanO2Wwxbcv4cgVK42eGMr/AKye97tAcut/Oj rpLbY93l/K+E3COGpE44d+Go1AEPJjn8bkkbK/RRf9xCkBBYY69RlbTHA0J+sQoJdDGK Rk+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G9Me5H4HxnlcM5ww7eSanprfKug7S4ARY4NwlnZPOcw=; b=Z+8efFNJtQL9WOs0UFZRbZAKcWmq2sejWTasNbTws+eBVjHG3bsrLkv8BdT3UihKDb FX0nDXVosgCXuuXFYLy7kkrGzOK0dEWsIRBXGxpWbt9iFo9AUqyzy5ItbJ/PHDDJwwGY lSxv2FwlL++aYQdjA7ILiVYegcoK+9gGKzwWcAPFyAFinS4HEvgQe8BwhXu6iOpkzaZj N+jCAAd/aQc7dDIs3cN8V8NWoBlaa2hrUOZj6RFPfOkFH6b4ogBYjGUHyKE+5vh3HAkx THJ41863Q4Lx99GaD+DojdMYtN/J+U7zkU/3rIk5Eyw18BNVQ1tiJdxPzvSFDl2wrHQK Jzrw==
X-Gm-Message-State: AOAM533vaccic+81S4efiDXE9bPHyDoy+fLG+KrbqFkqrkSw8n9TVcH8 WB9tgjd3KQzVrFAdVe+vejahXlqC5MdYOA==
X-Google-Smtp-Source: ABdhPJwzO/xEOr/P0OI4HPJkMkMgVC/k6YSeVcatu3fCaMdJPJaBTKsCaonmqGGnfCKkIfnxGSY51g==
X-Received: by 2002:aa7:8f09:0:b029:18c:4cc6:891d with SMTP id x9-20020aa78f090000b029018c4cc6891dmr15177972pfr.46.1605558062770; Mon, 16 Nov 2020 12:21:02 -0800 (PST)
Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id s21sm5091185pgm.65.2020.11.16.12.21.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 12:21:02 -0800 (PST)
Subject: Why this is broken [was Re: Extending a /64]
To: Tony Whyman <tony.whyman@mccallumwhyman.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, ipv6@ietf.org
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> <5f505585-1328-d942-2ec2-a2d96b7b4779@foobar.org> <m1kePdR-0000I6C@stereo.hq.phicoh.net> <b022d11f-b55d-07ef-307d-949ff57cd562@foobar.org> <m1keS7i-0000E0C@stereo.hq.phicoh.net> <f06db586-15ed-6dd3-d09f-06a4e3759275@mccallumwhyman.com> <m1kecJm-0000EOC@stereo.hq.phicoh.net> <5101F72E-4197-4E58-8DEF-9EB9D5541482@thehobsons.co.uk> <m1kefWI-0000ETC@stereo.hq.phicoh.net> <845e43f9-4534-a125-3105-9d345b85029f@mccallumwhyman.com> <f18f1e55-6c8f-2963-7e3a-f22a89dda46d@joelhalpern.com> <0443de45-931d-fbda-20ab-2931383a3a8d@mccallumwhyman.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <61f8e6f7-1bfd-4c17-9e42-dc5fc10a19b5@gmail.com>
Date: Tue, 17 Nov 2020 09:20:57 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <0443de45-931d-fbda-20ab-2931383a3a8d@mccallumwhyman.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bnHSyshtojEDK9TwoAsjrUfn1uM>
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: Mon, 16 Nov 2020 20:21:07 -0000
On 17-Nov-20 04:26, Tony Whyman wrote: > On 16/11/2020 14:50, Joel M. Halpern wrote: >> Tony, why are you embedding the 39 bit airplane ID into the IPv6 >> address. That seems to be the fundamental thing that then has you >> need very short prefixes, and doing other difficult operations. >> >> And if the answer is "ICAO said so", then we have a problem of really >> smart aviation engineers doing network engineering. >> >> Yours, >> Joel > > Perhaps the best way to answer this question is to look at the alternative. > > Aircraft MNPs are non-topological Thank you for that clear statement. Internet routing *is* topological. Therefore, you cannot use bits in the routing prefix for non-topological information. Therefore, you cannot put 39 magic bits into the routing prefix; the Internet doesn't work like that. End of story. Back to the drawing board. This is so badly conceived that I suggest an IETF liaison statement to ICAO may be needed. There's nothing to stop you putting those 39 bits into the Interface Identifier of the aircraft's IPv6 addresses. That would need a slightly different version of RFC7217, but would still allow 25 entropy bits. However, you should be aware that IP addresses are intrinsically forgeable. I'm not sure I would want to fly on an aircraft whose identity might be trivially forged. Also, it would be trivial for an attacker to observe that a particular address belongs to a particular aircraft. One more comment below... > and hence could be densely allocated. > However, if you want to go the distance and specify the minimum length > identifier then: > > 1. You need to set up a new registration database for aircraft (in order > to assign the new identifier) and one that is global rather than state > based - which is the present approach. > > 2. You need to update the specification for the Aircraft Personality > Module and organise the fleet wide upgrade necessary to ensure that > every affected aircraft gets a new ICAO global Aircraft Identifier. > > 3. Safety Authorities will now identify a new hazard potentially > resulting from a mis-match between the existing ICAO 24-bit identifier > (which still has to be used for radar, ADS-B, TCAS, etc.), and the new > airframe identifier. > > 4. We need to develop procedures and systems for mitigating the new > hazard, assuming it is deemed serious enough. > > 5. The protocol gateways that are planned to avoid having to upgrade the > existing ATC Systems in the same timeframe would now have to include a > lookup table between the "old" NSAP Addresses and the "new" IPv6 Addresses. > > 6. The Safety Authority would identify a new hazard resulting from a > table configuration/maintenance error and procedures/mitigations would > be needed to counter the threat. > > 7. The address mapping would have to extend to the application protocols. > > In other words - a lot of negatives each with a potentially large cost > attached to them. > > The next step is to accept that it is worth "wasting" a few more bits > and using the existing ICAO 24-bit aircraft identifier instead of some > new global aircraft identifier. This avoids issues 1 to 4 above. > > In order to avoid 5, 6 and 7, we need to have a simple algorithm to > convert between aircraft ATN/OSI NSAP Addresses and ATN/IPS IPv6 > Addresses. Are you aware that we already "solved" that in 1996 (https://tools.ietf.org/html/rfc1888), and scrapped it in 2005? Regards Brian > The existing (legacy) NSAP Address format for aircraft > addresses starts off with some constant prefix and is then followed by > an airline identifier, the ICAO 24-bit identifier, an 8 bit subnet id > and a 48-bit End System id (it follows a structure originally proposed > by NIST). The last two can be readily combined into a 64-bit host > identifier. Indeed, if we based the MNP on the ICAO 24-bit then the only > thing stopping a simple algorithm is the missing airline identifier part > - this cannot be readily predicted from the ICAO 24-bit identifier > without access to the registration database. > > In order to avoid a lookup table in the protocol gateway, etc. we need > to have an airline identifier in the MNP. 15 bits appears to be the > minimum we can get away with (in order to avoid a new airline > identifier, the proposal is to generate a 15-bit identifier by encoding > the existing ICAO three character airline identifier using ITA-2 letter > shift). Hence 24 +15 = 39. > > The industry's network providers also regard embedding an airline > identifier in the MNP as highly desirable. It is used in the existing > system for diagnostic purposes and firewalls. > > This is not an "ICAO says so" at all. This is practical engineering to > deliver a new system as an evolution from an existing system and with > limited budgets. Start with a clean sheet of paper and you could use a > lot less that 39 bits. Unfortunately, we do not have that luxury. > > Tony > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
- Extending a /64 otroan
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 otroan
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Alexandre Petrescu
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Ca By
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 otroan
- Re: Extending a /64 JORDI PALET MARTINEZ
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: [EXTERNAL] Re: Extending a /64 Mark Smith
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: Extending a /64 Brian E Carpenter
- Re: [EXTERNAL] Re: Extending a /64 Gyan Mishra
- Re: [EXTERNAL] Re: Extending a /64 Mark Smith
- Re: Extending a /64 otroan
- Re: [EXTERNAL] Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: [EXTERNAL] Extending a /64 Gyan Mishra
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 JORDI PALET MARTINEZ
- Re: Extending a /64 Pascal Thubert (pthubert)
- Re: Extending a /64 George Michaelson
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Christopher Morrow
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 otroan
- Re: Extending a /64 Christopher Morrow
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Alexandre Petrescu
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Mikael Abrahamsson
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Mikael Abrahamsson
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 S Moonesamy
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 JORDI PALET MARTINEZ
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 JORDI PALET MARTINEZ
- Re: Extending a /64 Simon Hobson
- Re: Extending a /64 Joel M. Halpern
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Joel M. Halpern
- Re: Extending a /64 Alexandre Petrescu
- Re: Extending a /64 Alexandre Petrescu
- RE: Extending a /64 Da Silva, Saulo
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Templin (US), Fred L
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Alexandre Petrescu
- Re: Extending a /64 Behcet Sarikaya
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Joel M. Halpern
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Templin (US), Fred L
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Templin (US), Fred L
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Tony Whyman
- RE: Extending a /64 Da Silva, Saulo
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Mark Smith
- Why this is broken [was Re: Extending a /64] Brian E Carpenter
- RE: [EXTERNAL] Why this is broken [was Re: Extend… Templin (US), Fred L
- Re: [EXTERNAL] Why this is broken [was Re: Extend… Matthew Petach
- Re: Why this is broken [was Re: Extending a /64] Tony Whyman
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: Why this is broken [was Re: Extending a /64] Brian E Carpenter
- Re: Extending a /64 David Farmer
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 (ATN/IPS worked example) Tony Whyman
- Re: Extending a /64 Tony Whyman
- Re: Why this is broken [was Re: Extending a /64] Tony Whyman
- Re: Extending a /64 (ATN/IPS worked example) Philip Homburg
- Re: Extending a /64 (ATN/IPS worked example) Tony Whyman
- Re: Extending a /64 David Farmer
- Re: Extending a /64 (ATN/IPS worked example) Philip Homburg
- Re: Extending a /64 Tony Whyman
- Re: [EXTERNAL] Why this is broken [was Re: Extend… Behcet Sarikaya
- Re: Extending a /64 Simon Hobson
- Re: Cellphones in aircraft [was: Why this is brok… Simon Hobson
- RE: [EXTERNAL] Why this is broken [was Re: Extend… Templin (US), Fred L
- Re: [EXTERNAL] Why this is broken [was Re: Extend… Behcet Sarikaya
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 (ATN/IPS worked example) Brian E Carpenter
- Re: Why this is broken [was Re: Extending a /64] Matthew Petach
- RE: [EXTERNAL] Re: Why this is broken [was Re: Ex… Templin (US), Fred L
- Re: Extending a /64 (ATN/IPS worked example) Templin (US), Fred L
- Re: Extending a /64 (ATN/IPS worked example) Brian E Carpenter
- Re: Extending a /64 (ATN/IPS worked example) Brian E Carpenter
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- Re: Extending a /64 (ATN/IPS worked example) Templin (US), Fred L
- Re: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Brian E Carpenter
- Re: Extending a /64 (ATN/IPS worked example) Brian E Carpenter
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Manfredi (US), Albert E
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- Re: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Philip Homburg
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Manfredi (US), Albert E
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 (ATN/IPS worked example) Michael Richardson
- Re: Extending a /64 (ATN/IPS worked example) Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 (The most welcome comment) Tony Whyman
- Re: Why this is broken [was Re: Extending a /64] Behcet Sarikaya
- Re: Extending a /64 (The most welcome comment) Brian E Carpenter
- RE: [EXTERNAL] Re: Extending a /64 (The most welc… Manfredi (US), Albert E
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 (The most welcome comment) Templin (US), Fred L
- RE: Extending a /64 (The most welcome comment) Manfredi (US), Albert E
- Re: Extending a /64 (The most welcome comment) Brian E Carpenter
- RE: [EXTERNAL] Re: Extending a /64 (The most welc… Templin (US), Fred L
- Re: Extending a /64 (The most welcome comment) David Farmer
- Re: Extending a /64 Michael Richardson
- Re: Why this is broken [was Re: Extending a /64] Michael Richardson
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Mark Smith
- Re: [EXTERNAL] Re: Extending a /64 (The most welc… Tony Whyman
- RE: [EXTERNAL] Re: Extending a /64 (The most welc… Pascal Thubert (pthubert)
- Re: [EXTERNAL] Re: Extending a /64 (The most welc… Tony Whyman
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Tony Whyman
- Re: [**EXTERNAL**] Re: Extending a /64 Mudric, Dusan
- Re: [**EXTERNAL**] Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 (The most welcome comment) Templin (US), Fred L
- Re: [**EXTERNAL**] Re: Extending a /64 tom petch
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Nick Hilliard
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Nick Hilliard