6lo AR. Sangi
Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies
Expires: December 18, 2016 C. Perkins
Futurewei
June 16, 2016
Designating 6LBR for IID Assignment
draft-rashid-6lo-iid-assignment-01
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 that requires 6LBR (6LoWPAN Border Router) to
provide a unique IID, avoiding the potential duplication.
Additionally, further optimizations are suggested to enable multiple
concurrent DAD cycles and to return the suggested 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 December 18, 2016.
Sangi, et al. Expires December 18, 2016 [Page 1]
Internet-Draft draft-rashid-6lo-IID-Assignment June 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
(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 . . . . . . . . . . . . . . . . . . . 4
3.1. Extended Request/Confirmation Message . . . . . . . . . . 5
3.2. Extended Address Registration Option . . . . . . . . . . 6
4. Concurrent DAD . . . . . . . . . . . . . . . . . . . . . . . 7
5. Aggregation Approach . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. EDAR and EDAC Messages, and EARO Option . . . . . . . . . 8
6.2. Additions to Status Field . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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[RFC4941],[RFC7217] is considered a default
mechanism. Using neighbour discovery (ND), the uniqueness of newly
generated IID is verified [RFC6775]. 6LBR performs DAD, and replies
with a status. A failed DAD would require the initiating 6LN
(6LoWPAN node) to regenerate an IID and wait for another DAD cycle,
until the 6LN successfully registers a unique address [RFC6775].
A locally generated IID can be derived either from an embedded IEEE
identifier [RFC4941], or randomly (based on a few variables)
Sangi, et al. Expires December 18, 2016 [Page 2]
Internet-Draft draft-rashid-6lo-IID-Assignment June 2016
[RFC7217]. Since MAC reuse is unfortunately far more common than
usually assumed [RFC7217], 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). Then 6LR proceeds to send an ICMPv6
based DAR (Duplicate Address Request) message to 6LBR. An LN sends
out a NS after checking its local cache for duplication; before
proceeding with DAR, the 6LR also protects against address
duplication within a locally maintained Neighbor Cache Entry (NCE)
[RFC7217].
Use cases including huge numbers of nodes and vast scale networks are
discussed in [RFC5548], [RFC5827]. The use of arbitrary IIDs can
resolve privacy concerns for a participating node, but a simple NS
intended to be targeted to a small group of nodes can pollute all the
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]. Since the
IIDs may be sporadically changed for privacy, the probability
increases that a duplicate IIDs would result in DAD failure and
repeated DAD cycles.
This document describes optimizations to 6LoWPAN ND which enable 6LBR
to grant a unique IID for failed DAD, to undergo concurrent DAD and
to return an IID to 6LN in a space-efficient manner.
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]. This document uses terminology from [RFC6775], [RFC2464],
[I-D.ietf-6man-default-iids], and
[I-D.ietf-6man-ipv6-address-generation-privacy].
SLLAO: Stateless Link-Local Address Option
RID: Random IDentifier
PRF: Pseudo Random Function
IID: Interface IDentifier
This document also uses the following terms:
EARO: Extended Address Registration Option
EDAR: Extended Duplicate Address Request
Sangi, et al. Expires December 18, 2016 [Page 3]
Internet-Draft draft-rashid-6lo-IID-Assignment June 2016
EDAC: Extended Duplicate Address Confirmation
LSB: Least Significant Bit
3. IID Assignment by 6LBR
MAC driven IIDs [RFC2464] reduce or eliminate 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,
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 method for IID
generation [RFC7217] that supports 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
If 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 forwarded to the LN.
Sangi, et al. Expires December 18, 2016 [Page 4]
Internet-Draft draft-rashid-6lo-IID-Assignment June 2016
6LN 6LR 6LBR
| | |
1. | --- NS with Address Reg --> | |
| [ARO + SLLAO] | |
| | |
2. | | ---------- EDAR --------> |
| | |
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 reactive rather than proactive; 6LBR
only replies with a locally generated IID when DAD fails.
3.1. Extended Request/Confirmation Message
The Prefix is the same throughout each LoWPAN network. This draft
uses that feature to reduce the size of the DAR:
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 | Rsrv | Cycle | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Registered IID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Extended Duplication Address Request
The fields are similar to DAR in [RFC6775] except:
Type: 159 (TBD)
Cycle: 4 out of 8 reserved bits to identify the DAD cycle between
given 6LR and 6LBR. The reference is used later by 6LR to extract
IID suggested by 6LBR.
Sangi, et al. Expires December 18, 2016 [Page 5]
Internet-Draft draft-rashid-6lo-IID-Assignment June 2016
Unlike the DAR, the Registered IID (64 bit) is returned instead of
Registered Address (128 bit).
EDAC reduces the space needed for returning the EUI-64:
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 | Rsrv | Cycle | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64/XOR Aggregation +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Extended Duplication Address Confirmation
The fields are similar to DAC in [RFC6775] except:
Type: 160 (TBD)
Cycle: 4 out of 8 reserved bits identify the DAD cycle between the
6LR and 6LBR. The reference is used later by 6LR to extract the IID
suggested by 6LBR.
In case of a failed DAD, a 6LBR-generated IID is aggregated using XOR
with EUI-64; otherwise the same EUI-64 occupies the 64 bits.
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 the
same ARO except for changing the status bit to indicate the
duplication detection. EARO is introduced in this document; 6LR can
send out this option if it receives EDAC instead of DAC from 6LBR.
Sangi, et al. Expires December 18, 2016 [Page 6]
Internet-Draft draft-rashid-6lo-IID-Assignment June 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/XOR Aggregation +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Extended Address Registration Option
The fields are similar to ARO in [RFC6775] except:
Type: 36 (TBD)
EUI-64/XOR Aggregation: a 64 bit IID generated by 6LBR is XOR'ed with
EUI-64.
4. Concurrent DAD
In [RFC6775], 6LN is expected to generate an IID; so 6LR only acts on
the first unique IID claim and silently discards any later claims for
the same IID. In contrast, this document enables 6LBR to assign a
unique IID in case of a duplicate IID claim by 6LR. For this
purpose, a "Cycle" field is introduced to enable concurrency that
will be helpful for large-scale networks [RFC5548]. See Figure 3 and
Figure 4 for the format of the Cycle field.
5. Aggregation Approach
Each iteration of DAR and DAC [RFC6775] carries the entire 128 bit
Registered Address during the DAD routine, even though the network
Prefix is the same throughout each LoWPAN. This document enables
eliding the network prefix part of the Registered Address as well in
EDAC and EARO using simple XOR aggregation. The aggregated 64 bit
field carries EUI-64 and suggested IID. See Figure 4 and Figure 5
for the format of the EUI-64/XOR Aggregation.
Under the proposed arrangement, 6LBR would only aggregate values, 6LN
would only extract values and 6LR would do both.
At 6LR before sending EDAR to 6LBR:
o 6LR would use the 4 out of 8 Reserved "Cycle" bits of EDAR to keep
track of multiple DAD cycles. These iterations are recorded at 6LR
Sangi, et al. Expires December 18, 2016 [Page 7]
Internet-Draft draft-rashid-6lo-IID-Assignment June 2016
and that information is used to extract IID/EUI-64 from EDAC to be
forwarded to the appropriate 6LN.
At 6LBR before sending to 6LR:
o If Status = 0 (Success), then 6LBR returns EDAC using all the
values as received from EDAR.
o If Status = 1 (Duplicate), then 6LBR generates IID and XORs it with
EUI-64 to return in the EDAC to 6LR.
At 6LR before sending to 6LN:
o If Status = 0 (Success) then keep the claimed address of 6LN as
Destination Address for ARO to 6LN.
o If Status = 1 (Duplicate), then match the "Cycle" bits of EDAC to
extract (using XOR) the EUI-64 address and use the extracted address
as the Destination Address for EARO to 6LN.
Finally, at 6LN:
o If Status = 0 (Success), 6LN starts using the address that it
claimed.
o If Status = 1 (Duplicate) then 6LN XORs the received EUI-64 address
with its claimed EUI-64, which results in the newly generated IID
sent by 6LBR.
6. IANA Considerations
6.1. EDAR and EDAC Messages, and EARO Option
The document requires two new ICMPv6 type numbers under the
subregistry 'ICMPv6 "type" Numbers':
o Extended Duplicate Address Request (159)
o Extended Duplicate Address Confirmation (160)
This document requires a new ND option type under the subregistry
"IPv6 Neighbor Discovery Option Formats":
o Extended Address Registration Option (36)
Sangi, et al. Expires December 18, 2016 [Page 8]
Internet-Draft draft-rashid-6lo-IID-Assignment June 2016
6.2. Additions to Status Field
One new value is required for the "Address Registration Option Status
Values" sub-registry under the "IPv6 Neighbor Discovery Option
Formats":
+--------+--------------------------------------------+
| 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
7. Security Considerations
TBD
8. References
8.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>.
[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>.
Sangi, et al. Expires December 18, 2016 [Page 9]
Internet-Draft draft-rashid-6lo-IID-Assignment June 2016
[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>.
[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>.
8.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-11 (work in progress), April
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>.
Sangi, et al. Expires December 18, 2016 [Page 10]
Internet-Draft draft-rashid-6lo-IID-Assignment June 2016
Authors' Addresses
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 December 18, 2016 [Page 11]