< draft-thubert-6lo-rfc6775-update-00.txt   draft-thubert-6lo-rfc6775-update-01.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft cisco Internet-Draft cisco
Updates: 6775 (if approved) E. Nordmark Updates: 6775 (if approved) E. Nordmark
Intended status: Standards Track Arista Networks Intended status: Standards Track Arista Networks
Expires: November 5, 2016 S. Chakrabarti Expires: April 29, 2017 S. Chakrabarti
Ericsson Ericsson
May 4, 2016 October 26, 2016
An Update to 6LoWPAN ND An Update to 6LoWPAN ND
draft-thubert-6lo-rfc6775-update-00 draft-thubert-6lo-rfc6775-update-01
Abstract Abstract
This specification proposes an update to 6LoWPAN Neighbor Discovery, This specification updates 6LoWPAN Neighbor Discovery (RFC6775), to
to clarify the role of the protocol as a registration technique, and clarify the role of the protocol as a registration technique,
provide enhancements to the registration capabilities, in particular simplify the registration operation in 6LoWPAN routers, and provide
for the registration to a backbone router for proxy ND operations. enhancements to the registration capabilities, in particular for the
registration to a backbone router for proxy ND operations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2016. This Internet-Draft will expire on April 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 14
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4 3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Extended Address Registration Option . . . . . . . . . . 4 3.1. Extended Address Registration Option . . . . . . . . . . 4
3.2. Link-local Scope and Consequences . . . . . . . . . . . . 5 3.2. Registering the Target Address . . . . . . . . . . . . . 5
4. Applicability and Requirements Served . . . . . . . . . . . . 6 3.3. Link-local Addresses and Registration . . . . . . . . . . 5
4. Applicability and Requirements Served . . . . . . . . . . . . 7
5. The Enhanced Address Registration Option (EARO) . . . . . . . 7 5. The Enhanced Address Registration Option (EARO) . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.1. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.3. External Informative References . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.1. Requirements Related to Mobility . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
A.2. Requirements Related to Routing Protocols . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 14
10.3. External Informative References . . . . . . . . . . . . 16
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 17
A.1. Requirements Related to Mobility . . . . . . . . . . . . 17
A.2. Requirements Related to Routing Protocols . . . . . . . . 17
A.3. Requirements Related to the Variety of Low-Power Link A.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 17 types . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.4. Requirements Related to Proxy Operations . . . . . . . . 18 A.4. Requirements Related to Proxy Operations . . . . . . . . 19
A.5. Requirements Related to Security . . . . . . . . . . . . 18 A.5. Requirements Related to Security . . . . . . . . . . . . 20
A.6. Requirements Related to Scalability . . . . . . . . . . . 19 A.6. Requirements Related to Scalability . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The scope of this draft is an IPv6 Low Power Lossy Network (LLN), The scope of this draft is an IPv6 Low Power Lossy Network (LLN),
which can be a simple star or a more complex mesh topology. The LLN which can be a simple star or a more complex mesh topology. The LLN
may be anchored at an IPv6 Backbone Router (6BBR). The Backbone may be anchored at an IPv6 Backbone Router (6BBR). The Backbone
Routers interconnect the LLNs over a Backbone Link and emulate that Routers interconnect the LLNs over a Backbone Link and emulate that
the LLN nodes are present on the Backbone using proxy-ND operations. the LLN nodes are present on the Backbone using proxy-ND operations.
IPv6 Neighbor Discovery (ND) Optimization for IPv6 over Low-Power IPv6 Neighbor Discovery (ND) Optimization for IPv6 over Low-Power
skipping to change at page 3, line 31 skipping to change at page 3, line 36
Routing for Low-Power and Lossy Networks" [RFC7102] and Routing for Low-Power and Lossy Networks" [RFC7102] and
[I-D.ietf-6tisch-terminology], as well as this additional [I-D.ietf-6tisch-terminology], as well as this additional
terminology: terminology:
Backbone This is an IPv6 transit link that interconnects 2 or more Backbone This is an IPv6 transit link that interconnects 2 or more
Backbone Routers. It is expected to be deployed as a high Backbone Routers. It is expected to be deployed as a high
speed backbone in order to federate a potentially large set of speed backbone in order to federate a potentially large set of
LLNS. Also referred to as a LLN backbone or Backbone network. LLNS. Also referred to as a LLN backbone or Backbone network.
Backbone Router An IPv6 router that federates the LLN using a Backbone Router An IPv6 router that federates the LLN using a
Backbone link as a backbone. A BBR acts as a 6LoWPAN Border Backbone link as a backbone. A 6BBR acts as a 6LoWPAN Border
Routers (6LBR) and an Energy Aware Default Router (NEAR). Routers (6LBR) and an Energy Aware Default Router (NEAR).
Extended LLN This is the aggregation of multiple LLNs as defined in Extended LLN This is the aggregation of multiple LLNs as defined in
[RFC4919], interconnected by a Backbone Link via Backbone [RFC4919], interconnected by a Backbone Link via Backbone
Routers, and forming a single IPv6 MultiLink Subnet. Routers, and forming a single IPv6 MultiLink Subnet.
Registration The process during which a wireless Node registers its Registration The process during which a wireless Node registers its
address(es) with the Border Router so the 6BBR can proxy ND for address(es) with the Border Router so the 6BBR can proxy ND for
it over the backbone. it over the backbone.
skipping to change at page 4, line 20 skipping to change at page 4, line 25
the NS(ARO) is that of the Registering Node, which causes it to the NS(ARO) is that of the Registering Node, which causes it to
attract the packets from the 6BBR to the Registered Node and attract the packets from the 6BBR to the Registered Node and
route them over the LLN. route them over the LLN.
Registered Address The address owned by the Registered Node node Registered Address The address owned by the Registered Node node
that is being registered. that is being registered.
3. Updating RFC 6775 3. Updating RFC 6775
The support of this specification is signaled in Router Advertisement The support of this specification is signaled in Router Advertisement
(RA) messages by 6LoWPAN Router (6LR) (how: tbd). A Registering Node (RA) messages by 6LoWPAN Router (6LR) (how: tbd). Support for this
that supports this specification will favor registering to a 6LR that specification can also be inferred from the update of the ARO option
indicates support for this specification over that of [RFC6775]. in the ND exchanges
. A Registering Node that supports this specification will favor
registering to a 6LR that indicates support for this specification
over that of [RFC6775].
3.1. Extended Address Registration Option 3.1. Extended Address Registration Option
This specification extends the Address Registration Option (ARO) used This specification extends the Address Registration Option (ARO) used
for the process of address registration. The new ARO is referred to for the process of address registration. The new ARO is referred to
as Extended ARO (EARO), and its semantics are modified as follows: as Extended ARO (EARO), and its semantics are modified as follows:
The address that is being registered with a Neighbor Solicitation The address that is being registered with a Neighbor Solicitation
(NS) with an EARO is now the Target Address, as opposed to the Source (NS) with an EARO is now the Target Address, as opposed to the Source
Address as specified in [RFC6775]. This change enables a 6LBR to use Address as specified in [RFC6775]. This change enables a 6LBR to use
skipping to change at page 5, line 5 skipping to change at page 5, line 11
Provable Temporary UID (PT-UID) as opposed to burn-in MAC address, Provable Temporary UID (PT-UID) as opposed to burn-in MAC address,
the PT-UID providing a trusted anchor by the 6LR and 6LBR to protect the PT-UID providing a trusted anchor by the 6LR and 6LBR to protect
the state associated to the node. the state associated to the node.
The specification introduces a Transaction ID (TID) field in the The specification introduces a Transaction ID (TID) field in the
EARO. The TID MUST be provided by a node that supports this EARO. The TID MUST be provided by a node that supports this
specification and a new T flag MUST be set to indicate so. The T bit specification and a new T flag MUST be set to indicate so. The T bit
can be used to determine whether the peer supports this can be used to determine whether the peer supports this
specification. specification.
3.2. Link-local Scope and Consequences 3.2. Registering the Target Address
The use of link-local addresses as source address for the One of the requirements that this specification serves is the
registration, and the expectation for the scope of those addresses, capability by a router such as a RPL root to proxy-register an
are clarified as follows: address to a 6BBR on behalf of a 6LN, as discussed in Appendix A.4.
In order to serve that requirement, this specification changes the
behaviour of the 6LN and the 6LR so that the Registered Address is
found in the Target Address field of the NS and NA messages as
opposed to the Source Address.
A link is abstracted as a one-hop point-to-point communication With this convention, a TLLA option would indicate the link-layer
medium. There is no need nor expectation that a link-local address address of the 6LN that owns the address, whereas the SLLA Option in
is unique across the whole LLN. A 6LR assumes that the link-local a NS message indicates that of the Registering Node, which can be the
address of a Registering Node is unique as long as the 6LR does not owner device, or a proxy.
have a conflicting registration for that address.
Since the Registering Node is the one that has reachability with the
6LR, and is the one expecting packets for the 6LN, it makes sense to
maintain compatibility with [RFC6775], and it is REQUIRED that an
SLLA Option is always placed in a registration NS(EARO) message.
3.3. Link-local Addresses and Registration
Considering that LLN nodes are often not wired and may move, there is
no guarantee that a link-local address stays unique between a
potentially variable and unbounded set of neighboring nodes.
Compared to [RFC6775], this specification only requires that a link-
local address is unique from the perspective of the peering nodes.
This simplifies the Duplicate Address Detection (DAD) for link-local
addresses, and there is no DAR/DAC exchange between the 6LR and a
6LBR for link-local addresses.
Additionally, [RFC6775] requires that a 6LoWPAN Node (6LN) uses an
address being registered as the source of the registration message.
This generates complexities in the 6LR to be able to cope with a
potential duplication, in particular for global addresses. To
simplify this, a 6LN and a 6LR that conform this specification always
use link-local addresses as source and destination addresses for the
registration NS/NA exchange. As a result, the registration is
globally faster, and some of the complexity is removed.
In more details:
An exchange between two nodes using link-local addresses implies that An exchange between two nodes using link-local addresses implies that
they are reachable over one hop and that at least one of the 2 nodes they are reachable over one hop and that at least one of the 2 nodes
acts as a 6LR. A node MUST register a link-local address to a 6LR in acts as a 6LR. A node MUST register a link-local address to a 6LR in
order to obtain link scope reachability from that 6LR beyond the order to obtain reachability from that 6LR beyond the current
current exchange, and in particular to use it as Source Address to exchange, and in particular to use the link-local address as source
register other addresses. address to register other addresses, e.g. global addresses. If there
is no collision with an address previously registered to this 6LR by
another 6LN, then, from the standpoint of this 6LR, this link-local
address is unique and the registration is acceptable. Conversely, it
may possibly happen that two different 6LRs expose a same link-local
address but different link-layer addresses. In that case, a 6LN may
only interact with one of the 6LR so as to avoid confusion in the 6LN
neighbor cache.
A consequence of this model is that the Duplicate Address Detection The DAD process between the 6LR and a 6LoWPAN Border Router (6LBR),
(DAD) process between the 6LR and a 6LoWPAN Border Router (6LBR),
which is based on a Duplicate Address Request (DAR) / Duplicate which is based on a Duplicate Address Request (DAR) / Duplicate
Address Confirmation (DAC) exchange as described in [RFC6775], does Address Confirmation (DAC) exchange as described in [RFC6775], does
not take place for link-local addresses. not need to take place for link-local addresses.
It is desired that a 6LR does not need to modify its state associated It is desired that a 6LR does not need to modify its state associated
to the Source Address of an NS(EARO) message. For that reason, when to the Source Address of an NS(EARO) message. For that reason, when
possible, it is RECOMMENDED to use an address that is already possible, it is RECOMMENDED to use an address that is already
registered with a 6LR as source for the NS(EARO) message. registered with a 6LR
When a Registering Node does not yet have an already-registered When registering to a 6LR that conforms this specification, a node
address, it MUST register a link-local address, using it as both the MUST use a link-local address as the source address of the
Source and the Target Address of an NS(EARO) message. In that case, registration, whatever the type of IPv6 address that is being
it is RECOMMENDED to use a link-local address that is (expected to registered. That link-local Address MUST be either already
be) globally unique, e.g. derived from a burn-in MAC address. registrered, or the address that is being registered.
When a Registering Node does not have an already-registered address,
it MUST register a link-local address, using it as both the Source
and the Target Address of an NS(EARO) message. In that case, it is
RECOMMENDED to use a link-local address that is (expected to be)
globally unique, e.g. derived from a burn-in MAC address. An EARO
option in the response NA indicates that the 6LR supports this
specification.
Since there is no DAR/DAC exchange for link-local addresses, the 6LR Since there is no DAR/DAC exchange for link-local addresses, the 6LR
may answer immediately to the registration of a link-local address, may answer immediately to the registration of a link-local address,
based solely on its existing state and the Source Link-Layer Option based solely on its existing state and the Source Link-Layer Option
that MUST be placed in the NS(EARO) message as required in [RFC6775]. that MUST be placed in the NS(EARO) message as required in [RFC6775].
A node must register its IPv6 Global Unicast IPv6 Addresses (GUA) to A node needs to register its IPv6 Global Unicast IPv6 Addresses (GUA)
a 6LR in order to obtain a global reachability for these addresses to a 6LR in order to obtain a global reachability for these addresses
via that 6LR. In particular a Registering NODE registering a GUA via that 6LR. As opposed to a node that complies to [RFC6775], a
SHOULD NOT use that GUA as Source Address for the registration to a Registering Node registering a GUA does use that GUA as Source
6LR that conforms this specification. Address for the registration to a 6LR that conforms this
specification. The DAR/DAC exchange MUST take place for non-link-
What makes this model practical in existing LLNs, which can grow to local addresses as prescribed by [RFC6775].
large number of nodes, is that a subnet may encompass multiple links,
which can be LLN links or can be backbone links that federate a
number of LLN links, effectively forming a non-broadcast multi-access
(NBMA) multi-link subnet (MLSN).
4. Applicability and Requirements Served 4. Applicability and Requirements Served
This specification extends 6LoWPAN ND to sequence the registration This specification extends 6LoWPAN ND to sequence the registration
and serves the requirements expressed Appendix A.1 by enabling the and serves the requirements expressed Appendix A.1 by enabling the
mobility of devices from one LLN to the next based on the mobility of devices from one LLN to the next based on the
complementary work in [I-D.ietf-6lo-backbone-router]. complementary work in [I-D.ietf-6lo-backbone-router].
In the context of the the TimeSlotted Channel Hopping (TSCH) mode of In the context of the the TimeSlotted Channel Hopping (TSCH) mode of
[IEEE802154], the 6TiSCH architecture [I-D.ietf-6tisch-architecture] [IEEE802154], the 6TiSCH architecture [I-D.ietf-6tisch-architecture]
skipping to change at page 9, line 10 skipping to change at page 10, line 10
Length: 2 Length: 2
Status: Status:
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Description | | Value | Description |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 0..2 | See [RFC6775]. Note that a Status of 1 "Duplicate | | 0..2 | See [RFC6775]. Note that a Status of 1 "Duplicate |
| | Address" applies to the Registered Address. If the Source | | | Address" applies to the Registered Address. If the Source |
| | Address differs from the Registered Address it conflicts | | | Address conflicts with an existing registration, |
| | with an existing registration, "Invalid Source Address" | | | "Duplicate Source Address" should be used instead |
| | should be used instead. |
| | | | | |
| 3 | Moved: The registration fails because it is not the | | 3 | Moved: The registration fails because it is not the |
| | freshest. | | | freshest |
| | | | | |
| 4 | Removed: The binding state was removed. This may be | | 4 | Removed: The binding state was removed. This may be |
| | placed in an asynchronous NS(ARO) message, or as the | | | placed in an asynchronous NS(ARO) message, or as the |
| | rejection of a proxy registration to a Backbone Router. | | | rejection of a proxy registration to a Backbone Router |
| | | | | |
| 5 | Proof requested | | 5 | Proof requested: The registering node is challenged for |
| | owning the registered address or for being an acceptable |
| | proxy for the registration |
| | | | | |
| 6 | Invalid Source Address: The address used as source of the | | 6 | Duplicate Source Address: The address used as source of |
| | NS(ARO) conflicts with an existing registration, or is | | | the NS(ARO) conflicts with an existing registration. |
| | not usable on this link, e.g. it is not topologically |
| | correct. |
| | | | | |
| 7 | Administrative Rejection: The address is reserved for | | 7 | Administrative Rejection: The address being registered is |
| | another use by an administrative decision (e.g. placed in | | | reserved for another use by an administrative decision |
| | a DHCPv6 pool). The Registering Node is requested to | | | (e.g. placed in a DHCPv6 pool); The Registering Node is |
| | form a different address and retry. | | | requested to form a different address and retry |
| | |
| 8 | Invalid Registered Address: The address being registered |
| | is not usable on this link, e.g. it is not topologically |
| | correct |
| | |
| 9 | Invalid Source Address: The address used as source of the |
| | NS(ARO) is not usable on this link, e.g. it is not |
| | topologically correct |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Table 1 Table 1
Reserved: This field is unused. It MUST be initialized to zero by Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver. the sender and MUST be ignored by the receiver.
T: One bit flag. Set if the next octet is a used as a TID. T: One bit flag. Set if the next octet is a used as a TID.
TID: 1-byte integer; a transaction id that is maintained by the node TID: 1-byte integer; a transaction id that is maintained by the node
skipping to change at page 10, line 25 skipping to change at page 11, line 33
Removed: This status is expected in asynchronous messages from a Removed: This status is expected in asynchronous messages from a
registrar (6LR, 6LBR, 6BBR) to indicate that the registration registrar (6LR, 6LBR, 6BBR) to indicate that the registration
state is removed, for instance due to time out of a lifetime, or a state is removed, for instance due to time out of a lifetime, or a
movement. It is used for instance by a 6BBR in a NA(ARO) message movement. It is used for instance by a 6BBR in a NA(ARO) message
to indicate that the ownership of the proxy state on the backbone to indicate that the ownership of the proxy state on the backbone
was transfered to another 6BBR, which is indicative of a movement was transfered to another 6BBR, which is indicative of a movement
of the device. The receiver of the NA is the device that has of the device. The receiver of the NA is the device that has
performed a registration that is now stale and it should clean up performed a registration that is now stale and it should clean up
its state. its state.
6. Security Considerations 6. Backward Compatibility
6.1. Legacy 6LoWPAN Node
A legacy 6LN will use the registered address as source and will not
use an EARO option. In order to be backward compatible, an updated
6LR needs to accept that registration if it is valid per [RFC3972],
and manage the binding cache accordingly.
The main difference with [RFC3972] is that DAR/DAC exchange for DAD
may be avoided for link-local addresses. Additionally, the 6LR
SHOULD use an EARO in the reply, and may use all the status codes
defined in this specification.
6.2. Legacy 6LoWPAN Router
The first registration by a an updated 6LN is for a link-local
address, using that link-local address as source. A legacy 6LN will
not makes a difference and accept -or reject- that registration as if
the 6LN was a legacy node.
An updated 6LN will always use an EARO option in the registration NS
message, whereas a legacy 6LN will always areply with an ARO option
in the NA message. So from that first registration, the updated 6LN
can figure whether the 6LR supports this specification or not.
When facing a legacy 6LR, an updated 6LN may attempt to find an
alternate 6LR that is updated. In order to be backward compatible,
based on the discovery that a 6LR is legacy, the 6LN needs to
fallback to legacy behaviour and source the packet with the
registrered address.
The main difference is that the updated 6LN SHOULD use an EARO in the
request regardless of the type of 6LN, legacy or updated
6.3. Legacy 6LoWPAN Border Router
With this specification, the DAR/DAC transports an EARO option as
opposed to an ARO option. As described for the NS/NA exchange,
devices that support this specification always use an EARO option and
all the associated behaviour.
7. Security Considerations
This specification expects that the link layer is sufficiently This specification expects that the link layer is sufficiently
protected, either by means of physical or IP security for the protected, either by means of physical or IP security for the
Backbone Link or MAC sublayer cryptography. In particular, it is Backbone Link or MAC sublayer cryptography. In particular, it is
expected that the LLN MAC provides secure unicast to/from the expected that the LLN MAC provides secure unicast to/from the
Backbone Router and secure Broadcast from the Backbone Router in a Backbone Router and secure Broadcast from the Backbone Router in a
way that prevents tempering with or replaying the RA messages. way that prevents tempering with or replaying the RA messages.
The use of EUI-64 for forming the Interface ID in the link-local The use of EUI-64 for forming the Interface ID in the link-local
address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
skipping to change at page 11, line 5 skipping to change at page 13, line 5
When the ownership of the OUID cannot be assessed, this specification When the ownership of the OUID cannot be assessed, this specification
limits the cases where the OUID and the TID are multicasted, and limits the cases where the OUID and the TID are multicasted, and
obfuscates them in responses to attempts to take over an address. obfuscates them in responses to attempts to take over an address.
The LLN nodes depend on the 6LBR and the 6BBR for their operation. A The LLN nodes depend on the 6LBR and the 6BBR for their operation. A
trust model must be put in place to ensure that the right devices are trust model must be put in place to ensure that the right devices are
acting in these roles, so as to avoid threats such as black-holing, acting in these roles, so as to avoid threats such as black-holing,
or bombing attack whereby an impersonated 6LBR would destroy state in or bombing attack whereby an impersonated 6LBR would destroy state in
the network by using the "Removed" status code. the network by using the "Removed" status code.
7. IANA Considerations 8. IANA Considerations
This document requires the following additions: This document requires the following additions:
Address Registration Option Status Values Registry Address Registration Option Status Values Registry
+--------+--------------------------+ +--------+--------------------------+
| Status | Description | | Status | Description |
+--------+--------------------------+ +--------+--------------------------+
| 3 | Moved | | 3 | Moved |
| | | | | |
skipping to change at page 11, line 29 skipping to change at page 13, line 29
| | | | | |
| 6 | Invalid Source Address | | 6 | Invalid Source Address |
| | | | | |
| 7 | Administrative Rejection | | 7 | Administrative Rejection |
+--------+--------------------------+ +--------+--------------------------+
IANA is required to change the registry accordingly IANA is required to change the registry accordingly
Table 2: New ARO Status values Table 2: New ARO Status values
8. Acknowledgments 9. Acknowledgments
Kudos to Eric Levy-Abegnoli who designed the First Hop Security Kudos to Eric Levy-Abegnoli who designed the First Hop Security
infrastructure at Cisco. infrastructure at Cisco.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<http://www.rfc-editor.org/info/rfc4429>. <http://www.rfc-editor.org/info/rfc4429>.
skipping to change at page 12, line 23 skipping to change at page 14, line 23
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <http://www.rfc-editor.org/info/rfc6550>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>. <http://www.rfc-editor.org/info/rfc6775>.
9.2. Informative References 10.2. Informative References
[I-D.chakrabarti-nordmark-6man-efficient-nd] [I-D.chakrabarti-nordmark-6man-efficient-nd]
Chakrabarti, S., Nordmark, E., Thubert, P., and M. Chakrabarti, S., Nordmark, E., Thubert, P., and M.
Wasserman, "IPv6 Neighbor Discovery Optimizations for Wasserman, "IPv6 Neighbor Discovery Optimizations for
Wired and Wireless Networks", draft-chakrabarti-nordmark- Wired and Wireless Networks", draft-chakrabarti-nordmark-
6man-efficient-nd-07 (work in progress), February 2015. 6man-efficient-nd-07 (work in progress), February 2015.
[I-D.delcarpio-6lo-wlanah] [I-D.delcarpio-6lo-wlanah]
Vega, L., Robles, I., and R. Morabito, "IPv6 over Vega, L., Robles, I., and R. Morabito, "IPv6 over
802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-6lo-6lobac] [I-D.ietf-6lo-6lobac]
Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, Lynn, K., Martocci, J., Neilson, C., and S. Donaldson,
"Transmission of IPv6 over MS/TP Networks", draft-ietf- "Transmission of IPv6 over MS/TP Networks", draft-ietf-
6lo-6lobac-04 (work in progress), February 2016. 6lo-6lobac-05 (work in progress), June 2016.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-01 (work in progress), March 2016. backbone-router-02 (work in progress), September 2016.
[I-D.ietf-6lo-dect-ule] [I-D.ietf-6lo-dect-ule]
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
Energy", draft-ietf-6lo-dect-ule-04 (work in progress), Energy", draft-ietf-6lo-dect-ule-07 (work in progress),
February 2016. October 2016.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Hong, Y. and J. Youn, "Transmission of IPv6 Packets over Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6
Near Field Communication", draft-ietf-6lo-nfc-03 (work in Packets over Near Field Communication", draft-ietf-6lo-
progress), March 2016. nfc-05 (work in progress), October 2016.
[I-D.ietf-6man-rs-refresh]
Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6
Neighbor Discovery Optional RS/RA Refresh", draft-ietf-
6man-rs-refresh-01 (work in progress), March 2016.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
in progress), November 2015. in progress), June 2016.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-07 (work in 802.15.4e", draft-ietf-6tisch-terminology-07 (work in
progress), March 2016. progress), March 2016.
[I-D.ietf-bier-architecture] [I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, A., and Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-03 (work in Replication", draft-ietf-bier-architecture-04 (work in
progress), January 2016. progress), July 2016.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002. progress), July 2002.
[I-D.nordmark-6man-dad-approaches]
Nordmark, E., "Possible approaches to make DAD more robust
and/or efficient", draft-nordmark-6man-dad-approaches-02
(work in progress), October 2015.
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
over IEEE 1901.2 Narrowband Powerline Communication over IEEE 1901.2 Narrowband Powerline Communication
Networks", draft-popa-6lo-6loplc-ipv6-over- Networks", draft-popa-6lo-6loplc-ipv6-over-
ieee19012-networks-00 (work in progress), March 2014. ieee19012-networks-00 (work in progress), March 2014.
[I-D.sarikaya-6lo-ap-nd] [I-D.sarikaya-6lo-ap-nd]
Sarikaya, B. and P. Thubert, "Address Protected Neighbor Sethi, M., Thubert, P., and B. Sarikaya, "Address
Discovery for Low-power and Lossy Networks", draft- Protected Neighbor Discovery for Low-power and Lossy
sarikaya-6lo-ap-nd-02 (work in progress), March 2016. Networks", draft-sarikaya-6lo-ap-nd-04 (work in progress),
August 2016.
[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.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>. <http://www.rfc-editor.org/info/rfc3810>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>. <http://www.rfc-editor.org/info/rfc3971>.
skipping to change at page 15, line 5 skipping to change at page 16, line 35
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428, over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015, DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>. <http://www.rfc-editor.org/info/rfc7428>.
[RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss
Resiliency for Router Solicitations", RFC 7559,
DOI 10.17487/RFC7559, May 2015,
<http://www.rfc-editor.org/info/rfc7559>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>. <http://www.rfc-editor.org/info/rfc7668>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 10.3. External Informative References
Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016,
<http://www.rfc-editor.org/info/rfc7772>.
9.3. External Informative References
[IEEE80211] [IEEE80211]
IEEE standard for Information Technology, "IEEE Standard IEEE standard for Information Technology, "IEEE Standard
for Information technology-- Telecommunications and for Information technology-- Telecommunications and
information exchange between systems Local and information exchange between systems Local and
metropolitan area networks-- Specific requirements Part metropolitan area networks-- Specific requirements Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications". Layer (PHY) Specifications".
[IEEE802151] [IEEE802151]
skipping to change at page 16, line 8 skipping to change at page 17, line 29
Appendix A. Requirements Appendix A. Requirements
This section lists requirements that were discussed at 6lo for an This section lists requirements that were discussed at 6lo for an
update to 6LoWPAN ND. This specification meets most of them, but update to 6LoWPAN ND. This specification meets most of them, but
those listed in Appendix A.5 which are deferred to a different those listed in Appendix A.5 which are deferred to a different
specification such as [I-D.sarikaya-6lo-ap-nd]. specification such as [I-D.sarikaya-6lo-ap-nd].
A.1. Requirements Related to Mobility A.1. Requirements Related to Mobility
Due to the unstable nature of LLN links, even in a LLN of immobile Due to the unstable nature of LLN links, even in a LLN of immobile
nodes a 6LoWPAN Node may change its point of attachment to a 6LR, say nodes a 6LN may change its point of attachment to a 6LR, say 6LR-a,
6LR-a, and may not be able to notify 6LR-a. Consequently, 6LR-a may and may not be able to notify 6LR-a. Consequently, 6LR-a may still
still attract traffic that it cannot deliver any more. When links to attract traffic that it cannot deliver any more. When links to a 6LR
a 6LR change state, there is thus a need to identify stale states in change state, there is thus a need to identify stale states in a 6LR
a 6LR and restore reachability in a timely fashion. and restore reachability in a timely fashion.
Req1.1: Upon a change of point of attachment, connectivity via a new Req1.1: Upon a change of point of attachment, connectivity via a new
6LR MUST be restored timely without the need to de-register from the 6LR MUST be restored timely without the need to de-register from the
previous 6LR. previous 6LR.
Req1.2: For that purpose, the protocol MUST enable to differentiate Req1.2: For that purpose, the protocol MUST enable to differentiate
between multiple registrations from one 6LoWPAN Node and between multiple registrations from one 6LoWPAN Node and
registrations from different 6LoWPAN Nodes claiming the same address. registrations from different 6LoWPAN Nodes claiming the same address.
Req1.3: Stale states MUST be cleaned up in 6LRs. Req1.3: Stale states MUST be cleaned up in 6LRs.
Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address
to multiple 6LRs, and this, concurrently. to multiple 6LRs, and this, concurrently.
A.2. Requirements Related to Routing Protocols A.2. Requirements Related to Routing Protocols
The point of attachment of a 6LoWPAN Node may be a 6LR in an LLN The point of attachment of a 6LN may be a 6LR in an LLN mesh. IPv6
mesh. IPv6 routing in a LLN can be based on RPL, which is the routing in a LLN can be based on RPL, which is the routing protocol
routing protocol that was defined at the IETF for this particular that was defined at the IETF for this particular purpose. Other
purpose. Other routing protocols than RPL are also considered by routing protocols than RPL are also considered by Standard Defining
Standard Defining Organizations (SDO) on the basis of the expected Organizations (SDO) on the basis of the expected network
network characteristics. It is required that a 6LoWPAN Node attached characteristics. It is required that a 6LoWPAN Node attached via ND
via ND to a 6LR would need to participate in the selected routing to a 6LR would need to participate in the selected routing protocol
protocol to obtain reachability via the 6LR. to obtain reachability via the 6LR.
Next to the 6LBR unicast address registered by ND, other addresses Next to the 6LBR unicast address registered by ND, other addresses
including multicast addresses are needed as well. For example a including multicast addresses are needed as well. For example a
routing protocol often uses a multicast address to register changes routing protocol often uses a multicast address to register changes
to established paths. ND needs to register such a multicast address to established paths. ND needs to register such a multicast address
to enable routing concurrently with discovery. to enable routing concurrently with discovery.
Multicast is needed for groups. Groups MAY be formed by device type Multicast is needed for groups. Groups MAY be formed by device type
(e.g. routers, street lamps), location (Geography, RPL sub-tree), or (e.g. routers, street lamps), location (Geography, RPL sub-tree), or
both. both.
 End of changes. 44 change blocks. 
136 lines changed or deleted 210 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/