> > 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. > 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 > > 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". one way is to have a session-layer protocol (finally!). or, you can switch from TCP to SCTP. 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. > 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. or .Net framework (Windows) or CFNetwork (MacOS X) can handle it for you inside the library. http://www.amazon.com/exec/obidos/ASIN/(A1555583180(B itojun _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf