If you're setting up the ISP, you probably choose the CPE.
If you don't find a commercial solution that supports the CLAT (because you may be too small for asking the feature), you need to consider buying cheap CPEs of your choice, and installing OpenWRT with the CLAT, which will solve all your problems. This way you don't need to look into "exotic" solutions, because a single solution works for all. Only in the case a customer wants to have a static IPv4, and pay for it, then you assign "real" dual-stack to that customer, instead of 464XLAT. We have already done this for several ISPs. This is in line with the other document I'm working on, and going to last-call in v6ops next week, hopefully: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Regards, Jordi -----Mensaje original----- De: <jool-list-boun...@nic.mx> en nombre de Petre Tudor <petre.tu...@cte.ro> Fecha: sábado, 11 de agosto de 2018, 15:25 Para: <email@example.com> Asunto: Re: [Jool-list] jool setup Hello Aberto, Jordi many thanks for the quick and detailed answers @Alberto - actually the resources usage was the next question, but you answered already; it looks like I found the software which does what I need, the rest is in the details of the implementation. @Jordi - the whole idea is thought for the residential users of an emerging isp, as an attempt to minimise the ipv4 usage and also to easily implement ipv6; the idea is in the early stages, but I imagine something like a linux gateway running jool in front of an ipv6-only network (ip's are assigned via pppoe), through which all uses exit; those visiting ipv6 sites, go directly and those requesting ipv4-only sites will be nat64-ed. I am fully aware that a solution which covers 100% of the possible cases is utopic, but I am happy if I can cover the normal cases; for the "exotic" ones I could always assign an ipv4 via the dual stack pppoe and solve the problem (these being the exceptions and not the rule) many thanks again for answering so quick on a saturday evening, cheers, petre On 8/11/2018 21:27, Alberto Leiva wrote: > These don't really address your first question directly, but might > serve as a reference point. They are everything I managed to collect > that is both public and refers to performance: > > (https://mail-lists.nic.mx/pipermail/jool-list/2018-July/000199.html) > First off, you're definitively not hitting the performance limit of Jool - it > easily scales to multiple Gb/s of throughput. There must be something else > that is causing your issues. > > (https://mail-lists.nic.mx/pipermail/jool-list/2017-October/000158.html) > Jool, even 3.5.4 Jool, withstands T-Rex's torture traffic without > flinching. There are no significant performance issues to worry about. CPU > usage is at 1% at worst and there are no packet drops. > ... > I can now say fairly confidently that Jool is pretty darn > fast, even without the latest performance tweaks applied, as evidenced from > the fact that, now that whatever was hobbling before is gone, it is pretty > clear that Jool can keep up to at least this configuration of T-Rex with > flying colors. > > (https://mail-lists.nic.mx/pipermail/jool-list/2016-September/000091.html) >> What is the CPU load on the x86 SIIT-BRs from Jool? > Our are practically idle. They are translating about 100Mb/s of mostly > web traffic. The hardware is quite old even, Sun X4170s with 2x > quad-core Intel L5520 CPUs. Less than a quarter of a single CPU core is > used for the entire system (so not only Jool), the remaining 7.75 CPU > cores are idle. > > -------- > > BTW: We're currently working on a performance bug that affects packets > that never traverse physical interfaces: > https://github.com/NICMx/Jool/issues/267 > On Sat, Aug 11, 2018 at 1:50 PM Alberto Leiva <ydah...@gmail.com> wrote: >>> is the setup above feasible for networks with several thousand users >>> (between 5-10k) >> Performance-wise, as a developer, I don't really have a means to test >> that level of traffic. Maybe somebody else in the list has that >> information. >> >> Functionality-wise though, Jool won't stop you. Just make sure that >> you have enough IPv4 transport addresses to mask all of that. >> >> Also, I'd suggest that you keep a decent understanding of this: >> https://jool.mx/en/usr-flags-pool4.html#--max-iterations >> >>> is there a latency induced for throughputs of more than a gb ? >> Not that I know of. (Why would that happen?) >> >>> exists the possibility of defining a pool of ipv4 addresses when >>> nat64-ing and not doing 1-to-1 specific rules ? >> Yes: https://jool.mx/en/pool4.html >> On Sat, Aug 11, 2018 at 1:35 PM Petre Tudor <petre.tu...@cte.ro> wrote: >>> hello >>> >>> i am trying to minimize the usage of the ipv4 addresses by assigning to >>> the users only ipv6 and nat64-ing them to the internet. (the final goal >>> would be to assign routable ipv4 only to those users who really need >>> them and pay them as an extra service; the normal users who don't have >>> specific requirements will only receive an ipv6 address and get nat64 >>> for the only-ipv4 destinations. >>> >>> before i start i have a few questions regarding the jool features >>> (please excuse if they are too trivial, I am new in this knowledge area): >>> >>> - is the setup above feasible for networks with several thousand users >>> (between 5-10k) >>> >>> - is there a latency induced for throughputs of more than a gb ? >>> >>> - exists the possibility of defining a pool of ipv4 addresses when >>> nat64-ing and not doing 1-to-1 specific rules ? >>> >>> >>> thanks, >>> >>> >>> petre >>> >>> _______________________________________________ >>> Jool-list mailing list >>> Joolfirstname.lastname@example.org >>> https://mail-lists.nic.mx/listas/listinfo/jool-list _______________________________________________ Jool-list mailing list Joolemail@example.com https://mail-lists.nic.mx/listas/listinfo/jool-list ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. _______________________________________________ Jool-list mailing list Joolfirstname.lastname@example.org https://mail-lists.nic.mx/listas/listinfo/jool-list