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