[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 Advanced Socket API extension for Mobile IP



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 majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------