> Is it invalid to base assumptions on what can be observed? Yes, if you fail to consider the limitations of your observations.
Most of the apps that exist today for IPv6 are just conversions of IPv4 apps - they are not representative of what can be done with IPv6. It's not even appropriate to judge the future of IPv4 based on current IPv4 applications. The way that the network is used keeps changing. For instance, p2p file transfer is a much bigger deal now than it was a couple of years ago. Why do you think it's reasonable to make the same error in predicting IPv6 usage, when IPv6 has far less deployment or usage history on which to base any extrapolation? > In my opinion, speculating on the wonderful ways that IPv6 could be > used (but isn't presently) and making assumptions that the ways in > which IPv6 might possibly be used and outlawing any other uses is a > foolish thing. The whole purpose of the Internet is to support diverse applications - and yes, this includes apps that neither you nor I know about. It's not "foolish" to consider the needs of such apps, it's realistic. What's foolish is to assume that everyone uses the Internet, now and in the future, exactly like you've seen it used within your limited experience. > My posting to this list was not intended to elicit so many responses > and drive the working group in to another mindless yelling match. I > wanted to share my experience. We have found a real world use for > IPv6LLs. It works, it doesn't appear to cause any harm. With our use > of mDNS, it is nearly transparent to most applications. And you failed to realize that it causes problems in wider use. When someone points this out to you, rather than getting a clue, you try to discredit them. Denial is not in anyone's interest. Did it occur to you that your emperical testing is inherently biased toward apps that don't have problems? Did it occur to you that "most" present applications that you've seen are not representative of anything else? Certainly not "all" applications or "all useful" applications or "most" apps that others are or will be using, or "future" applications. > > If you try to remove IPv6LL you will get push back from the industry. Who said anything about removing IPv6LL? But if the industry is trying to push LL for general purpose use they damn well should get pushback. Why are you trying to defend industry shortsightedness? > If you try to deprecate APIs, such as removing the scope id, when > there is no clear reason why, you will get push back. Nobody said anything about doing that either. We just need to realize that it's of very limited utility. > This working > group may do these things to satisfy the loud and obnoxious people on > the list. Which loud and obnoxious people - those who are trying to make the Internet safe for apps or those who keep trying to insist that IETF bless whatever dysfunctional practice they're trying to push in products? The IETF does not exist to bless stupidity or shortsightness. > It will drive the IETF further in to irrelevancy as vendors > stop paying attention to and participating in the IETF. These are not > threats, these are observations. Who is being irrelevant - the industry that fails to realize the consequences of its actions, or the people in IETF that try to explain these consequences but keep getting rebuffed by people who insist that "it just works" based on an inadequate amount of testing? > The major difference between IPv4LL and > IPv6LL is that IPv6LL is a part of IPv6 from the start. There are no > applications that are developed for IPv6 that don't experience IPv6LL > addresses. Yes, and this *is* better than IPv4LL. (though it's not the only major difference - ability to have multiple addresses per interface is significant also). But the point is that v6LL was not intended for, and is not suitable for, general use by apps. It's intended for specialized use by specialized apps - as an alternative to every link layer having to define its own way to propagate reachability and routing information. > a developer runs in to problems, the developer will work around them > or suffer public humiliation and financial ruin when they release a > sub-par product. Meanwhile, the v6 net is screwed up worse than the v4 net with NATs. I'm perfectly willing to let commercial developers live or die by the products they produce. But I'm not willing to let developers take the net down with them. At least, not without a fight. > Pointing the finger and saying "I can't make it work > because there's this extra address there that's easy to identify as > link-local and I just can't figure out how to ignore it" isn't going > to cut it. Ignoring such addresses is fine. But we have people arguing that it's reasonable to expect apps in general to use these things. Apps can't ignore those addresses if they're expected to use them. > > v6 link-locals make good sense as a mechanism to provide uniform > > (independent of link technology), inherently link-local services, > > like ND/RA. they are usable by a limited class of applications, but > > not applications in general. > > Does it not make sense to use them in that "limited class of > applications"? They sure work well for ssh, even when the rest of the > network is falling apart. As long as there are link-locals and the > local link is working, ssh can work. Sure! Knock yourself out. I certainly have used ssh with LL addresses, once or twice. > http will work as well, Maybe, as long as you don't do redirects. > along > with many network file systems and games. To suggest that the use of > IPv6LL for anything other than ND/RA is unholy is just ridiculous. It's the other way around. You're saying "there are limited cases where LLs work". I'm saying "they weren't designed for this purpose, there are lots of cases where LLs won't work, so don't count on LLs working in general, and don't encourage people to use LLs in general". What's your objection to telling the truth? > > great. let's encourage people to use IPv6 in a dysfunctional way, > > one that only works for a limited subset of apps, so that they'll > > never be able to realize the real advantages of IPv6. > > How is it dysfunctional? It solves real problems and it works. It works in a pinch, sometimes, but it also causes lots of apps to fail. > Stop driving this working group in to the weeds Keith. In case you haven't noticed, I'm trying to get it back on the road - the road that leads to a generally useful network that can support a wide range of apps. Trying to make scoped addresses generally applicable is a lot like being off in the weeds, because that path won't get us anywhere useful, and all it will do it frustrate those who try to follow it. > NAT is a huge pain. The biggest > pain stems from the fact that the IETF shunned the idea instead of > embracing it. That's because there's no way to make NATs work well. They're inherently broken. > Instead of developing a standard so that all NATs behave > the same, the IETF ignored NATs. Wrong. If all NATs were alike we'd still have most of the same problems. Your efforts to blame industry mistakes on IETF aren't going to accomplish anything that's technically useful, so please take it elsewhere. > I've said it before and I'll say it again. IPv6LLs are useful. We will > use them. The industry will use them. There is nothing you can do to > prevent that, just as there is nothing you can do to stop the spread > of NATs. Embrace it, and you may just have an opportunity steer it in > a direction that will be less destructive. Condone it and you will > lose control. You can't fix something that's fundamentally broken, and life is much too short to waste your time trying to do so. Indeed, the reason I'm trying to fix IPv6 is that IPv4 is already hopeless. You keep talking as if the industry is going to screw the net anyway, and you might be right. But if I were to accept that argument, it would be like accepting your argument that we can all extrapolate how well IPv6LL works in general from your limited experience with it. There's simply no justification for either conclusion. > > until native v6 service is available, anybody can still run 6to4. > > No they can't. A large number of people use NAT. You can't use 6to4 if > you're stuck behind NAT. Oh, that's right, NAT doesn't fit in to your > model of the internet. They need a NAT that runs 6to4. I have one at home, so it's clearly possible. Or maybe noncommercial products don't fit into your model of the Internet? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
