IPv6 Backbone Router
RFC 8929
Document | Type | RFC - Proposed Standard (November 2020; No errata) | |
---|---|---|---|
Authors | Pascal Thubert , Charles Perkins , Eric Levy-Abegnoli | ||
Last updated | 2020-11-23 | ||
Replaces | draft-thubert-6lo-backbone-router | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Shwetha Bhandari | ||
Shepherd write-up | Show (last changed 2019-10-02) | ||
IESG | IESG state | RFC 8929 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Suresh Krishnan | ||
Send notices to | "Samita Chakrabarti" <samitac.ietf@gmail.com>, Carles Gomez <carlesgo@entel.upc.edu>, Shwetha Bhandari <shwethab@cisco.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) P. Thubert, Ed. Request for Comments: 8929 Cisco Systems Updates: 6775, 8505 C.E. Perkins Category: Standards Track Blue Meadow Networking ISSN: 2070-1721 E. Levy-Abegnoli Cisco Systems November 2020 IPv6 Backbone Router Abstract This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate multiple wireless links to form a single Multi-Link Subnet (MLSN). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8929. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Terminology 2.1. Requirements Language 2.2. New Terms 2.3. Abbreviations 2.4. Background 3. Overview 3.1. Updating RFCs 6775 and 8505 3.2. Access Link 3.3. Route-Over Mesh 3.4. The Binding Table 3.5. Primary and Secondary 6BBRs 3.6. Using Optimistic DAD 4. Multi-Link Subnet Considerations 5. Optional 6LBR Serving the Multi-Link Subnet 6. Using IPv6 ND over the Backbone Link 7. Routing Proxy Operations 8. Bridging Proxy Operations 9. Creating and Maintaining a Binding 9.1. Operations on a Binding in Tentative State 9.2. Operations on a Binding in Reachable State 9.3. Operations on a Binding in Stale State 10. Registering Node Considerations 11. Security Considerations 12. Protocol Constants 13. IANA Considerations 14. Normative References 15. Informative References Appendix A. Possible Future Extensions Appendix B. Applicability and Requirements Served Acknowledgments Authors' Addresses 1. Introduction Ethernet bridging per IEEE Std 802.1 [IEEEstd8021Q] provides an efficient and reliable broadcast service for wired networks; applications and protocols have been built that heavily depend on that feature for their core operation. Unfortunately, Low-Power and Lossy Networks (LLNs) and local wireless networks generally do not provide the broadcast capabilities of Ethernet bridging in an economical fashion. As a result, protocols designed for bridged networks that rely on multicast and broadcast often exhibit disappointing behaviors when employed unmodified on a local wireless medium (see [MCAST-PROBLEMS]). Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended Service Set (ESS) act as Ethernet bridges [IEEEstd8021Q], with the property that the bridging state is established at the time of association. This ensures connectivity to the end node (the Wi-Fi Station (STA)) and protects the wireless medium against broadcast- intensive transparent bridging [IEEEstd8021Q] reactive lookups. In other words, the association process is used to register the link- layer address of the STA to the AP. The AP subsequently proxies the bridging operation and does not need to forward the broadcast lookups over the radio. In the same way as transparent bridging, the IPv6 [RFC8200] Neighbor Discovery (IPv6 ND) protocol [RFC4861] [RFC4862] is a reactive protocol, based on multicast transmissions to locate an on-link correspondent and ensure the uniqueness of an IPv6 address. The mechanism for Duplicate Address Detection (DAD) [RFC4862] was designed for the efficient broadcast operation of Ethernet bridging. Since broadcast can be unreliable over wireless media, DAD oftenShow full document text