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

[Mikael Abrahamsson <[e-mail]>]

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.

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?

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.

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

-- 
Mikael Abrahamsson    email: [e-mail]