draft-ietf-6lo-backbone-router-01.txt   draft-ietf-6lo-backbone-router-02.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft cisco Internet-Draft cisco
Intended status: Standards Track March 18, 2016 Intended status: Standards Track September 19, 2016
Expires: September 19, 2016 Expires: March 23, 2017
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-01 draft-ietf-6lo-backbone-router-02
Abstract Abstract
This specification proposes an update to IPv6 Neighbor Discovery, to This specification proposes an update to IPv6 Neighbor Discovery, to
enhance the operation of IPv6 over wireless links that exhibit lossy enhance the operation of IPv6 over wireless links that exhibit lossy
multicast support, and enable a large degree of scalability by multicast support, and enable a large degree of scalability by
splitting the broadcast domains. A higher speed backbone federates splitting the broadcast domains. A higher speed backbone federates
multiple wireless links to form a large MultiLink Subnet. Backbone multiple wireless links to form a large MultiLink Subnet. Backbone
Routers acting as Layer-3 Access Point route packets to registered Routers acting as Layer-3 Access Point route packets to registered
nodes, where an classical Layer-2 Access Point would bridge. nodes, where an classical Layer-2 Access Point would bridge.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 19, 2016. This Internet-Draft will expire on March 23, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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. Applicability and Requirements Served . . . . . . . . . . . . 5 2. Applicability and Requirements Served . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. New Types And Formats . . . . . . . . . . . . . . . . . . . . 11 5. New Types And Formats . . . . . . . . . . . . . . . . . . . . 11
5.1. Transaction ID . . . . . . . . . . . . . . . . . . . . . 11 5.1. Transaction ID . . . . . . . . . . . . . . . . . . . . . 11
5.2. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 11 5.2. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 11
5.3. The Enhanced Address Registration Option (EARO) . . . . . 12 5.3. The Enhanced Address Registration Option (EARO) . . . . . 12
6. Backbone Router Routing Operations . . . . . . . . . . . . . 14 6. Backbone Router Routing Operations . . . . . . . . . . . . . 14
6.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 14 6.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 14
6.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 16 6.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 16
7. BackBone Router Proxy Operations . . . . . . . . . . . . . . 17 7. BackBone Router Proxy Operations . . . . . . . . . . . . . . 17
7.1. Registration and Binding State Creation . . . . . . . . . 20 7.1. Registration and Binding State Creation . . . . . . . . . 20
7.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 21 7.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 22 9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 24
12.3. External Informative References . . . . . . . . . . . . 28 12.3. External Informative References . . . . . . . . . . . . 28
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 29
A.1. Requirements Related to Mobility . . . . . . . . . . . . 29 A.1. Requirements Related to Mobility . . . . . . . . . . . . 29
A.2. Requirements Related to Routing Protocols . . . . . . . . 29 A.2. Requirements Related to Routing Protocols . . . . . . . . 29
A.3. Requirements Related to the Variety of Low-Power Link A.3. Requirements Related to the Variety of Low-Power Link
skipping to change at page 4, line 14 skipping to change at page 4, line 14
and a multicast routing protocol is setup between the 6BBRs over the and a multicast routing protocol is setup between the 6BBRs over the
backbone of the MLSN. backbone of the MLSN.
As the network scales up, none of the approaches of using either As the network scales up, none of the approaches of using either
broadcast or N*unicast for a multicast packet is really satisfying broadcast or N*unicast for a multicast packet is really satisfying
and the protocols themselves need to be adapted to reduce their use and the protocols themselves need to be adapted to reduce their use
of multicast. of multicast.
One degree of improvement can be achieved by changing the tuning of One degree of improvement can be achieved by changing the tuning of
the protocol parameters and operational practices, such as suggested the protocol parameters and operational practices, such as suggested
in Reducing energy consumption of Router Advertisements in Reducing energy consumption of Router Advertisements [RFC7772]
[I-D.ietf-v6ops-reducing-ra-energy-consumption] (RA). This works (RA). This works enables to lower the rate of RA messages but does
enables to lower the rate of RA messages but does not solve the not solve the problem associated with multicast NS and NA messages,
problem associated with multicast NS and NA messages, which are a lot which are a lot more frequent in large-scale radio environments with
more frequent in large-scale radio environments with mobile devices mobile devices which exhibit intermittent access patterns and short-
which exhibit intermittent access patterns and short-lived IPv6 lived IPv6 addresses.
addresses.
In the context of IEEE802.15.4 [IEEE802154], the more drastic step of In the context of IEEE802.15.4 [IEEE802154], the more drastic step of
considering the radio as a medium that is different from Ethernet considering the radio as a medium that is different from Ethernet
because of the impact of multicast, was already taken with the because of the impact of multicast, was already taken with the
adoption of Neighbor Discovery Optimization for IPv6 over Low-Power adoption of Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs) [RFC6775]. This Wireless Personal Area Networks (6LoWPANs) [RFC6775]. This
specification applies that same thinking to other wireless links such specification applies that same thinking to other wireless links such
as Low-Power IEEE802.11 (Wi-Fi) and IEEE802.15.1 (Bluetooth) as Low-Power IEEE802.11 (Wi-Fi) and IEEE802.15.1 (Bluetooth)
[IEEE802151], and extends [RFC6775] to enable proxy operation by the [IEEE802151], and extends [RFC6775] to enable proxy operation by the
6BBR so as to decouple the broadcast domain in the backbone from the 6BBR so as to decouple the broadcast domain in the backbone from the
wireless links. The proxy operation can be maintained asynchronous wireless links. The proxy operation can be maintained asynchronous
so that low-power nodes or nodes that are deep in a mesh do not need so that low-power nodes or nodes that are deep in a mesh do not need
to be bothered synchronously when a lookup is performed for their to be bothered synchronously when a lookup is performed for their
addresses, effectively implementing the ND contribution to the addresses, effectively implementing the ND contribution to the
concept of a Sleep Proxy [I-D.nordmark-6man-dad-approaches]. concept of a Sleep Proxy [I-D.nordmark-6man-dad-approaches].
RFC 6775 is now being updated as [I-D.thubert-6lo-rfc6775-update];
this upodate duplicates some text from this document, and the intent
to migrate what is common to the update document once it is adopted.
DHCPv6 [RFC3315] is still a viable option in Low power and Lossy DHCPv6 [RFC3315] is still a viable option in Low power and Lossy
Network (LLN) to assign IPv6 global addresses. However, the IETF Network (LLN) to assign IPv6 global addresses. However, the IETF
standard that supports address assignment specifically for LLNs is standard that supports address assignment specifically for LLNs is
6LoWPAN ND [RFC6775], which is a mix of IPv6 stateless 6LoWPAN ND [RFC6775], which is a mix of IPv6 stateless
autoconfiguration mechanism (SLAAC) [RFC4862] and a new registration autoconfiguration mechanism (SLAAC) [RFC4862] and a new registration
process for ND. This specification introduces a Layer-3 association process for ND. This specification introduces a Layer-3 association
process based on 6LoWPAN ND that maintains a proxy state in the 6BBR process based on 6LoWPAN ND that maintains a proxy state in the 6BBR
to keep the LLN nodes reachable and protect their addresses through to keep the LLN nodes reachable and protect their addresses through
sleeping periods. sleeping periods.
skipping to change at page 5, line 19 skipping to change at page 5, line 21
interaction between the 2 protocols was not defined. This interaction between the 2 protocols was not defined. This
specification details how periodic updates from RPL can be used by specification details how periodic updates from RPL can be used by
the RPL root to renew the association of the RPL node to the 6BBR on the RPL root to renew the association of the RPL node to the 6BBR on
its behalf so as to maintain the proxy operation active for that its behalf so as to maintain the proxy operation active for that
node. node.
This document suggests a limited evolution to [RFC6775] so as to This document suggests a limited evolution to [RFC6775] so as to
allow operation of a 6LoWPAN ND node while a routing protocol (in allow operation of a 6LoWPAN ND node while a routing protocol (in
first instance RPL) is present and operational. It also suggests a first instance RPL) is present and operational. It also suggests a
more generalized use of the information in the ARO option of the ND more generalized use of the information in the ARO option of the ND
messages outside the strict LLN domain, for instance over a converged messages outside the strict LLN domain, for instance over a
backbone. federating backbone.
2. Applicability and Requirements Served 2. Applicability and Requirements Served
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 IEEE802.15.4 [RFC6775] can be extended to other types of links beyond IEEE802.15.4
for which it was defined. The registration technique is beneficial for which it was defined. The registration technique is beneficial
when the Link-Layer technique used to carry IPv6 multicast packets is when the Link-Layer technique used to carry IPv6 multicast packets is
not sufficiently efficient in terms of delivery ratio or energy not sufficiently efficient in terms of delivery ratio or energy
consumption in the end devices, in particular to enable energy- consumption in the end devices, in particular to enable energy-
skipping to change at page 6, line 43 skipping to change at page 6, line 46
In the case of Low-Power IEEE802.11, a 6BBR may be collocated with a In the case of Low-Power IEEE802.11, a 6BBR may be collocated with a
standalone AP or a CAPWAP [RFC5415] wireless controller, and the standalone AP or a CAPWAP [RFC5415] wireless controller, and the
wireless client (STA) leverages this specification to register its wireless client (STA) leverages this specification to register its
IPv6 address(es) to the 6BBR over the wireless medium. In the case IPv6 address(es) to the 6BBR over the wireless medium. In the case
of a 6TiSCH LLN mesh, the RPL root is collocated with a 6LoWPAN of a 6TiSCH LLN mesh, the RPL root is collocated with a 6LoWPAN
Border Router (6LBR), and either collocated with or connected to the Border Router (6LBR), and either collocated with or connected to the
6BBR over an IPv6 Link. The 6LBR leverages this specification to 6BBR over an IPv6 Link. The 6LBR leverages this specification to
register the LLN nodes on their behalf to the 6BBR. In the case of register the LLN nodes on their behalf to the 6BBR. In the case of
BTLE, the 6BBR is collocated with the router that implements the BTLE BTLE, the 6BBR is collocated with the router that implements the BTLE
central role as discussed in section 2.2 of [I-D.ietf-6lo-btle]. central role as discussed in section 2.2 of [RFC7668].
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Readers are expected to be familiar with all the terms and concepts Readers are expected to be familiar with all the terms and concepts
that are discussed in "Neighbor Discovery for IP version 6" that are discussed in "Neighbor Discovery for IP version 6"
[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],
skipping to change at page 7, line 20 skipping to change at page 7, line 26
Neighbor Discovery Optimization for Low-power and Lossy Networks Neighbor Discovery Optimization for Low-power and Lossy Networks
[RFC6775] and "Multi-link Subnet Support in IPv6" [RFC6775] and "Multi-link Subnet Support in IPv6"
[I-D.ietf-ipv6-multilink-subnets]. [I-D.ietf-ipv6-multilink-subnets].
Readers would benefit from reading "Multi-Link Subnet Issues" Readers would benefit from reading "Multi-Link Subnet Issues"
[RFC4903], ,"Mobility Support in IPv6" [RFC6275], "Neighbor Discovery [RFC4903], ,"Mobility Support in IPv6" [RFC6275], "Neighbor Discovery
Proxies (ND Proxy)" [RFC4389] and "Optimistic Duplicate Address Proxies (ND Proxy)" [RFC4389] and "Optimistic Duplicate Address
Detection" [RFC4429] prior to this specification for a clear Detection" [RFC4429] prior to this specification for a clear
understanding of the art in ND-proxying and binding. understanding of the art in ND-proxying and binding.
Additionally, this document uses terminology from Additionally, this document uses terminology from [RFC7102] and
[I-D.ietf-roll-terminology] and [I-D.ietf-6tisch-terminology], and [I-D.ietf-6tisch-terminology], and introduces the following
introduces the following terminology: terminology:
LLN Low Power Lossy Network. Used loosely in this specification to LLN Low Power Lossy Network. Used loosely in this specification to
represent WLANs and WPANs. See [RFC4919] represent WLANs and WPANs. See [RFC4919]
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
skipping to change at page 16, line 9 skipping to change at page 16, line 11
correspondent nodes may maintain an incorrect neighbor state, which correspondent nodes may maintain an incorrect neighbor state, which
they will eventually discover through Neighbor Unreachability they will eventually discover through Neighbor Unreachability
Detection (NUD). Because mobility may be slow, the NUD procedure Detection (NUD). Because mobility may be slow, the NUD procedure
defined in [RFC4861] may be too impatient, and the support of defined in [RFC4861] may be too impatient, and the support of
[RFC7048] is recommended in all nodes in the network. [RFC7048] is recommended in all nodes in the network.
Since the MultiLink Subnet may grow very large in terms of individual Since the MultiLink Subnet may grow very large in terms of individual
IPv6 addresses, multicasts should be avoided as much as possible even IPv6 addresses, multicasts should be avoided as much as possible even
on the backbone. Though it is possible for plain hosts to on the backbone. Though it is possible for plain hosts to
participate with legacy IPv6 ND support, the support by all nodes participate with legacy IPv6 ND support, the support by all nodes
connected to the backbone of [I-D.nordmark-6man-rs-refresh] is connected to the backbone of [I-D.ietf-6man-rs-refresh] is
recommended, and this implies the support of [RFC7559] as well. recommended, and this implies the support of [RFC7559] as well.
6.2. Over the LLN Link 6.2. Over the LLN Link
As a router, the Nodes and Backbone Router operation on the LLN As a router, the Nodes and Backbone Router operation on the LLN
follows [RFC6775]. Per that specification, LLN Hosts generally do follows [RFC6775]. Per that specification, LLN Hosts generally do
not depend on multicast RAs to discover routers. It is still not depend on multicast RAs to discover routers. It is still
generally required for LLN nodes to accept multicast RAs generally required for LLN nodes to accept multicast RAs [RFC7772],
[I-D.ietf-v6ops-reducing-ra-energy-consumption], but those are rare but those are rare on the LLN link. Nodes are expected to follow the
on the LLN link. Nodes are expected to follow the Simple Procedures Simple Procedures for Detecting Network Attachment in IPv6 [RFC6059]
for Detecting Network Attachment in IPv6 [RFC6059] (DNA procedures) (DNA procedures) to assert movements, and to support the Packet-Loss
to assert movements, and to support the Packet-Loss Resiliency for Resiliency for Router Solicitations [RFC7559] to make the unicast RS
Router Solicitations [RFC7559] to make the unicast RS more reliable. more reliable.
The Backbone Router acquires its states about the addresses on the The Backbone Router acquires its states about the addresses on the
LLN side through a registration process from either the nodes LLN side through a registration process from either the nodes
themselves, or from a node such as a RPL root / 6LBR (the Registering themselves, or from a node such as a RPL root / 6LBR (the Registering
Node) that performs the registration on behalf of the address owner Node) that performs the registration on behalf of the address owner
(the Registered Node). (the Registered Node).
When operating as a Routing Proxy, the router installs hosts routes When operating as a Routing Proxy, the router installs hosts routes
(/128) to the Registered Addresses over the LLN links, via the (/128) to the Registered Addresses over the LLN links, via the
Registering Node as identified by the Source Address and the SLLAO Registering Node as identified by the Source Address and the SLLAO
skipping to change at page 25, line 8 skipping to change at page 25, line 8
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-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", draft-ietf-6lo-btle-17 (work in progress), August
2015.
[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-05 (work in progress),
February 2016. May 2016.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Youn, J. and Y. Hong, "Transmission of IPv6 Packets over Hong, Y. and J. Youn, "Transmission of IPv6 Packets over
Near Field Communication", draft-ietf-6lo-nfc-02 (work in Near Field Communication", draft-ietf-6lo-nfc-04 (work in
progress), October 2015. progress), July 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-06 (work in 802.15.4e", draft-ietf-6tisch-terminology-07 (work in
progress), November 2015. progress), March 2016.
[I-D.ietf-bier-architecture] [I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., P, T., and S. Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
Aldrin, "Multicast using Bit Index Explicit Replication", S. Aldrin, "Multicast using Bit Index Explicit
draft-ietf-bier-architecture-03 (work in progress), Replication", draft-ietf-bier-architecture-04 (work in
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.ietf-roll-terminology]
Vasseur, J., "Terms used in Routing for Low power And
Lossy Networks", draft-ietf-roll-terminology-13 (work in
progress), October 2013.
[I-D.ietf-v6ops-reducing-ra-energy-consumption]
Yourtchenko, A. and L. Colitti, "Reducing energy
consumption of Router Advertisements", draft-ietf-v6ops-
reducing-ra-energy-consumption-03 (work in progress),
November 2015.
[I-D.nordmark-6man-dad-approaches] [I-D.nordmark-6man-dad-approaches]
Nordmark, E., "Possible approaches to make DAD more robust Nordmark, E., "Possible approaches to make DAD more robust
and/or efficient", draft-nordmark-6man-dad-approaches-02 and/or efficient", draft-nordmark-6man-dad-approaches-02
(work in progress), October 2015. (work in progress), October 2015.
[I-D.nordmark-6man-rs-refresh]
Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6
Neighbor Discovery Optional Unicast RS/RA Refresh", draft-
nordmark-6man-rs-refresh-01 (work in progress), October
2014.
[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.thubert-6lo-rfc6775-update]
Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update
to 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-00 (work
in progress), May 2016.
[I-D.vyncke-6man-mcast-not-efficient] [I-D.vyncke-6man-mcast-not-efficient]
Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
Yourtchenko, "Why Network-Layer Multicast is Not Always Yourtchenko, "Why Network-Layer Multicast is Not Always
Efficient At Datalink Layer", draft-vyncke-6man-mcast-not- Efficient At Datalink Layer", draft-vyncke-6man-mcast-not-
efficient-01 (work in progress), February 2014. efficient-01 (work in progress), February 2014.
[I-D.yourtchenko-6man-dad-issues] [I-D.yourtchenko-6man-dad-issues]
Yourtchenko, A. and E. Nordmark, "A survey of issues Yourtchenko, A. and E. Nordmark, "A survey of issues
related to IPv6 Duplicate Address Detection", draft- related to IPv6 Duplicate Address Detection", draft-
skipping to change at page 28, line 10 skipping to change at page 27, line 44
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <http://www.rfc-editor.org/info/rfc6830>.
[RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection Is Too Impatient", RFC 7048, Detection Is Too Impatient", RFC 7048,
DOI 10.17487/RFC7048, January 2014, DOI 10.17487/RFC7048, January 2014,
<http://www.rfc-editor.org/info/rfc7048>. <http://www.rfc-editor.org/info/rfc7048>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
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>.
[RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss
Resiliency for Router Solicitations", RFC 7559, Resiliency for Router Solicitations", RFC 7559,
DOI 10.17487/RFC7559, May 2015, DOI 10.17487/RFC7559, May 2015,
<http://www.rfc-editor.org/info/rfc7559>. <http://www.rfc-editor.org/info/rfc7559>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016,
<http://www.rfc-editor.org/info/rfc7772>.
12.3. External Informative References 12.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".
skipping to change at page 30, line 45 skipping to change at page 30, line 45
6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in 6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in
particular the capability to derive a unique Identifier from a 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],
IEEE802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 IEEE802.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 [I-D.ietf-6lo-btle]. 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 802.15.4, matching at least the LLN links to more LLN links than IEEE 802.15.4, matching at least the LLN links
for which an "IPv6 over foo" specification exists, as well as Low- for which an "IPv6 over foo" specification exists, as well as Low-
Power Wi-Fi. 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-
 End of changes. 24 change blocks. 
67 lines changed or deleted 72 lines changed or added

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