Subject: [v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 22 Oct 2020 03:11:46 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-slaac-renum-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. It is easy to read but errs
sometimes on the anecdotes side rather than on the facts side (except for
Jordi's survey). As discussed before, I personaly wonder whether it is a real
problem for the IETF: it is largely about CPE/node implementation issues and
not a protocol one (even if I agree that the RFC 4861 default timers were badly
chosen 20 years ago).

Please find below a couple of non-blocking COMMENT points and one nit but
please also check: -  Ted Lemon's IoT directorate review with his note about
sleeping devices and time-outs:
        https://datatracker.ietf.org/doc/review-ietf-v6ops-slaac-renum-04-iotdir-telechat-lemon-2020-10-19/
- Sheng Jiang's Internet directorate review:
        https://datatracker.ietf.org/doc/review-ietf-v6ops-slaac-renum-04-intdir-telechat-jiang-2020-10-19/

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
"for an unacceptably long period of time, thus resulting in connectivity
problems." while the 'long period of time" is explained in the end of this
section, giving a hint would help the reader to appreciate the problem. I found
this introduction rather qualitative than quantitative.

"it is not an unusual behavior" may be... but, documenting (OS versions,
specific use cases) would make this argument stronger.

"there has been evidence that some 802.1x supplicants do not reset network
settings after successful 802.1x authentication." this is a very outdated
behavior of Windows if not mistaken and fixed years ago. In all cases,
documenting (OS version, specific case) would make this argument stronger.

"Lacking any explicit signaling to deprecate the previously-advertised
prefixes", as the explicit mechanism exists, I suggest to s/explicit/reliable/

"because of egress-filtering by the CPE or ISP" or is it ingress-filtering when
packets are sourced by an 'internal' host ?

"or routed elsewhere" I wonder how a packet could be routed elsewhere if the
source address is wrong. Policy-based routing ? Suggest to remove those words.

-- Section 2.1 --
Jordi's survey (a good one) does not say how often and how planned are those
prefix changes? My own /48 is not 'stable per contract' but has been stable for
7 years (as long as the BNG does not change it will stay the same as AAA & DHCP
are linked together at my ISP). So, the 37% is probably not meaning that 37% of
the CPE are changing of prefix everyday.

Did the authors check with the German ISP? AFAIK, the default policy has
changed.

Suggest to change the reference from RFC 4941 to the -bis document that is in
the same IESG telechat (so will not cause delay in the publication of this
document).

-- Section 2.3 --
No reply required but I find the last part of this section quite smart. I would
not have thought about this corner case ;-)

-- Section 2.5 --
"Not unusually, the two protocols are implemented in two different", I am
afraid that this is again 'anecdote' and not 'facts'. Citing implementations
details would make this statement stronger.

-- Section 3 --
To be honest, I was about to ballot a DISCUSS on this section as I think that
there could be other mitigation techniques. E.g., the ISP could advertise 2
prefixes by DHCP-PD for a while (would need to re-read DHCPv6 to be sure)
allowing an easier roll-over of the prefixes (esp. when planned prefix change).
Or possibly remove completely this section as 3.1 obvious and it is not
exhaustive.

-- Section 3.2 --
While I agree that the default timers are wrong and that the suggested values
are way better, this is a change in the CPE doing SLAAC and not in operator
settings (or did I badly understood 'operator' as 'network operator' in the
sense of ISP as opposed as residential user?). Is the same technique also
described in the SLAAC CPE document ?

== NITS ==

-- Section 3.2 --
The use of () in the first paragraph renders it difficult to parse. Consider
rewriting it.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Oct 2020 13:43:09 -0300

Hello, Eric,

Thanks so much for your comments! In-line....

On 22/10/20 07:11, Éric Vyncke via Datatracker wrote:
[....]

As noted in the introduction, I believe this both an operational and a 
protocol related problem. One of the many reasons for which you may 
experience this is related to CPEs -- but that's not the only one. There 
are also operational scenarios that lead to the same problem.

There's also a protocol robustness problem: the default timers in 
RFC4861 means that as soon as something happens out of plans, you have a 
long outage. The protocol itself should be more robust in that respect.

>          https://datatracker.ietf.org/doc/review-ietf-v6ops-slaac-renum-04-intdir-telechat-jiang-2020-10-19/

FWIW, we're working on these.

> this introduction rather qualitative than quantitative.

How about adding "(more than one week)"?

> specific use cases) would make this argument stronger.

OpenBSD's implementation seems one case. See e.g.: 
https://marc.info/?l=openbsd-misc&m=160243530006001&w=2

[...]
> documenting (OS version, specific case) would make this argument stronger.

Will try to find out. This had been reported by Jen.

> prefixes", as the explicit mechanism exists, I suggest to s/explicit/reliable/

What we meant here is that the signaling doesn't take place. So yes, 
we'd hope for reliable signaling of this condition. BUt there's no 
signaling at all.

> packets are sourced by an 'internal' host ?

I guess it's in the eyes of the observer? :-)  e.g., my CPE might filter 
on egress, and my ISP could filter on ingress from me.

> source address is wrong. Policy-based routing ? Suggest to remove those words.

What we meant was "... or the return traffic being discarded or routed 
elsewhere".

> the CPE are changing of prefix everyday.

No. But when the change happens, you may experience the problem. At 
least for me, whether that's once a day, once a week, or once a month, 
still means there's a problem.

> Did the authors check with the German ISP? AFAIK, the default policy has

FWIW, BFDI seems to me a government organization, rather than an ISP.

> the same IESG telechat (so will not cause delay in the publication of this

Wouldn't this actually be the other way around? If we reference a draft, 
some might want to the draft to be published as RFC before progressing 
this one....

> not have thought about this corner case ;-)

:-)

> details would make this statement stronger.

Example: Linux radvd(8) does not do DHCPv6-PD. OpenBSD rad() does not do 
DHCPv6-PD, either.

In fact, the only one that I can think of that does both is dhcpcd.

> Or possibly remove completely this section as 3.1 obvious and it is not

IIRC, the procedure to do graceful renumbering in dhcpv6 is largely 
unspecified. That said, if RECONFIGURE is nto supported, then you need 
to wait for the clients to contact the server -- which is not a lot 
different than simply waiting for the prefixes to expire.

Note: I'm not a fan myself of Section 3.1 as a mitigation. But rather 
this was a result of what some part of the wg sees as a way to avoid the 
problem.

> sense of ISP as opposed as residential user?). 

Here we're talking about any routers, and not necessarily just the CPE.

> Is the same technique also

Yes.

> The use of () in the first paragraph renders it difficult to parse. Consider

How about:

   An operator may wish to override some SLAAC default lifetimes such
   that, under normal circumstances, the associated timers will be
   refreshed/reset by local routers but, in the presence of network
   faults, the corresponding information  will be  phased out in a
   timelier manner.

?

Thanks!

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