Subject: Re: [Softwires] New version of 4rd-U - Header mapping (4rd-H vs 4rd-T)

From: Rémi Després <[email-masked]>
Date: Wed, 1 Feb 2012 18:33:17 +0100

Le 2012-02-01 à 03:04, Maoke a écrit :

> 
> 
> 2012/1/30 Rémi Després <[email-masked]>
> 
>> and definitely there is no compatibility to single translation in RFC6145 at all. as the result, RFC6145 provides a unified solution, while 4rd-U requires ISP (who prefer to use translation) disjointly deploy their networks for single and double translations.
>>  
>>  
>> 
>> If you have a specific configuration that illustrates your concern, it could be discussed with more details.
> 
> Could you, for the sake of a less abstract discussion, describe at least one configuration you have in mind, in which some IPv4 addresses are statelessly shared, and in which there is the RFC6145 compatibility you are talking about.
> Without that, I can't figure out what you mean. 
> (The goal remains customer service, without harm if this happens to be possible without full support of RFC4125, right?)
> 
> to my best understanding, one of the merits of the translation approach is: when an end system changes its stack from ipv4 to ipv6,

If it is on a V6-only network, isn't the end system already dual stack?
Then, if it needs to be reachable in IPv4, why would it change IPv6-only while the 4rd service remains available?

RD

> as long as the ipv4-translatable ipv6 address is applied, its peers in the past can keep using the same ipv4 address (as the temporal-unique identifier) to have access to it. in other words, the stack-changing doesn't impact already-existing peers, but enlarges the opportunity for the new connections from native ipv6 peers. separating single translation and double translation with deploying disjoint ipv4 (as well as corresponding ipv6) spaces is meaningless in this term.

...

---

From: Maoke <[email-masked]>
Date: Thu, 2 Feb 2012 12:26:35 +0900

2012/2/2 Rémi Després <[email-masked]>

>
>
>
> to my best understanding, one of the merits of the translation approach
> is: when an end system changes its stack from ipv4 to ipv6,
>
>

dual stack doesn't mean dual networking, which is costy in operation and
management.

> while the 4rd service remains available?

it need to be reachable in both IPv4 and native IPv6, and it is expected
that the latter will be more and more in the future.

- maoke

---

From: Rémi Després <[email-masked]>
Date: Thu, 2 Feb 2012 10:30:47 +0100

Le 2012-02-01 à 03:04, Maoke a écrit :
> ...
> 
> i have investigated, technically, what if we had updated RFC6145 with carrying ICMPv4 messages in IPv6 directly instead of translating to ICMPv6, specially for double translation,

Introducing ICMPv4 messages in IPv6 packets "instead of" ICMPv6 messages in RFC6145 would be an incompatible change. 
I don't think anyone proposed that.
 
What might be envisaged without the same backward incompatibility, is that IPv6-only hosts would accept in IPv6 packets BOTH IPv6 ICMP messages and ICMPv4 messages.

Yet, it remains to be analyzed whether it would be useful in real world.

This depends on a detailed use case being identified, where double RFC6145 translation would have a substantial advantage over the header-mapping variant of 4rd-U-03 (4rd-H). (This advantage would have to compensate for the loss of IPv4 transparency as good as that of 4rd-E, and for the loss of the tunnel-specific traffic class which can be used in 4rd-E.) 

This use case, key for this discussion, is subject of another e-mail thread.

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 2 Feb 2012 10:32:13 +0100

...
> Could you, for the sake of a less abstract discussion, describe at least one configuration you have in mind,
...
> to my best understanding, one of the merits of the translation approach is: when an end system changes its stack from ipv4 to ipv6, as long as the ipv4-translatable ipv6 address is applied, its peers in the past can keep using the same ipv4 address (as the temporal-unique identifier) to have access to it.
...
> i think this is a clear-enough use-case but if i still make any confusion, i may draw some pictures for you offline. 

This discussion IMHO deserves to remain online.
Could you, for this use case:
- indicate applicable mapping rules 
- clarify whether there is a NAT64 or not
(pictures don't seem necessary at this stage) 

We should be able to analyze what is won and what is lost compared to other solutions.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Thu, 2 Feb 2012 19:59:59 +0900

dear Remi,

sorry but your change of the title of this thread is misleading. i mean: no
change to RFC6145 needed for practice of operation. my observation on the
ICMP transparency of RFC6145 in double translation is relatively
independent, without much relationship to 4rd-U. well, the only connection
is: 4rd-U REQUIRES IPv6 carrying ICMPv4 messages without translation.

> i have investigated, technically, what if we had updated RFC6145 with
> carrying ICMPv4 messages in IPv6 directly instead of translating to ICMPv6,
> specially for double translation,
>
>
> Introducing ICMPv4 messages in IPv6 packets "instead of" ICMPv6 messages
> in RFC6145 would be an incompatible change.
> What might be envisaged without the same backward incompatibility, is that
> IPv6-only hosts would accept in IPv6 packets BOTH IPv6 ICMP messages and
> ICMPv4 messages.
>
> This depends on a detailed use case being identified, where double RFC6145
> translation would have a substantial advantage over the header-mapping
> variant of 4rd-U-03 (4rd-H). (This advantage would have to compensate for
> the loss of IPv4 transparency as good as that of 4rd-E, and for the loss of
> the tunnel-specific traffic class which can be used in 4rd-E.)
>

i (and others) have tested the single/double-compatibility in practice and
confirmed it is useful at least for some users. another mail thread might
fall into pure philosophical debate, which is not preferred, especially
considering that carrying ICMPv4 in IPv6 is not secure. in other words,
even if the philosopher had thought the compatibility with single
translation was useless, he'd better not to deploy the IPv6 network
carrying ICMPv4 payload without IPv4 header encapsulated.

- maoke

---

From: Mark Townsley <[email-masked]>
Date: Thu, 2 Feb 2012 14:49:03 +0100

>> i have investigated, technically, what if we had updated RFC6145 with carrying ICMPv4 messages in IPv6 directly instead of translating to ICMPv6, specially for double translation,

As I watch double-translation slowly morph into tunnel encapsulation one step at a time right before my eyes....

- Mark

---

From: Rémi Després <[email-masked]>
Date: Fri, 3 Feb 2012 11:15:36 +0100

Le 2012-02-02 à 11:59, Maoke a écrit :

> dear Remi,
> 
> sorry but your change of the title of this thread is misleading. i mean: no change to RFC6145 needed for practice of operation. my observation on the ICMP transparency of RFC6145 in double translation is relatively independent, without much relationship to 4rd-U.

> well, the only connection is: 4rd-U REQUIRES IPv6 carrying ICMPv4 messages without translation. 

4rd-U is indeed proposed with all IPv4 payloads transparently transmitted, including ICMPv4.
This could be changed if ICMPv4 if there would be a convincing need.
Honestly, what you have provided so far hasn't been convincing. 

> i (and others) have tested the single/double-compatibility in practice and confirmed it is useful at least for some users.

I don't deny. I just believe that, to have a chance to be convinced, I need a description of at least a use case where it is useful (with applicable mapping rules and indication of whether there is a DNS64).

> another mail thread might fall into pure philosophical debate, which is not preferred,

Whatever the thread, I look for a technical discussion, not a philosophical one.

RD