IPv6 Backbone Router
RFC 8929

Document Type RFC - Proposed Standard (November 2020; No errata)
Updates RFC 6775, RFC 8505
Authors Pascal Thubert  , Charles Perkins  , Eric Levy-Abegnoli 
Last updated 2020-11-23
Replaces draft-thubert-6lo-backbone-router
Stream IETF
Formats plain text html xml pdf 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)
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 often
Show full document text