On Wed, Feb 8, 2012 at 1:23 AM, Rémi Després <[email protected]> wrote:
> Hi Behcet,
>
> Le 2012-02-08 à 09:46, Behcet Sarikaya a écrit :
>
>> Hi Cameron,
>> 4rd solution IMHO is more suitable for a fixed network. CPE in 4rd is
>> not appropriate to be hosted in a UE.
>>
>> I think your solution 464XLAT's mobile part is way better for your
>> purposes. There you can put all your IPv4 resources on the PLAT box so
>> that CLAT box is kept simpler.
>>
>> In 4rd, CPEs have A+P and BR is kept "stateless" these are not so
>> useful for your purposes, I think.
>
> Note however that:
> - 464XLAT doesn't support shared IPv4 addresses (while 4rd does)

Hmm... we may be getting off topic.

464XLAT definitely shares IPv4 addresses on the PLAT -- That is RFC
6146 -- statefule NAT64.

Perhaps what you mean to say is that 464XLAT uses stateful sharing of
IPv4 addresses as defined in RFC6146.  The public IPv4 address
resources are decoupled from the IPv4 service deployment at the edge.
This is more flexible, IPv4 efficient, and allows for geographic
redundancy of the translation exit points.

So, to summarize.  Both 4RD and 464XLAT support address sharing. One
is stateless and the other is stateful.

> - 4rd over 6rd can work, and therefore offer both IPv6 and shared-address 
> IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP (while 464XLAT cannot 
> AFAIK).
>

4RD over 6RD?

That is a lot of RD :)

I believe the implementation report here shows that 464XLAT provides a
good users experience on 3G networks

http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html

CB

> Regards,
> RD
>
>>
>> Regards,
>>
>> Behcet
>>
>>
>> On Tue, Feb 7, 2012 at 9:05 AM, Cameron Byrne <[email protected]> wrote:
>>> Are the map and 4rd solutions deployable for existing networks that do not
>>> have reserves  of ipv4 ?  My assumption is that these solutions target
>>> existing networks that have meaningful growth and they need a v6 solution.
>>>
>>> If yes, how? Any pointers within the reams of drafts I should look for?
>>>
>>> In my brief and simple skimming, it appears to me that setting up one of
>>> these solutions would require me to collapse my existing network to harvest
>>> back the addresses so that they may be redeployed in map.
>>>
>>> What would the deployment process be for an address exhausted network of 10
>>> million subs with 10% annual growth be?
>>>
>>> Cb
>>>
>>>
>>> _______________________________________________
>>> 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

Reply via email to