i guess we are living with very different assumptions. > > no, the people who have implemented your applications that are written in > > IPv4-only and NAT-unfriendly, to be IPv4/v6 bilingual. i do not care > > about NAT (un)friendliness, i just need it to support IPv6. > > > you have it backwards. It is the NATs that are unfriendly to apps, not > the other way around. i guess we agree on this point, but recent IETF documents got it backwards so i worded it the way presented in the above. > it's easy to write a distributed app that can handle the case where all > nodes are IPv4, or the case where all nodes are IPv6. it is much more > difficult to write such an app that can handle the case where some nodes > are IPv4, some are IPv6, some are both, and there is a need to > communicate between arbitrary pairs of nodes within the app and to allow > some nodes to do referrals to other nodes. DNS names are not a good way > to solve this problem for reasons of performance and reliability and > because a DNS name does not, in practice, uniquely bind to a particular > host. sorry, you are, too lazy. remember the days when we had bitnet, decnet and compuserve (niftyserve in japan) in email world. we had a lot of technologies, or tricks i would say, to make emails get delivered from/to arbitrary networks. in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the Internet. of course. > > well, that depends on what kind of programming language you will be > > using. Python uses a model where you explicitly need to invoke bind(2) > > and getaddrinfo(3), so the programmer has to be knowledgeable enough > > to handle IPv4/v6 stuff. iirc Ruby TCPSocket class embeds all the > > details about getaddrinfo(3) loop within the class/instance method, > > so you do not have to care about which IP version is in use. > > > it is not reasonable to assume that for all apps the correct model is to > do a DNS lookup and then try the resulting IP addresses one at a time > until a connection succeeds for one of them. without giving out the details of your "correct model" we cannot discuss. go by mathematical rules, first you give me axioms and then we talk about your theories. do not call theories a "fact" or "correct model" because we cannot define them. > that, and getaddrinfo() is broken in a great many ways: it isn't tied to > DNS (so if your app is defined to use DNS then you can't trust > getaddrinfo() to do what your app needs); even if the implementation > does use DNS, getaddrinfo() can only do A and AAAA queries, it's not > asynchronous, if you want PTR, MX and NS records, use res_send and stuff. use getnameinfo NI_NAMEREQD and getaddrinfo AI_NUMERICHOST if you want DNS resolution to happen for certain. > and the whole idea that a host stack can select a > source/destination address pair by trial-and-error and get good results > within a reasonable time is, quite frankly, a joke. we agree on this point. i'm having trouble understaing the entire "source address selection" stuff. it won't get deployed nor properly managed. > > may i talk with you/designer of PVM/MPI code so that they can implement > > them in IPv6-friendly manner? privately. > > > I don't work there any more, and none of the people whom I knew that > worked on those codes work there any more either. ok, you need bump-in-the-stack (hitachi) or bump-in-the-library (erik nordmark/sun microsystems). > > there were tons of multipath TCP drafts, but there's no real > > authentication so all of them failed badly. so i see some future in ssh. > > ssh is not a bad protocol, but it doesn't solve the > multiple-addresses-per-host problem, even if you change it to allow > peers to re-connect (which would be a nice feature). what is the problem you have with "multiple-addresses-per-host" problem? i never had any problem even with IPv4. > > please tell me, your apps are totally multicast or broadcast? > > if not, we need to solve 2-nodes communication first, then you can > > solve communication among n (n could be very big) nodes. > > > this isn't a multicast or broadcast problem I'm speaking of. I'm > speaking of the need for the network to provide complete connectivity > between arbitrary pairs of nodes in a distributed system. describe what is "complete connectivity" in your definition. are you talking about QoS? > > then use vendor libraries that are URL-based. > > > my, you have a simplistic view of the application world! you did not give me the details, so i have to guessing. the last note. i guess i have a clear idea about how to make Skype dual stack. current Skype protocol is totally IPv4-only (see "silver needle in skype" paper), but i can make it dual stack, i mean, mixture of IPv4-only, IPv4/v6 dual stack and IPv6-only. if you are the IPv6 guy in Skype, we need to talk :-) itojun _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf