Jun-ichiro itojun Hagino wrote: >>>> that I personally use? I'm guessing about a half-dozen, though I don't >>>> use them all everyday. some other apps work across NAT but with >>>> degraded functionality. >>>> >>> >>> okay. if you could name them we can try to convince people who are >>> responsible. >>> >>> >> the people responsible for polluting the network with NATs? it's too >> late to punish them, I fear :) >> > > 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. 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. >>> we kame are guilty for almost every application IPv6 support, including >>> Python, Apache, Ruby, Postfix (wietse rewrote the whole thing), all tools >>> on *BSD, BSD libc, whatever. honestly noone can beat us on this topic:-P >>> >>> >> and the rest of us are very appreciative! of course, not all of the >> applications that people use are those that are shipped with *BSD. and >> while it's quite helpful if programming languages support IPv6, that >> doesn't mean that the programs written in those languages will >> automatically work with IPv6. >> > > 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. 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, 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. >>> so, which is your real-world protocol which has the above problem? or >>> is it a theoretical debate? "code then spec". >>> >>> >> no, it's not a theoretical debate. I worked with a number of distributed >> systems: PVM, some MPI implementations, and one of my own design that >> didn't become so popular. There are a lot of applications layered on top >> of one or the other of these. But unless you're into high-performance >> computing you probably aren't aware of them. >> > > 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. >>> one way is to have a session-layer protocol (finally!). >>> or, you can switch from TCP to SCTP. >>> >>> >> for several reasons, SCTP is not a drop-in replacement for TCP. (but I'd >> love to see further development and standardization of multipath TCP - >> that seems like a very promising avenue) >> > > 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). > 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. >>> you have to. you cannot be that lazy. >>> >> our goal in IETF should be to allow programmers to be that lazy. >> separation of function between the host and the network is a Good Thing. >> let the hosts exchange packets and the network route them. >> >> the goal is certainly not to keep increasing complexity of the network >> and to keep making programmers' jobs more difficult. >> > > then use vendor libraries that are URL-based. > my, you have a simplistic view of the application world! Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf