ethdev: introduce NAT64 action

RFC PATCH In review Bing Zhao 3 participants 5 messages Aug 11, 2023 – Nov 28, 2023

Share & tools

Bing Zhao

author

2023-08-11 14:07 UTC #0 lore raw

RFC PATCH 1/1 ethdev: introduce NAT64 action

In order to support the communication between IPv4 and IPv6 nodes in the network, different technologies are used, like dual-stacks, tunneling and NAT64. In some IPv4-only clients, it is hard to deploy new software and hardware to support IPv6.

NAT64 is a choice and it will also reduce the unnecessary overhead of the traffic in the network. The NAT64 gateways take the responsibility of the packet headers translation between the IPv6 clouds and IPv4-only clouds.

This action should support the offloading of the IP headers' translation. The following fields should be reset correctly in the translation.
- Version
- Traffic Class / TOS
- Flow Label (0 in v4)
- Payload Length / Total length
- Next Header
- Hop Limit / TTL

Since there are different mapping and translating modes of the addresses, it will depend on the capabilities of each vendor.

The ICMP* and transport layers protocol is out of the scope of NAT64 rte_flow action.

Reference links:
- https://datatracker.ietf.org/doc/html/rfc6146
- https://datatracker.ietf.org/doc/html/rfc6052
- https://datatracker.ietf.org/doc/html/rfc6145

Signed-off-by Bing Zhao <[email protected]>

---
 lib/ethdev/rte_flow.c |  1 +
 lib/ethdev/rte_flow.h | 27 +++++++++++++++++++++++++++
 2 files changed, 28 insertions(+)

lib/ethdev/rte_flow.c +1 -0

index 271d854f78..b60a4f6654 100644
@@ -265,6 +265,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
 	MK_FLOW_ACTION(IPV6_EXT_REMOVE, sizeof(struct rte_flow_action_ipv6_ext_remove)),
 	MK_FLOW_ACTION(INDIRECT_LIST,
 		       sizeof(struct rte_flow_action_indirect_list)),
+	MK_FLOW_ACTION(NAT64, sizeof(struct rte_flow_action_nat64)),
 };
 
 int

lib/ethdev/rte_flow.h +27 -0

index 86ed98c562..2002999a35 100644
@@ -2989,6 +2989,13 @@ enum rte_flow_action_type {
 	 * @see struct rte_flow_action_indirect_list
 	 */
 	RTE_FLOW_ACTION_TYPE_INDIRECT_LIST,
+
+	/**
+	 * Support the NAT64 translation.
+	 *
+	 * @see struct rte_flow_action_nat64
+	 */
+	RTE_FLOW_ACTION_TYPE_NAT64,
 };
 
 /**

@@ -4092,6 +4099,26 @@ rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t v)
 	*RTE_FLOW_DYNF_METADATA(m) = v;
 }
 
+/**
+ * NAT64 translation type for IP headers.
+ */
+enum rte_flow_nat64_type {
+	RTE_FLOW_NAT64_6TO4 = 0, /**< IPv6 to IPv4 headers translation. */
+	RTE_FLOW_NAT64_4TO6 = 1, /**< IPv4 to IPv6 headers translation. */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_NAT64
+ *
+ * Specify the NAT64 translation type.
+ */
+struct rte_flow_action_nat64 {
+	enum rte_flow_nat64_type type;
+};
+
 /**
  * Definition of a single action.
  *

Signature · 1 line

2.34.1

Ori Kam

Acked-by on v1 1/1

2023-09-19 10:05 UTC #1 lore raw

Hi Bing

Quoted 31 lines

-----Original Message-----
From: Bing Zhao <[email protected]>
Sent: Friday, August 11, 2023 5:07 PM
Subject: [RFC PATCH] ethdev: introduce NAT64 action
In order to support the communication between IPv4 and IPv6 nodes in the network, different technologies are used, like dual-stacks, tunneling and NAT64. In some IPv4-only clients, it is hard to deploy new software and hardware to support IPv6.
NAT64 is a choice and it will also reduce the unnecessary overhead of the traffic in the network. The NAT64 gateways take the responsibility of the packet headers translation between the IPv6 clouds and IPv4-only clouds.
This action should support the offloading of the IP headers' translation. The following fields should be reset correctly in the translation.
- Version
- Traffic Class / TOS
- Flow Label (0 in v4)
- Payload Length / Total length
- Next Header
- Hop Limit / TTL
Since there are different mapping and translating modes of the addresses, it will depend on the capabilities of each vendor.
The ICMP* and transport layers protocol is out of the scope of NAT64 rte_flow action.

Quoted 7 lines

Reference links:
- https://datatracker.ietf.org/doc/html/rfc6146
- https://datatracker.ietf.org/doc/html/rfc6052
- https://datatracker.ietf.org/doc/html/rfc6145
Signed-off-by Bing Zhao <[email protected]>
---

Acked-by Ori Kam <[email protected]>

Best,
Ori

Ferruh Yigit

2023-09-21 15:45 UTC #2 lore raw

Quoted 38 lines · Ori Kam

Hi Bing
Quoted 36 lines
-----Original Message-----
From: Bing Zhao <[email protected]>
Sent: Friday, August 11, 2023 5:07 PM
Subject: [RFC PATCH] ethdev: introduce NAT64 action
In order to support the communication between IPv4 and IPv6 nodes in the network, different technologies are used, like dual-stacks, tunneling and NAT64. In some IPv4-only clients, it is hard to deploy new software and hardware to support IPv6.
NAT64 is a choice and it will also reduce the unnecessary overhead of the traffic in the network. The NAT64 gateways take the responsibility of the packet headers translation between the IPv6 clouds and IPv4-only clouds.
This action should support the offloading of the IP headers' translation. The following fields should be reset correctly in the translation.
- Version
- Traffic Class / TOS
- Flow Label (0 in v4)
- Payload Length / Total length
- Next Header
- Hop Limit / TTL
Since there are different mapping and translating modes of the addresses, it will depend on the capabilities of each vendor.
The ICMP* and transport layers protocol is out of the scope of NAT64 rte_flow action.
Reference links:
- https://datatracker.ietf.org/doc/html/rfc6146
- https://datatracker.ietf.org/doc/html/rfc6052
- https://datatracker.ietf.org/doc/html/rfc6145

Quoted 5 lines

Quoted 2 lines
Signed-off-by Bing Zhao <[email protected]>
---
Acked-by Ori Kam <[email protected]>

Hi Bing,

This is a RFC, but we are not having more comment & objection, so what do you think to continue with a patch including testpmd implementation?

Ferruh Yigit

2023-10-10 09:55 UTC #3 lore raw

Quoted 42 lines · Ferruh Yigit

Quoted 41 lines · Ori Kam
Hi Bing
Quoted 38 lines
-----Original Message-----
From: Bing Zhao <[email protected]>
Sent: Friday, August 11, 2023 5:07 PM
Subject: [RFC PATCH] ethdev: introduce NAT64 action
In order to support the communication between IPv4 and IPv6 nodes in the network, different technologies are used, like dual-stacks, tunneling and NAT64. In some IPv4-only clients, it is hard to deploy new software and hardware to support IPv6.
NAT64 is a choice and it will also reduce the unnecessary overhead of the traffic in the network. The NAT64 gateways take the responsibility of the packet headers translation between the IPv6 clouds and IPv4-only clouds.
This action should support the offloading of the IP headers' translation. The following fields should be reset correctly in the translation.
- Version
- Traffic Class / TOS
- Flow Label (0 in v4)
- Payload Length / Total length
- Next Header
- Hop Limit / TTL
Since there are different mapping and translating modes of the addresses, it will depend on the capabilities of each vendor.
The ICMP* and transport layers protocol is out of the scope of NAT64 rte_flow action.
Reference links:
- https://datatracker.ietf.org/doc/html/rfc6146
- https://datatracker.ietf.org/doc/html/rfc6052
- https://datatracker.ietf.org/doc/html/rfc6145
Signed-off-by Bing Zhao <[email protected]>
---

Quoted 9 lines

Quoted 2 lines
Acked-by Ori Kam <[email protected]>
Hi Bing,
This is a RFC, but we are not having more comment & objection, so what do you think to continue with a patch including testpmd implementation?

Hi Bing, what is the latest status of the patch?

Bing Zhao

author

2023-11-28 15:21 UTC #4 lore raw

Hi Ferruh,

The full patch set will be sent for the coming 24.03 release.

Thank you.

Quoted 58 lines

-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Tuesday, October 10, 2023 5:56 PM
To: Ori Kam <[email protected]>; Bing Zhao <[email protected]>; NBU- Contact-Thomas Monjalon (EXTERNAL) <[email protected]>; [email protected]
Cc: [email protected]
Subject: Re: [RFC PATCH] ethdev: introduce NAT64 action
External email: Use caution opening links or attachments
Quoted 45 lines · Ferruh Yigit
Quoted 43 lines · Ori Kam
Hi Bing
Quoted 31 lines
-----Original Message-----
From: Bing Zhao <[email protected]>
Sent: Friday, August 11, 2023 5:07 PM
Subject: [RFC PATCH] ethdev: introduce NAT64 action
In order to support the communication between IPv4 and IPv6 nodes in the network, different technologies are used, like dual-stacks, tunneling and NAT64. In some IPv4-only clients, it is hard to deploy new software and hardware to support IPv6.
NAT64 is a choice and it will also reduce the unnecessary overhead of the traffic in the network. The NAT64 gateways take the responsibility of the packet headers translation between the IPv6 clouds and IPv4-only clouds.
This action should support the offloading of the IP headers' translation. The following fields should be reset correctly in the translation.
- Version
- Traffic Class / TOS
- Flow Label (0 in v4)
- Payload Length / Total length
- Next Header
- Hop Limit / TTL
Since there are different mapping and translating modes of the addresses, it will depend on the capabilities of each vendor.
The ICMP* and transport layers protocol is out of the scope of NAT64 rte_flow action.
Quoted 7 lines
Reference links:
- https://datatracker.ietf.org/doc/html/rfc6146
- https://datatracker.ietf.org/doc/html/rfc6052
- https://datatracker.ietf.org/doc/html/rfc6145
Signed-off-by Bing Zhao <[email protected]>
---
Acked-by Ori Kam <[email protected]>

Quoted 8 lines

Quoted 6 lines
Hi Bing,
This is a RFC, but we are not having more comment & objection, so what do you think to continue with a patch including testpmd implementation?
Hi Bing, what is the latest status of the patch?

BR. Bing