From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 895873B260; Sun, 3 Jul 2016 17:12:14 -0400 (EDT) Received: from [10.136.200.16] ([95.91.196.93]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MDhGw-1b606U205O-00H5Uf; Sun, 03 Jul 2016 23:12:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Sun, 3 Jul 2016 23:12:11 +0200 Cc: cake@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <57501404.5010704@darbyshire-bryant.me.uk> <6A7C70EE-906E-4624-A84A-645ED4530A07@gmail.com> <5774E766.2050302@darbyshire-bryant.me.uk> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:NJwijf5bLZblDl8DeyCqQpq5TLvyyUxGzAJZFlSeI3s/gB/o9UO x/5GCqrNIo5i0F3xfxRW4KOrvXIURisU5syDi7cyqKrvcO4k3B1Nrt5vyILEWCWuefVJnaI 3dVcywM98QmTuRquWdHVwKfokNOKwtvl64qRIlyyks+JbC+mTV2gLSUjyIygOhlJKnMltCF DNEihBKpsd73PGVW/vhCw== X-UI-Out-Filterresults: notjunk:1;V01:K0:p8j/YHShpZA=:7J2RypW4cr08QUNVUS94Bf jZ5fuBFJHmysPaosvrZpeLkRRI4Z6WZqoBAcjJGWFgAAzyka4+6rQb6cIFVqRRsfi5kKmx7eU wg3DbJaKP54IsYEr1FY/bYfeHb7t9q7MrlaR7WmdNOI6+Kx4DY5+QAyO8aqhEHKFHRxnBNkw0 EHd1YJcW7SaHE05+Zm2xYLJ7Fi4uFMcDhw07DibD1IHKau7ah+l+guhOPfUEe170WsKlguLNy b/vklWgeaGFddi4vTJ2Jzuc0hEGHfKCiiIg4f9GH6MC0D7D3zHbjE0KFhgSA7wols6W52YIQg afwU+rRNejUq3w+u5wRVO9P8Mps72x5MeGize/aujmSkemW3RJU5jq8C+AEs9FP/ZmutaE5kX cKgXW1jxq4/Z/ac+7735rC3Gcm+K6p6A1w+x7rWgihgCoj/pu87jcRlGX9s66Ubf1RaYL0Gh4 mdAxS/WQaRk7swYNghAv1HUFyH1kIg/20xO2W9iE3ilNtsD5fugxAWEMwxSwKuevt9GDbtanv N0sn4ga0uehBq/f0JPWMfxQzLCRWqe/lS3zyORXjF/JElU2qaKf99hYIpvxQVZw9OBqgCW+YA 6cT5JrR5XaAcUoyyVerlpL7PYaXnSFxOfrzBiABBXLAkTfMvLl4MpyRxQdKQbF9rQ6Y4FJP+r L+3ZQUXZRRTn9lslllJSkhB100gXfILbsevEM8LRowygwqZ40SmfXFyU6xxIUVG295IbRbdq8 S3pOPdcHqLGWpkf0E2CO2UxoMr25z3KtWd/Lneke23Zv5/nUd18XDyLpPQhp2UN+42EjWxAtJ VvuYRFw Subject: Re: [Cerowrt-devel] conntrack and ipv6 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 21:12:14 -0000 Hi Dave, > On Jul 2, 2016, at 14:47 , Dave T=C3=A4ht wrote: >=20 > It is generally my hope that ipv6 nat will not be widely deployed. I checked a few RFCs and both NAT66 = (https://tools.ietf.org/html/draft-mrw-behave-nat66-02) or NPTv6 = (https://tools.ietf.org/html/rfc6296) only seem to change the = prefix-part while maintaining the last 64 bit of IPv6 addresses so that = cake will see different (somewhat) stable IPv6 addresses (probably just = as stable as IPv6 privacy addresses can be), so internal-IP fairness = should not require conntrack at all. They also thankfully leave the port = numbers alone, maening that neither udp nor tcp headers typically need = to be touched, nice=E2=80=A6 Now, if someone should come up with NATv6/128 that hides all = internal addresses behind a single /128 and does the old port remapping = song and dance, I believe that person should be entitled to keep all the = pieces=E2=80=A6 >=20 > Firewalls will be stateful instead, and thus there would be no need to > access the conntrack information for ipv6 in cake. >=20 > I'm not sure, however, to > what extent ipv6 conntrack is in openwrt today, certainly udp and tcp, > "in" is essentially blocked by default, and needs to be triggered by = an > outgoing message. Similarly I'm unfamiliar with the state of ipv6 upnp > and pcp support in openwrt or client applications at present. >=20 >=20 > On 6/30/16 10:33 AM, Kevin Darbyshire-Bryant wrote: >>=20 >>=20 >> On 02/06/16 13:29, Jonathan Morton wrote: >>>> On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant >>>> wrote: >>>>=20 >>>> Cake uses the flow dissector API to do flow hashing...including per >>>> host flows for dual/triple isolation. The unfortunate bit is that >>>> the qdisc inevitably gets placed after packets have been NATed on >>>> egress and before they've been de-NATed on ingress. >>>>=20 >>>> When mentioned before Johnathan said "flow dissector ideally needs = to >>>> be tweaked to do this" or words to that effect. >>>>=20 >>>> I'd like to progress that idea...the thought of me kernel = programming >>>> should horrify everyone but really I'm asking for help in being >>>> pointed in the right direction to ask for help...and go from there = :-) >>> I believe Linux does NAT using a =E2=80=9Cconnection tracker=E2=80=9D = subsystem. That >>> would contain the necessary data for resolving NAT equivalents. I >>> don=E2=80=99t know how easy it is to query in a qdisc context, = though. >> Imagine my joy of discovering http://fatooh.org/esfq-2.6/ - someone = has >> already bl**dy done it....and I found it lurking in LEDE as part of a >> patch. >>=20 >> So there relevant bits are something of the order: >>=20 >>=20 >> +#ifdef CONFIG_NET_SCH_ESFQ_NFCT >> + enum ip_conntrack_info ctinfo; >> + struct nf_conn *ct =3D nf_ct_get(skb, &ctinfo); >> +#endif >>=20 >> +#ifdef CONFIG_NET_SCH_ESFQ_NFCT >> + /* defaults if there is no conntrack info */ >> + info.ctorigsrc =3D info.src; >> + info.ctorigdst =3D info.dst; >> + info.ctreplsrc =3D info.dst; >> + info.ctrepldst =3D info.src; >> + /* collect conntrack info */ >> + if (ct && ct !=3D &nf_conntrack_untracked) { >> + if (skb->protocol =3D=3D __constant_htons(ETH_P_IP)) = { >> + info.ctorigsrc =3D >> ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u3.ip; >> + info.ctorigdst =3D >> ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.ip; >> + info.ctreplsrc =3D >> ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip; >> + info.ctrepldst =3D >> ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip; >> + } >> + else if (skb->protocol =3D=3D = __constant_htons(ETH_P_IPV6)) { >> + /* Again, hash ipv6 addresses into a single = u32. */ >> + info.ctorigsrc =3D >> jhash2(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u3.ip6, 4, >> q->perturbation); >> + info.ctorigdst =3D >> jhash2(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.ip6, 4, >> q->perturbation); >> + info.ctreplsrc =3D >> jhash2(ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip6, 4, >> q->perturbation); >> + info.ctrepldst =3D >> jhash2(ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip6, 4, >> q->perturbation); >> + } >> + >> + } >> +#endif >>=20 >> I'd rip out the IPv6 conntrack stuff as I'm much more concerned by >> handling IPv4 NAT. And I'm not sure how to get it into cake's host >> handling yet but.... >>=20 >> I can feel an experiment and hackery coming on later today :-) >>=20 >> Am overjoyed! >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel