On Wed, Jun 9, 2010 at 8:57 PM, <ned+ietf@xxxxxxxxxxxxxxxxx> wrote: >> Sorry, this was in reference to an approach based on passed >> assumptions. The inflection point for when multiple IPv4 addresses at >> an access point becomes anachronistic will occur with an IPv6 >> connectivity imperative driven by the lack of IPv4 addresses. > > But things have to get to that point first. I for one am not especially > sanguine about IPv4 address scarcity forcing sensible behavior soon enough. > Especially given the major holes in IPv6 device support we've been > discussing. Try 'desirable'. Sticking to IPv4 till the last minute and letting everyone else make the necessary investment to support the transition is the 'sensible' approach for most parties. The Internet has a billion users and it is now impossible to change it without putting a great deal of thought into the incentives for co-operation. > 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. And the number of protocols is exploding due to Web Services. We now have far more than 64K protocols in use. The only reason we have not exhausted the ports is that in the modern Internet everything has to be layered on port 80 or 443. What I would like to see the IETF do is to produce a new architecture document that tells application and Web Service designers how they should be using the Internet. In my view DNS+SRV should become the only way that Web services are located (I do not think the extra capabilities of NAPTR are necessary or even useful for service discovery). At the moment we have the OpenID people who currently have five service discovery mechanisms, none of which use the DNS properly. And they are not the only group that is merrily creating entropy that is going to have to be serviced. We also have a similar issue with the use of XML, there the problem is that there are four different ways to achieve a certain aim and we spend a year arguing about which one to pick each time we start a working group. What I like about RFC822 style headers is not that they are the best way to move metadata but that they are used in the same way in every protocol. >> The inflection point for when multiple IPv4 >> addresses at an access point become anachronistic occurs with an IPv6 >> connectivity imperative. > > Yes, but the trick is getting things to that point. > >> Perhaps the US will delay acceptance of this >> imperative, long after the rest of the world has embraced IPv6. After >> all, US, Liberia, and Burma have yet to adopt metric measures. :^) > > That may indeed be the case, but I must say Hardly a fair comparison for a > lot > of venues. It's always easier to deploy new infrastructure when there's > relatively little old infrastructure that has to coexist or be replaced. > >> > Calling small business use of a small number of IPv4 addresses >> > "anachronistic" >> > doesn't change the fact that this is a widespread practice fully >> > supported by >> > an ample number of reasonable quality router products. And you're not >> > going to >> > get IPv6 deployed in such cases without a drop-in replacement that >> > adds IPv6 >> > support to what's already there. > >> 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. > >> This could be practical when many within an >> organization are affected, but would not involve commodity low-end >> routers. Such configurations will remain rare due to IPv4 resource >> consumption, and greater support complexity. 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 somethign 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. > > Ned > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf