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

[Fernando Gont <[e-mail]>]

Hello, Eric,

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

On 22/10/20 07:11, Éric Vyncke via Datatracker wrote:
[....]
> 
> ----------------------------------------------------------------------
> 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).

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.



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

FWIW, we're working on these.



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

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



> "it is not an unusual behavior" may be... but, documenting (OS versions,
> 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


[...]
> "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.

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




> "Lacking any explicit signaling to deprecate the previously-advertised
> 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.



> "because of egress-filtering by the CPE or ISP" or is it ingress-filtering when
> 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.



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

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



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

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

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




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

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




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

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.



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

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.


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

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


> Is the same technique also
> described in the SLAAC CPE document ?

Yes.



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

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