>> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf