Designating 6LBR for IID Assignment
draft-rashid-6lo-iid-assignment-03

Document Type Active Internet-Draft (individual)
Last updated 2017-03-12
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
6lo                                                            AR. Sangi
Internet-Draft                                                   M. Chen
Intended status: Standards Track                     Huawei Technologies
Expires: September 13, 2017                                   C. Perkins
                                                               Futurewei
                                                          March 12, 2017

                  Designating 6LBR for IID Assignment
                   draft-rashid-6lo-iid-assignment-03

Abstract

   In IPv6 Stateless Address Autoconfiguration (SLAAC), randomizing the
   interface identifier (IID) is a common practice to promote privacy.
   If there are a very large number of nodes, as has been discussed in
   several use cases, the effect will to proportionately increase the
   number of IIDs.  A duplicate address detection (DAD) cycle is needed
   for each configured IID, introducing more and more overhead into the
   network.  Each failed DAD requires the initiating node to regenerate
   a new IID and undergo the DAD cycle again.  This document proposes an
   optimized approach when higher privacy is required in a given network
   by allowing a 6LBR (6LoWPAN Border Router) to provide a unique IID,
   avoiding any potential duplication.  Such practice also prevents
   failure of time-critical applications, by enabling 6LBR to provide a
   unique IID, in case of address collision.

   Further improvements are proposed to enable multiple concurrent DAD
   cycles, and to return the randomized IID from 6LBR to 6LN in a space-
   efficient manner.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 13, 2017.

Sangi, et al.          Expires September 13, 2017               [Page 1]
Internet-Draft       draft-rashid-6lo-IID-Assignment          March 2017

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Likelihood of Address Collision . . . . . . . . . . . . . . .   4
   4.  IID Assignment by 6LBR  . . . . . . . . . . . . . . . . . . .   4
     4.1.  Advantages of proposed algorithm  . . . . . . . . . . . .   6
     4.2.  Extended Duplicate Address Request (EDAR) . . . . . . . .   6
     4.3.  Extended Duplicate Address Confirmation (EDAC)  . . . . .   7
     4.4.  Extended Address Registration Option  . . . . . . . . . .   7
   5.  Multiple DAD cycles . . . . . . . . . . . . . . . . . . . . .   8
   6.  XOR Encoding  . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  EDAR and EDAC Messages, and EARO Option . . . . . . . . .   9
     7.2.  Additions to Status Field . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   IPv6 addresses in SLAAC are formed by concatenating a network prefix,
   acquired from Router Advertisement (RA) messages, with a locally
   generated IID [RFC4862], [RFC2464].  Since the best method for
   generating IIDs varies depending on the network, none of the proposed
Show full document text