I also don't have a lot of faith in "should be", not when I've seen DHCP
servers routinely refuse to renew leases after very short times, nor
when I've heard people say that a site should be able to renumber every
day.
So, someone misconfigured something. Such misconfigurations
usually get fixed fast.
In all of the cases where I've seen the DHCP thing happen, it was
deliberate. And no, stupid network admins do not get fixed quickly. At
least, not as a general rule. The Peter Principle applies here as to
that profession as any other.
"address leasing" is one of the fundamental design flaws of DHCP. Of
course, that's also water under the bridge.
Getting the automation to the state where a daily renumber
is possible is an achievable goal. If we were doing that
the long running apps would have been fixed long ago.
And if we could make the sun run backwards then we wouldn't need
streetlights. Never mind those people on the other side of the world...
You want to make applications be slower, less reliable, and more complex
in order to make routing easier. It's understandable that you might
feel that way, but don't expect everyone else to go along with it.
Now if you find a way to solve the problems you are concerned about,
while also providing a truly viable solution for others, Then we might
make some progress. But mere handwaving won't cut it. You have to make
a convincing case that your solution is comprehensive.
The
fact that they aren't is more a matter of pressure than
anything else. That's why I started with a large period
when I was suggesting that router and firewall vendors
actually renumber themselves periodically. It was to keep
the problem in the management space rather than the application
space.
Yes, but firewall and router boxes are relatively easy to renumber,
because there are a smaller number of vendors and a smaller number of
interfaces. Apps are much harder because they are so diverse.
Have each vendor work on their part of the problem is the
way to go.
Lots of apps vendors out there would have to come to some sort of
agreement. Any purported solution had better be very versatile. Of
course, a lot of the problem is a security problem. Find a decent
(efficient, mostly reliable, easy to configure, and works across
administrative domain boundaries) way for hosts and nets to quickly
distinguish trustworthy traffic from untrustworthy traffic without using
IP addresses and you'd probably decrease application configuration of
addresses by an order of magnitude, maybe two. (and also note that any
renumbering scheme can't been seen as weakening the relationship between
IP address and trustworthiness - that relationship is already too weak
as it is, but people will cling to it until there's something better)
I used to try to get people to specify a minimum amount of time that a
non-deprecated address should be expected to be valid - say a day. Then
application writers and application protocol designers would have an
idea about whether they needed a strategy for recovery from a
renumbering event, and what kind of strategy they needed. But the only
people who seemed to like this idea were application area people.
Until applications deal nicely with the other failure modes,
complaints about renumbering causing problems at the
application level are just noise.
in other words, one design error can be used to justify another? sort
of like the blind leading the blind?
No. People should work on making renumbering work efficiently.
I don't disagree that it's worthy of further investigation. I just
don't think that it's likely to succeed anytime soon, which is to say,
within a decade or maybe two. Automated renumbering is not going to
alleviate the need for PI space or for the routing system to be able to
somehow handle large numbers of PI prefixes. Something else might, but
not automated renumbering. At least, that's what my intuition says.
That doesn't mean don't try, it means don't depend on that being the
solution.
I see a significant difference between a design flaw in a particular
application that cripples that application, and a design flaw in a lower
layer that cripples all applications.
Reconnect is a reasonable strategy for most applications.
Sounds very naive to my ears.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf