Skip to main content

Dynamic Softwire Configuration of MAP-T and MAP-E Prefix Parameters via BGP
draft-bgp-softwire-map-prefix-communities-00

Document Type Active Internet-Draft (individual)
Authors Moshiko Nayman , Avinash Reddy Lingala
Last updated 2024-08-16
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-bgp-softwire-map-prefix-communities-00
Network Working Group                                     M. Nayman, Ed.
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                              R. Lingala
Expires: 17 February 2025                                           AT&T
                                                             August 2024

Dynamic Softwire Configuration of MAP-T and MAP-E Prefix Parameters via
                                  BGP
              draft-bgp-softwire-map-prefix-communities-00

Abstract

   This document proposes an OPTIONAL extension to the current MAP-T
   (Mapping of Address and Port using Translation) [RFC7599] and MAP-E
   (Mapping of Address and Port with Encapsulation) [RFC7597]
   configuration mechanisms.  It allows for dynamically learned and
   programmed MAP-T or MAP-E prefix value parameters via BGP-learned
   prefixes marked with extended community attributes, enabling a more
   flexible and scalable approach compared to static configuration.

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 2 February 2025.

Copyright Notice

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

Nayman & Lingala        Expires 17 February 2025                [Page 1]
Internet-Draft  Dynamic Softwire Configuration MAP-T and     August 2024

   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 . . . . . . . . . . . . . . . . . .   2
     1.2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   3.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     3.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acronyms and Abbreviations . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   MAP-T and MAP-E are mechanisms that enable the transition from IPv4
   to IPv6 by mapping IPv4 addresses and ports to IPv6 addresses (RFC
   7599 and RFC 7597 respectively).

   The current standard requires static configuration of MAP-T and MAP-E
   prefix parameters, which can be cumbersome and inflexible in large-
   scale networks.  This document proposes a method to dynamically
   configure MAP-T and MAP-E parameters using BGP-learned prefixes with
   extended community attributes, enhancing the efficiency and
   adaptability of network configurations.

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] when, and only when, they appear in all capitals, as
   shown here.

1.2.  Overview

   The proposed solution introduces dynamic MAP-T and MAP-E softwire
   prefixes parameter configuration using BGP-learned prefixes.  This
   approach allows for the dynamic assignment of MAP-T and MAP-E domain-
   specific parameters, such as the DMR prefix, IPv4 prefix, and MAP-T/
   MAP-E prefix, based on BGP updates.

Nayman & Lingala        Expires 17 February 2025                [Page 2]
Internet-Draft  Dynamic Softwire Configuration MAP-T and     August 2024

   This initiative leverages the framework established in [RFC7153] for
   defining new BGP communities.  The new BGP communities are required
   to indicate where the prefix will be imported and dynamically
   configured.  By associating these communities with specific MAP-T and
   MAP-E parameters, the BGP updates can precisely control the
   importation and configuration of these prefixes within the network.
   This ensures that the dynamic parameters are applied accurately and
   efficiently, allowing for real-time adaptability to network changes.

      To facilitate this dynamic configuration, new BGP softwire
      extended communities will be defined.  These communities will be
      associated with specific softwire concentrators and prefixes:

      - dmr:{number}:{prefix}

      - ipv4:{number}:{prefix}

      - map:{number}:{prefix}

   The community attribute *dmr* refers to the DMR prefix (Softwire DMR
   IPv6 Address).  The community attribute ipv4 refers to the MAP-T/
   MAP-E domain's rule IPv4 prefix/length.

   The community attribute *map* refers to the MAP-T/MAP-E domain's rule
   IPv6 prefix/length.

   The {number} refers to the name or number or term of the MAP-T/MAP-E
   softwire concentrator.  Since a MAP-T BR can have multiple MAP-T
   domains with different prefixes, this helps identify where the prefix
   will be associated.  The {prefix} refers to the actual MAP-T or MAP-E
   prefix.

      These extended community attributes are associated with the
      following Address Family Identifier (AFI) and Subsequent Address
      Family Identifier (SAFI) combinations as specified in IANA and
      described in [RFC2858] and [RFC4760].

      - IPv4 Unicast (AFI: 1, SAFI: 1)

      - IPv6 Unicast (AFI: 2, SAFI: 1)

      - VPNv4 Unicast (AFI: 1, SAFI: 128)

      - VPNv6 Unicast (AFI: 2, SAFI: 128)

   Behavior and Route Resolution:

Nayman & Lingala        Expires 17 February 2025                [Page 3]
Internet-Draft  Dynamic Softwire Configuration MAP-T and     August 2024

      - Route with only one or more softwire communities (e.g.,
      dmr:{number}:{prefix}, ipv4:{number}:{prefix}, or
      map:{number}:{prefix}): The route will be accepted with a maximum
      metric and will not be installed in the forwarding table.

      - Route with Other Communities: The route will be processed
      according to the standard BGP policy or the specific policy
      defined by the user.

      - Softwire communities: This community MUST also act as a
      NO_ADVERTISE (0xFFFFFF02) attribute well-known as defined in
      [RFC8642] unless a user-defined policy specifies otherwise.

   This initiative is OPTIONAL for MAP-T and MAP-E; it is not necessary
   for them to function.  It provides an optional mechanism to enhance
   the configuration process.

   Users can take advantage of BGP-advertised MAP-T and MAP-E parameters
   by leveraging the newly defined BGP extended communities to
   dynamically update their configurations.  When a BGP route containing
   one of the specified extended communities (e.g.,
   dmr:{number}:{prefix}, ipv4:{number}:{prefix}, or
   map:{number}:{prefix}) is received, the router can automatically
   parse these communities and update the MAP-T/MAP-E configuration
   accordingly.  This approach ensures that the configuration is always
   up-to-date with the latest network changes, reduces administrative
   overhead, and enhances scalability by allowing centralized management
   of MAP-T and MAP-E parameters through BGP.

   The new softwire extended community attributes defined in this
   document are **Transitive Extended Communities**. This designation is
   essential because MAP-T and MAP-E parameters need to be propagated
   across different BGP sessions, ensuring that routers throughout the
   network can dynamically configure themselves based on these
   attributes, thus maintaining consistency and efficiency in the
   network configuration.

2.  Security Considerations

   The Prefix-List Community attribute is a Non-Transitive Extended
   Community and should be treated with the same security considerations
   as other BGP extended communities.  Care should be taken to ensure
   that only authorized routers and networks utilize this attribute to
   prevent unauthorized or malicious routing changes.

   To prevent unauthorized use of the Prefix-List Community attribute,
   it is recommended to implement a filter or access control lists
   (ACLs) and BGP authentication mechanisms by implementing session

Nayman & Lingala        Expires 17 February 2025                [Page 4]
Internet-Draft  Dynamic Softwire Configuration MAP-T and     August 2024

   protection through TTL security [RFC5082], TCP Authentication Option
   (TCP-AO) or Message Digest Algorithm 5 (MD5) and control-plane
   filtering.  [RFC7574].

3.  References

3.1.  Normative References

   [RFC7153]  Rosen, E. and Y. Rekhter, "IANA Registries for BGP
              Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
              March 2014, <https://www.rfc-editor.org/info/rfc7153>.

   [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>.

   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
              Port with Encapsulation (MAP-E)", RFC 7597,
              DOI 10.17487/RFC7597, July 2015,
              <https://www.rfc-editor.org/info/rfc7597>.

   [RFC7599]  Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
              and T. Murakami, "Mapping of Address and Port using
              Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
              2015, <https://www.rfc-editor.org/info/rfc7599>.

3.2.  Informative References

   [RFC2858]  Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
              "Multiprotocol Extensions for BGP-4", RFC 2858,
              DOI 10.17487/RFC2858, June 2000,
              <https://www.rfc-editor.org/info/rfc2858>.

   [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>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

Nayman & Lingala        Expires 17 February 2025                [Page 5]
Internet-Draft  Dynamic Softwire Configuration MAP-T and     August 2024

   [RFC8642]  Borkenhagen, J., Bush, R., Bonica, R., and S. Bayraktar,
              "Policy Behavior for Well-Known BGP Communities",
              RFC 8642, DOI 10.17487/RFC8642, August 2019,
              <https://www.rfc-editor.org/info/rfc8642>.

   [RFC7574]  Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-
              Peer Streaming Peer Protocol (PPSPP)", RFC 7574,
              DOI 10.17487/RFC7574, July 2015,
              <https://www.rfc-editor.org/info/rfc7574>.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
              <https://www.rfc-editor.org/info/rfc5082>.

Appendix A.  Acronyms and Abbreviations

   AFI: Address Family Identifier

   BGP: Border Gateway Protocol

   DMR: Default Mapping Rule

   IP: Internet Protocol

   IPv4: Internet Protocol version 4

   IPv6: Internet Protocol version 6

   MAP-T: Mapping of Address and Port using Translation

   MAP-E: Mapping of Address and Port with Encapsulation

   NLRI: Network Layer Reachability Information

   VPN: Virtual Private Network

   SAFI: Subsequent Address Family Identifier

Acknowledgements

   To be added later

Contributors

   To be added later

Nayman & Lingala        Expires 17 February 2025                [Page 6]
Internet-Draft  Dynamic Softwire Configuration MAP-T and     August 2024

Authors' Addresses

   Moshiko Nayman (editor)
   Juniper Networks
   18 Buckingham Dr
   Manalapan, NJ 07726
   United States of America
   Email: mnayman@juniper.net

   Avinash Lingala
   AT&T
   3400 W Plano Pkwy
   Plano, TX 75075
   United States of America
   Email: ar977m@att.com

Nayman & Lingala        Expires 17 February 2025                [Page 7]