Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/15/10 11:04 AM, ned+i...@mauve.mrochek.com wrote: And since I'm not in the best of moods I'll also answer in kind by saying us application engineers might also be waiting for someone with half a clue as to how to design a proper standard API to come along and do that. Ned, Agreed, better progress should have been made. What impact do you see a new suite of network APIs making? That depends on what API you're talking about, and what you're hoping to accomplish. At this point work on the core C API, with the intent of helping along IPv6 deployment by getting application developers on board is IMO a complete waste of time. Consider: Given how these things go and what needs to be done, we'd be lucky to have anything in 18 months, and 2-3 years is not beyond possibility. And that's just the start. Even if you assume implementations are done in line as the standard is developed, think how long it will be before there will be enough deployment that application developers will be able to count on the new routines enoough to take advantage of them. An aside. We got a new, corporate-standard Windows laptop for our office the other day. (Needed because everyone in the office is on Mac but a bunch of Oracle internal appls only work on Windows.) Both the box and the laptop itself were covered with Windows 7 stickers. BUt when we booted the thing, XP came up. The original Windows 7 install had been erased and replaced with the corporate standard configuration, which is currently XP despite the fact that XP is now almost 9 years old. And I doubt if Oracle is alone in doing this sort of thing. This, like it or not, is the world application developers live in. A new API may sound really keen, but it's useless until you can count on it being present on the overwhelming majority of the platforms people actually use. And the lead time there seems to best be measured in decades, not years. Now, if the goal is simply to make the world a better place for application development, then sure, coming up with a standard connectbyname interface makes all sorts of sense. But maybe this time someone might want to talk with the folks who actually make the most use of the API when designing it. Just sayin'. Another alternative would be to try and improve the routines available in various higher level programming languages, which while in general far superior to the socket level stuff are nevertheless lackiing in various ways. It is much easier to deploy a new version of Java, PHP, Perl etc. than it is to deploy stuff at the operating system level. But once again, since most of the popular languages were updated to support IPv6 some time ago, meaning most applications written in those languages just work with IPv6 with no changes, this isn't going to help IPv6 deployment much if at all. Broader support for SRV records, OTOH, is a need that might be met to some extent this way. It is not hard to understand a view that one should avoid making NATP translations, where IPv6 should easily be able to avoid this issue. THe operative word here is should, Sure, the glut of addresses IPv6 provides theoretically solves this problem. But in practice, the lack of IPv6 connectivity for the overwhelming majority of users means that anyone counting on IPv6 to eliminate the need for either mutlple IPv4 addresses or NATPT is being extraordinarily foolish. When dealing with older code that should have been changed, dual stack transitional schemes, such as ds-lite or 6to4, depend less on existing code working directly with IPv6. You're significantly overestimating the issues with existing code, and significantly underestimating the other problematic aspects of IPv6 deployment. Most expect port mapping agility, or manual intervention will retain functionality by moving this function to the realm of newer equipment. Access to maintenance interfaces is another area where proprietary schemes are working well. Even Debian distributions such as Ubuntu, offer pre-installed services which make remote configuration easier and safer. Having fewer maintenance interfaces exposed directly to the Internet is a good thing, since few older interfaces have adequate protection. Here is a document that explains how the aiport router supports an API for managing port mappings: http://tools.ietf.org/html/draft-cheshire-nat-pmp-03 I'm sure this solves a problems for someone somewhere, but it doesn't address any of the issues I've raised in any meaningful way. This approach avoids complex service and device specific structures, and dependence upon insecure, complex, and proprietary assignment protocols that ultimately depend upon users being updated and knowing when to click okay. No doubt it does, but since none of these things you're railing against are at issue here, it's entirely irrelevant. Ned ___ Ietf mailing list Ietf@ietf.org
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
getaddrinfo() works for clients. It does not work for servers, in particular it does not work for peer-to-peer services that may be hidden behind layers of NAT44, NAT46 and NAT64. Port forwarding requests have to be a part of the model. That in turn means that there has to be a security model. And the well known port approach for discovery really does not work for Web Services where we already have more services than ports. The API has to hide all the complexity, not just some of it. And it has to be compatible with coding in scripting languages like Perl or Ruby, not just something that can be done from C++ with a Mb plus of networking stack. These are not difficult problems. In fact the remaining issues are difficult because they are easy, not because they are hard. Anyone can have an opinion on how to label SRV prefixes for services. And many people do. Net result is that what should have been done ten years ago is still incomplete. Ever wondered why Henry Ford only made cars in black? He observed that the more choices a customer was faced with, the longer it took them to come to a buying decision. Even more so when multiple people were making the decision. Decisions that had practical consequences were easy to solve as either there was a need or was not. Decisions such as color that had no practical consequence took forever. One of the reasons X.500 directory deployment was a nightmare was that the design of the directory tree and DIT had no technical consequence, only political consequences. On Tue, Jun 15, 2010 at 1:30 PM, Fred Baker f...@cisco.com wrote: On Jun 15, 2010, at 5:57 AM, Phillip Hallam-Baker wrote: But in a Betamax/VHS type contest, attempting to differentiate the new through obfuscation merely raises barriers to transition. In that circumstance you want to minimize the differences between the two technologies so that they can be used interchangeably. So, things like implementing getaddrinfo() to replace gethostbyname() and as a result making the applications network layer agnostic. The kind of thing that not only helps with IPv6 deployment, but makes multi-homing work well for the IPv4-only application as well, makes solutions like pnat irrelevant, and all that. http://www.ietf.org/rfc/rfc2553.txt 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc3493.txt 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format: TXT=82570 bytes) (Obsoletes RFC2553) (Status: INFORMATIONAL) Supported in Windows, Mac/BSD, Linux, you name it. Been there a long time. Yes, all we need is application engineers with a network clue. They seem to be hard to come by. I have a solution. Let's go through those OS's and rename gethostbyname to GetHostByName. Put in huge comments everywhere that the character string is found (man pages, which btw already have this, and in the code itself) if you use this, you're an idiot. Make folks use their heads momentarily. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
The mistake there being to insist on implementation of the IPv6 specification rather than what is necessary to enable the transition to IPv6. You can't build a building without scaffolding. In the middle ages the design of the scaffold was often as great an engineering feat as the building (c.f. Brunelleschi and the dome of Florence cathedral). We have had a lot of people focused on the desired end state and not enough consideration given to what it takes to get to that end state. The idea of developing technology whose sole purpose is to enable a transition is not always appreciated. I am just writing a proposal in another field which argues for a considerable sum to be invested for the sole purpose of reducing the number of indispensable parties by one. I have no particular reason to expect that party not to co-operate. In fact I have designed the political drivers so that their participation is eventually inevitable. But I need to convince other parties to move before this has become generally apparent. On Tue, Jun 15, 2010 at 1:45 PM, Melinda Shore melinda.sh...@gmail.com wrote: Fred Baker wrote: I have a solution. Let's go through those OS's and rename gethostbyname to GetHostByName. Put in huge comments everywhere that the character string is found (man pages, which btw already have this, and in the code itself) if you use this, you're an idiot. Make folks use their heads momentarily. That's actually how a number of problems were fixed in the BSD libraries. gcc came along and it flagged some things - as errors - that weren't really incorrect but were bad practice (writing into constant strings, for example). Can't imagine anything like that happening today. We've gotten a vendor or two to implement v6 in their products by explaining that we've got a non-negotiable requirement for it and that we'd be unable to continue to license their stuff without it. Melinda -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
Anyone can design a system for use by highly motivated geniuses. It takes a lot more skill to build something that can be used by people whose primary motivation is not to make 'your stuff' work. The issue Ned raises is very typical of what most engineers spend 80% of their time on - fixing stupid issues that need never have existed if someone else had done their job a little better or described what they are doing more accurately. The only people who are going to have labs set up to test the full range of IPv6 interop issues are people whose primary focus is IPv6 interop. Ergo anyone who wants the typical application engineer to develop IPv6 compatible code had better work out how to completely encapsulate all those issues at the platform level. On Tue, Jun 15, 2010 at 3:42 PM, Dave CROCKER d...@dcrocker.net wrote: On 6/15/2010 7:30 PM, Fred Baker wrote: Yes, all we need is application engineers with a network clue. They seem to be hard to come by. Every layer is clue-challenged, when it comes to staffing. Possibly at other times, too. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/15/10 11:04 AM, ned+i...@mauve.mrochek.com wrote: And since I'm not in the best of moods I'll also answer in kind by saying us application engineers might also be waiting for someone with half a clue as to how to design a proper standard API to come along and do that. Ned, Agreed, better progress should have been made. What impact do you see a new suite of network APIs making? It is not hard to understand a view that one should avoid making NATP translations, where IPv6 should easily be able to avoid this issue. When dealing with older code that should have been changed, dual stack transitional schemes, such as ds-lite or 6to4, depend less on existing code working directly with IPv6. Most expect port mapping agility, or manual intervention will retain functionality by moving this function to the realm of newer equipment. Access to maintenance interfaces is another area where proprietary schemes are working well. Even Debian distributions such as Ubuntu, offer pre-installed services which make remote configuration easier and safer. Having fewer maintenance interfaces exposed directly to the Internet is a good thing, since few older interfaces have adequate protection. Here is a document that explains how the aiport router supports an API for managing port mappings: http://tools.ietf.org/html/draft-cheshire-nat-pmp-03 This approach avoids complex service and device specific structures, and dependence upon insecure, complex, and proprietary assignment protocols that ultimately depend upon users being updated and knowing when to click okay. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
Yes, I am aware that some applications are IPv6 only. But I don't think that they have enough momentum to carry the IPv4 world forward into IPv6. The applications that are following that route are self-selecting for requiring little or no IPv4 connectivity. There are two models of technology adoption that might be applicable here. The paradigm that I think most IETF transition planning was based on was vinyl being replaced by CD. The advantages of CD were obvious to anyone who wasn't an audiophile bore who had spent $5000 on a turntable and some clever marketing. So the transition occurred even though it required people to repurchase their vinyl records on CD. But IPv6 does not deliver a clear technical advantage to the purchaser over IPv4. So the model that is more appropriate is Betamax vs. VHS and the question is whether the technical factors that the designers think people should care about (picture quality, ability to freeze frame) win over the ones that they actually care about (ability to record feature length movie on one tape, open standards, availability of content). If we were in a vinyl/CD type race then the previous IETF strategy of attempting to maximize the differences between the technologies would make sense. In that circumstance you would want to kill off NAT64 and so on. But in a Betamax/VHS type contest, attempting to differentiate the new through obfuscation merely raises barriers to transition. In that circumstance you want to minimize the differences between the two technologies so that they can be used interchangeably. [Oh and I am aware of the ridiculous claims by Lieberwitz and Margolis concerning the history of Betamax/VHS. As with their work on QWERTY, it was performed for a DC thunk tank being paid to deliver an argument that network effects do not exist. As such it is paid advocacy, not scholarship and their claims do not merit consideration.] On Tue, Jun 15, 2010 at 4:31 AM, Thierry Ernst thierry.er...@inria.fr wrote: Dear all, I follow this amusing debate - I'm not reacting to this post specifically. I would like to point out that there are people out there specifying communication architectures for new uses of the Internet, e.g. Cooperative Systems for communications involving vehicles. The system running between all entities composing their network will be living in an IPv6-only world. They will only deploy transition mechanisms to keep communication going on with other parts of the Internet not running IPv6, if that proportion is still significant by the time these new systems get deployed (hopefully, they won't have to do so, and for sure they won't deploy dual stack). It seems to me that these new uses are always ignored when one is debatting transition from IPv4 to IPv6. In some many cases, it is simply transition from something not IP to IPv6. So, there will be IPv6-only systems deployed out there (the sad news is that there are also sectors transitioning from non IP (e.g. X25) to IPv4 - just because they are not aware about IPv6 or are still thinking IPv6 is for the next decade). Regards, Thierry. On 15/06/10 02:10, Mark Andrews wrote: In messageaanlktimoqnpmkcbitki07kag9xtroyiv84rqsmo0d...@mail.gmail.com, Phil lip Hallam-Baker writes: On Thu, Jun 10, 2010 at 11:04 PM, Mark Andrewsma...@isc.org wrote: I'm thinking 10, 15+ years out when there are lots of IPv6 only served zones. Much the same way we no longer worry about MTA's that don't know about MX records and no longer add A records to accomodate them. Why would there be any IPv6 only served zones? Because it going to get harder and harder to get stable IPv4 addresses. ISP's are looking at moving their entire client base from having unshared public addresses to shared public addresses. What John and I have been trying to get across here is that there is no incentive to create an IPv6 only zone now and never will be in the future. You present an induction without a base case. Except IPv6 only zones already exist so there must be some incentive to have them. Back in the days when Internet on phones meant WAP, there was a possibility of them being supported on IPv6. But now the iPhone has changed the model and the Web on a phone will look just like the rest of the net and so they have to run IPv4. That is the big flaw in the IPv6 ready program. It assumes that the incentive for transition is that IPv6 is a good in itself. It is not, in fact IPv6 will be slower (more header baggage) than IPv4 and if you are IPv6 only you will have to go through gateways. And IPv4 will have multiple header re-writting. DPI to fix up the fact that headers have been re-written multiple times along with checksum re-calculations etc. I actually expect IPv6 to be faster in the end if only marginally. Most measurements to day say that IPv4 and IPv6 are roughly the same. We do seem to be making some progress. I have been banging on about this
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On Jun 15, 2010, at 5:57 AM, Phillip Hallam-Baker wrote: But in a Betamax/VHS type contest, attempting to differentiate the new through obfuscation merely raises barriers to transition. In that circumstance you want to minimize the differences between the two technologies so that they can be used interchangeably. So, things like implementing getaddrinfo() to replace gethostbyname() and as a result making the applications network layer agnostic. The kind of thing that not only helps with IPv6 deployment, but makes multi-homing work well for the IPv4-only application as well, makes solutions like pnat irrelevant, and all that. http://www.ietf.org/rfc/rfc2553.txt 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc3493.txt 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format: TXT=82570 bytes) (Obsoletes RFC2553) (Status: INFORMATIONAL) Supported in Windows, Mac/BSD, Linux, you name it. Been there a long time. Yes, all we need is application engineers with a network clue. They seem to be hard to come by. I have a solution. Let's go through those OS's and rename gethostbyname to GetHostByName. Put in huge comments everywhere that the character string is found (man pages, which btw already have this, and in the code itself) if you use this, you're an idiot. Make folks use their heads momentarily. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
Fred Baker wrote: I have a solution. Let's go through those OS's and rename gethostbyname to GetHostByName. Put in huge comments everywhere that the character string is found (man pages, which btw already have this, and in the code itself) if you use this, you're an idiot. Make folks use their heads momentarily. That's actually how a number of problems were fixed in the BSD libraries. gcc came along and it flagged some things - as errors - that weren't really incorrect but were bad practice (writing into constant strings, for example). Can't imagine anything like that happening today. We've gotten a vendor or two to implement v6 in their products by explaining that we've got a non-negotiable requirement for it and that we'd be unable to continue to license their stuff without it. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On Jun 15, 2010, at 5:57 AM, Phillip Hallam-Baker wrote: But in a Betamax/VHS type contest, attempting to differentiate the new through obfuscation merely raises barriers to transition. In that circumstance you want to minimize the differences between the two technologies so that they can be used interchangeably. So, things like implementing getaddrinfo() to replace gethostbyname() and as a result making the applications network layer agnostic. The kind of thing that not only helps with IPv6 deployment, but makes multi-homing work well for the IPv4-only application as well, makes solutions like pnat irrelevant, and all that. Right general idea, but wrong in the details. The API applications should be using is one of the connectbyname variants that avoids having to do any handling of raw addresses of any sort. PHB's suggestions are spot on here. Among other things, using a connectbyname API provides the abiltiy to easily implement support for SRV records. http://www.ietf.org/rfc/rfc2553.txt 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc3493.txt 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format: TXT=82570 bytes) (Obsoletes RFC2553) (Status: INFORMATIONAL) Supported in Windows, Mac/BSD, Linux, you name it. Been there a long time. But still too low level. And the fact that the addrinfo APIs are supported on a lot of platforms doesn't mean code written on top of them interoperates. Case in point. A few months back I was testing some code that uses the addrinfo interfaces on a new platform. getaddrinfo worked fine, but getnameinfo, not so much. After contacting the vendor, I was informed that the length field in the structure had to match the length field supplied in the parameter list exactly or the call would fail. The suggested fix was to put a switch statement in front of the call to fill in the lengths appropriately depending on the address family in use. That's not exactly futureproofing, is it? Yes, all we need is application engineers with a network clue. They seem to be hard to come by. And tHat's frankly insulting - the main problem isn't new code, which by and large is being written in languages that support proper connectbyname and getconnectinfo APIs that hide all this stuff completely. No, the problem is the vast amounts of old code written long before the addrinfo APIs existed. Switching all of this stuff over is NOT trivial. An especially pernicious problem is library code where the source is either unavailable or is available but you're not allowed to modify it for one reason or another. And since I'm not in the best of moods I'll also answer in kind by saying us application engineers might also be waiting for someone with half a clue as to how to design a proper standard API to come along and do that. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/15/2010 7:30 PM, Fred Baker wrote: Yes, all we need is application engineers with a network clue. They seem to be hard to come by. Every layer is clue-challenged, when it comes to staffing. Possibly at other times, too. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
