在 2012年3月29日星期四，Huangjing 写道： > just to clarify, maybe my point is not clear in the previous reply. > > you said " i don't think it it wise to write it into a standard", but as > i know, checksum neutral is also recommended in > http://tools.ietf.org/html/rfc6296#page-10, > it is a useful technology which can be put into a standard >
well, i should clarify i meant "...into a standard of the MAP scope." NAPT is fine to use whatever address without need to consider much about operation nor other devices, but MAP involves device interoperation and operation. it'd better the standard is made conservative. - M > > > ------------------------------ > *From:* [email protected] <javascript:_e({}, 'cvml', > '[email protected]');> [[email protected]<javascript:_e({}, > 'cvml', '[email protected]');>] > on behalf of Maoke [[email protected] <javascript:_e({}, 'cvml', > '[email protected]');>] > *Sent:* Wednesday, March 28, 2012 19:04 > *To:* Simon Perreault > *Cc:* [email protected] <javascript:_e({}, 'cvml', > '[email protected]');> > *Subject:* Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 > > > > 2012/3/28 Simon Perreault <[email protected] <javascript:_e({}, > 'cvml', '[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
