| 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
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.
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.
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.
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 mechanisms [RFC4941],[RFC7217] is considered a default mechanism. Using neighbour discovery (ND), the uniqueness of newly a 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) [RFC7217]. Since MAC reuse is unfortunately far more common than usually assumed [RFC7217][MAC-Duplication], 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 a great deal of 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.ietf-6lo-backbone-router]. Since the IIDs may be sporadically changed for privacy, the probability further increases that a duplicate IIDs would result in DAD failure and repeated DAD cycles.
On the other hand, waiting for 6LN to regenerate another IID due to a failed DAD might lead to failure of a time-critical application.
Address assignment can also be done using DNS (Domain Name Server), but doing so typically requires multicast traffic and introduces more control overhead. Unlike DNS, the 6LoWPAN ND works on layer 2 and our proposed mechanism implicitly provides assistance to the DAD process.
This document describes improvements to 6LoWPAN ND which enable 6LBR to grant a unique IID for failed DAD, to enable multiple concurrent DAD cycles, and to return an IID to 6LN in a space-efficient manner.
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], [RFC8064], and [RFC7721].
This document also uses the following terms:
The following observations have motivated the design of this proposal:
MAC driven IIDs [RFC2464] reduce or eliminate the need for DAD, but in practice such IID generation is discouraged ([RFC8064], [RFC7721]), as common privacy concerns still persist, for instance:
Multiple approaches are proposed to suit different network constraints. The mechanisms specified in [RFC4941], which are mainly based on MAC address or an appropriate simple random number generation algorithm can also be used to generate IID.
Considering the scalability of a network and enabling 6LBR to randomize an IID, the method for IID generation specified in [RFC7217] SHOULD be used because this method is appropriate 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
If DAD fails, the 6LBR will use public values for Prefix, Interface Index, and Network ID; the remaining two variables (DAD Counter, Randomized Secret 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.
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.
Appendix A [RFC7217] states that a Net_Iface parameter can either be:
EUI-64 of 6LN would be sent to 6LBR via 6LR within EARO and using that, a Link-Layer Address can be derived at 6LBR to input in PRF. For multiple interfaces, DAD_counter would be incremented as soon as the collision occurs.
By reference to the algorithm in [RFC7217], the resulting IID offers the following advantages:
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 Duplicate Address Request
The fields are similar to DAR in [RFC6775] except:
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 Encoding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Extended Duplicate Address Confirmation
The fields are similar to DAC in [RFC6775] except:
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.
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 Encoding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Extended Address Registration Option
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 multiple concurrent DAD cycles that will be helpful for large-scale networks [RFC5548]. At 6LN, this "Cycle" field is also used when extracting both IID and EUI-64 that are XOR'ed by 6LBR. See Figure 3 and Figure 4 for the format of the Cycle field.
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 encoding. The encoded 64 bit field carries EUI-64 and randomized IID. See Figure 4 and Figure 5 for the format of the EUI-64/XOR encoding.
Under the proposed arrangement, 6LBR would only encode 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 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.
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)
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
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2464] | Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998. |
| [RFC4862] | Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007. |
| [RFC4941] | Narten, T., Draves, R. and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007. |
| [RFC6775] | Shelby, Z., 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. |
| [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. |