Subject: Re: [Mip6] Update on MIP6 API draft

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 28 Apr 2004 00:38:53 -0700 (PDT)

>
> > 
> > Is your idea pattern1?
> 
> Yes. Because I expect that legacy applications will not care about the 
> routing type 2 hdr and hoa destination options.
> 
> This API is concerned about the MIPv6 user-level implementations or diagnostic
> applications. Thus I was expecting that these applications ( which also
> receives MH) could open RAW socket and sets RECV_DST* or RECV_RTH* and expect
> to receive MH and BU/BA etc. I have no code on that here. Since, you're 
> implementing, can you tell if that is problem for regular data?
> 
> I was thinking of the following code example to obtain COA:
> 
> 
>         msg.msg_iovlen = 1;
>         msg.msg_name = (struct sockaddr *)&from;
>         msg.msg_namelen = sizeof (from);
>         msg.msg_control = ancillary_data;
>         msg.msg_controllen = sizeof (ancillary_data);
> 
>         if ((len = recvmsg(sock, &msg, 0)) < 0) {
>                 logerror();
>                 return;
>         }
> 
> Note, msg contains the ancillary data while from contains the
> src-addr of the packet on the wire, which is COA.
> 

Thought a bit about it more...
I think my assumption is not correct as it will break mobility
unaware apps if the MN is moving. Thus they always expect "from"
address as home-address.

Thus, I can see the problem of retrival of COA. However, not sure if
storing the COA in home-address destination option ancillary data item
is the best way. What do others think on this?
As an alternative idea, we can have another socket option for retrieving
COA ? 

So far, do we agree on the following ?

- recvfrom, recvmsg, getpeername() will return home-address as the
  source address of the receiving packet if home-address option is
  present and the packet is successfully received by the implementation.
  
- All IPv6 apps should check the option types for destination option
  processing on the receive side. Mobility unaware apps should ignore
  the ancillary data items for HoA destination option or routing header
  type 2.

Question to the wg to resolve:

- Should RTHDR type 2 data item on the receive side contain 
  COA (i.e. the value after source address swapping) ?
  If this is consistent with RTHDR type 0, then the answer might be yes.
  
- Should HoA destination option ancillary data item contain COA (i.e
  after processing of HoA at the lower level) ?
  
Pros: 
   It's a way of getting COA for MIP6 user level implemention and diagnostic
    apps without any other change in the API. Works well if the kernel
    does address swapping for destination option and RTHDR type2.
    
Cons:
   It overloads the meaning of home-address destination option.
   It assumes that kernel takes care of address swapping before
   the packet is passed up to the upper layer.
   
 If the answer to the above question is no, then we need to
 define a API to retrieve COA.

 Thanks,
 -Samita  

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 30 Apr 2004 13:03:37 -0700 (PDT)

>   present and the packet is successfully received by the implementation.

Yes.

>   the ancillary data items for HoA destination option or routing header

I think what you are saying is that applications which use destination options
and/or (type 0) routing headers need to be coded to ignore the HAO and the
type 2 routing headers. This is due to the IPV6_RECV* options enabling the
receipt such that HAO and type 2 RH will be passed up.

>   If this is consistent with RTHDR type 0, then the answer might be yes.

Yes. 

>   after processing of HoA at the lower level) ?

Yes.

This is overloading, but the alternative would be to define additional
options and ancillary data items to carry this which would make
more work for the implementors. Ideally we should have a
IPV6_RECVSRCCOA/IPV6_RECVDSTCOA to enable the receipt and corresponding
ancillary data items to make the API cleaner, but the benefits of this seems
very small and it is extra code in the implementations compared to overloading
the existing mechanism.

   Erik