You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

IPv6 Working Group

Threaded
Collapse

[ipv6-wg] Its that time of the year...

Yannis Nikolopoulos

2019-11-29 11:47:10 CET

...when we're starting to deploy yet another IPv6-only technology :)

Hello all,

as a fairly large ISP (for Greek standards at least), we've been 
affected by IPv4 exhaustion for quite some time now. A few years back we 
gave LW4o6 a go, as documented here 
https://ripe76.ripe.net/presentations/11-lw4o6-deployment-as6799.pdf . 
In the end, it did not work out very well. Quoting myself (from v6ops 
mailing list), the reasons behind that were:
"In no particular order:

1. CPE (almost OK after ~2 years and god knows how many iterations)
2. lwaftr performance (worth noting the the lwaftr is implemented as a VNF
3. vendor's reluctance to continue (much needed) dev/ment because of 
*lack of interest from other ISPs* "

Please take extra note of (3).

In any case, being the optimists we are, and having supportive mgmt, we 
decided (once more) against burying ourselves deeper into CGN. This time 
we're going with MAP-E (which incidentally was our first choice), mainly 
because we understand it and our MAP BR vendor does too :) .

So, as I already mentioned, we're just about to deploy it commercially. 
We've tested with 2 CPE vendors sucessfully and we're just ironing out 
some provisioning details before launching. Deployment will be gradual 
of course and very very cautious.

Unofficially, we are aware of a couple of similar trials from other ISPs 
and we'd love to hear about people who have already deployed such 
technologies (IPv6-only with IPv4aas) or are thinking about doing so. 
After all, that is exactly what this WG is about :)

thanks for reading,
Yannis

User Image

Jordi Palet Martinez

2019-11-29 11:53:41 CET

Hi Yannis,

Taking advantage of your email and IPv4aaS transition mechanisms ...

I will remind all that you should keep insisting your CE vendors to make sure to comply with RFC8585.

https://datatracker.ietf.org/doc/rfc8585/

One more related document (finally published this week) is RFC8683:

https://datatracker.ietf.org/doc/rfc8683/



Regards,
Jordi
@jordipalet
 
 

El 29/11/19 11:47, "ipv6-wg en nombre de Yannis Nikolopoulos" <ipv6-wg-bounces _at_ ripe _dot_ net en nombre de dez _at_ otenet _dot_ gr> escribió:

    ...when we're starting to deploy yet another IPv6-only technology :)
    
    Hello all,
    
    as a fairly large ISP (for Greek standards at least), we've been 
    affected by IPv4 exhaustion for quite some time now. A few years back we 
    gave LW4o6 a go, as documented here 
    https://ripe76.ripe.net/presentations/11-lw4o6-deployment-as6799.pdf . 
    In the end, it did not work out very well. Quoting myself (from v6ops 
    mailing list), the reasons behind that were:
    "In no particular order:
    
    1. CPE (almost OK after ~2 years and god knows how many iterations)
    2. lwaftr performance (worth noting the the lwaftr is implemented as a VNF
    3. vendor's reluctance to continue (much needed) dev/ment because of 
    *lack of interest from other ISPs* "
    
    Please take extra note of (3).
    
    In any case, being the optimists we are, and having supportive mgmt, we 
    decided (once more) against burying ourselves deeper into CGN. This time 
    we're going with MAP-E (which incidentally was our first choice), mainly 
    because we understand it and our MAP BR vendor does too :) .
    
    So, as I already mentioned, we're just about to deploy it commercially. 
    We've tested with 2 CPE vendors sucessfully and we're just ironing out 
    some provisioning details before launching. Deployment will be gradual 
    of course and very very cautious.
    
    Unofficially, we are aware of a couple of similar trials from other ISPs 
    and we'd love to hear about people who have already deployed such 
    technologies (IPv6-only with IPv4aas) or are thinking about doing so. 
    After all, that is exactly what this WG is about :)
    
    thanks for reading,
    Yannis
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.





User Image

Jan Zorz

2019-12-01 20:16:50 CET

On 29/11/2019 11:47, Yannis Nikolopoulos wrote:
> A few years back we gave LW4o6 a go. In the end, it did not work out very well. 

I think that you might be much happier with MAP-E as it is stateless and 
keeps NAT at the right place (CPE).

No matter how hard you try, at the end of the day LW4o6 is still 
stateful mechanism.

Please, keep us in sync how the deployment is going.

Just out of curiosity - how many ports per CPE did you configure?

Cheers, Jan

User Image

Jan Zorz

2019-12-02 13:45:11 CET

On 01/12/2019 20:57, Ole Troan wrote:
>> No matter how hard you try, at the end of the day LW4o6 is still
>> stateful mechanism.
> 
> Just make sure there are no misunderstandings. MAP-E and LW46 both
> have the same NAT placement (at the CPE). A MAP-E implementation can
> implement LW46 by supporting a MAP rule per subscriber. So it’s more
> correct to say that LW46 has per-user configured state, and that
> MAP-E can aggregate this configured state into a few rules covering
> the whole domain. Both are stateless, in contrast to a NAT that has
> state per session.

Ya, you are right. Got confused for a millisecond with dslight ;) Too 
many things going on right now. My bad.

As far as I remember - LW4o6 is useful in cases where you don't have one 
huge IPv4 block of addresses to assign to the transition mechanism 
and/or where you want to dynamically assign additional ports to the CPE 
if it runs out of it.

If none of this is a requirement, then MAP-E/T should be the way to go.

Do we have any experiments/deployments of 464XLAT in fixed networks? 
CLAT in CPE and NAT64 in the core?

Cheers, Jan

Yannis Nikolopoulos

2019-12-02 17:34:19 CET

Hi Jan,

On 12/1/19 9:16 PM, Jan Zorz - Go6 wrote:
> On 29/11/2019 11:47, Yannis Nikolopoulos wrote:
>> A few years back we gave LW4o6 a go. In the end, it did not work out 
>> very well. 
> 
> I think that you might be much happier with MAP-E as it is stateless and 
> keeps NAT at the right place (CPE).

I think so too. If CPE issues do not arise, we're hoping that the BR 
performance will be satisfying.

> No matter how hard you try, at the end of the day LW4o6 is still 
> stateful mechanism.
> Please, keep us in sync how the deployment is going.
> 
> Just out of curiosity - how many ports per CPE did you configure?

1008 ports

> Cheers, Jan

cheers,
Yannis