< draft-ietf-6lo-rfc6775-update-03.txt   draft-ietf-6lo-rfc6775-update-04.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 Intended status: Standards Track
Expires: October 29, 2017 S. Chakrabarti Expires: November 2, 2017 S. Chakrabarti
April 27, 2017 May 1, 2017
An Update to 6LoWPAN ND An Update to 6LoWPAN ND
draft-ietf-6lo-rfc6775-update-03 draft-ietf-6lo-rfc6775-update-04
Abstract Abstract
This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
clarify the role of the protocol as a registration technique, clarify the role of the protocol as a registration technique,
simplify the registration operation in 6LoWPAN routers, and provide simplify the registration operation in 6LoWPAN routers, and provide
enhancements to the registration capabilities, in particular for the enhancements to the registration capabilities, in particular for the
registration to a Backbone Router for proxy ND operations. registration to a Backbone Router for proxy ND operations.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 October 29, 2017. This Internet-Draft will expire on November 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 24 skipping to change at page 2, line 24
5.1. Extended Address Registration Option . . . . . . . . . . 6 5.1. Extended Address Registration Option . . . . . . . . . . 6
5.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 6 5.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 6
5.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 7 5.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 7
5.4. Registering the Target Address . . . . . . . . . . . . . 8 5.4. Registering the Target Address . . . . . . . . . . . . . 8
5.5. Link-Local Addresses and Registration . . . . . . . . . . 8 5.5. Link-Local Addresses and Registration . . . . . . . . . . 8
5.6. Maintaining the Registration States . . . . . . . . . . . 10 5.6. Maintaining the Registration States . . . . . . . . . . . 10
6. Updated ND Options . . . . . . . . . . . . . . . . . . . . . 11 6. Updated ND Options . . . . . . . . . . . . . . . . . . . . . 11
6.1. New 6LoWPAN capability Bits in the Capability Indication 6.1. New 6LoWPAN capability Bits in the Capability Indication
Option . . . . . . . . . . . . . . . . . . . . . . . . . 11 Option . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. The Enhanced Address Registration Option (EARO) . . . . . 12 6.2. The Enhanced Address Registration Option (EARO) . . . . . 12
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14
7.1. Discovering the capabilities of an ND peer . . . . . . . 15 7.1. Discovering the capabilities of an ND peer . . . . . . . 14
7.1.1. Using the E Flag in the CIO . . . . . . . . . . . . . 15 7.1.1. Using the E Flag in the CIO . . . . . . . . . . . . . 14
7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 15 7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 15
7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 16 7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 15
7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 16 7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 16
7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 16 7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 21
11.3. External Informative References . . . . . . . . . . . . 24 11.3. External Informative References . . . . . . . . . . . . 23
Appendix A. Applicability and Requirements Served . . . . . . . 24 Appendix A. Applicability and Requirements Served . . . . . . . 24
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 24
B.1. Requirements Related to Mobility . . . . . . . . . . . . 25 B.1. Requirements Related to Mobility . . . . . . . . . . . . 25
B.2. Requirements Related to Routing Protocols . . . . . . . . 26 B.2. Requirements Related to Routing Protocols . . . . . . . . 25
B.3. Requirements Related to the Variety of Low-Power Link B.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 27 types . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.4. Requirements Related to Proxy Operations . . . . . . . . 27 B.4. Requirements Related to Proxy Operations . . . . . . . . 27
B.5. Requirements Related to Security . . . . . . . . . . . . 28 B.5. Requirements Related to Security . . . . . . . . . . . . 27
B.6. Requirements Related to Scalability . . . . . . . . . . . 29 B.6. Requirements Related to Scalability . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
RFC 6775, the "Neighbor Discovery Optimization for IPv6 over Low- RFC 6775, the "Neighbor Discovery Optimization for IPv6 over Low-
Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775]
introduced a proactive registration mechanism to IPv6 Neighbor introduced a proactive registration mechanism to IPv6 Neighbor
Discovery (ND) services that is well suited to nodes belonging to a Discovery (ND) services that is well suited to nodes belonging to a
Low Power Lossy Network (LLN). Low Power Lossy Network (LLN).
The scope of this draft is an IPv6 LLN, which can be a simple star or The scope of this draft is an IPv6 LLN, which can be a simple star or
a more complex mesh topology. The LLN may be anchored at an IPv6 a more complex mesh topology. The LLN may be anchored at an IPv6
Backbone Router (6BBR) [I-D.ietf-6lo-backbone-router]. The 6BBRs Backbone Router (6BBR) [I-D.ietf-6lo-backbone-router]. The 6BBRs
interconnect the LLNs over a Backbone Link and emulate that the LLN interconnect the LLNs over a Backbone Link and emulate that the LLN
nodes are present on the Backbone using proxy-ND operations. nodes are present on the Backbone using proxy-ND operations.
This specification modifies and extends the behaviour and protocol This specification modifies and extends the behavior and protocol
elements of RFC 6775 [RFC6775] to enable additional capabilities, in elements of RFC 6775 [RFC6775] to enable additional capabilities, in
particular the registration to a 6BBR for proxy ND operations. particular the registration to a 6BBR for proxy ND operations.
2. Considerations On Registration Rejection 2. Considerations On Registration Rejection
The purpose of the Address Registration Option (ARO) RFC 6775 The purpose of the Address Registration Option (ARO) RFC 6775
[RFC6775] and of the Extended ARO (EARO) that is introduced in this [RFC6775] and of the Extended ARO (EARO) that is introduced in this
document is to facilitate duplicate address detection (DAD) for hosts document is to facilitate duplicate address detection (DAD) for hosts
and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the
routers to reduce the need for sending multicast neighbor routers to reduce the need for sending multicast neighbor
skipping to change at page 8, line 7 skipping to change at page 8, line 7
Networks" [I-D.ietf-6lo-ap-nd]. Networks" [I-D.ietf-6lo-ap-nd].
In any fashion, it is recommended that the node stores the unique Id In any fashion, it is recommended that the node stores the unique Id
or the keys used to generate that ID in persistent memory. or the keys used to generate that ID in persistent memory.
Otherwise, it will be prevented to re-register after a reboot that Otherwise, it will be prevented to re-register after a reboot that
would cause a loss of memory until the Backbone Router times out the would cause a loss of memory until the Backbone Router times out the
registration. registration.
5.4. Registering the Target Address 5.4. Registering the Target Address
This specification changes the behaviour of the 6LN and the 6LR so This specification changes the behavior of the 6LN and the 6LR so
that the Registered Address is found in the Target Address field of that the Registered Address is found in the Target Address field of
the NS and NA messages as opposed to the Source Address. the NS and NA messages as opposed to the Source Address.
The reason for this change is to enable proxy-registrations on behalf The reason for this change is to enable proxy-registrations on behalf
of other nodes in Route-Over meshes, for instance to enable that a of other nodes in Route-Over meshes, for instance to enable that a
RPL root registers addresses on behalf LLN nodes that are deeper in a RPL root registers addresses on behalf LLN nodes that are deeper in a
6TiSCH mesh, as discussed in Appendix B.4. In that case, the 6TiSCH mesh, as discussed in Appendix B.4. In that case, the
Registering Node MUST indicate its own address as source of the ND Registering Node MUST indicate its own address as source of the ND
message and its MAC address in the Source Link-Layer Address Option message and its MAC address in the Source Link-Layer Address Option
(SLLAO), since it still expects to get the packets and route them (SLLAO), since it still expects to get the packets and route them
skipping to change at page 9, line 36 skipping to change at page 9, line 36
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 registered with a 6LR
When registering to a 6LR that conforms this specification, a node When registering to a 6LR that conforms this specification, a node
MUST use a Link-Local address as the source address of the MUST use a Link-Local address as the source address of the
registration, whatever the type of IPv6 address that is being registration, whatever the type of IPv6 address that is being
registered. That Link-Local Address MUST be either already registered. That Link-Local Address MUST be either already
registrered, or the address that is being registered. registered, or the address that is being registered.
When a Registering Node does not have an already-registered address, When a Registering Node does not have an already-registered address,
it MUST register a Link-Local address, using it as both the Source 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 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) 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 globally unique, e.g. derived from a burn-in MAC address. An EARO
option in the response NA indicates that the 6LR supports this option in the response NA indicates that the 6LR supports this
specification. 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
skipping to change at page 11, line 28 skipping to change at page 11, line 28
DAC message bearing a Status of 0 "Success". If it is not the DAC message bearing a Status of 0 "Success". If it is not the
freshest, then a Status 2 "Moved" is returned instead, and the freshest, then a Status 2 "Moved" is returned instead, and the
existing entry is conserved. The 6LBR SHOULD conserve the address in existing entry is conserved. The 6LBR SHOULD conserve the address in
a DELAY state for a configurable period of time, so as to protect a a DELAY state for a configurable period of time, so as to protect a
mobile node that deregistered from one 6LR and did not register yet mobile node that deregistered from one 6LR and did not register yet
to a new one. to a new one.
6. Updated ND Options 6. Updated ND Options
This specification does not introduce new options, but it modifies This specification does not introduce new options, but it modifies
existing ones and updates the associated behaviours as follow: existing ones and updates the associated behaviors as follow:
6.1. New 6LoWPAN capability Bits in the Capability Indication Option 6.1. New 6LoWPAN capability Bits in the Capability Indication Option
This specification defines a number of capability bits in the CIO This specification defines a number of capability bits in the CIO
that was introduced by RFC 7400 [RFC7400]. that was introduced by RFC 7400 [RFC7400].
Support for this specification is indicated by setting the "E" flag Support for this specification is indicated by setting the "E" flag
in a CIO option. Routers that are capable of acting as 6LR, 6LBR and in a CIO option. Routers that are capable of acting as 6LR, 6LBR and
6BBR SHOULD set the L, B andP flags, respectively. 6BBR SHOULD set the L, B and P flags, respectively.
Those flags are not mutually exclusive and if a router is capable of Those flags are not mutually exclusive and if a router is capable of
multiple roles, it SHOULD set all the related flags. multiple roles, it SHOULD set all the related flags.
0 1 2 3 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 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 = 1 |_____________________|L|B|P|E|G| | Type | Length = 1 |_____________________|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_______________________________________________________________|
|_______________________________________________________________| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: New capability Bits L, B, P, E in the CIO Figure 1: New capability Bits L, B, P, E in the CIO
Option Fields Option Fields
Type: 36 Type: 36
L: Node is a 6LR, it can take registrations. L: Node is a 6LR, it can take registrations.
B: Node is a 6LBR. B: Node is a 6LBR.
P: Node is a 6BBR, proxying for nodes on this link. P: Node is a 6BBR, proxying for nodes on this link.
E: This specification is supported and applied. E: This specification is supported and applied.
skipping to change at page 14, line 26 skipping to change at page 14, line 12
| | rejection of a proxy registration to a Backbone Router | | | rejection of a proxy registration to a Backbone Router |
| | | | | |
| 5 | Proof requested: The registering node is challenged for | | 5 | Proof requested: The registering node is challenged for |
| | owning the registered address or for being an acceptable | | | owning the registered address or for being an acceptable |
| | proxy for the registration. This Status is expected in | | | proxy for the registration. This Status is expected in |
| | asynchronous messages from a registrar (6LR, 6LBR, 6BBR) | | | asynchronous messages from a registrar (6LR, 6LBR, 6BBR) |
| | to indicate that the registration state is removed, for | | | to indicate that the registration state is removed, for |
| | instance due to time out of a lifetime, or a movement. It | | | instance due to time out of a lifetime, or a movement. It |
| | is used for instance by a 6BBR in a NA(ARO) message to | | | is used for instance by a 6BBR in a NA(ARO) message to |
| | indicate that the ownership of the proxy state on the | | | indicate that the ownership of the proxy state on the |
| | backbone was transfered to another 6BBR, which is | | | backbone was transferred to another 6BBR, which is |
| | indicative of a movement of the device. The receiver of | | | indicative of a movement of the device. The receiver of |
| | the NA is the device that has performed a registration | | | the NA is the device that has performed a registration |
| | that is now stale and it should clean up its state. | | | that is now stale and it should clean up its state. |
| | | | | |
| 6 | Duplicate Source Address: The address used as source of | | 6 | Duplicate Source Address: The address used as source of |
| | the NS(ARO) conflicts with an existing registration. | | | the NS(ARO) conflicts with an existing registration. |
| | | | | |
| 7 | Invalid Source Address: The address used as source of the | | 7 | Invalid Source Address: The address used as source of the |
| | NS(ARO) is not a Link-Local address as prescribed by this | | | NS(ARO) is not a Link-Local address as prescribed by this |
| | document. | | | document. |
skipping to change at page 16, line 35 skipping to change at page 16, line 22
the 6LN was a legacy node. the 6LN was a legacy node.
An updated 6LN will always use an EARO option in the registration NS 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 message, whereas a legacy 6LN will always areply with an ARO option
in the NA message. So from that first registration, the updated 6LN in the NA message. So from that first registration, the updated 6LN
can figure whether the 6LR supports this specification or not. can figure whether the 6LR supports this specification or not.
When facing a legacy 6LR, an updated 6LN may attempt to find an When facing a legacy 6LR, an updated 6LN may attempt to find an
alternate 6LR that is updated. In order to be backward compatible, alternate 6LR that is updated. In order to be backward compatible,
based on the discovery that a 6LR is legacy, the 6LN needs to based on the discovery that a 6LR is legacy, the 6LN needs to
fallback to legacy behaviour and source the packet with the fallback to legacy behavior and source the packet with the registered
registrered address. address.
The main difference is that the updated 6LN SHOULD use an EARO in the The main difference is that the updated 6LN SHOULD use an EARO in the
request regardless of the type of 6LN, legacy or updated request regardless of the type of 6LN, legacy or updated
7.4. Legacy 6LoWPAN Border Router 7.4. Legacy 6LoWPAN Border Router
With this specification, the DAR/DAC transports an EARO option as With this specification, the DAR/DAC transports an EARO option as
opposed to an ARO option. As described for the NS/NA exchange, opposed to an ARO option. As described for the NS/NA exchange,
devices that support this specification always use an EARO option and devices that support this specification always use an EARO option and
all the associated behaviour. all the associated behavior.
8. Security Considerations 8. Security Considerations
This specification extends RFC 6775 [RFC6775], and the security This specification extends RFC 6775 [RFC6775], and the security
section of that draft also applies to this as well. In particular, section of that draft also applies to this as well. In particular,
it is expected that the link layer is sufficiently protected to it is expected that the link layer is sufficiently protected to
prevent a rogue access, either by means of physical or IP security on prevent a rogue access, either by means of physical or IP security on
the Backbone Link and link layer cryptography on the LLN. This the Backbone Link and link layer cryptography on the LLN. This
specification also expects that the LLN MAC provides secure unicast specification also expects that the LLN MAC provides secure unicast
to/from the Backbone Router and secure Broadcast from the Backbone to/from the Backbone Router and secure Broadcast from the Backbone
skipping to change at page 20, line 44 skipping to change at page 20, line 22
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<http://www.rfc-editor.org/info/rfc4429>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>. <http://www.rfc-editor.org/info/rfc6282>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<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>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <http://www.rfc-editor.org/info/rfc7400>. 2014, <http://www.rfc-editor.org/info/rfc7400>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016,
<http://www.rfc-editor.org/info/rfc7934>.
11.2. Informative References 11.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
skipping to change at page 23, line 40 skipping to change at page 22, line 40
[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>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>. <http://www.rfc-editor.org/info/rfc3972>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<http://www.rfc-editor.org/info/rfc4429>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>. <http://www.rfc-editor.org/info/rfc4919>.
[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>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>. 2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
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>.
[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>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016,
<http://www.rfc-editor.org/info/rfc7934>.
11.3. External Informative References 11.3. External Informative References
[IEEEstd802154] [IEEEstd802154]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE, "IEEE Standard for Low-Rate Wireless Networks",
IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875,
<http://ieeexplore.ieee.org/document/7460875/>. <http://ieeexplore.ieee.org/document/7460875/>.
Appendix A. Applicability and Requirements Served Appendix A. Applicability and Requirements Served
This specification extends 6LoWPAN ND to sequence the registration This specification extends 6LoWPAN ND to sequence the registration
skipping to change at page 24, line 48 skipping to change at page 24, line 25
[I-D.ietf-6tisch-architecture] introduces how a 6LoWPAN ND host could [I-D.ietf-6tisch-architecture] introduces how a 6LoWPAN ND host could
connect to the Internet via a RPL mesh Network, but this requires connect to the Internet via a RPL mesh Network, but this requires
additions to the 6LOWPAN ND protocol to support mobility and additions to the 6LOWPAN ND protocol to support mobility and
reachability in a secured and manageable environment. This reachability in a secured and manageable environment. This
specification details the new operations that are required to specification details the new operations that are required to
implement the 6TiSCH architecture and serves the requirements listed implement the 6TiSCH architecture and serves the requirements listed
in Appendix B.2. in Appendix B.2.
The term LLN is used loosely in this specification to cover multiple The term LLN is used loosely in this specification to cover multiple
types of WLANs and WPANs, including Low-Power Wi-Fi, BLUETOOTH(R) Low types of WLANs and WPANs, including Low-Power Wi-Fi, BLUETOOTH(R) Low
Energy, IEEE std 802.11AH and IEEE std 802.15.4 wireless meshes, so Energy, IEEE Std.802.11AH and IEEE Std.802.15.4 wireless meshes, so
as to address the requirements discussed in Appendix B.3 as to address the requirements discussed in Appendix B.3
This specification can be used by any wireless node to associate at This specification can be used by any wireless node to associate at
Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing
services including proxy-ND operations over the backbone, effectively services including proxy-ND operations over the backbone, effectively
providing a solution to the requirements expressed in Appendix B.4. providing a solution to the requirements expressed in Appendix B.4.
"Efficiency aware IPv6 Neighbor Discovery Optimizations" "Efficiency aware IPv6 Neighbor Discovery Optimizations"
[I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND
[RFC6775] can be extended to other types of links beyond IEEE Std. [RFC6775] can be extended to other types of links beyond IEEE Std.
skipping to change at page 27, line 7 skipping to change at page 26, line 26
option, a RPLInstanceID. option, a RPLInstanceID.
Req2.3: Multicast operations SHOULD be supported and optimized, for Req2.3: Multicast operations SHOULD be supported and optimized, for
instance using BIER or MPL. Whether ND is appropriate for the instance using BIER or MPL. Whether ND is appropriate for the
registration to the 6BBR is to be defined, considering the additional registration to the 6BBR is to be defined, considering the additional
burden of supporting the Multicast Listener Discovery Version 2 burden of supporting the Multicast Listener Discovery Version 2
[RFC3810] (MLDv2) for IPv6. [RFC3810] (MLDv2) for IPv6.
B.3. Requirements Related to the Variety of Low-Power Link types B.3. Requirements Related to the Variety of Low-Power Link types
6LoWPAN ND [RFC6775] was defined with a focus on IEEE std 802.15.4 6LoWPAN ND [RFC6775] was defined with a focus on IEEE Std.802.15.4
and in particular the capability to derive a unique Identifier from a and in particular the capability to derive a unique Identifier from a
globally unique MAC-64 address. At this point, the 6lo Working Group globally unique MAC-64 address. At this point, the 6lo Working Group
is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique
to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token- to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token-
Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy
[I-D.ietf-6lo-dect-ule], Near Field Communication [I-D.ietf-6lo-nfc], [I-D.ietf-6lo-dect-ule], Near Field Communication [I-D.ietf-6lo-nfc],
IEEE std 802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 IEEE Std.802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2
Narrowband Powerline Communication Networks Narrowband Powerline Communication Networks
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R) [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R)
Low Energy [RFC7668]. Low Energy [RFC7668].
Related requirements are: Related requirements are:
Req3.1: The support of the registration mechanism SHOULD be extended Req3.1: The support of the registration mechanism SHOULD be extended
to more LLN links than IEEE std 802.15.4, matching at least the LLN to more LLN links than IEEE Std.802.15.4, matching at least the LLN
links for which an "IPv6 over foo" specification exists, as well as links for which an "IPv6 over foo" specification exists, as well as
Low-Power Wi-Fi. Low-Power Wi-Fi.
Req3.2: As part of this extension, a mechanism to compute a unique Req3.2: As part of this extension, a mechanism to compute a unique
Identifier should be provided, with the capability to form a Link- Identifier should be provided, with the capability to form a Link-
Local Address that SHOULD be unique at least within the LLN connected Local Address that SHOULD be unique at least within the LLN connected
to a 6LBR discovered by ND in each node within the LLN. to a 6LBR discovered by ND in each node within the LLN.
Req3.3: The Address Registration Option used in the ND registration Req3.3: The Address Registration Option used in the ND registration
SHOULD be extended to carry the relevant forms of unique Identifier. SHOULD be extended to carry the relevant forms of unique Identifier.
skipping to change at page 28, line 50 skipping to change at page 28, line 19
their respective roles, as well as with the 6LoWPAN Node for the role their respective roles, as well as with the 6LoWPAN Node for the role
of 6LR. of 6LR.
Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
the 6LR and the 6LBR to validate new registration of authorized the 6LR and the 6LBR to validate new registration of authorized
nodes. Joining of unauthorized nodes MUST be impossible. nodes. Joining of unauthorized nodes MUST be impossible.
Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet
sizes. In particular, the NS, NA, DAR and DAC messages for a re- sizes. In particular, the NS, NA, DAR and DAC messages for a re-
registration flow SHOULD NOT exceed 80 octets so as to fit in a registration flow SHOULD NOT exceed 80 octets so as to fit in a
secured IEEE std 802.15.4 [IEEEstd802154] frame. secured IEEE Std.802.15.4 [IEEEstd802154] frame.
Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be
computationally intensive on the LoWPAN Node CPU. When a Key hash computationally intensive on the LoWPAN Node CPU. When a Key hash
calculation is employed, a mechanism lighter than SHA-1 SHOULD be calculation is employed, a mechanism lighter than SHA-1 SHOULD be
preferred. preferred.
Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate
SHOULD be minimized. SHOULD be minimized.
Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable the Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable the
 End of changes. 34 change blocks. 
59 lines changed or deleted 57 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/