Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 19 February 2021 14:39 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 5DE9D3A0EED; Fri, 19 Feb 2021 06:39:00 -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 mKk7ksZkP7P0; Fri, 19 Feb 2021 06:38:58 -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 EDA603A0E7A; Fri, 19 Feb 2021 06:38:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 11JEcovA019519; Fri, 19 Feb 2021 09:38:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1613745532; bh=MSh2//i5EQ0yHee53XLxGNHmWNQgBfZ/OxkCb3c36wg=; h=From:To:CC:Subject:Date:From; b=FznhvQ/SRkCXBKGJfxAWEqubqzhZwcaJcwJ5y54GAMHaxT25nahYvNbQGjDuIiNQf bCDE93LDycnmLrdZVHyQgSc5vzX62634dfAoBOxYxikuxHkv9n/uzvlrymYRGuwXn9 YJ6iEC4bwuK4cJdIF1lkXoMh9xu/sazOpz63SR4qcSSzZZaBmHfvWLANiQCJiKdyvw xIGStu1bi1Eb6nIwNYepSmCcdktbXphy+wU1yWetUDyPIqGOXbBBUz/WAkSAuuSknl /g6mGGRDjOUeojo2fDNZtbLoHC13vRWUrDCKaCXiNqH3EwqWkkVQ3biTPn6rBCBMXm fkmK6UZoaoqag==
Received: from XCH16-01-09.nos.boeing.com (xch16-01-09.nos.boeing.com [144.115.65.234]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 11JEcfWN019332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 19 Feb 2021 09:38:41 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-01-09.nos.boeing.com (144.115.65.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2176.2; Fri, 19 Feb 2021 06:38:40 -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.2176.002; Fri, 19 Feb 2021 06:38:40 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Fernando Gont <fgont@si6networks.com>, "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
CC: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
Thread-Topic: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
Thread-Index: AdcGyvW3W+sVDlRSTeub7q63dLqlKA==
Date: Fri, 19 Feb 2021 14:38:40 +0000
Message-ID: <4f2246e2060c408ab029754f5a913b88@boeing.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: 2EDD88621C4D3A1A7AB10CCBF3172F282DE0E30D1852417A8B98C020891623DB2000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/I5tONb4yatKhN0AqSFphSJPP7W4>
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: Fri, 19 Feb 2021 14:39:07 -0000

I can see this discussion has wrapped back on itself somewhat, but please do not
be too quick to write off MANETs. With new use cases like Urban Air Mobility and
Intelligent Transportation Systems, MANETs (or, Vehicular Ad-hoc Networks
(VANETs)) will provide a common access network paradigm that is multihop
internally and only intermittently connected to the global Internet.

When the MANET is detached from the global Internet, mobile nodes will need
some form of multihop-compatible IPv6 address for MANET-local communications,
and HITs seem like a good fit.

When the MANET connects to the global Internet, mobile nodes can get a prefix
delegation from an infrastructure element such as a roadside unit and use true
GUAs to talk to Internet nodes beyond the MANET.

So, a mobile node will have a decision point about whether to use HITs or GUAs
and it seems like that needs to be somehow represented in the hierarchy of
available addresses - even if as some special case.

Fred

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: Thursday, February 18, 2021 4:36 PM
> To: Fernando Gont <fgont@si6networks.com>om>; Manfredi (US), Albert E <albert.e.manfredi@boeing.com>
> Cc: IPv6 Operations <v6ops@ietf.org>rg>; 6man@ietf.org
> Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-
> ipv6-ula-scope-00.txt)
> 
> So, my thought (and it belongs on this thread OR the 'IPv6 addressing: Gaps?' one) is something like:
> 
> We should abolish, delete, expunge and deprecate the word "scope" from all IPv6 documents. It clearly doesn't have an agreed
> meaning, so it is worse than useless.
> 
> All addresses have a region of reachability. This may be confined to a single "link" (whatever a "link" means), some type of limited
> domain (such as, but not limited to, a "site" (whatever a "site" means)), or to a large part of the Internet as a whole (knowing that
> there is in reality no such thing as "the" Internet.)
> 
> LL addresses MUST NOT be used off a given L2 link.
> ULAs MUST NOT be routed outside a given limited domain.
> GUAs MAY be routed anywhere.
> 
> (MANETs and other mesh networks don't fit in there very well.)
> 
> Regards
>    Brian
> 
> On 19-Feb-21 12:58, Fernando Gont wrote:
> > On 18/2/21 20:39, Manfredi (US), Albert E wrote:
> >> -----Original Message-----
> >> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Fernando Gont
> >>
> >>> Well, this is a spec inconsistency. You have one spec (RFC4007) defining
> >> "scope" and "global scope", and another specs:
> >>>
> >>> a) making use of the same terms in an incorrect way, or,
> >>>
> >>> b) employing same terms but with a different definition.
> >>>
> >>> i.e., either the definition in RFC4007 is incorrect, or the use in
> >> RFC4193 and implicit use in RFC4291 is incorrect.
> >>
> >> You can also argue, if there are prefix bits sent in the clear, and those prefix bits are used to send the packets to a pre-determined
> gateway, and that gateway is then used to decrypt all of the remaining address bits, then route packets through a walled garden
> intranet with global span, then global scope could still apply.
> >
> > "global span" is defined as "Internet-wide" span. i.e., if an address
> > does not unambiguously specify an interface Internet-wide, it's not
> > global scope as per RFC4007.
> >
> >
> >
> >> Just sayin'. These still aren't like RFC 1918.
> >
> > The only practical differences I see with respect to rfc1918 are:
> >
> > 1) ULAs are not intended to be used with NAT.
> > However, were RFC1918 strictly specified to be employed along with NAT?
> > Besides "not indended" != "won't be".
> >
> > 2) ULAs are intended to have a small probability of collision when a
> > subset of ULA-based networks are interconnected.
> >
> > This is the product of mandating that some bits are generated from a
> > PRNG, plus the fact that ULAs have more bits than their RFC1918 counterpart.
> >
> > If I have missed any other differences, please enlighten me. :-)
> >
> > Thanks,
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------