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: <jool-list@nic.mx>

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

    >>> Jool-list@nic.mx

    >>> https://mail-lists.nic.mx/listas/listinfo/jool-list

    

    _______________________________________________

    Jool-list mailing list

    Jool-list@nic.mx

    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
Jool-list@nic.mx
https://mail-lists.nic.mx/listas/listinfo/jool-list

Reply via email to