Re: The point is to change it: Was: IPv4 depletion makes CNN2010-06-10 21:37:40On 6/10/10 3:12 PM, Ned Freed wrote: On 6/10/10 2:48 PM Douglas Otis wrote: > Disagree. HTTP is a bad example, since it allows canonical names > to be replaced with a name offered by clients for supporting name > based virtual hosts. In other words, a single port supports > thousands of websites. :^) True but irrelevant. The issue isn't support for multiple web sites, it's support for multiple servers. Virtual hosts are fine as long as everything you've got runs under the same web server and on the same hardware. But in many cases things don't work this way. Let's see. I'm running at least seven different pieces of software right now that include a web server component. Now, not all of them provide public services, and for those it doesn't matter that they're not on port 80. But three of them do provide public services. Of course redirects and proxies provide a means of getting around these limitations. But now you're talking about a substantial increase in application and configuration complexity. Multiple IPs are a lot simpler and easier to manage. A Pareto complaint scenario does not require every possible configuration be accommodated, when it also accommodates existing configurations. Only a small percentage of customers receive multiple IPv4 addresses from their provider. Of those, only a few run incompatible services on different systems. While those who participate within the IETF likely represent an exceptional population, it seems unlikely special accommodations for minor portions of a market is necessary before progress is possible. Those who wish to retain their current configurations can do so, forgoing IPv6 connectivity. For them, this becomes a question of what overcomes their current equilibrium (their PITA factor). Indirectly this is being answered when large providers internally route Internet services using IPv6 when lacking adequate IPv4 address space. From a security standpoint, direct routing to a device reduces complexity and operational issues. Whether a device is an LP tank sensor in the backyard, a power meter on the side of the house, or a heat pump in the basement, direct routing offers enhanced functionality and security for those who opt-in. Currently, low-end routers are commonly 0wned and are untrustworthy, and often lack adequate logs, assuming these logs could be trusted. Direct routes allow packets to arrive unaltered, where only its source is being trusted. > The impetus to change occurs after IPv6 becomes an imperative, such > as doing business with a region dependent upon IPv6. After that, > complaints related to NATs will fade, and support for IPv4 will be > seen as the PITA. The inflection point for this may move faster > than imagined. In other words, the way you see this unfolding is that once there's a significant IPv6-connected base somewhere, probably in some emerging market, somebody will view it as practical to deploy services that can only be reached by IPv6. As more and more of this happens, it will create a need for everyone to have IPv6 connectivity, which will then lead to more IPv6-only services, and so on. If this is accurate, I think you need to go back and reread John Klensin's recent messages for why this scenario really isn't all that likely to unfold the way you think. Region might mean a market segment or a geographic area, whether the impetus results from a lack of IPv4 address space, a lack of IP security, or a lack of functionality. Do you have a reference to one of John's messages? Over the years, this economic reference has been raised. Adding complexity to commodity devices for a minor portion of a market makes little sense. Higher-end routers offer a solution, but this means considering available alternatives when price does not seem justified. I don't see any strategy being proposed to force those not wishing to participate. For years I have had access to multiple static IP addresses, but never used more than one, nor would the services you seem to describe meet most residential AUPs. -Doug _______________________________________________ Ietf mailing list Ietf(_at_)ietf(_dot_)org https://www.ietf.org/mailman/listinfo/ietf
|
|