Jun-ichiro itojun Hagino wrote: >>> how many applications do you have that does not run across NATs? >>> >>> >> 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 :) >> at my last job, where we worked on distributed computing systems? >> several more than that. >> > > 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. >>> how many of them have hardcoded 32bit address field in the payload? >>> >> hard to say. I tried to promote IPv6-awareness at my last job and to >> get developers to stop assuming that an address was 32 bits. >> >> but the bigger problem isn't the hard-coded address size - it's the >> conflict between the application writer's desire that the network >> provide complete connectivity (imagine having a network that actually >> provided best-effort packet delivery!), and the various things that >> exist to split the network up into realms with arbitrary constraints on >> how traffic can be routed between those realms. having multiple address >> realms of any kind - be they private address realms behind NATs, or >> IPv4/IPv6, or whatever - basically forces apps to implement their own >> routing, and sometimes, their own addressing. and requiring apps to >> have their own routing is tantamount to requiring them to have their own >> infrastructure that is rooted in the public Internet (probably on port >> 80) where all nodes can presumably reach them. >> > > 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. > 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) > i have been trying to persuade openssh coders to have functionality > to re-connect ssh session even when TCP session go down. if you tunnel > everything over ssh, you won. > sigh. yes that would be valuable functionality, but somehow I don't think that the answer to every problem imposed by shortsighted hacks in the network is to push things down another layer. and this kind of solution only solves the problem for two-node applications. >> it's much simpler to write a distributed app that is either entirely >> IPv4 or entirely IPv6 than to write one that supports both. >> > > 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. > or .Net framework (Windows) or > CFNetwork (MacOS X) can handle it for you inside the library. > only if you want your application to be crippled in other ways. (my, you have a simplistic view of the application world!) Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf