Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Erik Kline <[e-mail]>]

On Wed, 20 Feb 2019 at 17:12, Manfredi (US), Albert E <
[e-mail]> wrote:

> -----Original Message-----
> From: Brian E Carpenter <[e-mail]>
>
> > NPTv6 is not NAT66, as the NPTv6 *Experimental* RFC explains.
>
> Okay, NPTv6. No port translations. RFC 6296.
>
> >> All of the advantages of the basic NAT come to bear,
> >
> > I'm not sure that that is true, but NPTv6 brings some, but not all,
> of the disadvantages of NAT too, as also explained in RFC6296.
>
> Few of the disadvantages, I'd say. For example, use of IPsec AH is
> compromised. But many people objected to the mandatory use of IPsec in IPv6
> already, because there are other ways of securing content that they prefer
> to deploy. I think that the wide deployment of NAPT in IPv4 has reduced the
> severity of the disadvantages of NPT, as application designers have long
> had to accommodate workarounds?
>
> > NPTv6 as a work-around for a defect in SLAAC when there is an
> unplanned renumbering?
>
> I mentioned SLAAC timers as an example. What I should have said is, as far
> as I can tell, all of the problems we have been discussing in this thread
> would be solved with NPTv6. Privacy in home nets, renumbering, route
> aggregation, SLAAC, what else? I can't think of an issue mentioned here
> that NPTv6 wouldn’t solve.
>
> It should not be all that surprising that the advantages of address
> independence have become entrenched in IP thinking, thanks to IPv4. So it
> should not be surprising if many have come to depend on these advantages,
> and don’t want to give them up.
>

As Lorenzo said, it "solves" some operational pain by pushing that pain
onto those that are not represented in the decision making process to
deploy any variety of NAT (i.e. apps, OSes, ...)

We've been here before <https://www.ietf.org/proceedings/74/6ai.html>, of
course.