Subject: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT)

From: Suresh Krishnan <[email-masked]>
Date: Thu, 02 Aug 2018 06:51:43 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-v6ops-conditional-ras-06: Yes

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

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

* Section 3.1.1.

I think a reference to RFC3704 (specifically written for describing ingress
filtering for multihomed networks) might be a good addition here to RFC2827

* Sections 3.2.1., 3.2.2. etc.

=> I think it is important to specify (at least the bounds of) the valid
lifetimes here as well. e.g. when the preferred lifetime is getting set to zero
it is important to specify that the valid lifetime is set to a non zero value
so that the host will form an address at all (even though it will not be used
when there are preferred addresses). This is important to reduce the potential
packet losses when the preferred uplink goes down.

* Section 3.2.2.

I think there is some text missing here about VRRP priorities here. There seems
to be an assumption in the draft that the uplink A failure will lead to R1
becoming backup ("If ISP_A uplink is down, then R1 becomes a backup.") and this
is not obvious at all. There needs to be a priority change with interface
tracking if this has to happen and the backup has to take over as the master.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 10 Aug 2018 22:25:50 +1000

Hi Suresh,

> filtering for multihomed networks) might be a good addition here to RFC2827

Done!

> packet losses when the preferred uplink goes down.

I've added a paragraph clarifying that we only modify preferred
lifetime and that RFC4862 does not
allow an RA with both preferred and valid lifetime for the prefix set
to 0 to invalidate the address completely:

https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07

> tracking if this has to happen and the backup has to take over as the master.

I've rephrased it to:
"R1 is the VRRP master by default (when ISP_A uplink is up).  If ISP_A
   uplink is down, then R1 becomes a backup (the VRRP interface status
   tracking is expected to be used to automatically modify the VRRP
   priorities and trigger the mastership switchover). "

Please let me know if the new version does not address your comments!

Thanks!

-- 
SY, Jen Linkova aka Furry

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Aug 2018 10:27:55 -0700

At Fri, 10 Aug 2018 22:25:50 +1000,

> https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07

To be very accurate, it's still allowed if the RA is authenticated:

          Neighbor Discovery [RFC3971]).  If the Router Advertisement
          was authenticated, the valid lifetime of the corresponding
          address should be set to the Valid Lifetime in the received
          option.

(whether v6ops-conditional-ras should be this accurate is a different
question, for which I don't have a strong opinion)

--
JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 15 Aug 2018 11:44:58 -0400

Hi Jinmei-san,

> On Aug 10, 2018, at 1:27 PM, 神明達哉 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Jen Linkova <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07 <https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07>
> 

Yes. You are absolutely correct, but given the lack of deployment of SEND this pretty much means that this will be a no-op. To allow for wiggle room we can add something like “in most cases” to qualify the new text regarding valid lifetime.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 15 Aug 2018 11:46:46 -0400

Hi Jen,

> On Aug 10, 2018, at 8:25 AM, Jen Linkova <[email-masked]> wrote:
> 
> Hi Suresh,
> 

Looks good to me with the minor clarification that Jinmei-san proposed. Thanks for addressing these comments.

Regards
Suresh

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Aug 2018 15:48:23 +1000

Hi Jinmei-san,

> To be very accurate, it's still allowed if the RA is authenticated:

Oops, that's what happens when I'm trying to submit a new version in
hurry, just a few hours before disappearing for vacation...;( Yes, you
are absolutely right...Thanks for pointing this out! I was going to
add that text but forgot :(

The draft meant to say
"Actually it would not even be possible for unauthenticated RAs (which
is the most common deployment scenario) as Section 5.5.3 of [RFC4862]
prevents hosts from setting valid lifetime for addresses to zero
unless RAs are authenticated."

instead of

"Actually it would not even be possible as Section 5.5.3 of [RFC4862]
prevents hosts from setting valid lifetime for addresses to zero."

> question, for which I don't have a strong opinion)

Well, I believe it should make the correct statement, so I'll update the text!

---

From: Jen Linkova <[email-masked]>
Date: Wed, 22 Aug 2018 09:09:28 +1000

I've submitted -08 version
https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/

where

"Actually it would not even be possible as Section 5.5.3 of [RFC4862]
prevents hosts from setting valid lifetime for
addresses to zero."

is replaced with

"Actually it would not even be possible for unauthenticated RAs (which
is the most common deployment scenario) as Section 5.5.3 of RFC4862]
prevents hosts from setting valid lifetime for
addresses to zero unless RAs are authenticated."

---

From: 神明達哉 <[email-masked]>
Date: Tue, 21 Aug 2018 16:38:20 -0700

At Wed, 22 Aug 2018 09:09:28 +1000,

> addresses to zero unless RAs are authenticated."

(I guess it's needless to say but) looks good to me.

--
JINMEI, Tatuya