On Nov 7, 2011 6:58 AM, "Alain Durand" <[email protected]> wrote: > > > On Nov 4, 2011, at 2:21 AM, Henderickx, Wim (Wim) wrote: > > > Reinaldo, > > > > What happens if a customer wants to get more ports than the CPE owns? > > Similar to the other stateless proposals such a 4rd or divi, there is no provision to dynamically extend that range allocated by the ISP. > The consensus that was expressed a number of time in the wg is that if you need this flexibility, > a stateless solution is the wrong approach, you'd be be better of with a stateful solution. > > > > How would PCP operate with this model? > > This is an interesting question... This should make the life of the PCP server rather easy, as there will be no state to keep there too. >
Interesting indeed, no pcp and no alg. So for stateless solutions anything that falls out of your static cgn allocation will not work? Like sip/rtp? Multiplayer games? Ftp? Rtsp? Pptp? Ipsec? ... Sorry if I missed something obvious for how these are enabled. Cb > Alain. > > > > > > > > > Cheers, > > Wim > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of Reinaldo Penno > > Sent: vrijdag 4 november 2011 1:33 > > To: Poscic, Kristian (Kristian); [email protected]; [email protected] > > Subject: Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite > > > > Hello Kristian, > > > > comments inline. > > > > > > On 11/3/11 4:38 PM, "Poscic, Kristian (Kristian)" > > <[email protected]> wrote: > > > >> Just to make sure I understand this. > >> > >> Deterministic (statefull) NAT is deterministically translating inside IP to > >> outside IP + port range (take NAT44 case). > > > > Yes. > > > >> > >> Deterministic stateLESS NAT is deterministically translating inside IP + > >> inside_src_port to outside IP + outside_src_port. > >> No states are required since the incoming traffic in the downstream direction > >> (outside IP +port) can be deterministically translated to inside IP+port. > >> Any incoming traffic from outside will be mapped to something (predictable) on > >> the inside even though there may be no traffic initiated from the inside. > > > > Correct, no need for previous outbound packet. Subscriber gets port > > forwarding naturally as a consequence. > > > >> > >> CPE still needs statefull NAT. > >> > >> Is this correct? > > > > Yes. > > > >> Thanks, > >> Kris > >> > >> > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf Of > >> Reinaldo Penno > >> Sent: Tuesday, November 01, 2011 4:12 PM > >> To: [email protected]; [email protected] > >> Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite > >> > >> Hello, > >> > >> we submitted a new draft detailing our implementation of > >> Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) > >> > >> http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 > >> > >> This is a based on our experience with port bucket/chunk allocation and > >> deterministic NAPT44. In the draft we provide a comparison with other > >> stateless/stateful methods floating around. > >> > >> Thanks, > >> > >> Reinaldo > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Behave mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > > Behave mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/behave
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
