IPv6 Backbone Router
RFC 8929
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 often
Show full document text