RFC 5701

RFC 5701: IPv6 Address Specific BGP Extended Community Attribute 💖

📜 The title block, quick and cute: This is RFC 5701 from the Network Working Group, filed as a Standards Track document in November 2009. Yakov Rekhter of Juniper Networks wrote it. The title block doesn't list anything it obsoletes or updates. ✨

Abstract

Okay so, BGP Extended Communities (RFC 4360) already have the IPv4 Address Specific Extended Community, but there's no IPv6 version 😭. That's a problem if an app relies on the IPv4 one and you want to run it in a pure IPv6 environment. This doc creates a new BGP attribute, the IPv6 Address Specific Extended Community, to fix that 🦋. It's basically the IPv4 version's twin, except it carries an IPv6 address instead of an IPv4 address 💅.

Status of This Memo

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright Notice

Copyright (c) 2009 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 (http://trustee.ietf.org/license-info) as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the BSD License.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications of it outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exception is formatting it for publication as an RFC, or translating it into languages other than English 🎀.

1. Introduction ✨

Okay, so the [RFC4360] BGP Extended Communities spec has the IPv4 Address Specific Extended Community, but it has zero IPv6 equivalent 💀. An app that uses the IPv4 one gets stuck when you want it in a pure IPv6 environment.

The BGP Extended Community attribute says each BGP Extended Community is 8 octets long. That's too small for an IPv6 address, so you can't define the IPv6 Specific Extended Community inside the existing attribute [RFC4360] 😩. So this doc creates a brand-new BGP attribute, the IPv6 Address Specific Extended Community. It's structured like the IPv4 one, so it can replace the IPv4 version in a pure IPv6 environment 🔥.

2. IPv6 Address Specific BGP Extended Community Attribute 💅

The IPv6 Address Specific Extended Community Attribute is a transitive, optional BGP attribute [BGP-4]. It holds a set of "IPv6 Address Specific extended communities". Every route that has this attribute belongs to the communities listed in it 🦋.

Just like every other BGP Extended Community, the IPv6 Address Specific Extended Community supports multiple sub-types 🌸.

Each IPv6 Address Specific extended community is a 20-octet quantity, laid out like this 👑:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x00 or 0x40  |    Sub-Type   |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Global Administrator (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Global Administrator (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Global Administrator (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Global Administrator (cont.)  |    Local Administrator        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first high-order octet tells you whether a sub-type of this community is transitive across Autonomous Systems (ASes) (0x00) or not (0x40). The second high-order octet is used to indicate the sub-type. The sub-types are the same as the ones for the IPv4 Address Specific Extended Community 🧚.

Global Administrator field: 16 octets 🌈

This field holds an IPv6 unicast address that one of the Internet registries assigned.

Local Administrator field: 2 octets 🍓

The organization that got the IPv6 address in the Global Administrator field can put any info it wants here. The format and meaning of the value in this field should be defined by the sub-type of the community 💜.

3. IANA Considerations 📋

This doc creates a new BGP attribute called the IPv6 Address Specific Extended Community (value 25) ✨.

It also creates a class of extended communities, also called the IPv6 Address Specific Extended Community. IANA made and will maintain a registry for it, titled "IPv6 Address Specific Extended Community". New assignments use the "First Come First Served" policy defined in [RFC5226]. Type values for transitive communities in this class are 0x0000-0x00ff. For non-transitive communities in that class, they're 0x4000-0x40ff. Each assignment has a name and a value 🎀.

This doc makes these assignments for the IPv6 Address Specific extended community types:

   Name                                     Type Value
   ----                                     --------------
   IPv6 address specific Route Target       0x0002
   IPv6 address specific Route Origin       0x0003

4. Security Considerations 🔐

This doc doesn't add any new security issues. All the security considerations for BGP Extended Communities apply here too. When this doc was written, there were big efforts underway to improve BGP's security properties. For examples of documents produced up to that point, see [RFC4593] and [SIDR].

There's a potentially serious issue if a malformed, optional, transitive attribute gets received 😱. That issue and how to avoid it are discussed in [OPT_TRANS]. Don't skip that one, bestie 🙈.

5. Acknowledgements 🫶

Huge thanks to Michael Lundberg and Emre Ertekin for reviewing and commenting on this doc 💕.

6. References 📚

6.1. Normative References

• [BGP-4] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
• [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
• [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.

6.2. Informative References

• [OPT_TRANS] Scudder, J. and E. Chen, "Error Handling for Optional Transitive BGP Attributes", Work in Progress, April 2009.
• [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
• [SIDR] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", Work in Progress, July 2009.

Author's Address 🧸

Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net