On Wed, 2005-02-02 at 03:45 -0500, Bound, Jim wrote: > > On Tue, 2005-02-01 at 23:25 -0500, Bound, Jim wrote: <SNIP> > > > But, besides v4mapped being widely deployed on "vendor" > > "production" > > > shipping code bases, used today by applications, > > > > Please name these 'vendor's and 'applications' I am quite > > sure if you ask them that they think it should be removed if > > they have made to try the code run on more than a single platform. > > I will not name applications but HP, IBM, Sun, and vendors who > productize Linux and FreeBSD to name a few. V4-mapped addresses are part > of the POSIX standards as stated in the Literature reference below.
As mentioned Linux is still the only to support v4-mapped addresses, that is that it is active per default. There is a toggle to turn it off. OpenBSD doesn't support it at all and NetBSD and FreeBSD only after toggling a sysctl setting. I had actually hoped that you identified the applications that you where mentioning as then we could ask the developers if they supported more than one platform or just only on one where they knew what to expect. Please do an inquiry under the developers you know and ask them about their experiences with programming IPv6 capable services. The biggest 'fun' of programming a multi-platform application, good examples, as mentioned are Apache and Mozilla, is that you never know what the underlying platform is going to do. A large number of ifdef's weird cases doesn't make the code easier to develop nor deploy. It is indeed in POSIX, but why don't admit that it is a mistake to have it? I though that it was a great idea too, until the Windows implementation came out that does not and cannot support it due to it's separate stacks. And there are a number of other platforms who likely have the same issue, especially if programming in a modular way. We still have a chance IPv4 mapped to at least _deprecate_, that is what I mentioned in my other message, the usage of these addresses and to note that implementors should really be using separate sockets, which is also what getaddrinfo() tells one to do. Simply explaining to people, with a small note, that they should not use it because it will cause them many pains in several coding aspects, especially when porting it to other platforms. Socket API's > > > believe v4mapped is a very useful and elegant solution for > > application > > > providers to provide a common binary v4+v6 solution as an option > > > "technically" and superior to not using it. > > > > Please look at the Apache2 APR code which demonstrates how 'elegant' > > this solution is because it is not default. > > The default is up to the software developer Netscape chose differently. > It is a choice in the standard. What has Netscape to do with Apache? Or am I really missing something? Then again I don't follow corporate takeovers and such, got better things to do; Netscape do have some influence with Mozilla/Firefox et al, and they also had a lot of problems with this, they actually almost refused to do a Windows IPv6 version because they didn't understand the concept of a separate IPv6 and IPv4 socket. Also see: https://bugzilla.mozilla.org/show_bug.cgi?id=175340 Apache's APR has the same problem and shows how much work one has to do when supporting multiple Operating Systems. I just named the above as that is very common and readable code and most likely used by, hmm jup, HP, IBM and Sun as they all have some form of repackaged-Apache in their 'products'. Please do realize that many people do the part that is implemented in APR on their own, you want to to reinvent all those bugs and have them get all the trouble over and over? There are many more examples of code out on the internet that demonstrate that having the v4-mapped addresses only gives a lot of issues. You haven't named one application though that does not have it. > > > I emphatically disagree > > > with Itojun, cmetz, et al referenced and we had this debate > > many years > > > ago, then again had the debate, and that view lost and we > > should not > > > revisit it again. > > > > You mean some people shoved the arguments away without having > > any background in the subject? > > That is a baldface indirect lie, and slander in the form of a question > to the team that worked on this for a long time, and you were not in > those conversations or on the api-list or part of the team, which was > where the in depth technical debate took place. Thanks for calling it a lie, any arguments to support it ? You mention yourself that the view was lost. Maybe time to refresh that view? Many policies get changed and reformed after they have been put to ground. Even RFC's get updated. Why is it not possible to do a good thing and update it now. IPv6 is not *that* deployed yet, there is still time to get it going in the correct direction. As some others have mentioned before, if these fundamental things are not tackled, the people doing IPv7 will soon be here and will be facing the same issues again, maybe they will get it right? > Now that you have decided to question the honor of the team that worked > on this discussion, and I was part of that team, I suggest you and I > take this offline in person face to face if you happen to be in > Minneapolis around March 6-9. I will look forward to it unless you can > only dishonor persons behind an indirect email message and don't have > the guts to do it in person? Unfortunately I am doing all of this in my spare time and as an individual, there are people who actually do this you know, otherwise I would tell you all of this face to face, but why offline actually, isn't the IETF a public organization? Oh, and you might not remember, but I already asked you a somewhat similar question before, "how many users are actually connected to your nice Internet2" when you where promoting that in Brussels last year, but then you didn't have time to answer the question either. I probably was not important enough for you. Not that I mind, many people have many other more important things to do and I am just a student with most of the time a little bit too big mouth stepping on peoples feet. As for the in person, anyone can easily validate that I wrote this message, there is a reason I PGP sign my emails. I have nothing to hide and I do completely stand behind my arguments. If you have an argument with me, which you do not want to publicly mention, you know my email address. > > > No one has to implement a port to IPv6 or a new application with > > > v4mapped addresses. It is merely an option that is available to a > > > programmer and upto them and it is available on production > > platforms > > > today. > > > > The production platforms mostly use KAME stacks, the other is Windows. > > KAME is one version and view of FreeBSD. I have no response regarding > what Windows supports or does not support. KAME is the IPv6 stack that FreeBSD has, unless I miss something, there is nothing else. Note that Linux also took a lot of KAME code into the mainstream kernel by means of the USAGI project. > > Guess what both of these platform don't have, at least turned on per > > default: ipv4-mapped. > > That is fine and not the point of this discussion. The point of this > discussion is to continue to support the ability to use v4-mapped > addresses. That I believe has consensus. If you would count the number of people who sent a message and where in favor of dropping the support it really is in favor of dropping it. You cannot simply claim consensus because you would like to. > > > > Please name the platforms you call 'production'. > > Did above your repeating yourself. In case you would miss out on the question ;) > > > Mark Andrews point is quite valid and that is the responsibility of > > > each implementation to document their use of v4mapped, and out of > > > scope for the IETF as that is an implementation manner. > > Whether it is > > > useful to document various behaviors (INFO, BCP) is not clear to me > > > that is necesary and see UNIX Network Programming Volume I > > Third Edition. > > > > Which nicely mentions the use of getaddrinfo() and separately doing :: > > and 0.0.0.0 with IPV6_ONLY sockets because of the inherit > > issues mentioned by Itojun. > > Give me a break Jeroen. <sarcasm> I don't think I have the financial means to give you a good enough holiday, sorry, if I had I would give it to you :) </sarcasm> > Read pp's 315 and on; the authors presented all > cases and v4-mapped is in the tables and it provides an unbiased view > presenting both solutions, I saw preliminary versions of this section > before it was published from one of the reviewers and I recall then it > was an unbiased version as was the Second Edition (minus the new > IPv6-ONLY option). Which is what I said above, they do discuss it, but they mention that one should use the IPV6-ONLY option. Thus why is it not possible to amend the text in a similar way? > The compromise we defined in the API is to support IPv6-ONLY option > there is no problem here at all. Then why not simply additionally add "please use IPV6-ONLY as there are many drawbacks when wanting to stay portable across different platforms" ? > I see no point of further responses to this email it has all been > discussed before, and the bogus accusations like the one you made above > too. Thank you again for mentioning that I make 'bogus accusations'. Ignoring is of course the best option in those cases where you don't want to make a case for your arguments. And indeed I mentioned three times or so that simply noting that using v4-mapped, or better said using getaddrinfo() without IPV6-ONLY causes a lot of problems. A tiny amendment would solve my argument. If you think that I am being hostile, then please take the break, you'll then need it for sure. Greets, Jeroen
signature.asc
Description: This is a digitally signed message part
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
