Subject: [Softwires] Transparency limitations of 4V6 Translation

From: Rémi Després <[email-masked]>
Date: Tue, 26 Jul 2011 16:53:35 +0200

Hi, all,

Wojciech's draft-dec-stateless-4v6-02 is overall very good IMHO, and deserves to soon become a WG. However, concerning differences between translation-based and encapsulation-based solutions (4V6T and 4V6E respectively), it can and should be more complete. 

Concerning the relationship of 4V6T and 4V6E with e2e transparency, I noted the following points.

1. IPV4 OPTIONS

The draft has: 

                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Supports IPv4 Header   | Yes - limited as   | Yes, except source  |
| Options                | per NAT64          | route option        |
|                        | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |

Suggested clarification:
                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Supports IPv4 Header   | No - limited per   | Yes                 |
| Options                | SIIT  [RFC6145]    |                     |
| ------------------     | ------------------ | ------------------  |

Justification:
- RFC 6145 says in sec. 1.2: "the translating function specified in this document does not translate any IPv4 options"
- Traversal of a 4V6E domain is treated as a single IPv4 link traversal. This, AFAIK, doesn't restrict IPv4 options that traverse the link.

2. UDP NULL CHECKSUM

RFC 6145 sec. 1.2 says: "Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant use in the Internet, and in general will not be translated by the IP/ICMP translator.  However, when the translator is configured to forward the packet without a UDP checksum, the fragmented IPv4 UDP packets will be translated."

Suggested presentation:
                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Transparency to UDP    | TBD - No with full | Yes                 |
| null checksums         | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |

3. DONT FRAGMENT BIT

RFC 6145 says in sec. 4: "When the IPv4 sender does not set the DF bit, the translator SHOULD always include an IPv6 Fragment Header to indicate that the sender allows fragmentation.  The translator MAY provide a configuration function that allows the translator not to include the Fragment Header for the non-fragmented IPv6 packets."

Suggested presentation:
                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Transparency to DF bit | TBD - No with full | Yes                 |
|                        | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |

4. TOS

RFC 6145 says in sec. 4.1: "An implementation of a translator SHOULD provide the ability to ignore the IPv6 traffic class and always set the IPv4 TOS Octet to a specified value."

This opens the door to losses of TOS values across 4V6T domains.
In 4V6E the original TOS is always preserved.

Suggested presentation:

                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Transparency to IPv4   | TBD - No with full | Yes                 |
| TOS                    | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |

All the above points happen to be favorable to 4V6E, but this is not because of a religion about it.
It is just because encapsulations inherently preserve e2e transparency, which itself simplifies architectural properties and facilitates qualification tests of deployed solutions.  

Cheers,
RD

---

From: Xing Li <[email-masked]>
Date: Wed, 27 Jul 2011 22:16:28 +0800

Hi, Rémi,

Comments inline.

> Concerning the relationship of 4V6T and 4V6E with e2e transparency, I noted the following points.
(1) RFC6145 does not support IPv4 header options.
(2) The name "SIIT" is not used in RFC6145, it should refer as "statless 
NAT64".
(3) When tunnel is treated as a single link, all hops inside the tunnel 
are hidden, therefore "except source route option" is still true in this 
sense.
> RFC 6145 sec. 1.2 says: "Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant use in the Internet, and in general will not be…
(1) Dual stateless translation is not "Transparency to UDP null 
checksums" by default. However, as stated in RFC6145, "Fragmented IPv4 
UDP packets that do not contain a UDP checksum (i.e., the UDP checksum 
field is zero) are not of significant in the Internet".
(2) It can be configured to forward the packet without a UDP checksum.
> RFC 6145 says in sec. 4: "When the IPv4 sender does not set the DF bit, the translator SHOULD always include an IPv6 Fragment Header to indicate that the sender allows fragmentation.  The translato…
(1) In general, RFC6145 is "Transparency to DF bit". The exception is 
defined by "MAY" cited above.
(2) The tunnel has its own issues when dealing with fragmentation. See 
Section "5.3. Fragmentation and Reassembly" and "6.3. Fragmentation and 
Reassembly" of 
http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-11.txt

> In 4V6E the original TOS is always preserved.
In general, RFC6145 is "Transparency to IPv4 TOS". The exception is 
defined by "SHOULD provide the ability to ignore the IPv6 traffic class" 
cited above.

> It is just because encapsulations inherently preserve e2e transparency, which itself simplifies architectural properties and facilitates qualification tests of deployed solutions.
In summary, the dual stateless translator can be configured to have 
"Yes" to (2), (3), (4). The only "No" is (1).
> RD

Regards,

xing

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Jul 2011 18:30:29 +0200

Le 27 juil. 2011 à 16:16, Xing Li a écrit :

> Hi, Rémi,
> 
> Comments inline.
> 
> 于 2011/7/26 22:53, Rémi Després 写道:
>> 
>> Hi, all,
>> 

Exactly. That's the point.

> (2) The name "SIIT" is not used in RFC6145, it should refer as "statless NAT64". 

Well, as the draft doesn't specify an acronym and describes an algorithm for "Stateless IP/ICMP Translation", I felt authorized. Sorry for that.
One could say just "limited per RFC6145" or "limited per Stateless NAT64 [RFC6145]".
Thanks 

> (3) When tunnel is treated as a single link, all hops inside the tunnel are hidden, therefore "except source route option" is still true in this sense.

I agree that just "yes" may be too short.
One could say something like "Yes, (domain traversal treated as on hop)".
Thanks

> (1) Dual stateless translation is not "Transparency to UDP null checksums" by default. However, as stated in RFC6145, "Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant in the Internet". 

It remains that some customers may be impacted, even if their number is believed to be to  
be insignificant.
A note with the sentence you quoted could be added.   

> (2) It can be configured to forward the packet without a UDP checksum.

OK.
That's the reason of the TBD.
If it becomes a rule for 4V6T, that solves the problem, but it has to be specified in the solution draft.

> (1) In general, RFC6145 is "Transparency to DF bit". The exception is defined by "MAY" cited above. 

OK.
That's the reason of the TBD, as above.

> (2) The tunnel has its own issues when dealing with fragmentation. See Section "5.3. Fragmentation and Reassembly" and "6.3. Fragmentation and Reassembly" of http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-11.txt 
> 
>> 4. TOS
>> 
> In general, RFC6145 is "Transparency to IPv4 TOS". The exception is defined by "SHOULD provide the ability to ignore the IPv6 traffic class" cited above.

First, it should be stated if it is a requirement in the solution draft, as above.
But, in addition, this would make it impossible to have a specific Traffic Class for tunnels.
This is another constraint that should IMHO be mentioned to be complete.

> In summary, the dual stateless translator can be configured to have "Yes" to (2), (3), (4). The only "No" is (1).

Agreed for (2) and (3) (provided the solution draft is completed).
Concerning (4) both the solution and the comparison drafts deserve updates, IMHO.

Regards,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 28 Jul 2011 00:13:31 +0200

In summary, the dual stateless translator can be configured to have "Yes" to
(2), (3), (4). The only "No" is (1).

> Concerning (4) both the solution and the comparison drafts deserve updates,

Agreed. WIll include the remarks in the next draft version.

Thanks,
Woj.