Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt

Fernando Gont <fgont@si6networks.com> Tue, 29 December 2020 15:01 UTC

Return-Path: <fgont@si6networks.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 5C5263A1420; Tue, 29 Dec 2020 07:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 GAdZDzfXZi9O; Tue, 29 Dec 2020 07:01:53 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B81D3A141E; Tue, 29 Dec 2020 07:01:47 -0800 (PST)
Received: from [10.0.0.134] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8D5C2280496; Tue, 29 Dec 2020 15:01:42 +0000 (UTC)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, IPv6 Operations <v6ops@ietf.org>, draft-gont-v6ops-ipv6-addressing-considerations@ietf.org
References: <160770241261.18071.12524922630334294118@ietfa.amsl.com> <fb832698-039e-baa5-ed6f-4d5a97e7b354@gmail.com> <299f492f-4cb7-fa9d-967f-b2a5df49034e@si6networks.com> <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <b20425a3-8069-3823-4610-79c93714ad2f@si6networks.com>
Date: Tue, 29 Dec 2020 12:00:27 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/lKpx59Cs1kITAryjf0pEON7ybys>
Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt
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: Tue, 29 Dec 2020 15:01:58 -0000

Hi, Brian,

Thanks for following up! In-line.....

On 24/12/20 19:15, Brian E Carpenter wrote:
[....]
>>
>> Now, my question is: why do this in the first place? What I would expect
>> is that you simply use the address. Then, if the same node attaches to
>> two networks that employ the same prefix, that's a configuration
>> problem. Period. *If* in such scenario, *and for debugging purposes* you
>> want to be able to specify which interface to use to send packets to a
>> site-local address (that looks like "on-link" on two different
>> interfaces), then you use the zone index -- but that's for *debugging*
>> purposes, since having two subnets employ the same site-local prefix
>> would be an error.
> 
> If you read RFC4007 

I had read RFC4007 in the past -- *years* ago. So I've just given it a 
fresh read.

Some initial questions:

* Any reason why this document is a separate/stand-alone document rather 
than part of RFC4291 (or RFC3513)?  Or, at the very least, any reasons 
why it does not even *update* one of those? (RFC3513, since RFC4007 
obviously predates RFC4291)  (particularly since it's Std Track)

* Section 5 states:
    Each interface belongs to exactly one zone of each possible scope.
    Note that this means that an interface belongs to a scope zone
    regardless of what kind of unicast address the interface has or of
    which multicast groups the node joins on the interface.

This would seem to imply that an interface cannot employ two different 
ULA prefixes? -- Why?  (unless their scope is considered global, and all 
ULAs plus GUAs are all considered to be part of the same global scope zone)



> you will *not* find that a zone index is formally
> equated to an interface index. The "zone" terminology is confusing since
> it did originally assume a nested scope model, link-local inside site-local
> inside global. 

(me thinking out loud) It seems that it *cannot* be equated, since an 
interface may (and usually will) belong to multiple zones.

So the zone index somehow ends up being the combination of "address" + 
"interface index", where the implementation infers the scope from the 
"address"?    (this isn't really a "zone index", though).



> By some magic the host was supposed to understand enough
> of the network topology to use a single value "zone index" to capture
> the topology and tell the drivers which interface to use. See diagrams
> at https://sites.google.com/site/bcabrc/miscellany .
> Slides 3 and 4 show scenarios that simply can't be captured
> by a one-dimensional zone index. In practice, of course, the zone index
> is only meaningful within the host. 

Isn't this the case *by definition*?



> So the whole concept of a zone
> index for nested scopes was a mistake. With hindsight, we should
> have cleaned that up more definitively in RFC4007.

You mean that it's problematic for the node to *automatically* determine 
which zone an address belongs to?

If so, yes -- that seems unfeasible. The best you can hope is the 
"default zone index" (which can indeed fail), or manual specification of 
the "zone index".




>> Regarding #2:
>> Modulo the above, for the most part non-global addresses *are*
>> ambiguous. So this is kind of a feature.
> 
> Yes, but not a *good* feature since it leads to the problems
> in my slides 3 and 4.

But... are site-locals special in this respect?  -- As with link-locals 
on multi-interface nodes, you either manually pick the outgoing 
interface (and hence the zone), or your rely on the default zone index 
(and cross your fingers :-) ).



[....]
>>>> 3.2.  Unique Local IPv6 Unicast Addresses (ULAs)
>>> ...
>>>> However, the only reasons for which these addresses are considered
>>>> to have "global scope" are:
>>>>
>>>> o  given two different networks that employ ULAs, it's unlikely
>>>> that they will employ the same ULA prefix
>>>
>>> Not at all. The reason they formally have global scope is because
>>> when site-local was scrapped (as being meaningless and unenforcable,
>>> see RFC3879), only two scopes were left: link-local and global.
>>> There was no other choice.
>>
>> Why not, say, "IPv6 Private Address Space"? -- Yes, in the light of
>> "ipv6 is all about the global addresses", mimicking IPv4's private
>> addresses probably wasn't "sexy", but IMO the concept is useful, and
>> well understood.
> 
> I think that adds confusion. They are only private because of the
> requirement to block them in border routers; it's not a property
> of the address itself. 

In a way, isn't that the case for all non-global addresses?  e.g. for 
link-locals as Destination Addresses it's kind of hardcoded. But for 
link-locals employed as Src Address, you also need the requirement for 
routers to drop the packets to prevent these addresses from leaking out 
of their zone. (But yes, for link-locals this check can also be hardocded).



> (Thumbs down to the Python ipaddress module
> by the way, which has invented an "is_private" property and gets
> "is_global" wrong for ULAs.)

Assuming ULAs are flagged as "global", I guess that's a consequence of 
RFC4291 (or it's antecessor) not being updated by the ULA spec?





>>> What that means is that protocols treat
>>> them *exactly the same* as RIR-assigned prefixes. That applies to
>>> all protocols: ND, RA, DHCPv6, and every routing protocol. They are
>>> only treated differently by policy, such as address selection policy
>>> or boundary router policy.
>>
>> Wouldn't this also be the case if they were redefined as "IPv6 private
>> address space"?  i.e., from the point of routing, modulo the link-local
>> prefixes, you simply have prefixes that you distribute information
>> about.  i.e. "Private address space" (i.e., non-global) shouldn't be
>> treated differently by routing protocols.
> 
> It's true, but that's what the "global" property means, and it's different
> from "globally reachable". 

You mean "global" as in "global scope"?

Section 4 of RFC4007 says:
    Every IPv6 address other than the unspecified address has a specific
    scope; that is, a topological span within which the address may be
    used as a unique identifier for an interface or set of interfaces.

As you noted in a previous email, this is probably unlikely for 40-bit 
global IDs (but should compute the birthday problem for this case) -- 
this might improve with RFC7217 (assuming randomized secret_keys for the 
algorithm)... but you could still have manually configured IIDs. So in 
that sense, I wouldn't consider ULAs as "global scope", either.

(must admit had to go through RFC8190 and friends a few times...)

Thanks, and Happy Holidays!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492