> 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.
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
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
