[BEHAVE] Application awareness of translator in draft-baker-behave-v4v6-translation-00

["Dan Wing" <[e-mail]>]

Fred, Xing, Congxiao,

(speaking as individual contributor)

I stumbled when I read Section 1.4 of
http://tools.ietf.org/html/draft-baker-behave-v4v6-translation-00.  Three
points:

* I believe much of the text in that section belongs in the Framework document
as it is not specific to a particular kind of translation.  The text is trying
to describe the problem (when translation occurs, an application will be
connecting to a host with a different address family and over that connection
the 'wrong' address family might be exchanged; this can lead to application
confusion) and also a solution (IN6_IS_ADDR_V4MAPPED).

* Some of the text describes stuff that just doesn't work.  For example,

   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 [RFC2428]), they already need
   to do that when running on dual nodes and the presence of translators
   does not add anything.  For example, when using the socket API
   [RFC3493] 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.

IN6_IS_ADDR_V4MAPPED only knows about IANA-registered prefixes for Teredo and
6to4.  I don't believe IN6_IS_ADDR_V4MAPPED is able, by itself, to determine
there is an embedded IPv4 address in the IPv6 address -- but correct me if I'm
wrong.  In order for IN6_IS_ADDR_V4MAPPED to indicate the address went through
a translator when the translator's IPv6 prefix is chosen by the ISP (rather
than IANA) the host needs to know the IPv6 prefix (and length) in order for
the IN6_IS_ADDR_V4MAPPED macro to function as expected.  This means (a) the
host's stack needs to implement something like
draft-wing-behave-learn-prefix-00.txt and tie that learned adddress into to
its IN6_IS_ADDR_V4MAPPED macro or (b) the application needs to implement
something like draft-wing-behave-learn-prefix-00.txt.  

* The text describing EPRT/EPSV needs considerable expansion.  At this point
there is consensus that a DNSSEC-aware resolver in the end host needs to know
about the translator.  But I don't believe there is consensus that other
applications -- such as FTP -- need to be knowledgable about the translator.
In the past, Brian Carpenter has raised an objection to the idea of putting
translator awareness into IPv6 applications
<http://www.ietf.org/mail-archive/web/behave/current/msg04129.html> so I
expect more discussion around this will be necessary.  If we decide to have
the application be aware of the translator, a generalized document titled
"Application Aspects of IPv6 Translation" seems appropriate and would be
similar to the existing RFC4038 ("Application Aspects of IPv6 Transition",
previously draft-ietf-v6ops-application-transition).

The alternative to translator awareness in the host's application is an ALG
somewhere in the network (probably as part of the translator).  In BEHAVE for
NAT44, due to the existing deployment of FTP ALGs we agreed that FTP ALGs were
tolerable.  

We need to decide where protocols should be 'fixed up' for translation.  This
decision might be on an application-by-application basis.  Starting with the
FTP seems appropriate, as everyone is reasonably familiar with it.

-d

_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave