Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt

Ralph Droms <> Wed, 22 January 2014 20:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 45BD01A047A for <>; Wed, 22 Jan 2014 12:20:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i7o4c6rkquYP for <>; Wed, 22 Jan 2014 12:20:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::22b]) by (Postfix) with ESMTP id B331E1A03E7 for <>; Wed, 22 Jan 2014 12:19:53 -0800 (PST)
Received: by with SMTP id z20so349370yhz.30 for <>; Wed, 22 Jan 2014 12:19:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vI2pwCqN41keIPs9zxhQUJBAmEobRrKtEAFB3luz/TA=; b=iPTdo5a+Rh5XRfvnk41G0QEL7YjswBdqkc3fkiop/z9QipGg297oy1romqaRbv515f K01nZaWb4OSooh1NvokpHGEwP/sL9Dsv6UoZcV2RbHxBWl1MCeHLEZhivZur69VQ0PNC HAUrn/7vZN4qyDeoaBHCRNPC3NZy8stL4SRtbTDkuao39fdrGmbDM9zwEvXWRdMsHMh/ PB1t34gYHoz7yNQqyzydYakLkkh6umdaCnryws1T7CLgiOnIyP8rVgsgRsT0pk4hLUWx 41NK3BjC99Q7TwyRx5lhJBrJ8qnGL/ulDKcHyb6q+yOpcX4tStPWYVeQ5ZX3S1rM0Xho 8hng==
X-Received: by with SMTP id c27mr3679234yhi.120.1390421993045; Wed, 22 Jan 2014 12:19:53 -0800 (PST)
Received: from ?IPv6:2001:420:285:1004:d849:2a2d:7919:cf85? ([2001:420:285:1004:d849:2a2d:7919:cf85]) by with ESMTPSA id s93sm8591859yhp.1.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 12:19:51 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt
From: Ralph Droms <>
In-Reply-To: <>
Date: Wed, 22 Jan 2014 12:19:48 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Ole Troan <>
X-Mailer: Apple Mail (2.1510)
Cc:, 6man WG <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jan 2014 20:20:03 -0000

On Jan 22, 2014, at 12:15 PM 1/22/14, Ole Troan <> wrote:

>>>  When an interface on a host is initialized, the host transmits Router
>>>  Solicitations in order to minimize the amount of time it needs to
>>>  wait until the next unsolicited multicast Router Advertisement is
>>>  received.  In certain scenarios, these router solicitations
>>>  transmitted by the host might be lost.  This document specifies a
>>>  mechanism for hosts to cope with the loss of the initial Router
>>>  Solicitations.  Furthermore, on some links, unsolicited multicast
>>>  Router Advertisements are never sent and the mechanism in this
>>>  document is intended to work even in such scenarios.
>>> Authors,
>>> One comment here.
>>> If the intent is that we should be able to run networks that do not send periodic RAs at all, then this document will need to require that hosts send router solicitations when their RAs (or whatever is in the RA contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are about to expire - otherwise the hosts will lose connectivity.
>> I think it's worse than that.
>> A host on a multicast-capable link on which "unsolicited multicast Router Advertisements are never sent" will have to use the same transmission behavior as a host on a non-multicast-capable link, so that the host can learn of changes in the link prefixes in a timely fashion.
>> Furthermore, a host on a multicast-capable link won't know if multicast RAs are being sent on the link, so all hosts will have to send periodic RSs.
> for periodic RAs Router Lifetime /  RtrAdvInterval >= 3 to ensure that the mechanism works even when a couple of multicast messages are lost.


> if it is specified that the periodic RS is sent only after 2/3s of the router lifetime has passed, then either the host would have received the multicast advertisement, and dropped sending the periodic RS, or it lost the multicast messages, and would be best off sending the RS anyway, or it was on a link-type that didn't send periodic RAs.

OK ... but the host will not learn about new prefixes assigned to the link in a timely fashion, which is (I infer) the motivation for this text:

   On non-multicast links, the hosts following this specification MUST
   continue retransmitting the RSs even after an RA that results in a
   default route is received.

- Ralph

> cheers,
> Ole