On 6/9/10 5:57 PM, Ned Freed wrote: > I note in passing that this might have played out differently had we > gotten SRV record support in place for all protocols a lot sooner. > But without it for HTTP in particular you're faced with the need for > multiple port 80s in a lot of cases.
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.
> > Clearly, with skill and non-commodity equipment, a configuration > > supporting multiple IPv4 addresses at an access point can be > > implemented in conjunction with IPv6. > > Of couse it can. But that's precisely the point - neither the skill > nor the non-commodity equipment are available in most cases. And > even when they are, a lot of people, like myself, run the costs > versus benefits and IPv6 ends up losing.
Agreed, but that changes once IPv6 becomes an imperative for these services, such as websites. At that point, its easier to scale a transitional solution when using fewer IPv4 addresses. As such, those few wishing to retain multiple IPv4 addresses lacking IPv6 connectivity are likely the last to adopt IPv6.
With all due respect, I think you need to go read up on pareto optimality and it's implications for the transitions you claim are inevitable as IPv4 addresses become more scarce.
> > Fortunately, it remains easy to adopt the resource conservative > > IPv4 configurations supported by commodity routers when obtaining > > IPv6 connectivity. Why should the IETF advocate an increased IPv4 > > use that lacks benefit once a network has been configured?
> More strawmen. We're not talking about increased IPv4 use, but > rather decent support for existing, long-deployed IPv4 use. If you > seriously think you can get people to dump their existing setups in > favor of something that is a major PITA to deal with and offers no > immediate benefit, well, I have a couple of bridges available at fire > sale prices.
I still have my English standard spanners, but they are seldom used.
Major analogy fail. Again, your assertion was that what I'm after involves increased IPv4 use. This is simply false.
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. Ned _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf