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

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Oct 2008 10:10:10 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Dave Thaler <[email-masked]>
Date: Thu, 30 Oct 2008 12:15:15 -0700

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Wing
> Sent: Thursday, October 30, 2008 10:10 AM
> To: 'Fred Baker'; 'Xing Li'; [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] Application awareness of translator in draft-baker-
> behave-v4v6-translation-00
>
> Fred, Xing, Congxiao,
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Oct 2008 12:25:27 -0700

> 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

> > * 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
> > 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
> > 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
> > * 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
> > expect more discussion around this will be necessary.  If 
> we decide to
> > have
> > "Application Aspects of IPv6 Translation" seems appropriate 
> and would
> > be
> > The alternative to translator awareness in the host's 
> application is an
> > ALG
> > We need to decide where protocols should be 'fixed up' for 
> translation.
> > This

---

From: Dave Thaler <[email-masked]>
Date: Thu, 30 Oct 2008 12:27:06 -0700

That's correct.

-Dave

> From: Dan Wing [mailto:[email-masked]]
> Sent: Thursday, October 30, 2008 12:25 PM
> To: Dave Thaler; 'Fred Baker'; 'Xing Li'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [BEHAVE] Application awareness of translator indraft-
> baker-behave-v4v6-translation-00
>
> > >    a dual node already have the mechanisms to determine whether
> they
> > > are
> > <http://www.ietf.org/mail-archive/web/behave/current/msg04129.html>
> so
> > > I
> > > NAT44, due to the existing deployment of FTP ALGs we agreed that
> FTP
> > > ALGs were
> > > tolerable.
> > >

---

From: Fred Baker <[email-masked]>
Date: Fri, 31 Oct 2008 06:18:07 +0800

Thanks; good catch. Let us rework that part.

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

> Framework document
> so I
> translation.  This

---

From: Fred Baker <[email-masked]>
Date: Fri, 31 Oct 2008 07:07:10 +0800

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

> about the translator.

Judging from IPv4 experience (which applications need to know about  
the NAT?), few if any applications need to know about the translator  
beyond the resolver; the resolver needs to understand the MITM nature  
of a translator and therefore needs to extract the IPv4 address to  
verify the record. That said, the resolver can determine that an  
address has been translated by *its* translator if it knows the  
translation prefix. I suspect that we can resolve this by having the  
resolver query a well-known name like "ipv6-translation-prefix" in the  
local domain to determine what that prefix is or whether it is  
relevant. But there will be an issue with addresses translated by  
other translators.

Note that using a well-known prefix doesn't fix this; if I send a well- 
known prefix into a remote domain as a source address and it also has  
translation, I will never get the reply.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 31 Oct 2008 09:23:24 +0200

> relevant. But there will be an issue with addresses translated by

Merely from IETF: FTP, RTSP, SIP, SMTP&Submission if you want to use an IP in 
EHLO, most probably NFS (I don't know that one).

> translation, I will never get the reply.

A well-known prefix makes it much easier to add the awareness to an 
application that needs it.

An alternative is to use some Bump-in-the-stack method whereby only the DNS 
resolver and IP stack are aware of the translation, and the application 
thinks it's using plain IPv4.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 31 Oct 2008 09:23:58 +0200

On Thursday 30 October 2008 21:25:27 ext Dan Wing, you wrote:
> But none of the proposals (IVI, NAT64, sNAT-PT) propose using that prefix
> -- they're all using operator prefixes,

There is no way the a C pre-compiler macro could cope with a run-time 
dependent value. So any new IN6_IS_ADDR_foobar would fail as well.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 31 Oct 2008 10:44:00 -0700

> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Friday, October 31, 2008 12:23 AM
> To: [email-masked]
> Cc: ext Fred Baker; Dan Wing; [email-masked]; 'Xing Li'
> Subject: Re: [BEHAVE] Application awareness of translator in 
> draft-baker-behave-v4v6-translation-00
> 

draft-wing-behave-learn-prefix-00.txt would not be adequate?

-d