<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc
    xmlns:xi="http://www.w3.org/2001/XInclude"
    category="std"
    submissionType="IETF"
    ipr="trust200902"
    xml:lang="en"
    docName="draft-bgp-ext-communities-map-prefixes-00">
    <front>
        <title abbrev="Dynamic Prefix Configuration MAP-T and MAP-E Parameters via BGP">Dynamic Prefix Configuration of MAP-T and MAP-E Parameters via BGP</title>
        <seriesInfo name="Internet-Draft" value="draft-bgp-ext-communities-map-prefixes-00"/>
        <author fullname="Moshiko Nayman" initials="M" role="editor" surname="Nayman">
            <organization>Juniper Networks</organization>
            <address>
                <postal>
                    <street>18 Buckingham Dr</street>
                    <city>Manalapan</city>
                    <code>07726</code>
                    <region>NJ</region>
                    <country>US</country>
                </postal>
                <email>mnayman@juniper.net</email>
            </address>
        </author>
        <author fullname="Avinash Lingala" initials="A" surname="Lingala">
            <organization>AT&amp;T</organization>
            <address>
                <postal>
                    <street>12186 Diamond Creek Dr</street>
                    <city>Frisco</city>
                    <code>75035</code>
                    <region>TX</region>
                    <country>US</country>
                </postal>
                <email>ar977m@example.com</email>
            </address>
        </author>        <date year="2024" month="August"/>
        <abstract>
            <t>This document proposes an extension to the current MAP-T (Mapping of Address and Port using Translation) <xref target="RFC7599"/> and MAP-E (Mapping of Address and Port with Encapsulation) <xref target="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.</t>
        </abstract>
    </front>
    <middle>
        <section title="Introduction" anchor="intro">
            <t>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).</t>
            <t>The current standard requires static configuration of MAP-T and MAP-E 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.</t>
            <section title="Requirements Language">
                <t>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 <xref target="RFC2119"/> when, and only when, they appear in all capitals, as shown here.</t>
            </section>
            <section title="Overview">
                <t>The proposed solution introduces dynamic MAP-T and MAP-E 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.</t>
                <t>To facilitate this dynamic configuration, new BGP extended communities will be defined. These communities will be associated with specific softwire concentrators and prefixes:</t>
                <ul>
                    <li>dmr:{number}:{prefix}</li>
                    <li>ipv4:{number}:{prefix}</li>
                    <li>map:{number}:{prefix}</li>
                </ul>
                <t>This initiative leverages the framework established in RFC 7153 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.</t>
                <t>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.</t>
                <t>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 descbied in <xref target="RFC2858"/> and <xref target="RFC4760"/>.</t>
                <t>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.</t>
                <t>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.</t>
                <t>The 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.</t>
            </section>
        </section>
        <section title="Dynamic MAP-T and MAP-E Prefixes Learned via BGP">
            <t>The proposed solution introduces dynamic MAP-T and MAP-E 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.</t>
            <t>To facilitate this dynamic configuration, new BGP extended communities will be defined. These communities will be associated with specific softwire concentrators and prefixes:</t>
            <ul>
                <li>dmr:{number}:{prefix}</li>
                <li>ipv4:{number}:{prefix}</li>
                <li>map:{number}:{prefix}</li>
            </ul>
            <t>This initiative leverages the framework established in <xref target="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.</t>
            <t>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.</t>
            <t>These extended community attributes are associated with the following Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) combinations as specified in IANA:</t>
            <ul>
                <li>IPv4 Unicast (AFI: 1, SAFI: 1)</li>
                <li>IPv6 Unicast (AFI: 2, SAFI: 1)</li>
                <li>VPNv4 Unicast (AFI: 1, SAFI: 128)</li>
                <li>VPNv6 Unicast (AFI: 2, SAFI: 128)</li>
            </ul>
            <t>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.</t>
            <t>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.</t>
            <t>The 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.</t>
        </section>
    </middle>
    <back>
        <references title="Normative References">
            <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7153.xml"/>
            <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
            <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7597.xml"/>
            <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7599.xml"/>
        </references>
        <references title="Informative References">
            <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2858.xml"/>
            <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4271.xml"/>
            <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4760.xml"/>
        </references>
        <section title="Acronyms and Abbreviations">
            <t>AFI: Address Family Identifier</t>
            <t>BGP: Border Gateway Protocol</t>
            <t>IP: Internet Protocol</t>
            <t>IPv4: Internet Protocol version 4</t>
            <t>IPv6: Internet Protocol version 6</t>
            <t>MAP-T: Mapping of Address and Port using Translation</t>
            <t>MAP-E: Mapping of Address and Port with Encapsulation</t>
            <t>NLRI: Network Layer Reachability Information</t>
            <t>VPN: Virtual Private Network</t>
            <t>SAFI: Subsequent Address Family Identifier</t>
        </section>
        <section anchor="Acknowledgements" numbered="false">
            <name>Acknowledgements</name>
            <t>To be added later</t>
        </section>
        <section anchor="Contributors" numbered="false">
            <name>Contributors</name>
            <t>To be added later</t>
        </section>
    </back>
</rfc>