Thomas Narten wrote: > Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> writes: > >>> Just think how much easier the IPv4 to IPv6 transition would have >>> been if nothing above the IP layer cared exactly what an IP >>> address looks like or how big it is. > >> It wouldn't have made much difference at all, > > Wow. I find this statement simply astonishing. > > IMO, one of the biggest challenges surrounding IPv6 > adoption/deployment is that all applications are potentially impacted, > and each and everyone one of them needs to be explicitely enabled to > work with IPv6. That is a huge challenge, starting with the > observation that there are a bazillion deployed applications that will > NEVER be upgraded. There were also a bazillion deployed applications that would never be upgraded to deal with Y2K. Somehow people managed. But part of how they managed was by replacing some applications rather than upgrading them. I certainly won't argue that it's not a significant challenge to edit each application, recompile it, retest it, update its documentation, educate tech support, and release a new version. But you'd have all of those issues with moving to IPv6 even if we had already had a socket API in place where the address was a variable-length, mostly opaque, object. Consider also that the real barrier to adapting many applications to IPv6 (and having them work well) isn't the size of the IPv6 address, or adapting the program to use sockaddr_in6 and getaddrinfo() rather than sockaddr_in and gethostbyname(). It's figuring out what it takes to get the application to work sanely in a world consisting of a mixture of IPv4 and IPv6, IPv4 private addresses and global addresses and maybe linklocal addresses (useful on ad hoc networks), IPv6 ULAs and global addresses and maybe linklocal addresses, the fact that 6to4 traffic is sometimes blocked (so v6 connections time out), and that 6to4 relay routers often cause IPv6 connections to work more poorly than native IPv4 connections, NATs, and so forth. (size *is* an issue for applications that do referrals, and those are important cases, but the vast majority of apps don't do that.) And at least from where I sit, almost all of the applications I use already support IPv6. (I realize that's not true for everybody, but it also tells me that it's feasible.) From where I sit, the support that's missing is in the ISPs, and the SOHO routers, and in various things that block 6to4. I understand from talking to others that support is also lagging in firewalls and traffic monitors needed by enterprise networks. > Boy, wouldn't it be nice of all we had to do was IPv6-enable the > underlying network and stack (along with key OS support routines and > middleware) and have existing apps work over IPv6, oblivious to IPv4 > vs. IPv6 underneath. Sure it would have been nice. But for that to have happened would have required a lot more than having the API treat addresses as opaque objects of arbitrary size. It would have required that IPv4 support variable length addresses in all hosts and routers so that there would have been no need for applications to try to deal with a mixture of IPv4 and IPv6 hosts that can't talk directly to one another. It would have required an absence of NATs so that apps wouldn't need to know how to route around them. It would have required that apps be able to be unaware of the IPv6 address architecture, and for them to not need to do intelligent address selection, which basically would have required solving the routing scalability problem. Basically if we had had all of that stuff in place in the early 1990s, we would never have needed to do a forklift upgrade of IPv4 - the net would have evolved approximately as gracefully as it did with CIDR. > And, if one wants to look back and see "could we have done it > differently", go back to the BSD folk that came up with the socket > API. It was designed to support multiple network stacks precisely > because at that point in time, there were many, and TCP/IP was > certainly not pre-ordained. But that API makes addresses visible to > APIs. And it is widely used today. > > Wouldn't it have been nice if the de facto APIs in use today were more > along the lines of ConnectTo(DNS name, service/port). No, because one of two things would have happened: 1. the defacto APIs would have long since been abandoned in favor of sockets APIs that were more flexible at letting apps deal with various kinds of network brain damage, or 2. if the defacto APIs were the only ones available on most platforms, then we wouldn't have any of the applications that we have today, that manage to get around NAT. we'd be stuck with email and everything-else-over-HTTP, with all servers constrained to be in the core, and prime IP real estate being even more expensive than it is now. -- Having said that, I'll grant that every barrier to IPv6 adoption is significant. The reason is that moving to IPv6 isn't just a matter of flipping switches at any level. It's one thing for an app to be able to deal with IPv6 on a small scale when talking to a single peer from a controlled environment, quite another for the app to be able to deal with IPv6 on a large scale when running in a customer's environment and talking with many peers that are in a variety of network environments. So it's not just a matter of editing and recompiling the app, or enabling IPv6 in a few routers, or arranging for your ISP to assign you an IPv6 prefix and start routing it to you. It's a matter of having several iterations of each of those where you (whatever your role is) discover significant bugs on each of the first several iterations. Keith p.s. If we're going to engage in "what if" discussions (e.g. "what if we had had a better defacto API in IPv4") we could of course ask "what if" IPng had been designed as an extension to IPv4 (e.g. IPAE) and we had worked harder to make that approach work well. And I suspect that with enough cleverness we could have done so, and in the process eliminated a few barriers to adoption - or at least, decoupled a few more things from one another so that upgrades would not have to be in sync to be of benefit. But we had good reasons for (most of) the decisions that were made in IPv6, just as there were good reasons for the BSD sockets API. I'm not sure what purpose there is in second-guessing them now. Nor do I really see the purpose in trying to clean up the API now, at a time when applications often do need to be aware of address formats and such. Maybe once everything uses IPv6 and all of the problems are solved and we figure out how to make DNS robust it will be possible for most apps to use a simpler API. But by then, we won't have any need to change the apps that are using the old one. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf