I'm not a big fan of any of those mechanisms, but I think that 464XLAT
makes some sense when used the way T-Mobile's done it, with Android
tablets/handsets they controlled.
This was an interesting podcast about it:
On Tue, Jan 27, 2015 at 4:01 PM, Nathan Ward <nznog(a)daork.net> wrote:
On 26 January 2015 at 07:52:59, Brian E Carpenter (
On 25/01/2015 22:33, Ben wrote:
>> CGN will not save you, and will add significant capital and
>> to any ISP, regardless of technology
> 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
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
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.
NZNOG mailing list