Subject: [Mip6] MIPV6API draft Issues/proposals

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 7 Oct 2003 18:09:41 -0700 (PDT)

We have discussed the following issues in mobile-ip and [email-masked]
alias. The co-authors of MIP6API draft have addressed them as below and would 
like to close them on this alias. Thanks for your comments.

PS: At Vienna IETF, MIP6 chairs wanted to discuss with IPv6 wg chairs
    to decide on the route of progress of this draft.
    Would like to know if there is any status on that.
    
    Basic Reference: draft-chakrabarti-mobileip-mipext-advapi-01.txt
    [Other minor issues have been resolved in the V02]
-----------------------------------------------------------------

Issues addressed: (Brian, Keiichi)
1.
For consistency:
Changed all the data structure defined in ip6mh.h as following:

ip6_mh -- MH hdr
ip6_mh_<msgtype>
ip6_mh_opt_<optiontype>

-----
2. (Brian, Keiichi)
Some minor modification of field names based on
implementor's recommendations. For example,
resvd -> reserved etc.
ip6hoa_->ip6oha_*
---
3. (Brian, Keiichi and others?)

 The data structure defined in icmp6.h for dynamic HA
 discovery etc. still has prefix MIP/mip.

Proposal:
 Do people want to see it as MIP6/mip6 or does not matter?
 We need at least 3 votes to change it.

---
4. (Vladislav, Jinmei)

 Checksum issue:

 This API should manadate that the kernel does do the checksumming
 by default. This does not go along with RFC3542 where it recommends
 only ICMPv6 protocols are used for default checksumming, but for
 all other RAW IPv6 sockets app. must set IPV6_CHECKSUM socket option.

Proposal:
 For compatibility with RFC3542, an application that opens a RAW socket
 with protocol IPPROTO_MH should set IPV6_CHECKSUM socket option.
 However, a  Mobile IPv6 implementation  must support mobility header
 API checksumming in the kernel for inbound and outbound path
 irrespective of IPV6_CHECKSUM socket option setting. Thus if the 
 third argument of the socket() is IPPROTO_MH, the checksum is 
 calculated by the kernel by default. A Mobile IPv6 implementation
 must not return error on IPV6_CHECKSUM socket option, even if the
 socket option is a NO-OP function for that implementation.

-----

5. (Vladislav)

  What is the value of IPPROTO_MH ?
  Is 55 an IANA assigned number for MIP6 ?

---

6. (Vladislav)

 Placement of HOA Destination option:

 RFC3542 adopts RFC2460 extension header ordering, but Mobile IPv6
 (section 6.3 of draft 24) has need for different home address
 destination option ordering. Should we use single ancillary data
 item for HOA destination option ?

Proposal:
 RFC3542 restricts that:

-  Each IPV6_xxx ancillary data object for a particular type of
      extension header can be specified at most once in a single control
      buffer.

-  IPV6_xxx ancillary data objects can appear in any order in a
      control buffer, because there is no ambiguity of the ordering.

Since no other destination option(IPV6_DSTOPTS) is defined (so far)
other than HOA destination option type, there will be only one HOA
ancillary data object in a particular control buffer. Thus, if HOA
IPV6_DSTOPTS is sent down to the kernel by the application, the kernel
is responsible for extracting the data object and placing the HOA
destination option extension header according to section 6.3 of base
Mobile IPv6 specification.
-----------------------------------

-Samita

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6