Jun-ichiro itojun Hagino wrote: > i guess we are living with very different assumptions. > it's just that the needs of applications vary as widely as the needs of users. it's not as if all Internet users do nothing but email and the web, and neither is it as if all Internet applications are like HTTP or ssh. >> 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. > yes, I remember those, and I also remember the problems we had trying to make all of that work well - in particular, the problem of rewriting addresses so that the mail would still be replyable after it crossed multiple gateway boundaries. (actually I wrote a thesis on the topic). I'm sure my experience with email addressing and gateways is part of why I could see the problems with NAT earlier than most people. of course, it's not as if every application in the v4/v6 world is like email. at least some of those email protocols were designed to be store-and-forward and to allow email to be transmitted across networks without end-to-end connectivity. store-and-forward isn't appropriate for every applications protocol. (and I'd even argue that it probably shouldn't be used for email anymore, at least not in the way that SMTP currently does it, because it's really hard to arrange for errors to be reliably reported to the party that needs to know about them.) >>> 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. > I don't think there is a single "correct model" for all apps that works in a network where hosts have multiple addresses and the performance can vary significantly depending on which address pair you choose. ideally, from the application's point-of-view, the network would always perform well enough to suit the needs of the application and it wouldn't matter which source and destination address were used. also, any address would be reachable from any point in the network. the traditional IPv4 network approximately fulfilled both conditions; the current IPv4 network with NATs still mostly fulfills the first one. having multiple addresses per host/network be the normal case in IPv6 threatens to remove the first condition, and having a mixed v4/v6 network nixes the second one. >> 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. > I don't recall that this guaranteed by the API specification. >> 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. > agreed. >>> 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). > nah. basically it's easy to port either system to a pure IPv6 network, and this might have already been done; it's just hard to run an app that expects complete connectivity among all nodes on a mixed IPv4/IPv6 network. >>> 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. >> it's the fact that in IPv6 if you don't select the best source and destination address to talk to a node, you might either fail to get a connection (and have to wait a long time for a timeout), or you might get a connection that performs much worse than some other source/destination address pair you could have used. this was true for IPv4 nodes with multiple interfaces also, but this was mostly solved in IPv4 by not having multiple active network interfaces. (people tried it, it didn't work well, so they stopped doing it.) In IPv6 the normal situation for hosts on multihomed networks is to have multiple addresses, and there are several pressures to have additional addresses - like for mobility, or using ULIAs for local apps on enterprise networks so that they won't be affected by renumbering. so address selection becomes more important in IPv6 than it was in 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? > if you are building a distributed computation system and you want it to perform well then any node should be able to send packets to any other node, even if some of those nodes are IPv4 only and others are IPv6 only. > if you are the IPv6 guy in Skype, we need to talk :-) > yeah, I think I see how to make Skype dual stack too, since they already have the infrastructure needed to relay packets between two nodes that are both behind NAT - they could use the same kind of infrastructure to relay packets between v4 and v6 realms. but I'm not the ipv6 guy in Skype. :) _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf