Re: DOSemu networking made easy

[email protected] (Eric W. Biederman)
Newsgroups org.kernel.vger.linux-msdos
Message-ID <[email protected]>
Stas Sergeev <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.