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

[Brian E Carpenter <[e-mail]>]

Hi,

Fernando and I have been chatting off-list, so rather than responding in
detail below, here are just a few general observations:

1. We have a problem with the formal definition of "global". All it really
means in the IPv6 addressing architecture is "not link-local", which is
not "global" in the normal English sense. It really seems too late to
change that, but it's unfortunate.

2. The "globally reachable" term added by RFC 8190 isn't perfect either.
All it really means is "potentially globally reachable" because prefixes
don't *have* to be advertised in BGP4.

3. If we're picky, "local" in ULA isn't perfect either, since there's
nothing in the laws of physics to prevent a ULA prefix being advertised
in BGP4.

4. The following table attempts to show some of the distinctions
involved (simplified). View in a fixed-width font. You may not
agree with it...

Unicast       Prefix      IID        Routeable   Announced
address       assigned    assigned
types         by          by
-----------------------------------------------------------
Link-local    fixed       host       no          no
              by RFC
  
ULA           user/RA     host or    yes         IGP only
              (random)    DHCPv6

GUA           IANA/RIR/   host or    yes         IGP,
              ISP/user/RA DHCPv6                 BGP4 by policy

Regards
   Brian

On 30-Dec-20 04:00, Fernando Gont wrote:
> 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,
>