4map6 Segment 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 the underlay in multi-domain networks. In this framework, each PE will be identified by at least one IPv6 mapping prefix, it will also have one or more associated IPv4 address blocks which are extracted from local IPv4 routing table or address pool. In addition, a specific data structure called address mapping rule is defined to express the mapping relationship between IPv4 address blocks and the IPv6 mapping prefix of the remote PE. With this design, if the mapping rules of the remote PE are obtained by the ingress PE, the mapping rule will give the forwarding guidance of IPv4 packet delivery in the IPv6-only network when the destination address of the IPv4 packet matches its IPv4 address block, the ingress PE will use the mapping rule to generate 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 network as a list of instructions, which are represented as 128-bit segments, often called Segment ID (SID). This document defines a new type of segment for Segment Routing, i.e., 4map6 segment, which is a mapping rule-based IPv4/IPv6 conversion function running in PE nodes. In multi-domain IPv6-only networks, a 4map6 segment at the ingress node can convert IPv4 packets into IPv6 ones by stateless encapsulation or translation, another 4map6 segment at the egress node can restore them to IPv4 packets after being transmitted 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.

SRv6 SID has the same format as a 128-bit IPv6 address, As per section 3 of , a SID consists of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG).

The LOC identifies the node which instantiates the SID and will lead the packets to the node. The FUNCT is an opaque identification of behavior bound to the SID. ARG field provides additional information for its processing. As a new type of SID, 4map6 segment will follow the format of a general SID. Furthermore, several information items specific to stateless address mapping and packet conversion are carried in the relevant fields of the 4map6 SID, as below, • The LOC field is a prefix allocated by operators to identify the node which instantiates the 4map6 SID. • The FUNCT field identifies the behavior bound to the 4map6 SID, the behavior will be defined in Section 4. • The ARG field contains the IPv4 address prefix associated with the PE node. Since the IPv4 address prefix requires a maximum of 32 bits of a SID, the value of L+F should be less than or equal to 96. For the PE node which instantiates 4map6 SID, its IPv6 mapping prefix for IPv4 delivery corresponds to the combination of LOC and FUNCT fields. Generally, the number of the SIDs it can instantiate equals to the number of IPv4 address block associated. When an operator instantiates a 4map6 SID at an edge node, they specify a SID value LOC:FUNCT:ARG and the behavior bound to the 4map6 SID, An 4map6 SRv6 endpoint behavior may require additional information for its processing (e.g., tunnel or translation). This information may be carried in the control plane, which is out of the scope of this draft.

Generally, the 4map6 SID nodes run in pairs. For a specific data flow, one node is ingress PE, denoted by PE1, and the other is egress PE, denoted by PE2. All 4map6 nodes located at the edge of the network need to announce their 4map6 SIDs to other nodes. PE2 announces its ability to other nodes in the format of 4map6 SID in the SRv6 domain at the control plane. When PE1 receives the 4map6 SID announced by PE2, it will be stored in the local database. This database can store multiple entries, and each entry includes IPv4 address block, Locator, Function, device capability and other information corresponding to the SID, The IPv6 mapping prefix, i.e. Locator and Function, represents the egress of the packet whose destination address is the IPv4 address block. When PE1 receives an IPv4 packet, it uses the destination IPv4 address block to look for the corresponding IPv4 address block entry in the local database. If a matching IPv4 address block entry is found, the corresponding IPv6 mapping prefix will splice the IPv4 destination address to generate a 4map6 SID, and the 32-bit IPv4 address is placed in the ARG field. Following the general SRv6 procedure, the SID is programmed into SRH. The newly generated packet with the SRH is sent into the IPv6-only network for further delivery. When a new IPv6 packet arrives at PE2, PE2 parses its Locator part. If it matches the IPv6 mapping prefix instantiated by itself, it decapsulates the packet according to the instructions in Function, removes the SRH and IPv6 mapping prefix of the outer layer, and then forwards it to the next-hop according to the destination IPv4 address carried in the ARG field.

In an SRv6 network environment, the 4map6 SID needs to be advertised. The node advertises the 4map6 SID, B:N:FUNCT:ARG, through the control plane together with the SRv6 Endpoint Behavior codepoint identifying the behavior of the SID. Similar to other types of SIDs, the 4map6 SID can be distributed within and across domains via IGP and BGP or other approaches. The advertisement method and reachability calculation are specific to the chosen routing protocol. The distribution of the 4map6 Endpoint Behavior codepoint is left in future documents, e.g. by extending the SRv6 L3 Service TLV as defined in .

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.