LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: [PATCH] ipvs: fix ipv6 icmp forwarding in natted services

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: [PATCH] ipvs: fix ipv6 icmp forwarding in natted services
Cc: Art -kwaak- van Breemen <ard@xxxxxxxxxxxxxxx>, Ansis Atteka <aatteka@xxxxxxxxxx>, lvs-devel@xxxxxxxxxxxxxxx, Jesper Dangaard Brouer <brouer@xxxxxxxxxx>, Patrick McHardy <kaber@xxxxxxxxx>
From: Hans Schillstrom <hans@xxxxxxxxxxxxxxx>
Date: Fri, 21 Feb 2014 06:46:41 +0100
Hello

On Fri, 2014-02-21 at 00:17 +0200, Julian Anastasov wrote:
>       Hello,
> 
> On Thu, 20 Feb 2014, Art -kwaak- van Breemen wrote:
> 
> > I ack the working of that change for my specific case: passing
> > pmtud's correctly:
> > Feb 20 18:58:59 c43236 kernel: [  721.473388] IPVS: Enter: 
> > ip_vs_icmp_xmit_v6, net/netfilter/ipvs/ip_vs_xmit.c line 1186
> > Feb 20 18:58:59 c43236 kernel: [  721.473389] IPVS: Enter: 
> > ip_vs_nat_icmp_v6, net/netfilter/ipvs/ip_vs_core.c line 738
> > Feb 20 18:58:59 c43236 kernel: [  721.473390] IPVS: 
> > icmp_offset=40,protocol=58
> > Feb 20 18:58:59 c43236 kernel: [  721.473391] IPVS: ip_vs_nat_icmp_v6() 
> > changed port 80 to 80
> > Feb 20 18:58:59 c43236 kernel: [  721.473393] IPVS: Leave: 
> > ip_vs_nat_icmp_v6, net/netfilter/ipvs/ip_vs_core.c line 786
> > Feb 20 18:58:59 c43236 kernel: [  721.473396] IPVS: Leave: 
> > ip_vs_icmp_xmit_v6, net/netfilter/ipvs/ip_vs_xmit.c line 1263
> > 
> > and:
> > 18:58:59.067282 00:23:24:26:b4:5c > 00:23:24:26:b4:34, ethertype IPv6 
> > (0x86dd), length 1294: 2001:7b8:2ff:6f::1 > 2a02:310:0:1013::1003: ICMP6, 
> > packet too big, mtu 1472, length 1240
> > 
> > So the "|| found" sounds sane.
> 
>       Thanks for the confirmation. Then may be Hans
> can post a fix for this problem after checking the callers
> of ipv6_find_hdr.

I'll do that.

> 
> > But now I'm going to be an ass by saying that maybe both patches must be
> > applied because we only get into ip_vs_nat_icmp_v6 by ip_vs_fill_iph_skb in
> > include/net/ip_vs.h, which determines the protocol and the start of the
> > protocol header by using -1 as target in ipv6_find_hdr.
> > Actually, before we reach that nat function we have traversed several 
> > constructs of:
> > protocol,offset = ipv6_find_hdr (target = -1 )
> > if ( protocol != IPPROTO_ICMPV6)
> >   bail out (return NF_ACCEPT actually) .
> 
>       Yes, it is not expected, the protocol was
> already validated. May be we will save some cycles
> without such check...

We will save some cycles here, very few actually..
I'm not sure about the mobility header if it can break this.
Have not read the RFC :-)

The -1 is OK for me right now

> > (and maybe use offset)
> > 
> > So I think it's clearer for the total code if we follow the exact same 
> > construct:
> > find a protocol, bail out if protocol wrong.
> > It should never happen at that point, but there are more things that never
> > should happen :-).
> > 
> > Anyway: whatever you guys decide, I owe you all beer. I think we are one of 
> > the
> > few companies that assume a working pmtud for ipv6. Most of the top 
> > companies
> > just use an mtu of 1280 because the "hardware" loadbalancer cannot handle it
> > (yet) or just want to prevent the hassle. Thanks!
> > 
> > Regards,
> > 
> > Ard van Breemen
> 
> Regards
> 
> --
> Julian Anastasov <ja@xxxxxx>

Regards
Hans

Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>