On Apr 2, 2012 8:17 AM, "Wojciech Dec" <wdec.i...@gmail.com> wrote:
>
>
>
> On 2 April 2012 15:46, Rémi Després <despres.r...@laposte.net> wrote:
>>
>>
>> Le 2012-04-02 à 12:33, Ole Trøan a écrit :
>>
>> >> If this is to say that until a BOF is started, you will keep your
objection(s) unknown, I continue to take it as a lack of identified
objections.
>> >
>> > the objections I'm aware of are:
>> > - people are uncomfortable with only a double translation solution
>>
>> Are you furtively suggesting that 4rd-U has all limitations of a real
double translation solution like MAP-T?
>> That mays sound tactically smart, but isn't justified by facts.
>
>
> Woj> Well, in terms of facts we have
> 1. 4rd-U does not supporting single translation mode, or if it does then
is requires NAT64/BIH/Something else. (How anybody thinks that deploying
4rd-u + "something" else is manageable is a mystery)
> 2. 4rd-u is incompatible with NAT64 use or deployment
> 2. MAP solution (call it MAP, divi, or other variants) has proven
deployment

Just for my own clarification, do these proven deployments use static ipv4
address+port sharing with coordinated dhcp assignment? These are the key
feature and method of map-t, and it would be good to know if and how these
key features have been proven.

Cb
> 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves
problems that are non-issues to operators.
> 4. 4rd-u changes the basic structure/use of the v6 header, which is a
change to IPv6 that needs to be vetted by 6man, etc. Creating such "novel"
(bogus?) IPv6 packets, that no regular IPv6 host today will recognize and
use, effectively creates a new IPv6 protocol sub-class.
>
> Indeed 4rd-u deserves an "experimental" status track, more than anything.
>
> -Wojciech.
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to