Re: [v6ops] [EXTERNAL] Re: Next step? [Re: The bottom is /112]

Mark Smith <markzzzsmith@gmail.com> Sun, 22 November 2020 20:10 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCA93A0C1D; Sun, 22 Nov 2020 12:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.93
X-Spam-Level:
X-Spam-Status: No, score=0.93 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.626, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 80CU1AKXKY1u; Sun, 22 Nov 2020 12:10:32 -0800 (PST)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 4CD463A0C1B; Sun, 22 Nov 2020 12:10:32 -0800 (PST)
Received: by mail-oi1-x22e.google.com with SMTP id j15so12021369oih.4; Sun, 22 Nov 2020 12:10:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m7QQ7U0FXlPlMWKGcTZ7Id06XE/G6oELz96dgSEhGjA=; b=Xb1YgFp6/HzoZdHk2XDlapPsMnf/mZvd8zDZ2dD+2IFwl7FT9w23D9H8KdXtrfirYd q/HMe2IPFyL8p19eAivfdt5ousthnhtyb7yJ9iFHTw9+pnmlaeUkn8XKRyb6vX8xmsoT Dp/94PM77QfTQOs6CP7DwGAfdVdtgztjtcj24JysvSLVllEEAiUsrtchzG1xaqW4eYZG pK9lTFID/2Fq42fVIFSHmOBiWNLbRhogSQGVp80bITrZAMDbX7IL4ErNI3z6Bg3Yclbh 1H61ipOiB4i1TkoEER6UcIrjKl4CWY7fd5y2x8jFvt3HLFJg5Qfag1W6Aua+YjAFHOxk fZeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m7QQ7U0FXlPlMWKGcTZ7Id06XE/G6oELz96dgSEhGjA=; b=h1n/YD3Flfuu3Vahq1PEZpkMYeGN9tvJ2digomhJ4X2FtddObK3+aWkz4+bzDWG+MQ A11rPWoV1XZnfT7ViX30ZlDHgug57u2VOoRZk5W2WdAlWWDuQ5Yj59vKQqlgJyLI3QC9 U0l3nxIEg2a3x6F0tEarPesqIPCnUikbffPGZtiZ/nkSOsSiiGc3Ap3lXZnJVdKoHI8x M5aemB/76pVxGharOPaiyPW8fIlYhQjnk3XH6NEO5qTUcBu89OtREQ8l3aflKDL71iYM CmZFqJC0y0y0U+25v7rxeLENNQY00c1gs6eUBTHLik5nARRNewcbpPKGvBZp+Pq4ltML fCRw==
X-Gm-Message-State: AOAM530jQlXGa6zPRbqqUEpc/Kcv5qK/htrBsd4nSlpOMlGqxk8/VU6q dsd5aRO+TiBGzKL0FBAov7F5nAqW5shK81Ciz+M=
X-Google-Smtp-Source: ABdhPJxTcSnjclpVcX1ZAlOWKf5PDsJ7LlFvmpSwyX3y4/bUKPjzvSHdzdiY0DqGuSSeCEMztqk+VLT/a0ICi68TJmQ=
X-Received: by 2002:aca:d755:: with SMTP id o82mr12121620oig.164.1606075831415; Sun, 22 Nov 2020 12:10:31 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV3fj-e9bEemivcNovnD3SZvKm8ZjFKp7BmusnPcgyznFQ@mail.gmail.com> <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <CABNhwV19neE3U_AisNp2nDUF4bWB8P8xHNEznDevZLE9amFTRA@mail.gmail.com> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <CABNhwV3bCss9y7cT6w2i+LKWBh1viPSXBM-CTaK+GVDyPS2D8w@mail.gmail.com> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <CABNhwV0-FZpPs84+RVB81=5H5QCEaxF0EUj9tcV+bdOu00RE2A@mail.gmail.com> <fb87c22c-388d-0492-1ea7-018655353f9b@joelhalpern.com> <CABNhwV0TbS7Kiynb=jvczJFDyy=uMfd-he+d0ii7aU5AnsUKeA@mail.gmail.com> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <CABNhwV1pSiEuaOZGN5ErR=KETjD1fVb58YM1EEd+mf7RtOenQw@mail.gmail.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> <CAO42Z2yvXCfn8bxxk7mT7MozmCyexmVKNCOvktf2sV-S7WPxig@mail.gmail.com> <CAD6AjGQCm4U06huxns6qGKPAa-MqbeaHpjZAhpBuv-S13xo44Q@mail.gmail.com> <e9b3d9e654c14020bebd83d3156c7d2c@boeing.com>
In-Reply-To: <e9b3d9e654c14020bebd83d3156c7d2c@boeing.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 23 Nov 2020 07:10:19 +1100
Message-ID: <CAO42Z2yQ73KH30pNVe9xGewsGda_tnQGJB9KHaJ5Xn2hENh=TA@mail.gmail.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: Ca By <cb.list6@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, IPv6 Operations <v6ops@ietf.org>, 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000069f9a205b4b7ab70"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/cgM1IWupEBfOJ55LtHbtSJ1xoJg>
Subject: Re: [v6ops] [EXTERNAL] Re: Next step? [Re: The bottom is /112]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Nov 2020 20:10:34 -0000

On Mon, 23 Nov 2020, 01:59 Templin (US), Fred L, <Fred.L.Templin@boeing.com>
wrote:

> Hi, I believe the AERO/OMNI approach to prefix delegation would be good
> for the 3GPP
> case also. The approach is predicated on the router returning an RA with
> an IPv6 link-local
> destination address determined by the delegated prefix. The link-local
> address is formed
> by writing the most significant 64 bits of the delegated prefix into the
> interface ID of the
> prefix fe80::/64.


> For example, if the delegated prefix were 2001:db8:1:0::/56 then the IPv6
> link-local
> destination address is fe80::2001:db8:1:0. This provides at least two
> important
> operational advantages.
>
> 1) It conveys the delegated prefix in the IPv6 destination address of the
> RA so that
> no PIOs inside the RA need to be used for prefix delegation.
>

In my operational experience it is far better to make things explicit in
packets rather than implicit.

See RFC8469 for an example of where what was implicit in packets has caused
so many problems that now being explicit has become the recommendation.
(Absence of this in a wholesaler's network caused us and a customer months
of troubleshooting for unusual performance problems, and is now costing us
service outages for many customers at once while they put it in place.)



> 2) It supplies the mobile node with a guaranteed-unique link-local address
> that
> it can use for future communications without the need to perform DAD.



So the RA DA is carries both delegated prefix information and with
link-local address configuration too? How does a node know to use the RA DA
as its link-local address?

With the rise of wireless we need to care about the global traceability of
link-local addresses too. Persistent, globally unique link-local IIDs have
the same privacy implications as persistent globally unique WiFi MAC
addresses and Bluetooth MAC addresses.

Have a look at https://wigle.net and the Android app for collecting the
data.

A similar app focused on Bluetooth is Ramble.

Neither of these apps require a hacked phone, the can just be installed and
run by anybody from the Google app store.


> Again, the proposal comes from the AERO/OMNI use case, but I believe is
> also
> good for 3GPP and really any other wireless use case where a lightweight
> prefix delegation capability is desired.
>
> Fred
>