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

Fernando Gont <> Thu, 22 October 2020 16:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AABBB3A0898; Thu, 22 Oct 2020 09:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N6n3mxPa-XPt; Thu, 22 Oct 2020 09:47:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F01673A0874; Thu, 22 Oct 2020 09:47:05 -0700 (PDT)
Received: from [IPv6:2800:810:464:b9c:452e:36a3:27fd:8f9b] (unknown [IPv6:2800:810:464:b9c:452e:36a3:27fd:8f9b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4EF43283A26; Thu, 22 Oct 2020 16:47:01 +0000 (UTC)
To: =?UTF-8?Q?=c3=89ric_Vyncke?= <>, The IESG <>
Cc:,,, Owen DeLong <>,,
References: <>
From: Fernando Gont <>
Message-ID: <>
Date: Thu, 22 Oct 2020 13:43:09 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-slaac-renum-04=3A_=28with_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Oct 2020 16:47:10 -0000

Hello, Eric,

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

On 22/10/20 07:11, Éric Vyncke via Datatracker wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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:
> - Sheng Jiang's Internet directorate review:

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

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

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

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


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



Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492