On 11/7/11 6:54 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.
Actually Alain, we can do it. It is a trade-off between public IP usage
efficiency and management.
If CPE run out of ports that subscriber/private IP, if changing IP is not an
option, is moved to another deterministic NAT pool with larger ranges.
Everything is transparent. This assumes you have a two-tier NAT pool model
(which is common), apart from that it is okay.
>
>
>> 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.
>
> 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
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
