Re: [v6ops] draft-gont-v6ops-cpe-slaac-renum **Call for Adoption**

[Mikael Abrahamsson <[e-mail]>]

On Thu, 20 Feb 2020, Fernando Gont wrote:

>> However, I have some feedback.
>> 
>> "     *  Any prefixes that were previously advertised via SLAAC, but
>>           that are not currently intended for address configuration, MUST
>>           be advertised with a PIO option with the "A" bit set to 1 and
>>           the "Valid Lifetime" and a "Preferred Lifetime" set to 0.
>> "
>> This seems to try to address similar problem as L-13 in RFC7084? What's the 
>> rationale for requiring A=1 here? If A=0 was used before, why should it all 
>> of a sudden be 1?
>
> What the text means to say is that if the prefix was advertised for address 
> configuration (A=1), it should be advertised with A=1 and lifetimes of 0.

Ok, for me "SLAAC" doesn't mean "A=1". If that's what you mean, then write 
that.

> There's a couple of things to note here:
> * While re-reading L-13 from RFC7084, it seems the requirement is a bit 
> underspecified (e.g., regarding how to set A/L). Besides, the section from 
> 4862 being referenced is about *processing* of RAs, rather than about 
> *sending* RAs.
>
> * It would seem to me that one could say that the "A" and "L" bits of the 
> prefix should be set to the same values that have been employed before. 
> However, e.g. when A=0, the PIO is ignored for the purpose of 
> auto-configuration -- in the same way that a PIO with L=0 is ignored for 
> on-link determination. Therefore, if the whole point of including a PIO with 
> a known-to-be-stale prefix is to deprecate the prefix, it would seem 
> appropriate to for A and L to 1, and set both the Preferred and Valid 
> Lifetime to 0.
>
> Thoughts?

A=0 means it's ignored for autoconfiguration of addresses in that PIO, 
nothing else (a default route might still be configured). The word "SLAAC" 
is ambigous in what it means. I agree what you're saying, the flags should 
be kept the same, so I'd like the text changed to say that. So I propose 
that the word SLAAC is replaced with different text that says what you say 
above (which I now understand is what your intention was all along).

>
>
>> Another comment, in my home I use sub-delegation. As in "ISP->R1->R2" where 
>> ISP delegates /56 to me, and R1 delegates /<something> to R2 (depending on 
>> what OpenWrt feels like doing).
>> 
>> I'd like to have requirement for R1 and R2 to be able to figure out 
>> together that if the /56 from the ISP has changed, the DHCPv6-PD 
>> subdelegated prefix to R2 is no longer valid.
>
> Wouldn't a RECONFIGURE message be the appropriate way to go here? (although I 
> seem to recall folks noting that this is not widely implemented?)

I know this is what DHCPv6 folks thinks should be done. However, this is 
v6ops, and I see no reason why (if we have consensus) say that if the 
covering /56 RIO goes away or has zero lifetime, invalidate DHCPv6 
addresses and prefixes (or at least trigger a renew to verify that they're 
still valid).

This ties into similar mechanism that 
draft-patterson-intarea-ipoe-health-05 talks about.

> Does it send the same set of RIOs on all interfaces?

I don't know. It does send the encompassing PD as an RIO anyway.

> In any case... is it really needed? i.e., R2 know that /something is on-link, 
> and everything else needs to be sent to R1....

For the simplest use-case, yes. For more complex use-cases, no. If there 
are two routers sending RAs with two different prefixes, the RIO can tell 
which one of these should be used for traffic which /56.

> Maybe this calls for a document that specifies e.g. the interface between 
> DHCPv6-PD/SLAAC and DHCPv6-PD/DHCPv6-PD?  This would also specifiy things 
> such as: "based on what you get from your upstream, how/what you lease 
> downstream". And there are other things such as how you select subnet-ids, 
> etc.

I don't know exactly how to solve it and what documents would make more 
sense. I just know that this who problem space could work better if 
vendors did more. Right now there are gaps that mean unneccesary breakage.

-- 
Mikael Abrahamsson    email: [e-mail]