"i am not against that checksum neutrality is useful but i don't think it it wise to write it into a standard "..
Checksum neutral is also recommended in http://tools.ietf.org/html/rfc6296#page-10 ________________________________ From: [email protected] [[email protected]] on behalf of Maoke [[email protected]] Sent: Wednesday, March 28, 2012 19:04 To: Simon Perreault Cc: [email protected] Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 2012/3/28 Simon Perreault <[email protected]<mailto:[email protected]>> On 03/28/12 12:50, Maoke wrote: Yup. RFC 6052 section 4. do you mean the following paragraph: No. See my response to Ole. 1. as a stateless address mapping, RFC6052 doesn't assumes any stateful NAT64 is also required to use checksum-neutral address -- liberal to others Not sure what you mean. Agree that checksum neutrality does not help stateful NAT64. I'm talking about stateless NAT64. 2. as a operational option, RFC6052 considers having checksum-neutrality through, e.g., choosing proper prefix if possible -- conservative to itself Yes. 3. comparing with RFC6145, the latter doesn't assume there MUST be a checksum-neutral address but keep adjusting L4 checksum -- conservative to itself Yes. Checksum neutrality still rocks. ;) i am not against that checksum neutrality is useful but i don't think it it wise to write it into a standard, forcing others doing. on the other hand, even we write it in, we'd better not to have it as a reason for disabling the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is a wrong direction. it is good to have a checksum-neutral address format, if situation allows, as a deployment option, rather than a mandatory element in standard. because it can only play the role of a complement in some cases. that's my point. hope it clarifies. ;-) - maoke Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
