[ih] vm vs. memory

[Toerless Eckert]

Yes, these are the classical arguments. 

IMHO, arguments 1. and 2. have mostly failed, especially
in large enterprises. They only provided some hard shell to the
outside, but mayority of attacks can easily come from the inside.
And protection to the outside has evolved long ago from trying
to (unnecessarily) hiding your addressing structure over
to app-level - keep the good bits in, and the bad bits out.

Argument 3 (i think you mean access providers) is more interesting.

I would love to hear from folks more involved in current deployments
what the BCP is for organizations using provider dependent
addresses to be able to quickly switch providers - without NAT.
I guess you would effectively build all org internal addressing & naming
on ULA, and use the provider addresses only for internal<->external
communications, but if you have an actual L3 network in the org, then
there is probably still a lot of renumbering necessary for which
there are no well defined network wide autoamted solutions. Although
i think there will be a new WG, forgot name to start tackling this.

If it was me, would have just evolved and improved on rfc1928.

Cheers
    Toerless

On Tue, Oct 24, 2017 at 07:35:12PM +0200, Paul Vixie wrote:
> > On Tue, Oct 24, 2017 at 02:12:06PM +0200, Paul Vixie wrote:
> >>
> >> ...
> >>
> >> LISP may be an example. NAT certainly is.
> 
> Toerless Eckert wrote:
> >Hmm... what are the redeeming qualities of NAT ?
> 
> every other attempt to add rapid renumbering and transparent
> multihoming has been rejected. NAT, by not trying to do those things
> and by not saying it would do those things, snuck under the
> defenses.
> 
> no multi-national enterprise should give real external addresses to
> all of its internal endpoints, for at least three reasons:
> 
> 1. the internal structure should not be visible or guessable.
> 
> 2. reachability should be prevented by more than just firewalls.
> 
> 3. you can add and drop transit providers as often as you want.
> 
> NAT did that. nothing else could have or did.
> 
> -- 
> P Vixie

-- 
---
tte at cs.fau.de