Subject: [mobile-ip] Re: IPv6 Advanced Socket API extension for Mobile IP

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 11 Jul 2003 18:19:13 -0700 (PDT)

> 
> 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

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 14 Jul 2003 14:28:23 -0400

Samita

> 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.

>    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

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 15 Jul 2003 14:05:39 -0700

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:
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------