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

[Dave Thaler <[e-mail]>]

That's correct.

-Dave

> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]]
> Sent: Thursday, October 30, 2008 12:25 PM
> To: Dave Thaler; 'Fred Baker'; 'Xing Li'; [e-mail]
> Cc: [e-mail]
> Subject: RE: [BEHAVE] Application awareness of translator indraft-
> 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.
>
> 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