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

[Fernando Gont <[e-mail]>]

Hello, Mikael,

In-line....

On 10/2/20 09:37, Mikael Abrahamsson wrote:
> On Sun, 12 Jan 2020, Ron Bonica wrote:
> 
>> Folks,
>>
>>
>>
>> Each week between now and IETF 107, we will review and discuss one 
>> draft with an eye towards progressing it.
>>
>>
>> This week, please review and comment on draft-gont-v6ops-cpe-slaac-renum.
>>
>> When reviewing this draft, please indicate whether you think that 
>> V6OPS should adopt it a s a work item.
> 
> I support the adoption of this document, this problem space needs to be 
> figured out.

Thanks for your support!


> 
> 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.

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?



> 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?)



> OpenWrt uses RIOs to advertise what routes are available through which 
> router, so one way would be for R2 to inspect the RIOs and if R1 changes 
> the /56 RIO to zero something, then it should also consider the 
> subdelegated prefix potentially invalid and try to renew it from R1.

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

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....



>  So 
> basically enhancing 2.1 and 2.2 in draft-gont-v6ops-cpe-slaac-renum to 
> also look at RIOs? But then, we also would need a document to tell how 
> to use RIOs, since RFC7084 (L-3 for ULA) is silent on what to put in 
> RIOs for GUA prefix (unless it's there but I can't find it)?

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.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492