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

Hi Chair，
  Thanks for comments. 
  Once I communicated with some operators and colleges about current 
situation of 
NATs deployment. They raised an issue that an internal server can not 
share an public
IP address with other internal subscribers. The scenario is similar to 
"DMZ hosts" indeed.
  So this draft describes a method of port assignment. Because a service 
that use private
port may be provided, so port range should not be constant, not only 
<1-1024>, but also 
<1025-2048>, or <x-y>.  And also, the rest ports should not be wasted and 
they could be 
assigned by others.
  With deploying of NATs, it may offset negative effects that bring to the 
people who 
are erecting servers in his/her home.

Cheers,
Wei

behave-bounces@ietf.org  2013-07-17 06:30:49:

> 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