Re: [v6ops] What's "global"? -- Re: Possible issue with source address selection for ULAs...

George Michaelson <ggm@algebras.org> Thu, 13 January 2022 01:24 UTC

Return-Path: <ggm@algebras.org>
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 BBEC33A0AB5 for <v6ops@ietfa.amsl.com>; Wed, 12 Jan 2022 17:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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=algebras-org.20210112.gappssmtp.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 goIMNUoV4diE for <v6ops@ietfa.amsl.com>; Wed, 12 Jan 2022 17:24:00 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 DD37C3A0AB0 for <v6ops@ietf.org>; Wed, 12 Jan 2022 17:23:59 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id u13so14149762lff.12 for <v6ops@ietf.org>; Wed, 12 Jan 2022 17:23:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=imG2bFGPJIoamZg8z8Fh6nNMtrkhfw0oMp8ojpj7njU=; b=r4OAX5U2gOvgwKx1FwRxvILlo6KbVVvDzm/qzof0Oisae/DLEhgydPb+uS5nNo6SiP rf0OlbVFOYVqdUqe5tL3uetvJ2RsPJBaDMoNiOmTxNiGZoGJpp3tuq/j99V306hvoJuq MDG5eUoVsnhtANmvTauRazo6jeZkDLnljOpriqCPq+f6PmnuuDr58ycPUKuhcT6l4MzS sGPK6oePGl8VABiVWRLiDYd+DUBaki6xcYXD9QF+qMi+58liNFCnrb5TbO4g2vQbdIfs Z0TCb74ybfLQN17HMxdFYj9/6+wsPjXL5/Jn+zPVl0GiW1VUiNIl9wKLtOQWfv17ydVB atCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=imG2bFGPJIoamZg8z8Fh6nNMtrkhfw0oMp8ojpj7njU=; b=bqwu+RZZm/m3KtgIONO/5vMD7225BCwCEAIN/11TMR0AqQU0xo69Vuf90jY2vS53vS yqWfqOYCsAigmMWmP/N0ylgsbBg1MKkO3jHSSeq0hDzlMhYhGO8xF6tT4wQUyL8rc+Av SIlCpcRNn8tER/FOHzHtnFuDOzxcBWFLmTHQrRmACpqnJhGHb5sfDAZ3jPowAsMNPEHh dlISdLsGm9soMO4ZsxJmpinRECsfFeVdlc8DppVn3oL6rkybTIZB6gOFkXPHBSsK/lBF x/TDCioobAwD0i8R0++Cfd5wOeYktSlwvKRzl8UIkTK12yAOaInWbN3SiCAo0dymNdhy iupg==
X-Gm-Message-State: AOAM532zKXe/NxoCnz5iDN0IeqB2DyEcAH+JNzSlTkYWb1TjkTZHC+A8 if8jD06w/4FtEW7DQbX+drWgXZBtjAjHgpKaaj5SMA==
X-Google-Smtp-Source: ABdhPJwdgUg54440syXhkhP+LnwARCw9cXlIrWZNQzx4c82l+7vIszCwHiIUvn2uSFNtJ0jkMgNNb3Og7Lc36j9PQxk=
X-Received: by 2002:a2e:95cd:: with SMTP id y13mr1512461ljh.342.1642037036831; Wed, 12 Jan 2022 17:23:56 -0800 (PST)
MIME-Version: 1.0
References: <4DD59CC3-1BDB-4A1C-A33B-8CC3EDE622A8@chinaunicom.cn> <550d1375e15941199e23f3d7a309cb4d@huawei.com> <CAPt1N1mXK1nsJ=1wyKm-ToqLj=+j2hXrywAyNZmE0X67ipT89g@mail.gmail.com> <73353834-0DFD-4542-95B1-06BAD1F32D41@employees.org> <D4C144D3-4227-4102-A00C-10C2CB686AAE@gmail.com> <22084.1641333602@localhost> <16560b6f48ab4eb09a01ce2c64b423bc@boeing.com> <11213.1641397599@localhost> <641ed285-38bc-0789-d5b4-cab942da756a@gmail.com> <a9a3e3db-ea89-bc50-3052-37922a50cd07@hit.bme.hu> <4f22bc62-8892-932c-dbf6-8841a141a11f@gmail.com> <A813CEBA-4933-4605-861C-3645B5383F31@gmail.com> <CAPt1N1mDZGPP76-Fgw62RvSpAQ=bY7vxvm86Ut6WWvj+PDr3uA@mail.gmail.com> <656d1c3c-26ea-fdcf-6c27-d4c54ba8b8f8@gmail.com>
In-Reply-To: <656d1c3c-26ea-fdcf-6c27-d4c54ba8b8f8@gmail.com>
From: George Michaelson <ggm@algebras.org>
Date: Thu, 13 Jan 2022 11:23:45 +1000
Message-ID: <CAKr6gn0rLVpwS6CDU=DqycTUnCaLAVnCS=uox3VfRYi1t6npqw@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Ted Lemon <mellon@fugue.com>, Fred Baker <fredbaker.ietf@gmail.com>, IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/FCL4-ruEfSwtgT5CxeH2g76kzHg>
Subject: Re: [v6ops] What's "global"? -- Re: Possible issue with source address selection for ULAs...
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: Thu, 13 Jan 2022 01:24:05 -0000

Forgive a probably obvious corollary/comment:

"globally reachable" doesn't mean it IS routed. It means it COULD BE.
Nobody should have bit marker rules to deny its routability, whereas
the others could have "don't route me bro" qualities by their bitmark
(multicast aside)

On Thu, Jan 13, 2022 at 11:11 AM Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> Ted,
>
> We have IETF rough consensus for the text in RFC8190/BCP153:
>
> "  Globally Reachable - A boolean value indicating whether an IP
>     datagram whose destination address is drawn from the allocated
>     special-purpose address block is forwardable beyond a specified
>     administrative domain."
>
> and we have IETF rough consensus for the text in RFC4291 (PS):
>
> "
>     The type of an IPv6 address is identified by the high-order bits of
>     the address, as follows:
>
>        Address type         Binary prefix        IPv6 notation   Section
>        ------------         -------------        -------------   -------
>        Unspecified          00...0  (128 bits)   ::/128          2.5.2
>        Loopback             00...1  (128 bits)   ::1/128         2.5.3
>        Multicast            11111111             FF00::/8        2.7
>        Link-Local unicast   1111111010           FE80::/10       2.5.6
>        Global Unicast       (everything else)
> "
>
> Perhaps surprisingly, uniqueness is not defined as a required
> property of a Global Unicast address in that RFC. In practice,
> because of ULAs or any other kind of limit on forwarding, the
> practical implication of the "Global Unicast" property is "this
> address MAY be forwarded off link and its prefix MAY be the
> subject of a routing protocol."
>
> Nothing more, so ULAs are simply a subset of Global Unicast,
> routable but not globally reachable.
>
> Regards
>     Brian Carpenter
>
> On 13-Jan-22 07:20, Ted Lemon wrote:
> > I don't think there's strong agreement on this, actually. We've had discussions about it before (maybe not here?). What I think "global scope" means is that the identifier is presumed to be globally unique. It doesn't
> mean that the identifier /is/ globally unique: just that we expect to be able to treat it as it is. I think that this is pretty close to what you said, but just thinking about it from a different angle.
> >
> > On Wed, Jan 12, 2022 at 1:04 PM Fred Baker <fredbaker.ietf@gmail.com <mailto:fredbaker.ietf@gmail.com>> wrote:
> >
> >     Please correct my understanding.
> >
> >     My understanding of "global scope" is that one could imagine the address being reachable from a non-local site, such as a site the the UAL owner/user has an agreement with, while "globally reachable" is a statement about routing and may or may not be true of any address that isn't local in scope. Close?
> >
> >      > On Jan 5, 2022, at 1:08 PM, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> >      >
> >      > On 06-Jan-22 09:12, Gábor LENCSE wrote:
> >      >> 1/5/2022 8:51 PM keltezéssel, Brian E Carpenter írta:
> >      >>>> If I can avoid using ULA, I would always do that.
> >      >>>
> >      >>> All the same, it seems that we really need a document that
> >      >>> characterises use cases for ULA usage and suggests guidelines.
> >      >>> We've tried and failed to do that it in the past, so the
> >      >>> issue keeps coming up.
> >      >>>
> >      >> Did you mean this one?
> >      >> https://tools.ietf.org/id/draft-carpenter-6man-whats-global-00.txt <https://tools.ietf.org/id/draft-carpenter-6man-whats-global-00.txt>
> >      >> I am not sure, what the best fix could be, but I think it would
> be worth
> >      >> trying to find one. :-)
> >      >
> >      >
> >      > No, I meant the previous serious attempt:
> >      > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-considerations/ <https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-considerations/>
> >      > but since we never reached WG consensus on that, a different approach seems
> >      > to be needed.
> >      >
> >      > The "what's global?" issue was formally resolved by RFC8190 (part of BCP153). This fixed the IANA terminology to use "globally reachable"
> at https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml <https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml>. But the problem isn't resolved in the real world: for example the Python ipaddress library is still wrong, since it doesn't distinguish "global scope" (should be True for ULAs) from "globally reachable" (should be False for ULAs).
> >      >
> >      >   Brian
> >      >
> >      >> Gábor
> >      >>> Regards
> >      >>>    Brian
> >      >> _______________________________________________
> >      >> v6ops mailing list
> >      >> v6ops@ietf.org <mailto:v6ops@ietf.org>
> >      >> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> >      >
> >      > _______________________________________________
> >      > v6ops mailing list
> >      > v6ops@ietf.org <mailto:v6ops@ietf.org>
> >      > https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >     _______________________________________________
> >     v6ops mailing list
> >     v6ops@ietf.org <mailto:v6ops@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops