On 2007-07-09 06:52, [EMAIL PROTECTED] wrote:
I think we should avoid any "straw man" arguments, as those tend not to
actually help advance the subject matter.
Just because one way of accomplishing a particular networking objective,
involves particularly unpleasant choices, does not mean that the technology
involved is at fault. It is also possible that the design choice was a case
of not using the right tool for the right job.
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.
I beg to differ.
PI space is available, from most if not all RIRs.
The criteria for obtaining such is reasonable, and having multiple
ISPs, i.e. being multihomed, generally accomplishes this.
That's unfortunately true, but since it doesn't scale to the ten
million or so networks we expect to desire multihoming, it will
only work for a few years. That's why we need other solutions.
Brian
ISPs are expected to have PA space available to assign to their customers.
This does not mean that every customer can only ever use PA space from
their ISP. It only means that customers who do not have their own PI space,
will be able to get PA space from their ISP.
If you are multihomed, the community generally expects you to use PI space.
And that community includes your ISPs.
If we did not need to have PI space being announced from anyone other than
the core of the DFZ (those entities which are generally considered "tier 1"
for lack of a better description), then we would only have AS paths of
length 1, and we would be able to run EGP (the predecessor of BGP).
And clearly the collection of RFCs describing IPv6 numbering schemes are
robust enough, and the routing protocols inclusive enough, that PI space
can be announced via ISPs, in addition to their own PA aggregates.
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.
You should, in this case, have a PI block, not be using anyone's PA block,
let along 3 x PA blocks. If you are using PI, you are running BGP, and
single link failures are the kind of thing that are relatively minor events
for any multi-connected entity, such as your network. No renumbering is
needed.
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.
Our collective job is to ensure that scalable solutions are disseminated,
not only in the RFCs, but in the actual implementations that customers use.
This may mean some small amount of customer education. Everyone wins when
the end customers (no matter whose customers they are) make a choice which
is not only right for them, but good for the community as a whole.
If anyone is multihomed currently, and using NAT+RFC1918, then having the
option to go to PIv6 will likely make their life much easier. The fact
that they would never need to renumber, is just a bonus.
(They will have to renumber, in moving to IPv6 in any flavour, remember.)
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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
