[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

6lo                                                            AR. Sangi
Internet-Draft                                                   M. Chen
Intended status: Standards Track                     Huawei Technologies
Expires: September 17, 2016                                   C. Perkins
                                                               Futurewei
                                                          March 16, 2016


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

Abstract

   In IPv6 Stateless Address Autoconfiguration (SLAAC), use of a random
   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 that requires 6LBR (6LoWPAN Border Router) to
   provide a unique IID, avoiding the potential duplication.

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 17, 2016.

Copyright Notice

   Copyright (c) 2016 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



Sangi, et al.          Expires September 17, 2016               [Page 1]


Internet-Draft       draft-rashid-6lo-IID-Assignment          March 2016


   (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.  IID Assignment by 6LBR  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Extended Confirmation Message . . . . . . . . . . . . . .   5
     3.2.  Extended Address Registration Option  . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Additions of EDAC Message and EARO Option . . . . . . . .   6
     4.2.  Additions to Status Field . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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 depends on the nature of networks, none of the
   proposed mechanisms is considered a default mechanism [RFC4941],
   [RFC7217].  Using neighbour discovery (ND), the uniqueness of newly
   generated IID is verified [RFC6775]. 6LBR ensures the duplication
   detection, and replies with a status.  A failed DAD would require the
   initiating 6LN (6LoWPAN Node) to regenerate an IID and undergo
   another DAD cycle, until either 6LN succeeds or reaches its maximum
   number of retries[RFC6775].

   A locally generated IID can be derived from embedded IEEE identifier
   [RFC4941] or randomly (based on a few variables) [RFC7217].  MAC
   reuse is far common than assumed [RFC7217], and IIDs derived from MAC
   address are likely to cause more than the expected number of DAD
   failures.  As soon as the 6LN generates an IID, it sends the NS
   (Neighbor Solicitation) message to 6LR (LLN Router) and 6LR proceeds
   with the address duplication request routine with 6LBR by sending an
   ICMPv6 based DAR (Duplicate Address Request) message.  An LN sends
   out a NS after checking its local cache for duplication; before
   proceeding with DAR, the 6LR also protects against address



Sangi, et al.          Expires September 17, 2016               [Page 2]


Internet-Draft       draft-rashid-6lo-IID-Assignment          March 2016


   duplication within a locally maintained Neighbor Cache Entry (NCE)
   [RFC7217].

   [RFC5548], [RFC5827] discuss use cases including huge numbers of
   nodes and vast scale networks.  The arbitrary use of IIDs resolves
   the privacy concerns of participating node.  A simple NS supposedly
   targeted to a very small group of nodes MAY ends-up polluting whole
   wireless bandwidth [I-D.vyncke-6man-mcast-not-efficient].  Multicast
   NS and NA are much more frequent in large scale radio environment
   with mobile devices [I-D.thubert-6lo-backbone-router].  Additionally,
   as the IIDs are periodically changed for privacy, the probability
   becomes high for a duplicate IIDs that would results in DAD failure
   and repeated cycles.

   This document describes optimization to 6LoWPAN ND by enabling 6LBR
   to grant a unique IID for failed DAD.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].  Additionally, this document uses terminology from
   [RFC6775], [RFC2464], [I-D.ietf-6man-default-iids], and
   [I-D.ietf-6man-ipv6-address-generation-privacy].  This document also
   uses the following terms:

   RID: Random identifier.

   PRF: Pseudo random function.

   LSB: Least significant bit.

   EDAC: Extended duplicate address confirmation.

   EARO: Extended address registration option.

3.  IID Assignment by 6LBR

   MAC driven IIDs [RFC2464] reduce or eliminate the the need for DAD,
   but in practice such IID generation is discouraged
   ([I-D.ietf-6man-default-iids],
   [I-D.ietf-6man-ipv6-address-generation-privacy]), as common privacy
   concerns still persist, for instance:

   o Network activity correlation,

   o Location tracking,



Sangi, et al.          Expires September 17, 2016               [Page 3]


Internet-Draft       draft-rashid-6lo-IID-Assignment          March 2016


   o Address scanning, and

   o Device-specific vulnerability exploitation.

   Moreover, multiple approaches are proposed to suit different network
   constraints.  Considering the scalability of a network and enabling
   6LBR to suggest an IID, this draft proposes another IID generating
   [RFC7217] approach to support periodically changing IIDs.

      RID (Random Identifier) :=
       |Prefix|Interface Index|N/W ID|DAD Counter|Randomized Secret Key|
             \                                            /
                 \                                    /
                     \                            /
                      +--------+--------+--------+
                      |      Hash Function       |
                      +--------+--------+--------+
                     /                            \
                   /                                \
                           Extract 64 LSBs

                  Figure 1: Using RFC7217 to generate IID

   In case DAD fails, the 6LBR will use public values for Prefix,
   Interface Index, and Network ID; the remaining two variables (DAD
   Counter, Randomized Private Key) are local values.  Neighbor
   solicitation using link-local address cannot be avoided, but only the
   newly generated IID needs to be passed on to LN (by way of relevant
   6LR).

           6LN                           6LR                        6LBR
            |                             |                           |
      1.    | --- NS with Address Reg --> |                           |
            |       [ARO + SLLAO]         |                           |
            |                             |                           |
      2.    |                             | ---------- DAR ---------> |
            |                             |                           |
      3.    |                             | <--------- EDAC --------- |
            |                             |                           |
      4.    | <-- NA with Address Reg --- |                           |
            |      [EARO with Status]     |                           |

              Figure 2: DAD cycle when 6LBR generates an IID

   The Approach in this draft is of reactive nature rather than
   proactive.  6LBR only replies with locally generated IID when DAD
   fails.




Sangi, et al.          Expires September 17, 2016               [Page 4]


Internet-Draft       draft-rashid-6lo-IID-Assignment          March 2016


3.1.  Extended Confirmation Message

   The Prefix is the same throughout each LoWPAN network.  This draft
   extends the DAC:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |      Code     |            Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Status      |    Reserved   |       Registration Lifetime   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                            EUI-64                             +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                     6LBR Generated IID                        +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: Extended Duplication Address Confirmation

   The fields are similar to DAC in [RFC6775] except:

   Type: 159

   6LBR Generated IID: 64 bit IID generated by 6LBR.

3.2.  Extended Address Registration Option

   ARO and EARO can ONLY be initiated by host and 6LR, respectively.
   [RFC6775] expects the reply of a host initiated ARO from 6LR with
   same ARO except the changed status bit to indicate the duplication
   result.  EARO is introduced in this document and 6LR can send out
   this option if it receives EDAC instead of DAC from 6LBR.















Sangi, et al.          Expires September 17, 2016               [Page 5]


Internet-Draft       draft-rashid-6lo-IID-Assignment          March 2016


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |   Length = 2  |     Status    |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Reserved            |     Registration Lifetime     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                            EUI-64                             +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                     6LBR Generated IID                        +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: Extended Address Registration Option

   The fields are similar to ARO in [RFC6775] except:

   Type: 36

   6LBR Generated IID: a 64 bit IID generated by 6LBR.

4.  IANA Considerations

4.1.  Additions of EDAC Message and EARO Option

   The document requires one new ICMPv6 "type" number under the
   subregistry "ICMPv6 "type" Numbers":

   o Extended Duplicate Address Confirmation (159)

   This document requires a new ND option type under the subregistry
   "IPv6 Neighbor Discovery Option Formats":

   o Extended Address Registration Option (36)

4.2.  Additions to Status Field

   IANA is required to assign two new values to the Status bit in
   Address Registration Option under the sub registry "IPv6 Neighbor
   Discovery Option Formats":








Sangi, et al.          Expires September 17, 2016               [Page 6]


Internet-Draft       draft-rashid-6lo-IID-Assignment          March 2016


            +--------+--------------------------------------------+
            | Status | Description                                |
            +--------+--------------------------------------------+
            | 0      | Success                                    |
            | 1      | Duplicate Address                          |
            | 2      | Neighbor Cache Full                        |
            | 3      | 6LBR generated IID                         |
            | 4-255  | Allocated using Standards Action [RFC5226] |
            +--------+--------------------------------------------+
                           Addition to Status bits

5.  Security Considerations

   TBD

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
              <http://www.rfc-editor.org/info/rfc2464>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <http://www.rfc-editor.org/info/rfc4941>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <http://www.rfc-editor.org/info/rfc6775>.



Sangi, et al.          Expires September 17, 2016               [Page 7]


Internet-Draft       draft-rashid-6lo-IID-Assignment          March 2016


   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <http://www.rfc-editor.org/info/rfc7217>.

6.2.  Informative References

   [I-D.ietf-6man-default-iids]
              Gont, F., Cooper, A., Thaler, D., and S. LIU,
              "Recommendation on Stable IPv6 Interface Identifiers",
              draft-ietf-6man-default-iids-10 (work in progress),
              February 2016.

   [I-D.ietf-6man-ipv6-address-generation-privacy]
              Cooper, A., Gont, F., and D. Thaler, "Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              draft-ietf-6man-ipv6-address-generation-privacy-08 (work
              in progress), September 2015.

   [I-D.thubert-6lo-backbone-router]
              Thubert, P., "IPv6 Backbone Router", draft-thubert-6lo-
              backbone-router-03 (work in progress), November 2015.

   [I-D.vyncke-6man-mcast-not-efficient]
              Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
              Yourtchenko, "Why Network-Layer Multicast is Not Always
              Efficient At Datalink Layer", draft-vyncke-6man-mcast-not-
              efficient-01 (work in progress), February 2014.

   [RFC5548]  Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
              D. Barthel, Ed., "Routing Requirements for Urban Low-Power
              and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
              2009, <http://www.rfc-editor.org/info/rfc5548>.

   [RFC5827]  Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and
              P. Hurtig, "Early Retransmit for TCP and Stream Control
              Transmission Protocol (SCTP)", RFC 5827,
              DOI 10.17487/RFC5827, May 2010,
              <http://www.rfc-editor.org/info/rfc5827>.

Authors' Addresses









Sangi, et al.          Expires September 17, 2016               [Page 8]


Internet-Draft       draft-rashid-6lo-IID-Assignment          March 2016


   Abdur Rashid Sangi
   Huawei Technologies
   No.156 Beiqing Rd. Haidian District
   Beijing  100095
   P.R. China

   Email: rashid.sangi@huawei.com


   Mach (Guoyi)Chen
   Huawei Technologies
   No.156 Beiqing Rd. Haidian District
   Beijing  100095
   P.R. China

   Email: mach.chen@huawei.com


   Charles E. Perkins
   Futurewei
   2330 Central Expressway
   Santa Clara  95050
   USA

   Email: charliep@computer.org


























Sangi, et al.          Expires September 17, 2016               [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/