Thus spake "Brian E Carpenter" <[EMAIL PROTECTED]>
On 2007-07-06 02:59, Stephen Sprunk wrote:
Why would you ever change PI space? The issue is changing PA
space, and that's something that may need to be done every few
weeks as upstream links go up and down.
Absolutely not. If you have 3 ISPs you run 3 PA prefixes all the time.
If you drop or add an ISP you drop or add a prefix in a planned manner.
RFC 4192.
When my link to one of those three ISPs goes down, I have a 1/3 chance of
each outbound connection failing because the return path is broken (or my
other two upstreams do uRPF). I also have a 1/3 chance of each inbound
connection failing until I update DNS to remove the relevant AAAA records;
smarter clients will try multiple addresses for inbound connections, but
there'll be a delay and not all clients are that smart.
The alternative is to renumber the entire network every time a link goes up
or down.
Compare to the cost of a NAT box and the choice is easy.
That's true if you don't put the indirect operational and user
costs of NAT, plus the opportunity cost of innovation blocked
by NAT, into the equation.
Most of the operational and innovation costs of NAT are also present with a
stateful firewall, which any sane organization will be using, because it's
really the stateful inspection that burns you.
It *is* hard to get this into the budget unless you think strategically,
and factor in the way IPv6 is designed to handle multiple PA prefixes
simultaneously.
When presented with the choice between a paradigm shift and continuing along
the present path, most people will pick the latter. In this case, that
means moving either from NAT+RFC1918 to NAT+RFC4193 or from PIv4 to PIv6.
If your choices are PI vs PA then yeah NAT does look very attractive,
but if you can have PA and "private"-PI (aka ULA) then things look a lot
less blurred (IMHO).
IMHO, you underestimate how much IT folks hate renumbering.
They hate renumbering IPv4 networks. I do too, having managed such an
operation a couple of times. It's as a result of that hatred that
IPv6 came out as it is, making RFC 4192 possible.
Again, RFC 4192 ignores all of the non-technical aspects of renumbering.
That's probably appropriate, given the IETF's domain, but it's only a tiny
part of what must be done. Changing the address on an interface takes a few
seconds; the change control processes leading up to it can burn months of
manpower.
You might convince me that if you do it frequently enough, the cost will be
low, but I don't want to work anywhere that renumbers often enough to be
good at it. That reminds me of a scene in _Broken Arrow_ where a character
comments he doesn't know whether to be more scared that they lost a nuclear
weapon or that it happens often enough the military has a name for it.
This is *not* to say that anyone will renumber weekly, and big networks
will avoid it (and are therefore candidates for PI). But for smaller
networks, the hatred should be substantially less, and balance the hatred
of NAT.
It's the smaller folks that can't get PI that hate NAT the least, because
they tend to have less-educated staff (or rely on consultants/vendors) and
may even see NAT as a good thing ("it makes me secure!"), not the evil that
it really is.
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
