On 2007-07-09 03:36, Mark Andrews wrote:
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.
No. You don't have to renumber. You just have to deprecate
the addresses associated with the downed link. This is the
sort of thing routers should be able to do automatically.
Indeed, and reachability detection is a necessary part of a
robust IPv6 implementation regardless of any of this, since
multiple addresses for the same host is a design feature
of IPv6.
Brian
As for uRPF you will either have a problem with that all
the time or none of the time. If your ISP doesn't do BCP
38 correctly (uRPF is not doing BPC 38 correctly) then
choose ISPs that offer BCP 38 support (i.e. they allow you
to send packets out with *any* of your PA addresses, not
just the ones they assigned to you).
The alternative is to introduce source address routing
within your network.
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.
NAT introduces costs above and beyond those of a stateful firewall.
And as for stateful firewalls, applications should be able to
talk to them to open up reply traffic if needed.
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.
Real renumbering events are rare.
You are wanting NAT to provide multi-homing support. This
does not require you to renumber. There is no need to use
NAT for this with IPv6. IPv6 provides the mechanisms to
move the source address selection back to the end host
(where it belongs).
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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
