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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
