Re: [Softwires] 4rd-u tunnels and stateful NAT64s

[Maoke <[e-mail]>]

2012/3/16 Rémi Després <[e-mail]>

>
> 2012-03-16 02:07, Maoke:
>
>
> on the other hand, may i suggest not to term "4rd tunnel" anymore? it
> confuses. i emphasized it is NOT a TUNNEL to the common understanding at
> all
>
>
> A "4rd" tunnel isn't "any" tunnel.
>

"a white horse is not a horse. " - ancient Chinese proverb. ;-) anyway i
won't be stubborn on this anymore. :)


> It is only that which is defined by the 4rd-u specification.
>
>
> (but it seems you never?seldom respond to this point, nor to the ICMP
> issue details. ) - maoke
>
>
> Having already answered (see just below), and having received so far no
> reaction on this subject, I don't think I should have done more.
> Your complaining about my insufficiently answering is therefore undeserved
> (IMHO).
>
> Please restate the ICMP issue you still have in mind.
> I will try to answer (as usual).
>

http://www.ietf.org/mail-archive/web/softwires/current/msg03626.html
i don't think that's only a replicate of our previous discussion. even if
so, i guess this is the first time in the mail list.

regards,
maoke


>
>
> "2012-03-09 09:49, Rémi Després :
>
> ...
> i don't incline to use the term "tunneling" since tunnel could have a
> variety of forms, among which encapsulation is one but not the only one.
>
>
> Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation
> tunnels."
>
>
>
> The fact is that there is no noticeable difference, e2e, between:
> - IPv4 packets that are only natively routed
> - IPv4 packets that are tunneled on their way any number of times (be it
> with 4rd tunnels or any other tunnels).
>
> We have, I think, more important subjects to debate.
>
> RD
>