> Thus spake "Mark Andrews" <[EMAIL PROTECTED]>
> >> 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.
>
> Are the routers going to summon all the affected folks to a change control
> meeting, verify the approvals, do the necessary post-change testing, etc?
> Are they going to update all the firewall configs, DNS, etc?
There are no firewall changes to make. There are no DNS
changes to make. Just because a prefix is deprecated it
doesn't suddenly become invalid. When the link is restored
the prefix will be reinstated.
Do multi-homing NAT boxes in the IPv4 world cause a change
control meeting?
All this is doing is moving the source address selection
from boxes in the middle of the network to the edge nodes.
> Even the above automatic address deprecation part isn't available yet,
> despite a decade of folks claiming that renumbering is easy, and that's not
> even the hard part.
We are not talking about renumbering. We are talking about
address selection. All the boxes will continue to have all
the addresses before, during and after the link down event.
> >> 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.
>
> That's like saying having a broken leg is an additional cost above and
> beyond the cost of death. Not breaking your leg doesn't make you any less
> dead.
So you don't think have packets change addresses and ports
as they cross the NAT is not a additional cost especially
for humans trying to diagnose problem?
It definitely much easier to see traffic flows on two sided
of a box if you don't have to also match different address
and ports.
> > And as for stateful firewalls, applications should be able to
> > talk to them to open up reply traffic if needed.
>
> Yeah, try to sell that to any enterprise security department. It's the
> applications and users that security folks are trying to protect their
> networks from in the first place, and internal users are a much, much bigger
> threat to security than external folks are.
That is why the firewall should be on the node and not in the
middle of the network. Every box protects itself from every
other box including internal boxes.
> >> 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.
>
> That all depends what you call "real". Any event that breaks connectivity
> (including established connections) for more than a few seconds is "real" to
> me.
I said renumbering events not link outages. If you don't have
a routing slot for the prefix you are using, which describes PA
addresses, then nothing a end site can do will prevent established
connections from failing if the link to where the covering prefix
traffic is sent fails.
> > 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).
>
> For the record, I hate NAT, for all the reasons that most of IETFers do.
> What I'm saying is that NAT is considered by the market to be less evil than
> the alternatives the IETF has proposed to date. Until folks recognize that,
> no progress will be made.
>
> I'd much prefer to see widespread use of PI space, and significant effort
> put into an id/loc split scheme so that the DFZ doesn't implode as a result.
> OTOH, router vendors are claiming the ability to support two million routes
> today and ten million in a few years, so we have time to work on that.
Well until that comes along, providing a multi-homing solution
that will work with existing without resorting to NAT is something
we should be striving for.
If there are pieces missing we should be indentifying them and
getting vendors to implement them. As for using multiple PA
about the only thing I see missing is detection of the trigger
events (link down).
IPv6 has a different management paradigm to IPv4. Education
is important.
> 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
> --------------------------------------------------------------------
--
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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
