BGP Extended Community for Identifying the Target Nodes
draft-ietf-idr-node-target-ext-comm-04

Network Working Group                                            J. Dong
Internet-Draft                                                 S. Zhuang
Intended status: Standards Track                     Huawei Technologies
Expires: 6 May 2027                                      G. Van de Velde
                                                                   Nokia
                                                             J. Tantsura
                                                                  Nvidia
                                                         2 November 2026

        BGP Extended Community for Identifying the Target Nodes
                 draft-ietf-idr-node-target-ext-comm-04

Abstract

   BGP has been used to distribute different types of routing and policy
   information.  In some cases, the information distributed may be only
   intended for one or a particular group of BGP nodes in the network.
   Currently BGP does not have a generic mechanism to designate the
   target nodes of the routing information.  This document defines a new
   type of BGP Extended Community called "Node Target" for this purpose.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 May 2027.

Copyright Notice

   Copyright (c) 2026 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

Dong, et al.               Expires 6 May 2027                   [Page 1]
Internet-Draft     BGP Node Target Extended Community      November 2026

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Node Target Extended Communities  . . . . . . . . . . . . . .   3
   3.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   BGP [RFC4271] has been used to distribute different types of routing
   and policy information.  In some cases, the information distributed
   may be only intended for one or a group of receiving BGP nodes in the
   network.  One typical use case is the distribution of BGP Flow Spec
   [RFC8955] [RFC8956] rules only to a particular group of BGP nodes.
   Such a targeted distribution mechanism is considered useful as it can
   save resource on nodes which do not need that information.

   Currently BGP does not have a generic mechanism to designate the set
   of nodes to which the information is to be distributed.  Route Target
   (RT) as defined in [RFC4364] was designed for the matching of VPN
   routes into the target VPN Routing and Forwarding tables (VRFs) on
   the PE nodes.  [RFC9830] introduces the mechanism of steering the SR
   Policy information to the target head end node based on RT, it is
   only applicable to the SR Policy Address Family.  Although it is
   possible to reuse RT to control the distribution of non-VPN
   information to one or a group of receiving nodes, such mechanism is
   not applicable when the information to be distributed is VPN-specific
   and is advertised with another set of RTs for the VRF matching, as
   the matching of any of the VPN RT in the BGP route would result in
   that route being imported to a local VRF, regardless of whether the
   receiving node is the target node or not.  Thus a general mechanism
   which is independent from the control of importing VPN routes to VRFs
   is needed.

Dong, et al.               Expires 6 May 2027                   [Page 2]
Internet-Draft     BGP Node Target Extended Community      November 2026

   Another possible approach is to configure, on each router, a
   community and the corresponding policies to match the community to
   determine whether to accept the received routes or not.  Such
   mechanism relies on manual configuration thus is considered error-
   prone.  It is preferable by some operators that an automatic approach
   can be provided, which would make the operation much easier.

   This document defines a new type of BGP Extended Community called
   "Node Target".  It can be used by a receiving BGP node to determine
   whether it is the target of the BGP information.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Node Target Extended Communities

   This section defines a new BGP Extended Community [RFC4360] called
   "Node Target Extended Community".  It can be a transitive extended
   community with the high-order octet of the type set to 0x01, or a
   non-transitive extended community with the high-order octet type set
   to 0x41.  The sub-type of the Node Target Extended Community is 0x09.

   The format of Node Target Extended Community is shown in Figure 1.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  0x01 or 0x41 |      0x09     |    Target BGP Identifier      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Target BGP Identifier (cont.) |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1. Node Target extended community

   Where:

   Target BGP Identifier (4 octets): The BGP Identifier of a target
   node.  It is a 4-octet, unsigned, non-zero integer as defined in
   [RFC6286].

   Reserved field (2 octets): Reserved for future use, MUST be set to
   zero on transmission and ignored on receipt.

Dong, et al.               Expires 6 May 2027                   [Page 3]
Internet-Draft     BGP Node Target Extended Community      November 2026

   One or more Node Target extended communities MAY be carried in an
   Update message to designate a group of target BGP nodes.

3.  Procedures

   In this section, the mechanism for intra-domain scenario is
   described, the mechanism for inter-domain scenario is for further
   study.  The domain here refers to an administrative domain, which may
   consists of one or multiple ASes managed by a single operator.

   When a network controller or BGP speaker plans to advertise BGP
   routing or policy information only to one or a group of BGP nodes in
   the network, it MUST put the BGP Identifier of each target node into
   a list of Node Target extended communities, and attach the Node
   Target extended communities to the BGP Update to be advertised.
   Duplicated BGP identifiers MUST NOT be carried in the Node Target
   extended communities of a BGP Update.

   When a BGP speaker receives a BGP Update which contains one or more
   Node Target extended communities, it MUST check the BGP Identifiers
   carried in the Node Target extended communities of the Update.  An
   invalid BGP Identifier (e.g. 0.0.0.0) received in Node Target
   Extended Communities MUST be ignored on receipt and SHOULD be logged.
   If multiple Node Target extended communities in an Update carry the
   same BGP Identifier, the receiver SHOULD treat them as a single
   occurrence of that target.  Duplicate occurrences have no additional
   meaning and SHOULD be silently ignored.

   If any of the Target BGP Identifiers in the Node Target extended
   communities matches the local BGP Identifier, this node is one of the
   target nodes of the Update, information in the Update is eligible for
   installation on this node.  If none of the Target BGP Identifiers in
   the Node Target extended communities matches with the local BGP
   Identifier, this node is not among the target nodes of the Update,
   information in the UPDATE MAY still be accepted by the BGP speaker
   (e.g. stored in Adj-RIB-In), but it MUST NOT be installed locally in
   the RIB/FIB/ACL etc. of this node, and MUST NOT be advertised further
   to other nodes.  Routing information that is not targeted to this
   node SHOULD still be observable for diagnostic purposes, this can be
   done by an indication that the route does not pass the Node Target
   check , together with the Node Target extended communities received.
   A counter of routes not passing the node-target check SHOULD also be
   kept.  The specific storage location is implementation-dependent.

   FlowSpec is a motivating use case for this mechanism.  When a
   FlowSpec NLRI carries Node Target extended communities, the Node
   Target check SHOULD be applied before the validation procedure
   defined in [RFC8955].

Dong, et al.               Expires 6 May 2027                   [Page 4]
Internet-Draft     BGP Node Target Extended Community      November 2026

   The mechanism of using Node Target extended community to control the
   BGP route distribution only to particular BGP nodes is out of the
   scope and will be specified in a separate document.

4.  Operational Considerations

   An operator who is responsible for the administration of one or
   multiple ASes need to ensure each BGP speaker in the network is
   assigned with a unique BGP Identifier.  The Node Target extended
   communities may be originated by a network controller or a BGP
   speaker, In order to construct the list of node targets, an inventory
   of the BGP Identifiers of the target nodes in the domain MUST be
   maintained.  The mechanism used to obtain and update such inventory
   is out of the scope of this document.  Operators are expected to
   derive it from their existing inventory, orchestration, or
   configuration management systems..

   Each node target consumes an 8-octet extended community, and targets
   are enumerated individually.  A large group of node target extended
   communities therefore adds substantially to the size of the Update.
   Operators SHOULD keep the target groups to a practical size, and
   SHOULD consider whether a small set of target nodes can meet the
   deployment need.  Implementations MAY impose a local limit on the
   number of Node Target extended communities per Update.

   The Node Target extended community can be deployed incrementally.
   BGP speakers that do not understand it ignore it and process the
   Update according to normal BGP procedures.  This ensures target nodes
   obtain the information they need, but may also result in unnecessary
   state on legacy nodes.  If the information is FlowSpec, legacy
   speakers may install unnecessary FlowSpec rules, potentially
   affecting traffic that matches those rules.  This may be mitigated by
   setting appropriate routing policies on the legacy BGP nodes.
   Operators should be aware of this requirement during the migration.

5.  IANA Considerations

   Per the early allocation process, IANA has assigned the sub-type
   value 0x09 for "Node Target Extended Community" from the "Transitive
   IPv4-Address-Specific Extended Community Sub-Types" registry of the
   "BGP Extended Communities" registry.

   Per the early allocation process, IANA has assigned the sub-type
   value 0x09 for "Node Target Extended Community" from the "Non-
   Transitive IPv4-Address-Specific Extended Community Sub-Types"
   registry of the "BGP Extended Communities" registry.

Dong, et al.               Expires 6 May 2027                   [Page 5]
Internet-Draft     BGP Node Target Extended Community      November 2026

6.  Security Considerations

   The mechanism defined in this document can limit the scope of the
   receiving nodes of BGP Updates, which make it possible for an
   attacker to do fine-grained targeting of malicious BGP Updates only
   to a restricted set of routers.  This may make it more difficult for
   a network administrator to discover an attack.  This may be mitigated
   by filtering the Node Target extended communities at the
   administrative network boundaries.  A misconfigured or injected Node
   Target extended community could suppress route installation across an
   entire administrative domain without generating any protocol error.
   Operators should treat target lists as security-sensitive
   configuration.

7.  Contributors

   Haibo Wang
   Email: rainsword.wang@huawei.com

8.  Acknowledgements

   The authors would like to thank Zhenbin Li, Ercin Torun, Jeff Haas,
   Robert Raszuk and John Scudder for the review and discussion of this
   document.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <https://www.rfc-editor.org/info/rfc4360>.

   [RFC6286]  Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
              Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
              June 2011, <https://www.rfc-editor.org/info/rfc6286>.

Dong, et al.               Expires 6 May 2027                   [Page 6]
Internet-Draft     BGP Node Target Extended Community      November 2026

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC8955]  Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
              Bacher, "Dissemination of Flow Specification Rules",
              RFC 8955, DOI 10.17487/RFC8955, December 2020,
              <https://www.rfc-editor.org/info/rfc8955>.

   [RFC8956]  Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
              "Dissemination of Flow Specification Rules for IPv6",
              RFC 8956, DOI 10.17487/RFC8956, December 2020,
              <https://www.rfc-editor.org/info/rfc8956>.

   [RFC9830]  Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
              P., and D. Jain, "Advertising Segment Routing Policies in
              BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
              <https://www.rfc-editor.org/info/rfc9830>.

Authors' Addresses

   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: jie.dong@huawei.com

   Shunwan Zhuang
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: zhuangshunwan@huawei.com

Dong, et al.               Expires 6 May 2027                   [Page 7]
Internet-Draft     BGP Node Target Extended Community      November 2026

   Gunter Van de Velde
   Nokia
   Antwerp
   Belgium
   Email: gunter.van_de_velde@nokia.com

   Jeff Tantsura
   Nvidia
   Email: jefftant.ietf@gmail.com

Dong, et al.               Expires 6 May 2027                   [Page 8]