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

[Fernando Gont <[e-mail]>]

On 20/2/20 04:22, Mikael Abrahamsson wrote:
> 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.

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



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

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?



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

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?


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

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?




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

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,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492