4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks

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 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, and egress nodes can restore IPv4 packets after transmission in IPv6-only networks.

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

The SRv6 SID has the same format as a 128-bit IPv6 address, and according to Section 3 of , 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).

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

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:

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:

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.

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.

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.

This document requests IANA to allocate the following codepoints in "SRv6 Endpoint Behaviors" sub-registry of "Segment Routing Parameters" top-level registry.

There is no additional security risk introduced by this design.