[6lo] Draft applicability for 6775bis

Erik Nordmark <nordmark@sonic.net> Wed, 29 March 2017 15:49 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2267D128D19 for <6lo@ietfa.amsl.com>; Wed, 29 Mar 2017 08:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 6sETN8avNwhS for <6lo@ietfa.amsl.com>; Wed, 29 Mar 2017 08:49:43 -0700 (PDT)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D95126557 for <6lo@ietf.org>; Wed, 29 Mar 2017 08:49:43 -0700 (PDT)
Received: from [31.133.133.70] (dhcp-8546.meeting.ietf.org [31.133.133.70]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v2TFnaiv005542 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 08:49:36 -0700
To: Lorenzo Colitti <lorenzo@google.com>, Christian Huitema <huitema@huitema.net>
From: Erik Nordmark <nordmark@sonic.net>
Cc: 6lo@ietf.org
Message-ID: <0d33195c-d828-1d5b-6a49-ca23d9d4a793@sonic.net>
Date: Wed, 29 Mar 2017 10:49:35 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVY950lEUSQUURFvbe+1k93OB+3VglUjGQeC1m7ZI+6KmVSOnzf0gV0E5EpGrtELyqBP7CYFXKUJ6lCErFzLYtX7
X-Sonic-ID: C;OkZGT5cU5xGkDbSd+VpWsw== M;tt+tT5cU5xGkDbSd+VpWsw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Gi4tmHDk6BYKPENtA0ypKM0buxg>
Subject: [6lo] Draft applicability for 6775bis
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2017 15:49:45 -0000

Here is an attempt at an applicability statement based on what we talked 
about today.
It is sufficiently strong?
Other RFCs or drafts that we should reference?

    Erik

----

Applicability

The purpose of the ARO and EARO is to facilitate duplicate address 
detection for hosts and pre-populate NCEs in the routers to reduce the 
need for sending multicast neighbor solicitations and also to be able to 
support backbone routers.

In some cases the address registration can fail or be useless for 
reasons other than a duplicate address. Example are the router having 
run out of space, the host having a stale sequence number, or the host 
is using an address which does not match the prefix(es) for the link. In 
such cases the host will receive an error to help diagnose the issue and 
retry.

However, the ability to return errors to address registrations MUST NOT 
be used to restrict the ability of hosts to form and use addresses as 
specified in [RFC7934]. In particular, this is needed for enhanced 
privacy, which implies that each host will register a multiplicity of 
address as part mechanisms like [RFC4941]. This implies that a 6LR or 
6LBR which is intended to support N hosts MUST have space to register at 
least on the order of 10N IPv6 addresses.

---