[RFC] ethdev: introduce NAT64 action
Checks
Commit Message
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 <bingz@nvidia.com>
---
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 27 +++++++++++++++++++++++++++
2 files changed, 28 insertions(+)
Comments
Hi Bing
> -----Original Message-----
> From: Bing Zhao <bingz@nvidia.com>
> 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 <bingz@nvidia.com>
> ---
Acked-by: Ori Kam <orika@nvidia.com>
Best,
Ori
On 9/19/2023 11:05 AM, Ori Kam wrote:
> Hi Bing
>
>> -----Original Message-----
>> From: Bing Zhao <bingz@nvidia.com>
>> 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 <bingz@nvidia.com>
>> ---
>
> Acked-by: Ori Kam <orika@nvidia.com>
>
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?
On 9/21/2023 4:45 PM, Ferruh Yigit wrote:
> On 9/19/2023 11:05 AM, Ori Kam wrote:
>> Hi Bing
>>
>>> -----Original Message-----
>>> From: Bing Zhao <bingz@nvidia.com>
>>> 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 <bingz@nvidia.com>
>>> ---
>>
>> Acked-by: Ori Kam <orika@nvidia.com>
>>
>
> 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?
Hi Ferruh,
The full patch set will be sent for the coming 24.03 release.
Thank you.
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Tuesday, October 10, 2023 5:56 PM
> To: Ori Kam <orika@nvidia.com>; Bing Zhao <bingz@nvidia.com>; NBU-
> Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> andrew.rybchenko@oktetlabs.ru
> Cc: dev@dpdk.org
> Subject: Re: [RFC PATCH] ethdev: introduce NAT64 action
>
> External email: Use caution opening links or attachments
>
>
> On 9/21/2023 4:45 PM, Ferruh Yigit wrote:
> > On 9/19/2023 11:05 AM, Ori Kam wrote:
> >> Hi Bing
> >>
> >>> -----Original Message-----
> >>> From: Bing Zhao <bingz@nvidia.com>
> >>> 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 <bingz@nvidia.com>
> >>> ---
> >>
> >> Acked-by: Ori Kam <orika@nvidia.com>
> >>
> >
> > 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
@@ -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
@@ -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.
*