Subject: Confirmation of consensus to adopt draft-krishnan-6man-maxra

From: [email-masked]
Date: Fri, 27 Nov 2015 12:35:56 +0100

There was clear consensus for adopting draft-krishnan-6man-maxra as a 6MAN working group document.
This message starts a one week call on confirming the consensus from the WG meeting.

      Title           : Support for adjustable maximum router lifetimes per-link
      Authors      : S. Krishnan, J. Korhonen, S. Chakrabarti, E. Nordmark, A. Yourtchenko
      Filename   : draft-krishnan-6man-maxra-03
      Pages        : 5
      Date           : 2015-10-18

      http://datatracker.ietf.org/doc/draft-krishnan-6man-maxra

Please respond only if you think this document should _not_ be adopted.
This adoption call will end on December 4, 2015.

Regards,

Ole Trøan & Bob Hinden

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 Nov 2015 20:50:08 +0900

> This adoption call will end on December 4, 2015.

I do not think we can adopt this document as long as it contains the text:

   This document also updates Sections 6.2.1., 6.2.2., 6.2.4. and 6.2.5.
   of [RFC4861] so that AdvSendAdvertisements can be set "FALSE" but the
   router would still continue be a router and respond with RAs to
   solicited RSes .

because doing so breaks all RFC4861-compliant implementations.

Explanation: if the routers on the link do not send periodic RAs, hosts
will lose connectivity unless someone on the link sends an RS and one of
the routers responds with a multicast RA. However, section 6.3.7 of RFC
4861 is clear about when hosts can send RSes. If no hosts attach to the
link and no hosts initialize their interfaces, nobody will send an RS. So
all hosts will lose connectivity when the default lifetime times out.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 27 Nov 2015 14:09:44 +0100

Hi,

> Explanation: if the routers on the link do not send periodic RAs, hosts will lose connectivity unless someone on the link sends an RS and one of the routers responds with a multicast RA. However, section 6.3.7 of RFC 4861 is clear about when hosts can send RSes. If no hosts attach to the link and no hosts initialize their interfaces, nobody will send an RS. So all hosts will lose connectivity when the default lifetime times out.

+1, I have seen this happen. RAs should be sent regularly or not at all. Sending them only when the router receives an RS really messes things up.

Cheers,
Sander

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Nov 2015 13:23:59 +0000

>From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
>Sent: Friday, November 27, 2015 6:50 AM
>To: Ole Troan
>Cc: 6man Chairs; 6man WG
>Subject: Re: Confirmation of consensus to adopt draft-krishnan-6man-maxra

>I do not think we can adopt this document as long as it contains the text:

 >  This document also updates Sections 6.2.1., 6.2.2., 6.2.4. and 6.2.5.
 > of [RFC4861] so that AdvSendAdvertisements can be set "FALSE" but the
 >  router would still continue be a router and respond with RAs to
 >  solicited RSes .

>Explanation: if the routers on the link do not send periodic RAs, hosts will lose connectivity unless someone on the link sends an RS and one of the routers responds with a multicast RA. However, section >6.3.7 of RFC 4861 is clear about when hosts can send RSes. If no hosts attach to the link and no hosts initialize their interfaces, nobody will send an RS. So all hosts will lose connectivity when the default
> lifetime times out.

+1.   More discussion is needed.

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Nov 2015 08:11:12 +1300

> I do not think we can adopt this document as long as it contains the text:

Disagreeing with one statement in a draft doesn't mean that the WG
shouldn't *adopt* the draft. It just means that we will be making
a change after adoption.

> all hosts will lose connectivity when the default lifetime times out.

As it happens, I think you're right. Also, this radical proposal is in
no way justified by the preceding discussion. Effectively it's a
proposal to set MaxRtrAdvInterval = AdvDefaultLifetime = infinity.
It's a direct contradiction of RFC 4861 (see the first sentence at
https://tools.ietf.org/html/rfc4861#page-48) so the wording of the
update is very casual anyway.

    Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Nov 2015 19:50:23 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Friday, November 27, 2015 2:11 PM
To: Lorenzo Colitti; Ole Troan
Cc: 6man Chairs; 6man WG
Subject: Re: Confirmation of consensus to adopt draft-krishnan-6man-maxra

>As it happens, I think you're right. Also, this radical proposal is in no way justified by the preceding discussion. Effectively it's a proposal to set MaxRtrAdvInterval = AdvDefaultLifetime = infinity.
>https://tools.ietf.org/html/rfc4861#page-48) so the wording of the update is very casual anyway.

If AdvDefaultLifetime == infinity, how does the link change a default router?  

Additionally, note the Router Lifetime is a 16-bit field in the RA while the 32-bit Reachable Time in the RA is a 32-bit field.  RFC 4861 already limits the Router Lifetime to 9000 secs.   A host does perform NUD with the default router.   The Router Lifetime expires, but the host finds the router reachable via NUD.   As per RF 4861,  the host considers this situation as a default router lost.  It's a separate question whether WiFi links perform NUD.

Hemant

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 28 Nov 2015 05:41:51 +0000

Hi Brian/Lorenzo,

> shouldn't *adopt* the draft. It just means that we will be making

Yep. The document is far from being done. I think this change can be made 
either before or after adoption.

> update is very casual anyway.

I agree with both of you as well. I think this needs to be left out the 
document to avoid the failure scenario Lorenzo talked about.

Thanks
Suresh