Subject: (ngtrans) Question about SIIT RFC 2765

From: Grigory Kljuchnikov <[email-masked]>
Date: Thu, 18 Oct 2001 19:25:54 +0400 (MSK)

Hello,

I'm sorry I didn't see mail archive it's very big and there isn't
a search system for it. And may be there is an answer for my question
in archive. But may be anyone can take me an entry point to it or
an answer.

RFC 2765 in 1.3 says:

   There are no extra changes needed to applications to operate through
   a translator beyond what applications already need to do to operate
   on a dual node. The applications that have been modified to work on
   a dual node already have the mechanisms to determine whether they are
   communicating with an IPv4 or an IPv6 peer.  Thus if the applications
   need to modify their behavior depending on the type of the peer, such
   as ftp determining whether to fallback to using the PORT/PASV command
   when EPRT/EPSV fails (as specified in [FTPEXT]), they already need to
   do that when running on dual nodes and the presense of translators
   does not add anything.  For example, when using the socket API
   [BSDAPI] the applications know that the peer is IPv6 if they get an
   AF_INET6 address from the name service and the address is not an
   IPv4-mapped address (i.e., IN6_IS_ADDR_V4MAPPED returns false).  If
   this is not the case, i.e., the address is AF_INET or an IPv4-mapped
   IPv6 address, the peer is IPv4.

But what about upper layer protocols those carry address information such
as FTP? Does SIIT need to change FTP protocol information in case when packet
carries IP address?

And what about IPv4-mapped addresses? RFC 2553 says:

   Applications may use PF_INET6 sockets to open TCP connections to IPv4
   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
   destination's IPv4 address as an IPv4-mapped IPv6 address, and
   passing that address, within a sockaddr_in6 structure, in the
   connect() or sendto() call.  When applications use PF_INET6 sockets
   to accept TCP connections from IPv4 nodes, or receive UDP packets
   from IPv4 nodes, the system returns the peer's address to the
   application in the accept(), recvfrom(), or getpeername() call using
   a sockaddr_in6 structure encoded this way.

If we use IPv4-mapped addresses as destination address for some
IPv6-enabled application, the system make an IPv4 connection with destination.
We plan to use some new addresses for thise case (without name):

	::ffff:ffff:a.b.c.d

Is it right?

And one more, in RFC 2765 (section 1.3, last paragraph):

   One way of viewing the translator, which might help clarify why
   applications do not need to know that a translator is used, is to
   look at the information that is passed from the transport layer to
   the network layer.  If the transport passes down an IPv4 address
   (whether or not is in the IPv4-mapped encoding) this means that at
   some point there will be IPv4 packets generated.  In a dual node the
   generation of the IPv4 packets takes place in the sending node.  In
   an IPv6-only node conceptually the only difference is that the IPv4
   packet is generated by the translator - all the information that the
   transport layer passed to the network layer will be conveyed to the
   translator in some form.  That form just "happens" to be in the form
   of an IPv6 header.

What is mean? If address is IPv4-mapped then should be exist an IPv4
connection.

Many thanks.

Best regards,

Grigory Klyuchnikov, System Engineer,
Institute for System Programming
Russian Academy of Sciences

---

From: Grigory Kljuchnikov <[email-masked]>
Date: Fri, 19 Oct 2001 12:56:54 +0400 (MSK)

Sorry, my questions aren't correct. I've read this section today
morning one more time, and I've understood what it says.

Sorry, if I take your time :(