Subject: [BEHAVE] draft-jennings-behave-nat6-00.txt

From: Cullen Jennings <[email-masked]>
Date: Sun, 6 Jul 2008 21:06:22 -0700

A draft related to the nat64 and nat46 topic ....

Begin forwarded message:

> From: [email-masked]
> Date: July 6, 2008 7:45:01 PM PDT (CA)
> To: [email-masked]
> Subject: I-D Action:draft-jennings-behave-nat6-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : NAT for IPv6-Only Hosts
> 	Author(s)       : C. Jennings
> 	Filename        : draft-jennings-behave-nat6-00.txt
> 	Pages           : 17
> 	Date            : 2008-07-06
>
> This specification defines a NAT that allows IPv6-only hosts that are
> inside the NAT to operate with IPv4 hosts that are outside the NAT.
> It requires no modifications to the v4 hosts or applications, or to
> the operating system of v6 hosts, but it does require some changes to
> v6 applications.  Typically this specification would be used to allow
> the hosts inside a NAT to connect to hosts outside it; but under some
> limitations, it can also allow hosts outside to connect to hosts
> inside.
> The goal of this draft is to consider what is the minimal feasible
> approach to this problem.  The draft is being discussed on the
> [email-masked] list.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jennings-behave-nat6-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Jul 2008 19:13:00 -0700

> A draft related to the nat64 and nat46 topic ....

Your draft appears to do suggest three significant things:

  * require NAT6 functionality in the v6 host.  This would cause the v6 host
to either (a) synthesize its own AAAA records (rather than having an external
DNS server do this on the host's behalf) pointing at the NAT6 box or (b) have
its applications be v4-aware and generate v6 packets using the NAT6 prefix.
Placing the NAT functionality into the host is described in section 1.2.4 of
draft-bagnulo-behave-nat64-00, with the same benefit (DNSSEC) as cited in your
draft.

  * require all v6 applications to handle the NAT6's address rewriting
themselves.  For FTP, your I-D says "There is no need for an FTP ALG; use
EPSV".  I found recently that the FTP server at ftp.rfc-editor.org
(ftp.isi.edu) does not support EPSV (see below).  But an FTP client on a v6
host could fall back to PASV (just as my FreeBSD FTP client does), and if that
FTP client knows how to prefix the NAT6's address to the v4 address returned
in the PASV response, it could successfully make a data connection to the FTP
server.  I believe that is the sort of behavior you are proposing that v6
applications adopt for NAT6?

  * require a stateful NAT6 box.  draft-bagnulo-behave-nat64-00 (and the
deprecated NAT-PT) uses SIIT (RFC2765).  Is there a disadvantage to using SIIT
or an advantage to using stateful v6->v4 translation that the working group
should be aware of?

-d

-----

     %date
     Mon Jul  7 19:07:23 PDT 2008
     %ftp -a -d ftp.rfc-editor.org
     Connected to ftp.rfc-editor.org.
     220 ftp.isi.edu NcFTPd Server (free educational license) ready.
     ftp_login: user `<null>' pass `<null>' host `ftp.rfc-editor.org'
     ---> USER anonymous
     331 Guest login ok, send your complete e-mail address as password.
     ---> PASS XXXX
     230-You are user #14 of 550 simultaneous users allowed.
     ...
     230-
     230 Logged in anonymously.
     ---> SYST
     215 UNIX Type: L8
     Remote system type is UNIX.
     Using binary mode to transfer files.
     ---> FEAT
     211-Extensions supported:
      CLNT
      MDTM
      MLST
type*;size*;modify*;UNIX.mode*;UNIX.owner;UNIX.uid;UNIX.group;UNIX.gi
d;unique
      PASV
      REST STREAM
      SIZE
      TVFS
      Compliance Level: 19981201 (IETF mlst-05)
     211 End.
     features[FEAT_FEAT] = 1
     features[FEAT_MDTM] = 1
     features[FEAT_MLST] = 1
     features[FEAT_REST_STREAM] = 1
     features[FEAT_SIZE] = 1
     features[FEAT_TVFS] = 1
     got localcwd as `/home2/dwing'
     ---> PWD
     257 "/" is cwd.
     got remotecwd as `/'
     ftp> dir
     ---> EPSV
     502 Unimplemented command.
     disabling epsv4 for this connection
     ---> PASV
     227 Entering Passive Mode (128,9,176,20,204,35)
     ---> LIST
     150 Data connection accepted from 208.201.244.42:53897; transfer
starting.
     drwxrwxr-x   2 ftpuser  ftpusers       512 Apr 24  1995 arts
     drwxrwxr-x   2 ftpuser  ftpusers      1024 Feb 17  2005 atomic-doc
     lrwxrwxrwx   1 ftpuser  ftpusers         7 May 28 12:35 bin -> usr/bin
     dr-xr-xr-x   2 ftpuser  ftpusers       512 Apr 24  1995 bin.0
     drwxrwxrwx   2 ftpuser  ftpusers       512 Sep 21  2007 craig
     ...

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Jul 2008 17:32:01 -0700

> draft-bagnulo-behave-nat64-00, with the same benefit (DNSSEC) as  

I think it is important to differentiate changes to the OS from  
changes to the Applications in talking about changes to the hosts but  
yes, this imagined changes to at least the applications.

> applications adopt for NAT6?

Sounds like a good suggestion to do the PASV approach. I was more  
interested in a conversation about what was the best way to do it than  
proposing that this was the right answer.

> or an advantage to using stateful v6->v4 translation that the  

I think this and the DNSALG stuff is some of the really key issues we  
need some good WG discussion on.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Jul 2008 18:02:41 -0700

> > draft-bagnulo-behave-nat64-00, with the same benefit (DNSSEC) as  
> > cited in your draft.
> 
> changes to the Applications in talking about changes to the 
> hosts but yes, this imagined changes to at least the applications.

So NAT6 proposes no changes to the v6 stack of the host.  Rather, 
NAT6 proposes that for those v6 applications that need to accept 
incoming connections (e.g., FTP and all others), they be "NAT6
capable", which appears to mean that such applications:
  - may need to send DNS A queries (if they get hostnames in
    their control channel)
  - prefix ::FFFF/96 before the v4 address.

Is that correct?

> > (ftp.isi.edu) does not support EPSV (see below).  But an 
> > FTP client  
> > on a v6
> > server.  I believe that is the sort of behavior you are proposing  
> > that v6 applications adopt for NAT6?
> 
> interested in a conversation about what was the best way to 
> do it than proposing that this was the right answer.
>
> > or an advantage to using stateful v6->v4 translation that the  
> > working group should be aware of?
> 
> I think this and the DNSALG stuff is some of the really key 
> issues we need some good WG discussion on.

I hope everyone feels free to discuss SITT versus stateful NAT,
and DNSALG versus make-v6-applications-NAT6-aware on the mailing
list.  We have chartered work that will consume a substantial
portion of the BEHAVE meeting in Dublin, and scant time to do
much else.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Jul 2008 11:05:34 +1200

On 2008-07-09 13:02, Dan Wing wrote:
...
> list.  

Conceptually, I definitely prefer the draft-bagnulo-behave-nat64
model (which I think of as a SIIT protocol translator in series
with a pretty much industry-standard IPv4-IPv4 NAT). I have a lot
of confidence that this can be made to work as well as conventional
NAT, and the DNS64 function seems robust too.

I think the draft-jennings-behave-nat6 approach has the negative
characteristic of importing NAT-related issues into IPv6-related
code, and that is something we want to avoid if we can.

   Brian

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 24 Jul 2008 17:37:52 +0200

Cullen,

Some comments as an individual.

I think I like the position that most application needs to be NAT aware 
and if so, they could easily traverse a NAT6 also. I think that is quite 
reasonable for any application that isn't a basic server client 
application. I do would like to see if we can get like HTTP to work over 
the translator without causing massive future issues without modifying 
the nodes. I guess that means DNS ALG and I hope we can find some 
solution that doesn't screw up the world.

In Section 5.1 you discuss hairpinning from v6 to translated address and 
then back through another translated address to another IPv6 host. Any 
idea on how to avoid this? They should be able to talk to each other.

In Section 5.3.1 when discussing the MTU issue. I think forcing DF bit 
when receiving unfragmented IPv6 packets then one needs to be able to 
indicate back this failure to that the IPv6 sender can address it. The 
big problem here is that you don't really know what the applications 
wish on fragmentation in this case is. You could do fragmentation on the 
IPv4 side and things would work, until you hit a v4 NAT that blackholes 
fragments and you get strange losses. You get similar problems when you 
set the DF and don't get any ICMP back about it. I think option FRAG-A 
is better as long as you can get the information flow about the MTU to 
get back across the translator as often as possible. But still this is a 
tough choice.

Section 5.8:

I don't see the complexities of adding DCCP and SCTP. On IPv6 they have 
a much better chance of making it then in todays heavily NATed IPv4 
space. My view is that we should try to improve the world, instead of 
only be pragmatic about it and live with everything over UDP and short 
keep-alives.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jul 2008 18:44:14 +0200

Magnus Westerlund escribió:
> I think I like the position that most application needs to be NAT 
> aware and if so, they could easily traverse a NAT6 also. I think that 
> is quite reasonable for any application that isn't a basic server 
> client application. I do would like to see if we can get like HTTP to 
> work over the translator without causing massive future issues without 
> modifying the nodes. I guess that means DNS ALG and I hope we can find 
> some solution that doesn't screw up the world.
this also is likely to imply not to use the v4 mapped prefix, i am afraid

regards, marcelo