Samita Chakrabarti wrote:
Do you mean other destination or hop-by-hop options or routing header ?
Here is what I mean. If an applications specifies multiple options in the same ancillary data structure (ex: a single cmsghdr with IPV6_DSTOPTS level), what happens if one of those options is HAO?
Since rfc3542 restrictes itself to header ordering described in rfc2460, do the implentations have to extract the HAO and put it into a separate header or leave it alone?
If the ancillar data is left alone and the entry cmsghdr converted into a single Destination Option Header, then do we follow the rules for placement of the Home Address Option? That may result in incorrect placement of other options specified in the same header.
If the HAO is extractred into it's own header, the implemention suffers a penalty for parsing the header, copying the data (which requires additional memory allocations), and re-padding and re-alligning the original header to accound for the now missing option. Doing this in a send operation would very negatively effect performance.
It definitely simplifies if we put that restriction.
With the restriction, a single ancilary data item would contain the HAO. Implementations may support multiple ancilary data items for each level (i.e multiple IPV6_DSTOPTS level items) since they already have to support multiple incomming headers of the same type.
Does anyone see any potential issue in having this restriction ?
that the checksumming should be on by default (similar to ICMPv6) with the ability to turn it off by the socket. The reason is that most Mobile IPv6 implementation are supported in the "kernel" and already do checksumming. The RAW socket interface can take advantage of that. So, at this poing NOT doing checksumming is an change to the expected behavior. To minimize that change, we can default to do checksumming with the ability to turn it off and let the applcation do it.
Only issue, I see that it then somewhat breaks what RFC3542 claims for RAW socket behavior. Hence, setting IPV6_CHECKSUM for mobility header seems to follow the following spec.
" The kernel will calculate and insert the ICMPv6 checksum for ICMPv6 raw sockets, since this checksum is mandatory.
Isn't checksumming for MIPv6 control messages also mandatory? At least that's the way I read the MIPv6 spec.
Since you are already extending rfc3542, the extended mandatory checksumming (as required by the MIPv6 protocol) also makes sence to me.
-vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX Network Group Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
