Re: Is NAT66 a help in migration to IPv6?

[[e-mail]]

> Answering the question in the subject field: No [RFC2993] [RFC4864] [RFC6296].
> 
>> IMHO: no NAT66 -> no progress for IPv6 in Enterprises. Because redundant connectivity to Carriers is needed very often.
> 
> It is, and that's why the failure of SHIM6 is very sad. But the real failure is the reluctance of enterprise operators to do what comes naturally in IPv6: if you have two providers, run two prefixes everywhere [RFC8028]. That's why there is still, sadly enough, a case for [RFC6296]. Sadly, because [RFC2993] explains why NAT or NPT is a problem, and [RFC4864] explains how to avoid them (and needs [RFC8028], which came very late, sorry).


The failure of SHIM6 or ILNP or even 8+8 is indeed sad.
MPMH hasn't exactly taken off. I ran it for a while but gave up. 8028 isn't enough, SADR is a big change.
Enterprises don't want to depend on host behaviour for exit selection.
Ref, the slaac-renum discussion I'd imagine Enterprises also wants a level of isolation from ISP/global addressing.
Keeping track of 4++ addresses per-host isn't a favourite with Enterprise network operators either.
And we can't exactly say that host implementations and applications have caught up with MPMH either.

PI or LISP MH are available solutions.
Multi-homing with NAT66 wouldn't work nearly as well (and you could argue stick with v4 then, which I guess is what they do).

Ole