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.
> 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
