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.
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.
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.
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.
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.
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.
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.
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!)
??? i do not get your point. you would like to be lazy, then use
libraries that are based on URLs. otherwise, you have to use
getaddrinfo(3). other than that, either your design is broken or
you are lazy.
itojun
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf