IETF Logo Mail Archive

RE: rs-refresh

"Hemant Singh (shemant)" <shemant@cisco.com> Thu, 05 March 2015 16:29 UTC

Return-Path: <shemant@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5D1A0378 for <ipv6@ietfa.amsl.com>; Thu, 5 Mar 2015 08:29:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 LgGKdbZCkRdi for <ipv6@ietfa.amsl.com>; Thu, 5 Mar 2015 08:29:55 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903781A1A52 for <6man@ietf.org>; Thu, 5 Mar 2015 08:24:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3322; q=dns/txt; s=iport; t=1425572681; x=1426782281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xDvlrsUDenImoSkucQgAV8pxe8uFK/vyQgVLlPjqjR0=; b=TV3tAPE75lwdohhLNEnOkSQDp4acvXJ+O2qVwp69yEKObAVsQKPdBgh0 Vx3SozDcIsEVnqiXe/oPpARbVRPIywv3AUjv8qZkQ7c/x3dHIdc1pmp7/ 3j8flfE4IxV2vkucG3x+SfRvHbWFbh0mBnmACdHvci1ZmUHQWeebnmvPK k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CNBgB+gvhU/5tdJa1agwaBLASDBsQeAhyBG00BAQEBAQF8hA8BAQEEIxE5DBACAQgRBAEBAwIGHQMCAgIwFAEICAEBBA4FCIgnvSCaZQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hD0xB4JoL4EUBZAHimeDJo8vI4Nub4ECBT1/AQEB
X-IronPort-AV: E=Sophos;i="5.11,347,1422921600"; d="scan'208";a="129258611"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 05 Mar 2015 16:24:40 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t25GOeXk012960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 16:24:40 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 10:24:40 -0600
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Lorenzo Colitti <lorenzo@google.com>
Subject: RE: rs-refresh
Thread-Topic: rs-refresh
Thread-Index: AdBXORCTDkYgMkaaSWaOLdishDJgqQAO5BAAAAYqfJA=
Date: Thu, 05 Mar 2015 16:24:39 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B8916812720@xmb-rcd-x06.cisco.com>
References: <75B6FA9F576969419E42BECB86CB1B8916811E1F@xmb-rcd-x06.cisco.com> <CAKD1Yr2tYNd26-KyU3PJm2P8tEbUTGN76KbkSysm8=brY2qe9w@mail.gmail.com>
In-Reply-To: <CAKD1Yr2tYNd26-KyU3PJm2P8tEbUTGN76KbkSysm8=brY2qe9w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.131.71.115]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/kASrM8T2gEGOngQ2kPkPQf8aNmE>
Cc: Erik Nordmark <nordmark@acm.org>, "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2015 16:29:56 -0000

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

From: Lorenzo Colitti [mailto:lorenzo@google.com] 
Sent: Thursday, March 05, 2015 7:46 AM
To: Hemant Singh (shemant)
Cc: Erik Nordmark; 6man@ietf.org
Subject: Re: rs-refresh

On Thu, Mar 5, 2015 at 8:39 PM, Hemant Singh (shemant) <shemant@cisco.com> 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. 

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

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

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

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

v2.23.0 | Report a Bug | By Email