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 RD > >> 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. > > Cheers, > Rajiv > > >> -----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. >> >> Simon >> -- >> 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 > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
