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

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Feb 2020 13:37:16 +0100 (CET)

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: [email-masked]

---

From: Job Snijders <[email-masked]>
Date: Mon, 10 Feb 2020 07:42:52 -0600

Hi,

I think this work should indeed be adopted.

Kind regards,

Job

On Sun, Jan 12, 2020 at 17:18 Ron Bonica <rbonica=
[email-masked]> wrote:

>                                                       Fred and Ron
> Juniper Business Use Only
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 10 Feb 2020 17:16:06 +0000

Hi,

I have some comments on the draft that I hope to find time to make, but I certainly support its adoption for further discussion within the WG towards publication.

Tim

On 10 Feb 2020, at 13:42, Job Snijders <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Kind regards,

Job

On Sun, Jan 12, 2020 at 17:18 Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:

Folks,

                                                      Fred and Ron

Juniper Business Use Only
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 11 Feb 2020 15:22:52 +0800

Hi, folks,
I think it should be adopted as a working document. Thanks
Chongfeng 

On Sun, Jan 12, 2020 at 17:18 Ron Bonica <rbonica=[email-masked]> wrote:
Folks,

 
 
                                                      Fred and Ron

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Feb 2020 02:18:19 -0300

Hello, Mikael,

In-line....

On 10/2/20 09:37, Mikael Abrahamsson wrote:
>> Each week between now and IETF 107, we will review and discuss one 
>> draft with an eye towards progressing it.
>>
>>

Thanks for your support!

> the rationale for requiring A=1 here? If A=0 was used before, why should 

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?

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

> 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 
> 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Feb 2020 08:22:09 +0100 (CET)

On Thu, 20 Feb 2020, Fernando Gont wrote:

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

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Feb 2020 05:24:44 -0300

On 20/2/20 04:22, Mikael Abrahamsson wrote:
>>> 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?
>>
> Ok, for me "SLAAC" doesn't mean "A=1". If that's what you mean, then 
> write that.

You're right. That was very sloppy wording. It has been updated in the 
posted version of the doc.

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

FWIW, we have updated the text (Section 2.2, page 4) to:

    o  Upon changes to the advertised prefixes, and after bootstrapping,
       the CE router advertising prefix information via SLAAC should
       proceed as follows:

       *  Any prefixes that were previously advertised via Router
          Advertisement (RA) messages for address configuration, but that
          are not currently intended for address configuration, MUST be
          advertised with a PIO with the "A" bit set to 1 and the "Valid
          Lifetime" and a "Preferred Lifetime" set to 0.

       *  Any prefixes that were previously advertised via RA messages as
          "on-link", but that are not currently not considered "on-link",
          MUST be advertised with a PIO with the "L" bit set to 1 and the
          "Valid Lifetime" and a "Preferred Lifetime" set to 0.

       *  If both of the previous conditions are met (a prefix was
          previously advertised with both the "A" and "L" bits set, but
          is currently *not* intended for address configuration and is
          *not* considered on-link), the prefix MUST be advertised with a
          PIO option with both the "A" and "L" bits set to 1 and the
          "Valid Lifetime" and a "Preferred Lifetime" set to 0.  That is.
          the advertisements of the previous two steps can be coalesced
          into a single one with both the "A" and "L" bits set.

       *  The aforementioned advertisement SHOULD be performed for at
          least the "Valid Lifetime" previously employed for such prefix.

Thoughts?

> addresses and prefixes (or at least trigger a renew to verify that 
> they're still valid).

FWIW, I am (and so are my co-authors, I bet) all for stuff that works. I 
mentioned "RECONFIGURE" because I'm not sure if the implementation 
status changed.

My two questions in this respect are:
* Is the same set of RIOs advertised on all interfaces?

* Can R2 expect R1 to advertise RIOs?

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

I'm asking if one can count on the RIO, or whether one would have to do 
something like:

1) Check if R1 sends RIOs

2) If R1 is known to send RIOs, and R1 has ceased to advertise a RIO for 
the previously advertised/leased prefix, assume the prefix is gone -- 
and e.g. try to RENEW the prefix?

> are two routers sending RAs with two different prefixes, the RIO can 
> tell which one of these should be used for traffic which /56.
> 

There's certainly a gap in how DHCPv6-PD and SLAAC and DHCP-PD 
upstream/downstream interact. Part of that is certainly out of scope for 
this document, but would certainly be worth pursuing in its own 
document. Then there's parts that might belong to this one -- I'm trying 
to figure out which part we could do in this one doc. (please see above).

Thanks!

Cheers,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Feb 2020 12:03:06 +0100 (CET)

>         Lifetime" and a "Preferred Lifetime" set to 0.

I think this is way too much text. Just say it should set the timers to 0 
and keep the flags, whatever they were. Writing this much prescriptive 
language means there is a risk to get it wrong, or there is 
misunderstandings.

>         "Valid Lifetime" and a "Preferred Lifetime" set to 0.

This can be rolled up into the previous paragraph.

>         into a single one with both the "A" and "L" bits set.

Dito.

>         least the "Valid Lifetime" previously employed for such prefix.

Why not roll all of it up into:

"* Any prefixes advertised via RA MUST be announced with "Valid 
lifetime" and "Preferred Lifetime" set to 0"

Guess if really needed, a sentence about "keeping A/L flags unchanged" 
could be added.

L-13 in RFC7084 is short and sweet, why can't this one be similarily 
brief?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Feb 2020 08:47:54 -0300

On 20/2/20 08:03, Mikael Abrahamsson wrote:
> I think this is way too much text. Just say it should set the timers to 
> 0 and keep the flags, whatever they were. Writing this much prescriptive 

Point taken. How about:
'Any prefixes that were previously advertised via PIOs in Router 
Advertisement (RA) messages, and that have become stale, should be 
advertised with a PIOs that have both the "Valid Lifetime" and the 
"Preferred Lifetime" set to 0, and the A/L flags with the same settings 
as in the previous RA messages'

Not sure if "with the same settings" is clear enough, though.

> L-13 in RFC7084 is short and sweet, why can't this one be similarily brief?

Agreed. Although L-13 of RFC7084 makes the reader assume what the proper 
settings for the flags are.

Thanks!

Cheers,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Feb 2020 13:54:06 +0100 (CET)

On Thu, 20 Feb 2020, Fernando Gont wrote:

> Advertisement (RA) messages, and that have become stale, should be advertised 
> with a PIOs that have both the "Valid Lifetime" and the "Preferred Lifetime" 
> set to 0, and the A/L flags with the same settings as in the previous RA 
> messages'
>
>

"unchanged"?

> settings for the flags are.

The longer I participate in the IETF, the more I adopt the opinion that 
documents should not be overly prescriptive.

Is there some text on *why* we're doing this? Perhaps that's better 
instead of writing exactly what the flags should be etc?

Perhaps write that Valid/Preferred lifetime should become zero so that new 
client connections are not sourced from these IPs? Isn't the most 
important thing that the Preferred lifetime is this way? Perhaps write 
"SHOULD NOT change any other flags in the PIO"?

L-13 also has text regarding 2 hour and "whatever is lower". I seem to 
remember this was because some other RFC said something about 2 hour 
minimum... is this still true?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Feb 2020 12:17:03 +1300

>> settings for the flags are.

And A=L=0 is valid sometimes too (RFC8028). Better to avoid the details here.

    Brian