Stas Sergeev <stsp@xxxxxxx> writes: > 25.06.2013 11:33, Mateusz Viste пишет: >> Well, the challenge is simple: let's say that a dos app wants to connect to 1.2.3.4. There is no chance to 'translate' this into an ipv6 address, because both protocols use very different addressing models. > How about this: > http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.hale001%2Fipv6d0031001726.htm Those are not on the wire addresses. Those are just for sockets that can talk to ipv4 and ipv6 addresses at the same time. Dual stack sockets work but can be a little odd sometimes. To use them would require upgrading socket calls and literal addresses of slirp and that is no likely to be worth the effort. If you happen to have something like NAT64 upstream you can implement 464xlate and get essentialy native IPv4 connectivity and that will handle connecting to 1.2.3.4. But at that point you linux box should already have ipv4 addresses so doing anything in taprouter or dosemu is pointless. Another painful example of the problems of trying to NAT between address families is connecting over ipv6 to an ftp server. What happens when the IPv6 ftp server tells the DOS IPv4 ftp client to connect to 2001:DB8:12:34:::21. The DOS ftp client doesn't won't have a clue what to do with that address. There are lots of protocols with that problem ftp is just the oldest of them. Certainly classes of web pages from services such as Akamai (so no where important) embbed ip address literals into web pages. Again defeating attempts to translate names in dns. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
