Subject: RE: rs-refresh

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 5 Mar 2015 11:39:45 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Thursday, March 05, 2015 1:28 AM
To: Erik Nordmark
Cc: [email-masked]
Subject: Re: rs-refresh

>I don't think this is as useful as it appears to be at first glance, for a few reasons:
>1. This is only useful if all the hosts on the link support it. If one host does not support it, then we fall back to sending multicast RAs again.

Not true.  See below where I have responded to items 3 and 4.

>2. Despite what the document says (in two different sections), it is not possible to make it so that "updated nodes can sleep better" AND "preserve the timely and scalable reconfiguration capabilities that a periodic RA >model provides" unless there are no legacy hosts on the network

Not true.  See below where I have responded to items 3 and 4.

>3. If the router misses all the RSes from a legacy node (which for a legacy node that doesn't implement resilient RS, means a total of 3 packets sent within 3 seconds of each other, which is quite possible) then that >node is blackholed.

No.  If the node never sees an RA, the node resets its network stack and tries another three RS messages and repeats until an RA is received.   If the node has received an RA and wakes up after sleep and does not receive any RA after sending three RS messages, the node sends traffic to the default router and uses old RA information.   A router can issue Redirect to the node.  The node refreshes the  default router information later.  

>If the router loses state, all legacy nodes are blackholed.

ND has always had default routers (plural).   Another router can still serve the nodes. 

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Mar 2015 21:46:02 +0900

On Thu, Mar 5, 2015 at 8:39 PM, Hemant Singh (shemant) <[email-masked]>
wrote:

> No.  If the node never sees an RA, the node resets its network stack and
> tries another three RS messages and repeats until an RA is received.

Which host implementations do this? Certainly not the Linux one - it just
lets the route expire, as per RFC 4862.

>    If the node has received an RA and wakes up after sleep and does not
> receive any RA after sending three RS messages,

No standard specifies that hosts should send RS after waking up from sleep.
Which implementations do this?

the node sends traffic to the default router and uses old RA information.

No, it doesn't. That's a clear violation of RFC 4862.

> ND has always had default routers (plural).   Another router can still

Which means that you have to run state synchronization protocol between
routers.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 5 Mar 2015 16:24:39 +0000

Please see in line below.  My responses are preceded by "<hs>". 

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Thursday, March 05, 2015 7:46 AM
To: Hemant Singh (shemant)
Cc: Erik Nordmark; [email-masked]
Subject: Re: rs-refresh

On Thu, Mar 5, 2015 at 8:39 PM, Hemant Singh (shemant) <[email-masked]> wrote:
No.  If the node never sees an RA, the node resets its network stack and tries another three RS messages and repeats until an RA is received.

Which host implementations do this? Certainly not the Linux one - it just lets the route expire, as per RFC 4862.
 
<hs>Over 200 million cable modems which support IPv6.  A consumer device has to be rock solid and thus some extra robustness has been specified in docsis 3.0 standard for ipv6 cable modems.   Aside from docsis,  if a host does not perform DHCPv6, the host has got to receive an RA.   So why would a host not try forever to receive an RA?   RFC 4862 covers ipv6 addresses, not routes and thus I do not see any route expiry in RFC 4862.  

 If the node has received an RA and wakes up after sleep and does not receive any RA after sending three RS messages,

No standard specifies that hosts should send RS after waking up from sleep. Which implementations do this?

<hs>I was alluding to section 5.5.1 of RFC 4861 that says "To obtain an advertisement quickly, a host sends out Router Solicitations as described in [RFC4861]."   What if the Router Lifetime expires when the node wakes up?  Then node has got to issue an RS to expedite learning a default router.   Other times too, if the node is delayed for receiving an RA, the node is recommended to issue an RS. 

 
<hs>The node has not seen any new RA and also not expired the Router Lifetime.  So why wouldn't the node use the existing RA information?  Also, when in doubt for data forwarding, it is always sane to send traffic to the default router.  

Which means that you have to run state synchronization protocol between routers.

<hs>No.  There are multiple routers in the same wireless link and each router sees multicast control traffic used by ND.  

Hemant