On 26 January 2015 at 07:52:59, Brian E Carpenter (firstname.lastname@example.org(mailto:email@example.com)) wrote:
> On 25/01/2015 22:33, Ben wrote:
> >> CGN will not save you, and will add significant capital and operational cost
> >> to any ISP, regardless of technology chosen.
> > There's not much choice if more IPv4 addresses aren't available. If you run out
> > of IP addreses you need CGN regardless of whether you have IPv6 support or not,
> > and IPv6 may decrease the load on the CGN but not remove the necessity of such.
> Agreed (http://tools.ietf.org/html/rfc6264).
> This also seems to be why 464XLAT (http://tools.ietf.org/html/rfc6877)
> is attracting a lot of attention. Since consumer IPv4 is in practice
> a translated service today, just provide it as a translated service
> running over an IPv6 substrate.
464XLAT is, from what I can see, impacted by the same flaws as DS-Lite. I haven’t followed it as closely as I did DS-Lite though, I’ll admit.
My understanding is that both require support on CPE, and neither reduce the CGN requirements in the ISP.
The benefit seems to be that you only need to run IPv6 in your access network.
I’d be surprised if any providers in NZ have so much trouble running dual stack that running v6 only is worth having to have CPE support.
The hard bit about NZ is that a large number of people own their own CPE, so upgrading software/replacing them with devices with support for new protocols is hard. If you decide to roll 464XLAT or DS-Lite, you have an interim state where you have some customers on the current native v4, and some on the translated/tunnelled v4. How long that interim state persists is anyone’s guess, and certainly sounds more complicated than just running v6 along side your existing native v4.
464XLAT might have a way to solve that better than DS-Lite, but like I say, I’m not super well versed so corrections are welcome.