Re: [v6ops] Operational Consensus on deployment

[Czerwonka Michał 1 - Hurt <[e-mail]>]

Hi Nick,

If you’re saying complainat with RFC6877, you will implement DHCPv6 PD and use dedicated ipv6 prefix for CLAT?

BR,
Mcz
From: Heatley, Nick [mailto:[e-mail]]
Sent: Tuesday, August 05, 2014 5:57 PM
To: Czerwonka Michał 1 - Hurt; Ca By; Brian E Carpenter
Cc: IPv6 Ops WG; Tore Anderson; Kossut Tomasz - Hurt
Subject: RE: [v6ops] Operational Consensus on deployment

Hi all, EE similar, but not identical. We are hot on 464xlat (RFC6877), it is perfect for networks that already extensively use NAT44, and gets customers off IPv4 (both public and private, as neither is sufficient).
Regards,
Nick

From: v6ops [mailto:[e-mail]] On Behalf Of Czerwonka Michal 1 - Hurt
Sent: 05 August 2014 10:22
To: Ca By; Brian E Carpenter
Cc: IPv6 Ops WG; Tore Anderson; Kossut Tomasz - Hurt
Subject: Re: [v6ops] Operational Consensus on deployment

Hi all,

I confirm this is correct. Even we went further and we do not use DNS64. Our architecture is CLAT+NAT64+DNS. So with dns and without dns ipv4 traffic always goes via CLAT. It’s perfect solution ☺ UK EE will do the same.

See more at: http://www.data.proidea.org.pl/plnog/12edycja/day2/track4/01_ipv6_implementation.pdf

Even triple translation is not bad too: CLAT+NAT64stateless+NAT44statefull.

BR,
Mcz
Orange Poland

[cid:image003.png@01CFB0A0.62223A60]
February 1% of active PDP IPv6 ctx, now over 8%



From: v6ops [mailto:[e-mail]] On Behalf Of Ca By
Sent: Tuesday, August 05, 2014 5:10 AM
To: Brian E Carpenter
Cc: IPv6 Ops WG; Tore Anderson
Subject: Re: [v6ops] Operational Consensus on deployment


On Aug 4, 2014 1:26 PM, "Brian E Carpenter" <[e-mail]<mailto:[e-mail]>> wrote:
>
>
> > My point in bringing this up is not that it is “useful in an IPv6 network” that might also be running IPv4 in parallel. It is that it seems useful to me in moving toward and IPv6-*only* network. Ross suggests that he sees conceptual movement - First they ignore you, then they laugh at you, then they fight you, and then you win. We may, Ross suggests, be approaching stage 4. It may be useful for us as a working group to lay out the game plan for that movement - not just to document IPv6 operational practice, but to help the IETF determine whether the dual stack consensus has changed or is changing, and help operators figure out how to turn IPv4 off without individually shooting their toes off. This would be part of that game plan.
>
> Well, I think the operators that moved early into genuine dual
> stack operation have no reason to regret it. I'm a happy customer
> of one such. On the other hand it seems that other operators are of
> the opinion (probably unprovable) that providing the illusion of dual
> stack service to the customer over an IPv6 infrastructure is cheaper.
> In any case the customer ends up with NATted IPv4 service in most
> cases, so at user level it doesn't really matter.
>
> I think we should probably not express a preference either way. It
> seems like a decision for each operator to make individually. What we
> probably should do is stop inventing more solutions.
>

Why?

I was told the same thing about 464xlat, we did not need another solution. If the ietf held the line against double translation i believe there would be exactly 1 ipv6 cellular provider in the world (verizon).

With 464xlat, afaik, there are globally 3 cellular providers that offer default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ).

It does not matter if the cat is white or black, it matters that it catches mice.

CB

> (In parenthesis, I've never seen sunsetting IPv4 as a real problem.
> One day somebody will notice that there are no more IPv4 packets. But
> that is many years in the future.)
>
>     Brian
>
> _______________________________________________
> v6ops mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops