Re: [BEHAVE] (no subject)

[Dan Wing <[e-mail]>]

On Jun 18, 2013, at 1:33 PM, ivan c <[e-mail]> wrote:

> Hi Senthil,
> 
> Thanks for your message. You might want to read
> http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 
> It features the list of updates to the existing RFC, adapted to new usage
> contexts such as CGNs, mobile networks, etc.
> 
> 
> On Tue, 18 Jun 2013 19:24:50 +0000, "Senthil Sivakumar (ssenthil)"
> 
>>> 
>>> Are you talking about UDP port preservation? 
>> 
>> Both TCP & UDP. The latest implementation in some router families is not
>> to have port preservation
>> (for both TCP & UDP).
>> 
> 
> The discussion here is not about UDP. UDP port preservation should
> generally not be implemented by NATs, as it could generate conflicts when 2
> internal hosts using the same local port, each with a session to the same
> endpoint. This would break end-to-end connectivity in rare cases, as there
> is no fallback mechanism (as opposed to TCP).
> 
> To be clear, the requirements are as follows:
> * NAT SHOULD NOT use UDP port preservation
> * NAT SHOULD use TCP port preservation
> 
> Here are some NATs that have been tested and implement TCP port
> preservation:
> in the UK:
> BT (British Telecom) (house-made gateway) - number 1 provider
> Virgin (house-made gateway) - number 2 provider
> Sky (Sagemcom) - number 3 provider
> 
> in France:
> Orange (Livebox) (house-made gateway) - number 1 provider
> Free (Freebox) (house-made gateway) - number 2 provider
> SFR/Neuf (Neufbox) (house-made gateway) - number 3 provider
> 
> This covers the overwhelming majority of subscribers.
> 
> We have the same results in Spain in Italy.
> 
> Misc:
> Linksys E1200, latest generation.
> Netgear, various models
> 
> 
> It is difficult to find any NAT that does *not* implement TCP port
> preservation in these countries.
> If you think some gateway implementations have dropped TCP port
> preservation, you need to substantially support your claim by a reference.

It is impossible to preserve TCP ports on a large or busy NAT (or a NAT that is both large and busy) because multiple clients will simultaneously use the same source port, especially if the clients are using the same operating system because most operating systems unfortunately do not bother to randomize their source ports.

It is also impossible to preserve TCP ports with A+P-related IPv4 address sharing mechanisms.  A+P was first described in RFC6346, and in the MAP-E and MAP-T specifications in Softwires (draft-ietf-softwire-map).  There are 2-3 similar Internet Drafts which have a static assignment of ports to subscribers.

-d


> We are not aware of anything that would support it. 
> 
> 
>> 
>> Most of the NATs that I know don’t do port overloading any more.
>> RFC 5382 also says,
>> REQ-7:  A NAT MUST NOT have a "Port assignment" behavior of "Port
>>      overloading" for TCP.
>> 
> 
> This is the purpose of the new draft
> http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 , to
> make the use case for port overloading, as it is needed in CGNs. It wasn't
> needed nearly as much in 2005 when RFC 5382 was first written.
> 
> REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port
> overloading" for TCP
> is too stringent, as proved in my earlier message and in the
> draft-ietf-behave-requirements-update-00, and not needed.
> 
> Port overloading is perfectly acceptable when the remote endpoints are
> distinct, as it preserves the uniqueness of the 5-tuple.
> 
> As a result, REQ-7 must be corrected.
> 
> 
> 
> -- 
> _Ivan Chollet_
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave