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

Erik Nordmark <nordmark@acm.org> Wed, 20 May 2015 20:30 UTC

Return-Path: <nordmark@acm.org>
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 718201A90AA for <ipv6@ietfa.amsl.com>; Wed, 20 May 2015 13:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no
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 dg9HAizI9JWA for <ipv6@ietfa.amsl.com>; Wed, 20 May 2015 13:30:31 -0700 (PDT)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FFE1A90A8 for <6man@ietf.org>; Wed, 20 May 2015 13:30:29 -0700 (PDT)
Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t4KKUKgN005171 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 May 2015 13:30:20 -0700
Message-ID: <555CEEDD.1060901@acm.org>
Date: Wed, 20 May 2015 13:30:21 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "6man@ietf.org" <6man@ietf.org>
Subject: Fwd: New Version Notification for draft-ietf-6man-rs-refresh-00.txt
References: <20150519172438.27493.96240.idtracker@ietfa.amsl.com>
In-Reply-To: <20150519172438.27493.96240.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20150519172438.27493.96240.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------080500020909080401080704"
X-Sonic-CAuth: UmFuZG9tSVbvJXMsgMslmLU/naVbeJCjFyTCrergIhYA3cgNQ2NXZ1aJHrY19MkCRfdOWmG6YB3LszuP+64oN5phjzB84KrY
X-Sonic-ID: C;BojRCC//5BG2fzDDQUxNRQ== M;pNzoCC//5BG2fzDDQUxNRQ==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/sRvUcxA_xnRP05rcg_5lZA2WFQE>
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: Wed, 20 May 2015 20:30:33 -0000


This draft has changes based on the discussion in Dallas and on the 
list. See below.

Based on the discussion I think it also makes sense to add something to 
make it more clear that hosts which sleep on a schedule will end up 
missing any unsolicted RAs with new information (and the draft requires 
certain behavior when such hosts wake up), but that should not be 
construed as an argument that all hosts can choose to ignore unsolicited 
RAs.
Suggested text is welcome!

    Erik


14.  Change Log

    Changes since draft-nordmark-6man-rs-refresh-01 of the draft:

    o  Made Refresh Time zero be reserved and RTOs with this value
       ignored by the receiver.

    o  Removed notion that all-ones refresh time means infinite lifetime.
       It now means 65535 seconds.

    o  Changed default to be multicast RS refresh, with the option to
       specify unicast in the RTO.  This enables discovering new routers
       on the link.

    o  Clarified the normative behavior for hosts that sleep on a
       schedule.

    o  Clarified the updated DNA behavior.

    o  Editorial fixes.


-------- Forwarded Message --------
Subject: 	New Version Notification for draft-ietf-6man-rs-refresh-00.txt
Date: 	Tue, 19 May 2015 10:24:38 -0700
From: 	internet-drafts@ietf.org
To: 	Andrew Yourtchenko <ayourtch@cisco.com>, Suresh Krishnan 
<suresh.krishnan@ericsson.com>, Andrew Yourtchenko <ayourtch@cisco.com>, 
Suresh Krishnan <suresh.krishnan@ericsson.com>, Erik Nordmark 
<nordmark@acm.org>, Erik Nordmark <nordmark@acm.org>



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

Name:		draft-ietf-6man-rs-refresh
Revision:	00
Title:		IPv6 Neighbor Discovery Optional RS/RA Refresh
Document date:	2015-05-19
Group:		6man
Pages:		14
URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-rs-refresh-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-rs-refresh/
Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-00


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