4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks
draft-dong-spring-sr-4map6-segments-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Guozhen Dong , Chongfeng Xie , Xing Li , Shuping Peng | ||
| Last updated | 2024-11-03 | ||
| Replaces | draft-dong-spring-sr-4map6-segment | ||
| 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-dong-spring-sr-4map6-segments-03
Network Working Group G. Dong
Internet-Draft C. Xie
Intended status: Standards Track China Telecom
Expires: 7 May 2025 X. Li
CERNET Center/Tsinghua University
S. Peng
Huawei Technologies
3 November 2024
4map6 Segments for IPv4 Service delivery over IPv6-only underlay
networks
draft-dong-spring-sr-4map6-segments-03
Abstract
This document defines a new type of segment for Segment Routing,
4map6 segment, which is an IPv4/IPv6 conversion function based on
stateless mapping rules running in PE nodes for the delivery of IPv4
services over IPv6-only network. At the same time, the BGP Prefix-
SID attribute SRv6 Service TLVs is extended to transmit IPv4/IPv6
address mapping rules in IPv6-only domain and cross-domain.
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 7 May 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.
Dong, et al. Expires 7 May 2025 [Page 1]
Internet-Draft 4map6s Segments Delivery November 2024
Please review these documents carefully, as they describe your rights
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. Overview of the new SID . . . . . . . . . . . . . . . . . . . 3
3. SRv6 Service TLV Extension . . . . . . . . . . . . . . . . . 4
4. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The document [I-D./draft-ietf-v6ops-framework-md-ipv6only-underlay]
proposes a framework for deploying IPv6-only as underlay in multi-
domain networks. In this framework, each PE will be identified by at
least one IPv6 mapping prefix assigned by the operator, and routable.
It will also have one or more associated IPv4 address blocks
extracted from the local IPv4 routing table or address pool. In
addition, a specific data structure is defined as address mapping
rules to express the mapping relationship between IPv4 address blocks
and the IPv6 mapping prefixes of the remote PE. With this design, if
the mapping rule of the remote PE is obtained by the ingress PE, the
mapping rule will give the forwarding guidance of the IPv4 packet in
the IPv6-only network when the destination address of the IPv4 packet
matches its IPv4 address block. The ingress PE will use the
information in the mapping rule to generate the corresponding IPv6
source and destination addresses from its IPv4 source and destination
addresses and then generate a new IPv6 packet.
This mapping-based conversion can also work in SRv6 [RFC8986]
networks. SRv6 defines packet processing in IPv6 networks as a list
of instructions, which are represented as 128-bit segments, often
referred to as Segment ID (SID). In this document, a new type of
segments, 4map6 segments, is defined for Segment Routing. They run
in PE nodes and provide support for implementing IPv4/IPv6 conversion
function based on mapping rules. In multi-domain IPv6-only networks,
ingress nodes can convert IPv4 packets into IPv6 packets by stateless
encapsulation or translation using the information in 4map6 segments,
Dong, et al. Expires 7 May 2025 [Page 2]
Internet-Draft 4map6s Segments Delivery November 2024
and egress nodes can restore IPv4 packets after transmission in
IPv6-only networks. This draft illustrates IPv4/IPv6 address mapping
and packet transformation from the perspective of SRv6, the new SID
mainly deal with how to generate new IPv6 headers based on the
information of IPv4 packets, it does not involve SRH, so it can be
considered as an approach of SRv6 BE.
The design of this draft only supports the scenarios in section 3 of
the document [I-D./draft-ietf-v6ops-framework-md-ipv6only-underlay].
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. Overview of the new SID
The SRv6 SID has the same format as a 128-bit IPv6 address, and
according to Section 3 of [RFC8986], the SID consists of
LOC:FUNCT:ARG, where the address (LOC) is encoded in the L most
significant bits of the SID, followed by F bits of the function
(FUNCT), and A bits of the argument (ARG).
+----------+----------------+----------+------------+------------+
| LOC(L bits) | FUNCT(F bits) | ARG(32bits)|
+----------+----------------+----------+------------+------------+
Figure 1: SID architecture
The LOC identifies the node where SID is instantiated and directs the
packet to it. The FUNCT is an opaque identity for a behavior bound
to SID. The ARG field provides additional information for its
processing. As a new type of SID, the 4map6 segment will follow the
format of the general SID. In addition, some information items
specific to stateless address mapping and packet translation are
carried in the relevant fields of the 4map6 SID as follows:
• The LOC field has the positioning function, which is unique in
the SR domain. It is a prefix assigned by the operator, and its
value reflects the operator's IPv6 address planning. The
operator needs to plan according to its own networking and
business classification, and it is used to identify the node that
instantiates the 4map6 SID.
Dong, et al. Expires 7 May 2025 [Page 3]
Internet-Draft 4map6s Segments Delivery November 2024
• The FUNCT field identifies the behavior bound to the 4map6 SID
and is used to instruct the 4map6 SID node to perform the
corresponding functional operation.
• The ARG field contains the behavioral identity of whether
stateless encapsulation or translation is performed at that point
and the IPv4 address associated with the PE node. The value of
L+F should be less than or equal to 96 since 32 bits are required
for IPv4 address.
For a PE node instantiating a 4map6 SID, its IPv6 mapping prefix IPv6
Prefix for IPv4 transmission corresponds to the LOC field. For the
encapsulation or translation processing of IPv4 packets E/T is
distinguished by the identity of ARG field. The 4map6 SID therefore
has the structure IPv6 Prefix + E/T + IPv4 address. In general, the
number of SIDs that can be instantiated on a PE is equal to the
number of associated IPv4 address blocks.
3. SRv6 Service TLV Extension
In SRv6 network environment, 4map6 SID needs to be published to
implement IPv4/IPv6 address mapping rule advertisement. This
document specifies that an egress PE can implement the BGP protocol
and extend in its BGP Prefix-SID property [RFC8669] to support
publishing the service SID contained in its TLV, that is, the 4map6
SID, as an overlay service prefix in the network. The standard BGP
update propagation scheme [RFC4271] can make use of route reflectors
[RFC4456] to propagate these prefixes. This document defines a new
BGP prefixed SID attribute extension TLV in the SRv6 Service TLVs to
implement SID signaling for the 4map6 service of the SRv6 service:
SRv6 4map6 Service TLV: Used to carry SRv6 SID information of 4map6
service in multi-domain IPv6-only network, extended to support
carrying End.4map6 SID.
The format of the extended SRv6 Services TLV is depicted below:
0 7 15 23 31
+--------------+----------------------------+--------------+
| TLV Type | TLV Length | Reserved |
+--------------+----------------------------+--------------+
| |
| SRv6 Service Sub-TLVs |
| |
+----------------------------------------------------------+
Figure 2: SRv6 Services TLV
Dong, et al. Expires 7 May 2025 [Page 4]
Internet-Draft 4map6s Segments Delivery November 2024
TLV Type (8 bits):
Used to identify different TLVS, SRv6 4map6 Service TLV is 8.
TLV Length (16 bits):
Total length of the TLV.
RESERVED (8 bits):
Reserved fields.
SRv6 Service Sub-TLVs (variable):
This field contains more specific SRv6 service information and is
encoded as an unordered list of Sub-TLVs whose format is described
below.
The format of SRv6 Service Sub-TLVs is depicted below:
0 7 15 23 31
+--------------+----------------------------+--------------+
| SRv6 Service | SRv6 Service | SRv6 Service |
| Sub-TLV Type | Sub-TLV Length | Sub-TLV Value|
+--------------+----------------------------+--------------+
Figure 3: SRv6 Service Sub-TLV
SRv6 Service Sub-TLV Type (8 bits):
This field identifies the type of SRv6 service information, which
takes the value 1, indicates the SRv6 SID Information Sub-TLV.
SRv6 Service Sub-TLV Length (16 bits):
The sub-TLV length.
SRv6 Service Sub-TLV Value (variable):
This field contains data specific to the Sub-TLV Type. The SRv6
SID information of 4map6 Service is filled in the SRv6 Service
Sub-TLV Value field.
4. Behavior
In general, 4map6 SID nodes operate in pairs. For a particular data
stream, one node is the ingress PE, denoted by PE1, and the other is
the egress PE, denoted by PE2. Each PE maintains a Mapping rule
Database (MD) as shown in Figure. The table entries in the MD
database consist of IPv4 address prefixes, IPv6 mapping prefixes, and
the encapsulation or translation processing E/T way of IPv4 packets.
It should be noted that the database here is only an example, and
developers can design the structure of the database according to the
actual situation.
Dong, et al. Expires 7 May 2025 [Page 5]
Internet-Draft 4map6s Segments Delivery November 2024
+-------------------+-------------------+--------------------------------+
|IPv4 Address Prefix|IPv6 Mapping Prefix|Encapsulation or Translation E/T|
+-------------------+-------------------+--------------------------------+
Figure 4: The Structure of Map Rule Database
Before transmitting an IPv4 packet from PE1 to PE2, the address
mapping rule corresponding to its IPv4 destination address needs to
be transferred from PE2 to PE1. Therefore, PE2, which supports 4map6
service based on SRv6, publishes the 4map6 SID corresponding to the
IPv4 destination address in the BGP Prefix-SID attribute, so as to
realize the PE2 node located at the edge of the network to other
nodes and synchronize the address mapping rule database on each PE
device. PE2 announces its capabilities to other nodes in the format
of the 4map6 SID of the SRv6 domain in the control plane. When PE1
receives the 4map6 SID announced by PE2, it extracts the relevant
information and stores it in the local mapping rule database. The
LOC field in the 4map6 SID corresponds to the database IPv6 Mapping
Prefix, the Encapsulation/Translation behavior identifier bit in the
ARG corresponds to the database encapsulation or translation E/T, and
the address field in the ARG corresponds to the database IPv4 address
block.
When PE1 receives an IPv4 packet, it first uses the destination IPv4
address block to find the corresponding IPv4 address block entry in
the local mapping rule database. If there is a matching IPv4 address
block entry, the corresponding IPv6 mapping prefix will concatenate
the IPv4 destination address to generate the 4map6 SID, and the
32-bit IPv4 destination address in the packet is placed in the ARG
field. According to the general SRv6 procedure, the SID is
programmed as an IPv6 destination address, and the newly generated
packet is sent to the pure IPv6 network for further delivery.
When a new IPv6 packet arrives at PE2, PE2 resolves the IPv6
destination address of the packet. If it matches an IPv6 mapping
prefix in its instantiated SID, it will process the packet according
to the 4map6 instruction in FUNCT, remove the IPv6 mapping prefix and
forward it to the next hop according to the encapsulation/translation
behavior in ARG field and the destination IPv4 address carried.
5. IANA Considerations
This document requests IANA to allocate the following codepoints in
"SRv6 Endpoint Behaviors" sub-registry of "Segment Routing
Parameters" top-level registry.
Dong, et al. Expires 7 May 2025 [Page 6]
Internet-Draft 4map6s Segments Delivery November 2024
+----------+--------+-----------------------+-----------------+
| Value | Hex | Endpoint behavior | Reference |
|----------|--------|-----------------------|-----------------|
| TBD | | End.4map6 | [This.ID] |
+----------+--------+-----------------------+-----------------+
Figure 5: End.4map6 Endpoint Behavior
6. Security Considerations
There is no additional security risk introduced by this design.
7. References
7.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>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>.
Dong, et al. Expires 7 May 2025 [Page 7]
Internet-Draft 4map6s Segments Delivery November 2024
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
7.2. Informative References
[I-D.ietf-v6ops-framework-md-ipv6only-underlay]
Xie, C., Ma, C., Li, X., Mishra, G. S., Boucadair, M., and
T. Graf, "Framework of Multi-domain IPv6-only Underlay
Network and IPv4-as-a-Service", Work in Progress,
Internet-Draft, draft-ietf-v6ops-framework-md-ipv6only-
underlay-08, 17 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
framework-md-ipv6only-underlay-08>.
Authors' Addresses
Guozhen Dong
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: [email protected]
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: [email protected]
Dong, et al. Expires 7 May 2025 [Page 8]
Internet-Draft 4map6s Segments Delivery November 2024
Xing Li
CERNET Center/Tsinghua University
Shuangqing Road No.30, Haidian District
Beijing
100084
China
Email: [email protected]
Shuping Peng
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing
100095
China
Email: [email protected]
Dong, et al. Expires 7 May 2025 [Page 9]