Subject: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant

From: Rémi Després <[email-masked]>
Date: Sat, 28 Jan 2012 18:59:35 +0100

Hello all,

The new version of the proposed unified 4rd has just ben posted.
It is available at:
  http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03

A major evolution since the previous version has been to have in it two variants.
- The Header-mapping variant is as in the previous version
- The Encapsulation variant is added after comments received, and accepted, that some use cases cannot be satisfied if the Header-mapping variant is the only one. 

Compared to the alternative approach of several MAP documents, the single-document approach is expected to avoid duplicate specifications, and to facilitate consistency checks of the design.
Besides:
- Header-mapping provides more complete transparency to IPv4 packets than solutions using twice the IPv6/IPv4 translation of RFC6145.
- It has also the advantage of a simpler and self-sufficient specification.
- The algorithm which permits BRs to forward datagram fragments without datagram reassembly is included.
- The problem of fragmented datagrams from shared address CEs that must have different Identification if they go to common destinations is covered.
- The design re-introduces the Domain IPv6 suffix which in some earlier 4rd designs, and somehow has been lost. 
- The port-set algorithm is without parameter.

All questions and comments will be most welcome.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Sun, 29 Jan 2012 13:38:07 +0900

hi Remi,

it a little confuses me that the new version introduces 2 variants - what
is the technical difference of 4rd-U encapsulation variant vs.
MAP-E? (except written in a single or some separated documents)

on the other hand, it is unfair to state the benefit "Header-mapping
provides more complete transparency to IPv4 packets than solutions using
twice the IPv6/IPv4 translation of RFC6145" without mentioning the (at
least the following two pieces of) cost: 1. losing the compatibility with
single translation; 2. putting ICMPv4 PDU as the payload of IPv6 directly,
with neither IP header nor ICMP header has the address checksum information
- this will disable firewall preventing attacks.

best regards,
maoke
2012/1/29 Rémi Després <[email-masked]>

> - The Encapsulation variant is added after comments received, and
> accepted, that some use cases cannot be satisfied if the Header-mapping
> variant is the only one.
>
> Compared to the alternative approach of several MAP documents, the
> single-document approach is expected to avoid duplicate specifications, and
> to facilitate consistency checks of the design.
> Besides:
> - Header-mapping provides more complete transparency to IPv4 packets than
> solutions using twice the IPv6/IPv4 translation of RFC6145.
> - The problem of fragmented datagrams from shared address CEs that must
> have different Identification if they go to common destinations is covered.
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 30 Jan 2012 10:22:19 +0100

Hi Maoke,

Good to see you back in technical discussions, of which we had so many useful ones.
More in line.

Le 2012-01-29 à 05:38, Maoke a écrit :

> hi Remi,
>  
> it a little confuses me that the new version introduces 2 variants

> - what is the technical difference of 4rd-U encapsulation variant vs. MAP-E? (except written in a single or some separated documents)

No difference (as said).

>  
> on the other hand, it is unfair to state the benefit "Header-mapping provides more complete transparency to IPv4 packets than solutions using twice the IPv6/IPv4 translation of RFC6145" without mentioning the (at least the following two pieces of)

>  cost: 1.

Not clear AFAIK.
It can be discussed if you expand, but less subjective issues like those below are IMHO more important.

> losing the compatibility with single translation; 2.

I don't see this because, in my understanding:
- IPv6-only CPEs, in order to work with IPv4 shared addresses processed by BRs are stateless, MUST be modified anyway.
- Unmodified IPv6-only CPEs don't need to be modified to work with shared addresses processed by stateful NAT64/DNS64 (with known limitations NAT-related limitations, but this is understood). 
- 4rd-U can coexist with NAT64/DNS64 in ISP networks. (Provided IPv4 address-spaces used by NAT64 and 4rd-U are disjoint, there is AFAIK no operational issue.

If you have a specific configuration that illustrates your concern, it could be discussed with more details.

>  putting ICMPv4 PDU as the payload of IPv6 directly, with neither IP header nor ICMP header has the address checksum information - this will disable firewall preventing attacks.

For a site having a customer-provided CPE that integrates a firewall to take advantage of stateless IPv4-address sharing, its FW  MUST be upgraded anyway. Adding to it 4rd-U support is for this a logical solution.  
If the FW-CPE is not modified, its operation across IPv6-only networks remains IPv6-only (translatable to IPv4 by NAT64 if supported by the ISP).
Adding a note on this in the document would be possible, if found useful.  

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Mon, 30 Jan 2012 19:47:48 +0900

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

> - what is the technical difference of 4rd-U encapsulation variant vs.
> least the following two pieces of)
>
>
>  cost: 1.
>
>
> Not clear AFAIK.
> - IPv6-only CPEs, in order to work with IPv4 shared addresses processed by
> BRs are stateless, MUST be modified anyway.
> - Unmodified IPv6-only CPEs don't need to be modified to work with shared
> addresses processed by stateful NAT64/DNS64 (with known limitations
> NAT-related limitations, but this is understood).
> - 4rd-U can coexist with NAT64/DNS64 in ISP networks. (Provided IPv4
> address-spaces used by NAT64 and 4rd-U are disjoint, there is AFAIK no
> operational issue.
>
>

well, if address spaces (as well as routings) are totally disjoint, it is
hard to call it as "coexist", ;-) 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.

>  putting ICMPv4 PDU as the payload of IPv6 directly, with neither IP
> header nor ICMP header has the address checksum information - this will
> disable firewall preventing attacks.
>
>
>
> For a site having a customer-provided CPE that integrates a firewall to
> take advantage of stateless IPv4-address sharing, its FW  MUST be upgraded
> anyway. Adding to it 4rd-U support is for this a logical solution.
>
>

the attack preventing should be done everywhere, including in the middle of
the IPv6 domain. however, IPv6-containing-ICMPv4 loses information checksum
regarding the original IPv4 addresses and therefore (no matter how the
firewall is upgraded) the consistency check is not possible. it should be a
big security concern.

this is one of the major reasons that i don't think putting ICMPv4 into
IPv6 directly is a good idea. either full encapsulation or Simple IP/ICMP
translation is far better.

best,
maoke

>
> If the FW-CPE is not modified, its operation across IPv6-only networks
> remains IPv6-only (translatable to IPv4 by NAT64 if supported by the ISP).

---

From: Rémi Després <[email-masked]>
Date: Mon, 30 Jan 2012 12:21:49 +0100

Le 2012-01-30 à 11:47, Maoke a écrit :

> well, if address spaces (as well as routings) are totally disjoint, it is hard to call it as "coexist", ;-)

Do you mean it would be difficult to route some of the ISP IPv4 prefix(es) to the NAT64 and some to the 4rd-U BR?
Isn't there already the same need if there are several NAT64s? (They must work with disjoint IPv4 address spaces.)

> 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.
>  
>  
> 

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?)

RD

> the attack preventing should be done everywhere, including in the middle of the IPv6 domain. however, IPv6-containing-ICMPv4 loses information checksum regarding the original IPv4 addresses and therefore (no matter how the firewall is upgraded) the consistency check is not possible. it should be a big security concern.
>  
> this is one of the major reasons that i don't think putting ICMPv4 into IPv6 directly is a good idea. either full encapsulation or Simple IP/ICMP translation is far better.
>  
> best,
> maoke
>  
>

---

From: Maoke <[email-masked]>
Date: Wed, 1 Feb 2012 11:04:03 +0900

>
> 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.
>
>
>>
>>
> 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.
> (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, 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.

i think this is a clear-enough use-case but if i still make any confusion,
i may draw some pictures for you offline.

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, but i found 1) the necessity is weak,
according to the transparency check for RFC6145 end-to-end behavior in
double-translation; 2) it is impossible to make decision among alternatives
due to lack of knowledge about the remote stack (i.e. cannot distinguish
single or double translation with no state nor complicated dynamic
configuration); and 3) it is harmful to have ICMPv4 in IPv6 payload (as i
mentioned previously). my conclusion is: for RFC6145, it is a wise choice
to keep using a unified translation algorithm no matter the case is single
or double.

- M.