Internet-Draft Dynamic Softwire Configuration MAP-T and August 2024
Nayman & Lingala Expires 17 February 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-bgp-softwire-map-prefix-communities-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Nayman, Ed.
Juniper Networks
R. Lingala
AT&T

Dynamic Softwire Configuration of MAP-T and MAP-E Prefix Parameters via BGP

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.

Table of Contents

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.

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:

  • - 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 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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc4760>.
[RFC8642]
Borkenhagen, J., Bush, R., Bonica, R., and S. Bayraktar, "Policy Behavior for Well-Known BGP Communities", RFC 8642, DOI 10.17487/RFC8642, , <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, , <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, , <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

Authors' Addresses

Moshiko Nayman (editor)
Juniper Networks
18 Buckingham Dr
Manalapan, NJ 07726
United States of America
Avinash Lingala
AT&T
3400 W Plano Pkwy
Plano, TX 75075
United States of America