draft-ietf-6lo-backbone-router-04.txt   draft-ietf-6lo-backbone-router-05.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft cisco Internet-Draft cisco
Intended status: Standards Track July 17, 2017 Intended status: Standards Track January 9, 2018
Expires: January 18, 2018 Expires: July 13, 2018
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-04 draft-ietf-6lo-backbone-router-05
Abstract Abstract
This specification proposes an update to IPv6 Neighbor Discovery, to This specification proposes proxy operations for IPv6 Neighbor
enhance the operation of IPv6 over wireless links that exhibit lossy Discovery on behalf of devices located on broadcast-inefficient
multicast support, and enable a large degree of scalability by wireless networks. A broadcast-efficient backbone running classical
splitting the broadcast domains. A broadcast-efficient backbone IPv6 Neighbor Discovery federates multiple wireless links to form a
running classical IPv6 Neighbor Discovery federates multiple wireless large MultiLink Subnet, but the broadcast domain does not need to
links to form a large MultiLink Subnet, but the broadcast domain does extend to the wireless links for the purpose of ND operation.
not need to extend to the wireless links for the purpose of ND Backbone Routers placed at the wireless edge of the backbone proxy
operation. Backbone Routers placed at the wireless edge of the the ND operation and route packets from/to registered nodes, and
backbone proxy the ND operation and route packets from/to registered wireless nodes register or are proxy-registered to the Backbone
nodes, and wireless nodes register or are proxy-registered to the Router to setup proxy services in a fashion that is essentially
Backbone Router to setup proxy services in a fashion that is similar to a classical Layer-2 association.
essentially similar to a classical Layer-2 association.
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 https://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 January 18, 2018. This Internet-Draft will expire on July 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
skipping to change at page 2, line 47 skipping to change at page 2, line 46
A.4. Requirements Related to Proxy Operations . . . . . . . . 26 A.4. Requirements Related to Proxy Operations . . . . . . . . 26
A.5. Requirements Related to Security . . . . . . . . . . . . 27 A.5. Requirements Related to Security . . . . . . . . . . . . 27
A.6. Requirements Related to Scalability . . . . . . . . . . . 28 A.6. Requirements Related to Scalability . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
One of the key services provided by IEEE std. 802.1 [IEEEstd8021] One of the key services provided by IEEE std. 802.1 [IEEEstd8021]
Ethernet Bridging is an efficient and reliable broadcast service, and Ethernet Bridging is an efficient and reliable broadcast service, and
multiple applications and protocols have been built that heavily multiple applications and protocols have been built that heavily
depends on that feature for their core operation. But a wide range depend on that feature for their core operation. But a wide range of
of wireless networks do not provide the solid and cheap broadcast wireless networks do not provide the solid and cheap broadcast
capabilities of Ethernet Bridging, and protocols designed for bridged capabilities of Ethernet Bridging, and protocols designed for bridged
networks that rely on broadcast often exhibit disappointing networks that rely on broadcast often exhibit disappointing
behaviours when applied unmodified to a wireless medium. behaviours when applied unmodified to a wireless medium.
IEEE std. 802.11 [IEEEstd80211] Access Points (APs) deployed in an IEEE std. 802.11 [IEEEstd80211] Access Points (APs) deployed in an
Extended Service Set (ESS) effectively act as bridges, but, in order Extended Service Set (ESS) effectively act as bridges, but, in order
to ensure a solid connectivity to the devices and protect the medium to ensure a solid connectivity to the devices and protect the medium
against harmful broadcasts, they refrain from relying on broadcast- against harmful broadcasts, they refrain from relying on broadcast-
intensive protocols such as Transparent Bridging on the wireless intensive protocols such as Transparent Bridging on the wireless
side. Instead, an association process is used to register side. Instead, an association process is used to register
proactively the MAC addresses of the wireless device (STA) to the AP, proactively the MAC addresses of the wireless device (STA) to the AP,
and then the APs proxy the bridging operation and cancel the and then the APs proxy the bridging operation and cancel the
broadcasts. broadcasts.
Classical IPv6 [RFC8200] Neighbor Discovery [RFC4862] Protocol (NDP) Classical IPv6 [RFC8200] Neighbor Discovery [RFC4861] [RFC4862]
operations are reactive and rely heavily on multicast operations to Protocol (NDP) operations are reactive and rely heavily on multicast
locate an on-link correspondent and ensure address uniqueness, which operations to locate an on-link correspondent and ensure address
is a pillar that sustains the whole IP architecture. When the uniqueness, which is a pillar that sustains the whole IP
Duplicate Address Detection [RFC4862] (DAD) mechanism was designed, architecture. When the Duplicate Address Detection [RFC4862] (DAD)
it was a natural match with the efficient broadcast operation of mechanism was designed, it was a natural match with the efficient
Ethernet Bridging, but with the unreliable broadcast that is typical broadcast operation of Ethernet Bridging, but with the unreliable
of wireless media, DAD is bound to fail to discover duplications broadcast that is typical of wireless media, DAD is bound to fail to
[I-D.yourtchenko-6man-dad-issues]. In other words, because the discover duplications [I-D.yourtchenko-6man-dad-issues]. In other
broadcast service is unreliable, DAD appears to work on wireless words, because the broadcast service is unreliable, DAD appears to
media not because address duplication is detected and solved as work on wireless media not because address duplication is detected
designed, but because the duplication is a very rare event as a side and solved as designed, but because the duplication is a very rare
effect of the sheer amount of entropy in 64-bits Interface IDs. event as a side effect of the sheer amount of entropy in 64-bits
Interface IDs.
In the real world, IPv6 multicast messages are effectively broadcast, In the real world, IPv6 multicast messages are effectively broadcast,
so they are processed by most if not all wireless nodes over the ESS so they are processed by most if not all wireless nodes over the ESS
fabric even when very few if any of the nodes is effectively fabric even when very few if any of the nodes is effectively
listening to the multicast address. It results that a simple listening to the multicast address. It results that a simple
Neighbor Solicitation (NS) lookup message [RFC4861], that is Neighbor Solicitation (NS) lookup message [RFC4861], that is
supposedly targeted to a very small group of nodes, ends up polluting supposedly targeted to a very small group of nodes, ends up polluting
the whole wireless bandwidth across the fabric the whole wireless bandwidth across the fabric
[I-D.vyncke-6man-mcast-not-efficient]. In other words, the reactive [I-D.vyncke-6man-mcast-not-efficient]. In other words, the reactive
IPv6 ND operation leads to undesirable power consumption in battery- IPv6 ND operation leads to undesirable power consumption in battery-
skipping to change at page 8, line 51 skipping to change at page 8, line 51
Address duplication is sorted out with the Owner Unique-ID field in Address duplication is sorted out with the Owner Unique-ID field in
the EARO, which is a generalization of the EUI-64 that allows the EARO, which is a generalization of the EUI-64 that allows
different types of unique IDs beyond the name space derived from the different types of unique IDs beyond the name space derived from the
MAC addresses. First-Come First-Serve rules apply, whether the MAC addresses. First-Come First-Serve rules apply, whether the
duplication happens between LLN nodes as represented by their duplication happens between LLN nodes as represented by their
respective 6BBRs, or between an LLN node and a classical node that respective 6BBRs, or between an LLN node and a classical node that
defends its address over the backbone with classical ND and does not defends its address over the backbone with classical ND and does not
include the EARO option. include the EARO option.
In case of conflicting registrations to multiple 6BBRs from a same In case of conflicting registrations to multiple 6BBRs from a same
node, a sequence counter called Transaction ID (TID) is introduced node, a sequence counter called Transaction ID (TID) in the EARO
that enables 6BBRs to sort out the latest anchor for that node. enables 6BBRs to sort out the latest anchor for that node.
Registrations with a same TID are compatible and maintained, but, in Registrations with a same TID are compatible and maintained, but, in
case of different TIDs, only the freshest registration is maintained case of different TIDs, only the freshest registration is maintained
and the stale state is eliminated. and the stale state is eliminated.
With this specification, Backbone Routers perform ND proxy over the With this specification, Backbone Routers perform ND proxy over the
Backbone Link on behalf of their Registered Nodes. The Backbone Backbone Link on behalf of their Registered Nodes. The Backbone
Router operation is essentially similar to that of a Mobile IPv6 Router operation is essentially similar to that of a Mobile IPv6
(MIPv6) [RFC6275] Home Agent. This enables mobility support for LLN (MIPv6) [RFC6275] Home Agent. This enables mobility support for LLN
nodes that would move outside of the network delimited by the nodes that would move outside of the network delimited by the
Backbone link attach to a Home Agent from that point on. This also Backbone link attach to a Home Agent from that point on. This also
skipping to change at page 19, line 10 skipping to change at page 19, line 10
10. Acknowledgments 10. 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.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-6lo-rfc6775-update] [I-D.ietf-6lo-rfc6775-update]
Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update Thubert, P., Nordmark, E., Chakrabarti, S., and C.
to 6LoWPAN ND", draft-ietf-6lo-rfc6775-update-06 (work in Perkins, "An Update to 6LoWPAN ND", draft-ietf-6lo-
progress), June 2017. rfc6775-update-11 (work in progress), December 2017.
[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>. <https://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, <https://www.rfc-editor.org/info/rfc4291>.
[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>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, Detecting Network Attachment in IPv6", RFC 6059,
DOI 10.17487/RFC6059, November 2010, DOI 10.17487/RFC6059, November 2010,
<http://www.rfc-editor.org/info/rfc6059>. <https://www.rfc-editor.org/info/rfc6059>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
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>. <https://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>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<http://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
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
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-ap-nd] [I-D.ietf-6lo-ap-nd]
Sarikaya, B., Thubert, P., and M. Sethi, "Address Sarikaya, B., Thubert, P., and M. Sethi, "Address
Protected Neighbor Discovery for Low-power and Lossy Protected Neighbor Discovery for Low-power and Lossy
Networks", draft-ietf-6lo-ap-nd-02 (work in progress), May Networks", draft-ietf-6lo-ap-nd-04 (work in progress),
2017. November 2017.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
"Transmission of IPv6 Packets over Near Field "Transmission of IPv6 Packets over Near Field
Communication", draft-ietf-6lo-nfc-07 (work in progress), Communication", draft-ietf-6lo-nfc-09 (work in progress),
June 2017. January 2018.
[I-D.ietf-6man-rs-refresh] [I-D.ietf-6man-rs-refresh]
Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6
Neighbor Discovery Optional RS/RA Refresh", draft-ietf- Neighbor Discovery Optional RS/RA Refresh", draft-ietf-
6man-rs-refresh-02 (work in progress), October 2016. 6man-rs-refresh-02 (work in progress), October 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-11 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
in progress), January 2017. in progress), November 2017.
[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-09 (work in 802.15.4e", draft-ietf-6tisch-terminology-09 (work in
progress), June 2017. progress), June 2017.
[I-D.ietf-bier-architecture] [I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., 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-07 (work in Replication", draft-ietf-bier-architecture-08 (work in
progress), June 2017. progress), September 2017.
[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] [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.
skipping to change at page 21, line 48 skipping to change at page 21, line 48
[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-
yourtchenko-6man-dad-issues-01 (work in progress), March yourtchenko-6man-dad-issues-01 (work in progress), March
2015. 2015.
[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>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <http://www.rfc-editor.org/info/rfc4389>. 2006, <https://www.rfc-editor.org/info/rfc4389>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007, DOI 10.17487/RFC4903, June 2007,
<http://www.rfc-editor.org/info/rfc4903>. <https://www.rfc-editor.org/info/rfc4903>.
[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>. <https://www.rfc-editor.org/info/rfc4919>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415, (CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009, DOI 10.17487/RFC5415, March 2009,
<http://www.rfc-editor.org/info/rfc5415>. <https://www.rfc-editor.org/info/rfc5415>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <http://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[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>. <https://www.rfc-editor.org/info/rfc6282>.
[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>. <https://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>. <https://www.rfc-editor.org/info/rfc7048>.
[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, <https://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>. <https://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>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc7668>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772, Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016, DOI 10.17487/RFC7772, February 2016,
<http://www.rfc-editor.org/info/rfc7772>. <https://www.rfc-editor.org/info/rfc7772>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
M., and D. Barthel, "Transmission of IPv6 Packets over M., and D. Barthel, "Transmission of IPv6 Packets over
Digital Enhanced Cordless Telecommunications (DECT) Ultra Digital Enhanced Cordless Telecommunications (DECT) Ultra
Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
2017, <http://www.rfc-editor.org/info/rfc8105>. 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token- Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <http://www.rfc-editor.org/info/rfc8163>. May 2017, <https://www.rfc-editor.org/info/rfc8163>.
11.3. External Informative References 11.3. External Informative References
[IEEEstd8021] [IEEEstd8021]
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 Part 1: Bridging and metropolitan area networks Part 1: Bridging and
Architecture". Architecture".
 End of changes. 43 change blocks. 
75 lines changed or deleted 75 lines changed or added

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