Fwd: New Version Notification for draft-ietf-6man-rs-refresh-01.txt

Erik Nordmark <nordmark@acm.org> Tue, 22 March 2016 17:28 UTC

Subject: Fwd: New Version Notification for draft-ietf-6man-rs-refresh-01.txt
References: <20160321161949.31924.24504.idtracker@ietfa.amsl.com>
To: "6man@ietf.org" <6man@ietf.org>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <56F180B8.4060001@acm.org>
Date: Tue, 22 Mar 2016 10:28:24 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160321161949.31924.24504.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/l3dy8MlaJLaKFyAg5MLp-QPCScg>
Precedence: list

I don't understand why this wasn't sent to the 6man list automagically.

Anyhow, please review and see if we need to add some strong(er) language 
about this not being an excuse for ignoring multicast RAs.
The statement we want to make is something along the lines of:
  If a host is receiving unicast IP packets, then it MUST NOT ignore 
periodic (multicast) RAs.

The purpose of the draft is that a host which power's off its receiver 
(hence doesn't receive any IP packets) can quickly use RS-refresh to get 
any updates when it wakes up.

But given the experience that Lorenzo and folks have had with 
implementations which ignore multicast RAs we need to make sure the 
language is sufficiently tight in this document.

Thanks,
    Erik

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-ietf-6man-rs-refresh-01.txt
Date: 	Mon, 21 Mar 2016 09:19:49 -0700
From: 	internet-drafts@ietf.org
To: 	Erik Nordmark <nordmark@acm.org>, Andrew Yourtchenko 
<ayourtch@cisco.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>



A new version of I-D, draft-ietf-6man-rs-refresh-01.txt
has been successfully submitted by Erik Nordmark and posted to the
IETF repository.

Name:		draft-ietf-6man-rs-refresh
Revision:	01
Title:		IPv6 Neighbor Discovery Optional RS/RA Refresh
Document date:	2016-03-21
Group:		6man
Pages:		14
URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-rs-refresh-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-rs-refresh/
Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rs-refresh-01

Abstract:
    IPv6 Neighbor Discovery relies on periodic multicast Router
    Advertisement messages to update timer values and to distribute new
    information (such as new prefixes) to hosts.  On some links the use
    of periodic multicast messages to all host becomes expensive, and in
    some cases it results in hosts waking up frequently.  Many
    implementations of RFC 4861 also use multicast for solicited Router
    Advertisement messages, even though that behavior is optional.

    This specification provides an optional mechanism for hosts and
    routers where instead of periodic multicast Router Advertisements the
    hosts are instructed (by the routers) to use Router Solicitations to
    request refreshed Router Advertisements.  This mechanism is enabled
    by configuring the router to include a new option in the Router
    Advertisement in order to allow the network administrator to choose
    host behavior based on whether periodic multicast are more efficient
    on their link or not.  The routers can also tell whether the hosts
    are capable of the new behavior through a new flag in the Router
    Solicitations.

                                                                                   


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Fwd: New Version Notification for draft-ietf-6man… Erik Nordmark