Ooops. Sorry about that I missed it. Thanks for pointing this out!
I will send a patch soon to update the NEWS and . It does make sense to add the OVS release version for them as well. I'm not sure why we weren't doing it beforehand ... -- Alin. -----Original Message----- From: Ilya Maximets <i.maxim...@ovn.org> Sent: Monday, April 25, 2022 8:33 PM To: Alin-Gabriel Serdean <aserd...@ovn.org>; 'ldejing' <svc.ovs-commun...@vmware.com>; d...@openvswitch.org Cc: 'ldejing' <ldej...@vmware.com>; i.maxim...@ovn.org Subject: Re: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack support on Windows. On 4/22/22 11:32, Alin-Gabriel Serdean wrote: > Applied on master. Thank you for working on the feature! Thanks, Alin, for taking care of these patches! Could you, please, fix the NEWS file though? The change there doesn't look correct to me. The new section got added for some reason. And maybe we should also add a NEWS entry for the previous change "IPv6 Geneve" along the way? And another question: I see that in the docs it's just stated "YES" for Windows datapath features support, while on other columns we have versions specified. Do you think it makes sense to specify 2.18 as a release version for these 2 new features? Best regards, Ilya Maximets. > > -----Original Message----- > From: dev <ovs-dev-boun...@openvswitch.org> On Behalf Of ldejing > Sent: Monday, April 11, 2022 10:18 AM > To: d...@openvswitch.org > Cc: ldejing <ldej...@vmware.com> > Subject: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack > support on Windows. > > From: ldejing <ldej...@vmware.com> > > Implementation on Windows: > Currently, IPv4 conntrack was supported on the windows platform. > In this patch we have implemented ipv6 conntrack functions according > to the current logic of the IPv4 conntrack. This implementation has > included TcpV6(nat and normal scenario), UdpV6(nat and normal > scenario), > IcmpV6 conntrack of echo request/reply packet and FtpV6(nat and normal > scenario). > > Testing Topology: > On the Windows VM runs on the ESXi host, two hyper-v ports attached to > the ovs bridge; one hyper-v port worked as client and the other port > worked as server. > > Testing Case: > 1. TcpV6 > a) Tcp request/reply conntrack for normal scenario. > In this scenario, 20::1 as client, 20::2 as server, it will generate > following conntrack entry: > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), > > reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=tcp) > > b) Tcp request/reply conntrack for nat scenario. > In this scenario, 20::1 as client, 20::10 as floating ip, 21::3 > as server, > it will generate following conntrack entry: > (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), > reply(src=21::3, src_port=1556, dst=20::1, dst_port= > 1555),protocol=tcp) > > 2. UdpV6 > a) Udp request/reply conntrack for normal scenario. > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), > reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=udp) > b) Udp request/reply conntrack for nat scenario. > (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), > reply(src=21::3, src_port=1556, dst=20::1, dst_port= > 1555),protocol=udp) > > 3. IcmpV6: > a) Icmpv6 request/reply conntrack for normal scenario. > Currently Icmpv6 only support to construct conntrack for > echo request/reply packet, take (20::1 -> 20::2) for example, > it will generate following conntrack entry: > (origin(src = 20::1, dst=20::2), reply(src=20::2, dst=20::1), > protocol=icmp) > b) Icmp request/reply conntrack for dnat scenario, > for example (20::1->20::10->21::3), 20::1 is > client, 20::10 is floating ip, 21::3 is server ip. > It will generate flow like below: > (origin(src=20::1, dst=20::10), reply(src=21::3, dst=20::1), > protocol=icmp) > > 4. FtpV6 > a) Ftp request/reply conntrack for normal scenario. > In this scenario, take 20::1 as client, 20::2 as server, it will > generate > two conntrack entries: > Ftp active mode > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), > reply(src=20::2, src_port=21, dst=20::1, dst_port=1555), protocol=tcp) > (Origin(src=20::2, src_port=20, dst=20::1, dst_port=1556), > reply(src=20::1, src_port=1556, dst=20::2, dst_port=20), > protocol=tcp) > > Ftp passive mode > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), > reply(src=20::2,src_port=21,dst=20::1,dst_port=1555),protocol=tcp) > (Origin(src=20::1, src_port=1556, dst=20::2, dst_port=1557), > reply(src=20::2,src_port=1557, dst=20::1, dst_port=1556) > protocol=tcp) > > b) Ftp request/reply conntrack for nat scenario. > Ftp passive mode, > In this secnario, 20::1 as client, 20::10 as floating ip, 21::3 > as server > ip. It will generate following flow: > (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=21), > reply(src=21::3, src_port=21, dst=20::1, dst_port= 1555),protocol=tcp) > (Origin(src=20::1, src_port=1556, dst=20::10, dst_port=1557), > reply(src=21::3, src_port=1557, dst=20::1, dst_port= > 1556),protocol=tcp) > > 5. Regression test for IpV4 in Antrea project (about 60 test case) > > Future work: > 1) IcmpV6 redirect packet conntrack. > 2) IpV6 fragment support on Udp. > 3) Support napt for IPv6. > 4) FtpV6 active mode for nat. > > Signed-off-by: ldejing <ldej...@vmware.com> > > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
