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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 25D461A037F for <>; Wed, 22 Jan 2014 12:05:45 -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 3yqRa7a6UG5a for <>; Wed, 22 Jan 2014 12:05:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c02::231]) by (Postfix) with ESMTP id 908661A02D5 for <>; Wed, 22 Jan 2014 12:05:43 -0800 (PST)
Received: by with SMTP id x10so809350pdj.22 for <>; Wed, 22 Jan 2014 12:05:43 -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=s0q2H6VODfW5iJcDBv4mgMP+SnHODPasSDTCnKNWaCQ=; b=t/Ig0mcUfJfuqtpSDN8OjxHFCFhRTqV6WpF4Ol7HiFHXCkPVs0kh41qnPjqcO5yWcT nz45/Marz7GPyatGeQ1falVxh2ufqKP3kHS2ThbFSaBKgI+PSjWgocLSShTlkI+6Xd3T r7fiytl3YYYDxeyQBz9EDs7d/SkMI5dBICSuIojYsPx2dPFXiOtjpfO4YpVLQdTrfW3G 9y+z120BoxEyrGAapctpbmxrnc1GIeDoF9eZk2EdVbDfoXF4LWhdv/pI9FFr5/qHz4It Zlx/a5VB0uOhNX/3xxTIUtEgO4bP3NwsFyipWyCHLHW/nxkokGmDm4UBzje/ivUL4ux/ v6lg==
X-Received: by with SMTP id zx2mr3733606pbb.74.1390421143104; Wed, 22 Jan 2014 12:05:43 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id q7sm26776578pbc.20.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 12:05:41 -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:05:39 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Lorenzo Colitti <>
X-Mailer: Apple Mail (2.1510)
Cc:, IETF IPv6 Mailing List <>
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:05:45 -0000

On Jan 22, 2014, at 11:55 AM 1/22/14, Lorenzo Colitti <> wrote:

> [Resending with hopefully correct author mailing list]
> On Wed, Jan 22, 2014 at 11:46 AM, Lorenzo Colitti <> wrote:
> On Mon, Oct 21, 2013 at 4:38 PM, <> 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.

- Ralph

> This may be difficult to specify correctly. Specifically, it may be hard to distinguish something that is being deprecated by the network (e.g., an RA whose lifetime is counting down because it comes from a PD) from an RA that is about to expire.
> If the intent is not that we should be able to run networks without periodic RAs, then at least the text in 2b needs to change.
> Cheers,
> Lorenzo
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------