Hello,
On Wed, 18 Jul 2018 at 14:30, Willy Tarreau <w...@1wt.eu> wrote: > > Hi Tim, > > On Wed, Jul 18, 2018 at 01:48:01PM +0200, Tim Düsterhus wrote: > > This would solve the issue for my use case and should not break anything > > (a few UNKNOWNs will become TCP6 then). > > OK. > > > I can rework the patch, if technical changes look good to you. There's a > > ton of memcpy in there to not destroy the data structures needed for the > > actual communication: make_proxy_line() now always operates on a copy of > > `struct connection remote`. > > I don't see why a copy could be needed, given that you should never have > to modify anything in the source. Or maybe it's because it was more > convenient to store the remapped addresses ? In this case I think that > it's still cleaner to have two local struct sockaddr_storage that you > can use for the operations. Another option, which I *thought* we had but > am probably wrong on this, was to first check the source+destination > address classes before deciding what to emit. (or maybe it's done in the > PPv2 format) : > > if (src_is_v4 && dst_is_v4) > /* emit_v4(src, dst) */ > else if (src_is_v6 && dst_is_v6) > /* emit_v6(src, dst) */ > else if (src_is_v6 && dst_is_v4) > /* emit_v6(src, 4to6(dst)) */ > else if (src_is_v4 && dst_is_v6) > /* emit_v6(4to6(src), dst) */ > else > /* emit_unknown()*/ > > So in practice you always need only one temporary sockaddr_storage for > a conversion. > > I'm personally fine with something roughly like this. Lukas, I'm interested > in your opinion on this one, as I *think* it addresses the issues without > introducing new ones. However if I read the pseudo-code correctly, we will still transform a v4 src to v6 src, when the destination is v6? I don't like transforming the address family at all - but I realize the proxy protocol needs a single AF for both source and destination, which means we need to compromise and the proposed solution is the best compromise as far as I can see. Agreed. cheers, lukas
