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

[Simon Perreault <[e-mail]>]

It seems you guys are forgetting about RFC 4787 REQ-3 a):

      a) If the host's source port was in the range 0-1023, it is
         RECOMMENDED the NAT's source port be in the same range.  If the
         host's source port was in the range 1024-65535, it is
         RECOMMENDED that the NAT's source port be in that range.

Does anything more need to be said about this?

Simon

Le 2013-07-17 10:08, [e-mail] a écrit :
> 
> 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.
> 
>    (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
> 
> 
> 
> [e-mail]  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: [e-mail] [[e-mail]] on behalf of
>> [e-mail] [[e-mail]]
>> Sent: Tuesday, July 16, 2013 8:22 PM
>> To: Reinaldo Penno (repenno)
>> Cc: [e-mail]; [e-mail]; 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
>>
>>
>> [e-mail] 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: [e-mail] [[e-mail]] on behalf of
>> > Dan Wing (dwing)
>> > Sent: Tuesday, July 16, 2013 3:30 PM
>> > To: [e-mail]
>> > Cc: [e-mail]
>> > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
>>
>> >
>> > On Jul 15, 2013, at 2:43 AM, [e-mail] 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