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

[Fred Baker <[e-mail]>]

Thanks; good catch. Let us rework that part.

On Oct 31, 2008, at 1:10 AM, Dan Wing wrote:

> 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