Re: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

Fernando Gont <fgont@si6networks.com> Thu, 22 October 2020 14:35 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6285D3A0EDF; Thu, 22 Oct 2020 07:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h804es5jv11c; Thu, 22 Oct 2020 07:35:52 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F3E3A0ED5; Thu, 22 Oct 2020 07:35:50 -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 fgont.go6lab.si (Postfix) with ESMTPSA id 8814D28151F; Thu, 22 Oct 2020 14:35:46 +0000 (UTC)
To: Erik Kline <ek.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong <owen@delong.com>
References: <160334506239.20395.15102292380884503313@ietfa.amsl.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <47621153-e87f-4d98-946c-45208580c24b@si6networks.com>
Date: Thu, 22 Oct 2020 11:34:59 -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: <160334506239.20395.15102292380884503313@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mtkoWoV8DBGW6rwbQT67njBv8Qc>
Subject: Re: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2020 14:35:55 -0000

Hello, Erik,

Thanks a lot for your comments! In-line....

On 22/10/20 02:37, Erik Kline via Datatracker wrote:
[....]> 
----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> [ section 3.2 ]
> 
> * I absolutely agree in principle at these other lifetimes should be updated
>    to the shorter of the two applicable lifetimes, but I'm worried that this
>    text is not sufficiently precise.  Specifically, this recommendation only
>    applies to options that depend in any way on the change in the delegated
>    prefix, yes? 

I'd say it applies to options that depend on the delegated prefix or the 
existence of the router that advertised them (which in a way are 
intimately related).

Local example at home:
I recently installed a backup connection. Both of my ISPs do IPv6.

Say I'm testing whether the setup works. I connect CPE1, connected to 
ISP1. Then Connect CPE2, connected to ISP2. Then unplug CPE1.

What's the usefulness of the options advertised by CPE1 if the only 
thing I have is CPE2? (e.g., ISP1 might have ACLs that only allows 
subscribers of ISP1 to use its recursive servers).


> Perhaps just this qualifier is sufficient?

You mean the qualifier instead of spelling out the option names? Or are 
you suggesting to add this clarification in addition to spelling out the 
option names.

(Adding the clarification, either in the second paragraph of Section 
3.2, or as one of the bullets in the "RATIONALE" below would be useful. 
OTOH, replacing the list of options with this note probably wouldn't 
(since then we're throwing the problem at implementers, who now need to 
know the analysis themselves).



>    For example, none of these comparative lifetime recommendations apply to
>    a stable ULA for a router that meets requirements ULA-[1..5] and chooses
>    to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think.

I see your point. However, my next question would be: do ULA 
implementations behave in that way? (most (if not all) of the CPEs I've 
run into don't treat ULAs in any special way).  And, what if (as you 
correctly noted in your review for the other companion document) you 
have two cascading routers, that do ULA+GUA, where the first router 
generates the /48 ULA, and the cascading one gets a leased ULA prefix 
from the former?

And, besides, if the options are not refreshed, that's because the 
corresponding router is gone. So, in that case, you wouldn't have a 
router that forwards your packets. And, if nodes are on-link, why not 
use link-locals instead.



>    That being said, should this document also be saying that the ULA-derived
>    options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot
>    causes a new ULA to be generated (i.e. the one supposedly in stable storage
>    is lost or otherwise unrecoverable)?

At least in my mental model, that was implied (i.e., I don't think that 
ULAs are special in this respect, because of the reasons noted above).

That said, are you suggesting that explicitly note this for ULA PIOs, or 
something else?  (me thinking out loud: I realize that for the CE Router 
connecting to the ISP, ULAs are special case in the sense that they are 
being locally generated... and hence it would make sense to be explicit 
about that).

Thoughts?


> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ comments ]]
> 
> [ section 3.1 ]
> 
> * With respect to the second bullet: the lifetimes need to be dynamically
>    *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT
>    values are always lower than the remaining PD lifetimes.  In this situation,
>    the requirement is still that the lifetimes can be updated, but to the
>    casual observer of the steady state the RA contents might appear static
>    (e.g., while the PD'd prefix is continuously renewed).
> 
>    Maybe there's no text required here, but I didn't want a reader to be left
>    with the impression that no two RAs could be identical

Agreed. How about if we tweak the bullet as:

       *  The lifetime values of prefixes advertised on the LAN-side via
          SLAAC must be dynamically updated (rather than static values),
          otherwise the advertised lifetimes would eventually span past
          the DHCPv6-PD lifetimes. In scenarios where the LAN-side
          configured option lifetimes (see Section 3.2 and Section 4) are
          always smaller than (or equal to) the  remaining DHCPv6-PD
          lifetimes, the LAN-side option lifetimes will exhibit constant
          values.

> 
> 
> [[ nits ]]
> 
> [ section 3.3 ]
> 
> * In the 2nd bullet's 2nd bullet (this might be easier if these lists were
>    numbered), 

Will do the symbols-> numbers .



> it might be good to clarify that "the *deprecated* prefix can
>    simply be advertised..."

Will do.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492