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

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>; Manfredi (US), Albert E <albert.e.manfredi@boeing.com>
> Cc: IPv6 Operations <v6ops@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)
> 
> 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
> --------------------------------------------------------------------