> > Section 2.2 assignes the value 62 to be the mobility header. According > to IANA, valud 62 is assigned to CFTP. According to same document, > the value 55 is currently assigned to IP Mobility. I am not very familiar > with Mobile IPv4, but I did not think it required a new protocol value. >
Thanks for the information. Mobile IPv4 is at the application layer, so I'd assume 'IP Mobility' (55) is for Mobile IPv6. Does anyone else know for sure ? > > In Section 3 you describe how to set the Home Address option through the > ancilary data. However, you do not address what happens if the user > specifies multiple options, include HAO, in the same ansilary data > (same header). I would suggest adding a restriction that to correctly > set the HAO in the destination header, the option SHOULD be specified alone > in a given ancilary data object. > Do you mean other destination or hop-by-hop options or routing header ? It definitely simplifies if we put that restriction. Does anyone see any potential issue in having this restriction ? > In Section 4.1, the draft describes how to use the IPV6_CHECKSUM > option on mobility headers. The draft seems to turn off "kernel" > checksumming by default on the IPPROTO_MH socket. I belive Yes. As per RFC3542 only ICMPv6 has the default checksumming feature. > 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. For other raw IPv6 sockets (that is, for raw IPv6 sockets created with a third argument other than IPPROTO_ICMPV6), the application must set the new IPV6_CHECKSUM socket option to have the kernel (1) compute and store a checksum for output, and (2) verify the received checksum on input, discarding the packet if the checksum is in error." Thanks for your comments. -Samita -------------------------------------------------------------------- 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] --------------------------------------------------------------------
