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

IN6_IS_ADDR_V4MAPPED() specifically tests if an address is an IPv4-mapped
address (::FFFF:<IPv4-address>) as defined in RFC 3493 section 3.7.
It does not know about Teredo or 6to4 or anything else.

-Dave

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Dan Wing
> Sent: Thursday, October 30, 2008 10:10 AM
> To: 'Fred Baker'; 'Xing Li'; congxiao@cernet.edu.cn
> Cc: behave@ietf.org
> Subject: [BEHAVE] Application awareness of translator in draft-baker-
> behave-v4v6-translation-00
>
> 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
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave