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

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

> 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.

Thanks.  

But none of the proposals (IVI, NAT64, sNAT-PT) propose using that prefix --
they're all using operator prefixes,
http://tools.ietf.org/html/draft-baker-behave-v4v6-framework-00#appendix-A.2 

So IN6_IS_ADDR_V4MAPPED would return false for a translated address, right?

-d


> -Dave
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Dan Wing
> > Sent: Thursday, October 30, 2008 10:10 AM
> > To: 'Fred Baker'; 'Xing Li'; [e-mail]
> > Cc: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
> 

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