Thanks for your response. I'll discuss the issues you raised at tomorrow's presentation. If time permits, we can ask for wg input.
For the checksumming, I understand your point. But we have to be careful here, unless RFC3542 does not change, having kernel to do the MIPv6 checksumming by default may bring some incomaptibilties between non-mipv6 and mipv6 systems in terms of application behavior. From socketAPI perspective, IMHO, it's good idea to stick to the existing RFC3542 specification - but I'll still discuss the issue at the meeting tomorrow. -Samita Vladislav Yasevich wrote: > > Samita > > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
