Hi, Simon, See inline.
Le 3 août 2011 à 15:05, Simon Perreault a écrit : > On 2011-08-03 04:01, Rémi Després wrote: >> >> Le 3 août 2011 à 00:39, Rajiv Asati (rajiva) a écrit : >> >>> Satoru-san, >>> >>> This is an important point that most of us forget that restricting to >>> "n" ports doesn't equate to just "n" NAT sessions rather many more than >>> n sessions. We must add that to the 4v6 motivation draft as well as to >>> the 4v6 comparison draft. >> >> +1 > > I think there is an important point missing from this discussion. It is > tricky but it has important practical consequences. > > As I said, "The 900G figure is valid, *as long as internal hosts reuse > the same source address+port for different destinations*." > > The "as long as ..." part is important. Agreed. > I don't know of any operating > system that behaves like that. The point is that this behavior concerns the NAT44 of a CE that supports address sharing (it doesn't concern a PC OS). By permitting _this_ NAT to do endpoint-dependent mapping for TCP connections, the number of supported connections can be largely increased (if found useful). Cheers, RD > That is, a different source port will be > used for each new outbound session, regardless of the destination. > Therefore, in practice, each session will require one NAT binding, which > will in turn consume one external port. > > So the 900G figure is valid *in theory*, but *in practice* we're stuck > with a number of sessions roughly equal to the number of external ports > available on the NAT. > > Now, if there is no NAT and the host itself is constrained to a given > port range, the OS will usually start reusing source ports for different > destinations when there is pressure to do so (i.e. when all source ports > are in use). Where a NAT would simply drop the session-creating packet, > in this case the OS is able to reuse a source port. So if there is no > NAT, the 900G figure is also valid in practice. > > Simon > >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] >>> On Behalf >>>> Of Simon Perreault >>>> Sent: Tuesday, August 02, 2011 9:55 AM >>>> To: [email protected] >>>> Subject: Re: [Softwires] Clarification of the stateles/stateful >>> discussion >>>> >>>> Simon Perreault wrote, on 08/02/2011 09:24 AM: >>>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM: >>>>>> Thanks, a clarification has made to clear a confusion of restricted >>> port >>>>>> set/ranges and NAT session table limitation. Even if a CPE is >>> allocated 256 >>>>>> ports, NAT session can be made over 900G sessions in theory. >>> ('2^32'<Full >>>>>> 32bits v4 address> - '2^29'<class-D/E> - '2^7'<0/8,127/8>) * >>> 2^8<256 >>>> ports>. >>>>> >>>>> This is only true for endpoint-dependent NATs, which are forbidden >>> by the >>>> BEHAVE >>>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have >>>>> endpoint-independent mapping behaviour. This means that each NAT >>> session >>>> will >>>>> consume one external port. >>>> >>>> Sorry, I confused the terminology. Each NAT *binding* will consume one >>>> external >>>> port. There may be multiple session to different destinations using >>> the same >>>> external port. The 900G figure is valid, as long as internal hosts >>> reuse the >>>> same source address+port for different destinations. > > > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
