Re: [BEHAVE] NAPGT request for comments, THANKS!

Hi,
  Please see inline.

Thanks,
Wei

"Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>  2013-07-17 21:30:24:

> From: "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
> Date: Wednesday, July 17, 2013 4:08 AM
> To: "Reinaldo Penno (repenno)" <repenno@cisco.com>
> Cc: "behave-bounces@ietf.org" <behave-bounces@ietf.org>, 
"behave@ietf.org" <
> behave@ietf.org>, "Dan Wing (dwing)" <dwing@cisco.com>
> Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
> 
> 
> Hi, 
>   I got what the example means. 
> 
>   1-1024 is just an example, the range could be any valid value.
> 
>   "<1-1024> might be used as NAT, <1025-65535> might be used as 
> dynamic NAPT", example is as below. 
> 
>    +----------+     +-----+    +--------+ 
>    + Internet + ----+ NAT +----+ Server + 
>    +----------+     +-----+    +--------+ 
> 
>    (1) "<1-1024> might be used as NAT" means, 
>        A server behind a NAT. 
>    A message, sent by server, its source port is in 1-1024 (or 
> 4500-4501 or ...).
>    The source address will be converted by NAT, the source port remains
>    the same. 
> 
> [Senthil] Sorry, I didn’t read the draft, but the above logic wont 
> work if there are multiple servers using the same source port.
> Also, in some applications (I think rcmd, rshell etc), the source 
> port doesn’t have to be preserved but must be below 1024.
> 
> Senthil

[Wei] I'm presenting the proposal so as to solve this problem : assign 
port 
x-y(i.e. 1-1024) to a server(for port preserving function, like NAT), 
assign 
the rest of ports to others(for common NAPT).
  Of course, if there are many servers bebind NAT and whether or not using 

the same source port, NAT has to need more than one public address.
  But in this case ,a server will never occupys all ports of a public 
address, 
just "x-y". 

Wei

> 
> 
> 
>    (2)<1025-65535> might be used as dynamic NAPT 
>        Meanwhile, many hosts are behind NAT. They attempt to access to 
>     internet. 
>        A message, sent by a host, both its source address and port will
>     be converted by NAT, and the new port will be in 1025-65535.
> 
> 
> It will make IP address assignment more effective.
> 
> Cheers, 
> Wei 
> 
> 
> 
> behave-bounces@ietf.org  2013-07-17 12:36:30:
> 
> > Hi, 
> > 
> > I'm not sure what exactly you man by "might be used as NAT". 
> > 
> > 0-1024 might be used for NAPT in a FCFS basis where port 
> > preservation (this is what we are talking about here, right?) is 
needed. 
> > 
> > As a concrete example, many IPsec Servers still expect to see the 
> > source port within 0-1024 and preferably a specific source port. If 
> > that source port is used by the NAT, and more than one IPsec client 
> > is behind it, there are a some choices available. 
> > 
> > - Some funky IPSec ALG (implemented in many products) 
> > - Give a port above 1024 and hope for the best 
> > - Deny the connection 
> > - others.. 
> > 
> > Other ports for the same public IP can be used by any other internal
> > IP address. This is very common in implementations. 
> > 
> > thanks, 
> > 
> > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of
> > meng.wei2@zte.com.cn [meng.wei2@zte.com.cn]
> > Sent: Tuesday, July 16, 2013 8:22 PM
> > To: Reinaldo Penno (repenno)
> > Cc: behave-bounces@ietf.org; behave@ietf.org; Dan Wing (dwing)
> > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
> 
> > 
> > Hi Reinaldo, 
> >   So I suppose <1-1024> might be used as NAT, <1025-65535> might be 
used as 
> > dynamic NAPT. 
> >   That is what this view says in the draft. 
> > 
> > Cheers, 
> > Wei 
> > 
> > 
> > behave-bounces@ietf.org 2013-07-17 09:52:34:
> > 
> > > I'm not sure this is a good idea. There are still some protocols 
> > > around that use ports < 1024 and maintaining the source port after 
> > > translation in this range is important. 
> > > 
> > > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of
> > > Dan Wing (dwing)
> > > Sent: Tuesday, July 16, 2013 3:30 PM
> > > To: meng.wei2@zte.com.cn
> > > Cc: behave@ietf.org
> > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
> > 
> > > 
> > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: 
> > > 
> > >     I have submitted a new draft. The objective is to solve a 
> problem that 
> > >     prevents an external client from accessing an internal server. 
> > > 
> > >     https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ 
> > > 
> > >     I expect your comments. Thanks a lot! 
> > > 
> > > Draft-meng-behave-napgt appears to describe something that is very 
> > > similar to the long-standing "DMZ host" configuration available on 
> > > almost all residential-class NAT devices.  I don't think we could 
> > > standardize that behavior, but perhaps that is possible. 
> > > 
> > > Draft-meng-behave-napgt also describes an update to the port 
> > > assignment behavior described in http://tools.ietf.
> > > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.
> > > org/html/rfc4787#section-4.2.1 (UDP).  If I understand Section 4 of 
> > > draft-meng-behave-napgt properly, it is saying that NATs should not 
> > > assign ports below 1024 to dynamic connections.  This might be 
> > > something worth considering for 
draft-ietf-behave-requirements-update? 
> > > 
> > > -d 
> > > _______________________________________________
> > > Behave mailing list
> > > Behave@ietf.org
> > > https://www.ietf.org/mailman/listinfo/behave
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave