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.


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


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

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