Subject: [Softwires] Objection to 4rd-U made in Softwire meeting understood to be invalid

From: Rémi Després <[email-masked]>
Date: Wed, 16 Nov 2011 07:09:59 +0800

Ole,

In the Softwire meeting of Monday, the key argument against the 4rd unified approach (4rd-U) was that *Because checksum neutrality of addresses is part of 4rd-U, it would allegedly cause "address spreading" (addresses used between a pair of hosts would vary)*. 
You had a slide asserting it, and the argument was taken as granted, and important, in verbal comments from Mark Townsley and Dave Thaler.
I forcefully declared that this was technically false.
Since no time has been granted to explain, I invited anyone in doubt to contact me for explanations. 
Thanks for having taken the time to do it.

Following our discussion of yesterday, I think you now understand that, as I said:
- *TCP/UDP checksum neutrality of addresses DOES NOT interfere in any way with stability of addresses between host pairs*.
- Consequently, the key argument of the meeting against 4rd-U is invalid.

Since there is no more Softwire session in IETF 82, I will appreciate if you acknowledge it now on this mailing list.

Thanks,
RD

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Nov 2011 10:26:19 +0800

Remi, et al,

> - *TCP/UDP checksum neutrality of addresses DOES NOT interfere in any way with stability of addresses between host pairs*.

acknowledged. as far as I can understand the checksum neutrality proposal will work, and it will result in stable addresses.
two flows between two hosts will have the same addresses. and there is no "destination spread" with this mechanism.

apologies for the uncertainty and confusion created by questioning this.

> - Consequently, the key argument of the meeting against 4rd-U is invalid.

that I disagree with. there were multiple arguments. let me try to summarize.

- if 4rd-U resulted in one specification as opposed to two then 4rd-U is a good thing.
  if 4rd-U results in three specifications as opposed to two, then that is a bad thing.
  I have discussed this with the authors of the other two proposals, and they don't appear to withdraw their proposals
  in favour of this one.
- 4rd-U has destination spread as written with the Max PSID has destination spread. this can obviously be fixed.
- 4rd-U has the V octet, which impacts native IPv6 forwarding, and I think in general is problematic
- 4rd-U is 'just' another translation proposal; it might provide a 'better' translation than what has been done so far
  in behave, but that doesn't alleviate the arguments made for encapsulation
- 4rd-U has checksum neutrality, there is already a solution for the checksum. that is widely implemented, why
  bring in another way of doing it, creating two specifications for the same problem instead of using an existing one?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 16 Nov 2011 13:42:47 +0800

> apologies for the uncertainty and confusion created by questioning this.

No problem left on this.

> that I disagree with. there were multiple arguments.

No contradiction here either: I just wished it to be known by the group that the "key" objection is now understood to be invalid.
I do agree that other objections you list in your email, despite their being much less decisive AFAIK, deserve to be seriously discussed. I will comment them in a separate response.

Thanks,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 18 Nov 2011 12:34:26 +0800

Hi all, 

In his last answer, on the thread "Objection to 4rd-U made in Softwire meeting understood to be invalid", Ole listed his objections to 4rd-U after the main one presented in the Softwire meeting (checksum neutrality of IPv6 addresses said to cause "address spreading") was found to be invalid.

Here are responses to these other objections. 

> - 4rd-U has destination spread as written with the Max PSID has destination spread. this can obviously be fixed.

The current 4rd-U draft does include an address format that supports the max PSID but no one proposes this feature any longer. 
Suppressing Max PSID from the 4rd-U draft is trivial. It will be done for the next version of the 4rd-U draft.
The objection no longer holds. 

> - 4rd-U has the V octet, which impacts native IPv6 forwarding, and I think in general is problematic

Without the Max PSID (see above), the V octet has AFAIK no impact on IPv6 forwarding. 
Until a proof would be given that such impacts exists, this objection should therefore be considered invalid. 
 
Now, reasons to propose the V octet are as follows:
- Without the V octet, a standard subnet ID has to be reserved (and normally documented by IANA), with the additional constraint that its length isn't standardized. Subnet 11...1 of any length can do it, as proposed in the MAP specification, but this remains a limitation on subnet assignments of IPv6 sites. The V octet eliminates this limitation.
- Without the V octet, a device in the middle that needs to distinguish IPv4 packets from native IPv6 packets MUST know which lengths of CE IPv6 prefixes apply to which IPv6 prefixes. For this, knowing mapping rules is sufficient, but this adds significant complexity to this device. The V octet eliminates this complexity.

If the "in general problematic" refers to the belief expressed during the MAP-DT meeting that the chosen V mark wouldn't be effective because it MAY already appear in valid IPv6 addresses, this is AFAIK not the case.
The proposed V mark is a first interface-ID octet whose u and g bits are both = 1. It cannot appear in unicast addresses based on MAC addresses (they have u=1, and g=0 since they are not group addresses), neither can it appear other valid IPv6 addresses (they all have AFAIK u=0).   
Unless a proof of the contrary is given,  this objection should be considered as inexistent.

Note also that it is well understood that introducing the V octet implies a complement to RFC 4291, but this shouldn't be a problem if there is a consensus in Softwire on its utility.

>  in behave, but that doesn't alleviate the arguments made for encapsulation

4rd-U is a "Reversible header mapping" proposal: it consists in mapping IPv4 headers into IPv6 headers at domain entrance and doing the reverse at domain exit. 
It isn't therefore a "Double translation" proposal  4via6, aka 4rd-T, or dIVI/dIVI-pd, because it doesn't use the IP/ICMP stateless translation of RFC 6145, which all translation solutions require (4via6 aka 4rd-T, dIVI, dIVI/pd).
(It isn't either an "Encapsulation" proposal because it doesn't need an IPv4 header after the IPv6 header.) 
 
4rd-u does build on work previously done on Double-translation solution, as well as on Encapsulation solutions, which is well acknowledged, but this doesn't make it a variation of either of them. 

Reversible header mapping is a natural approach for traversal of IPv6 domains by IPv4 packets because in-domain headers (IPv6) are much longer than off-domain headers (IPv4). For 6rd, Encapsulation was a natural choice because in-domain headers (IPv4) were much shorter than off-domain headers (IPv6).
Now, the effect of using Reversible header mapping, compared to using Encapsulation is the following:
 . Processing is (moderately) increased, and transmission overhead is (moderately) decreased - nothing essential. 
 . It becomes possible that IPv4 packets that traverse the domain appear as valid IPv6 packets. They can thus be processed by existing intra-domain functions such as web caches and UDP-port based access controls - unnecessary for some use cases, but also a major advantage for some others.  
 
Because of this, 4rd-U makes it possible to have, for residual IPv4 across IPv6, ONLY ONE STATELESS STANDARD (rather than having two, MAP+translation and MAP+encapsulation, both having their own specific use cases). 

>  bring in another way of doing it, creating two specifications for the same problem instead of using an existing one?

The sateless IP/ICMP translation from IPv6-only to IPv4 of RFC 6145, because it is generic, has to work for all NAT64 scenarios. Because of this, it cannot count on IPv4 related IPv6 address formats that would preserve checksum neutrality for both source and destination addresses. It MUST therefore deal with UDP/TCP checksum validity by a modification at the transport layer.
Now, for IPv4 across IPv6 domains, both IPv6 addresses are mapped from IPv4 addresses. Each one can therefore have an ad hoc format, chosen to ensure the UDP/TCP checksums aren't impacted by replacements of IPv4 addresses by IPv6 addresses. 

The end result is that checksum neutrality is ensured once and for all for ALL PROTOCOLS that use the same checksum algorithm a UDP/TCP.

In particular, it works for DCCP [RFC4340], while RFC6045 translation explicitly leaves it open to treat or not to treat checksums for DCCP. Consequence:  DCCP can be broken in case of double translation if the same choice isn't made at entrance and exit of the domain.
Also, should for example an SCTP variant that uses UDP-like checksum be found useful in the future (to reduce processing overhead, and for NATs to be able to support SCTP), no update of UDP checksum handling would be needed to support it.

Technically,, ensuring checksum neutrality in 4rd-U IPv6 addresses is essentially as simple as modifying the checksum in transport headers (a few additions and subtractions in one's complement arithmetic, as presumably Behave specialists can confirm).

End result: since checksum neutrality CAN be performed at the IP layer of 4rd-U, and since it ensures a BETTER compatibility with existing    and possibly-future protocols, it adds value to the proposed unified standard. 

Further comments are most welcome.

Regards to all,
RD