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

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 27 Apr 2004 18:45:16 -0700 (PDT)

Hi Keiichi and Ryuji,

> 
> > Let me clarify your idea.  If a mobile node sends a packet which
> > contains HOA dstopt from CoA, what will the receiving node get by
> > socket API?

I assume you mean (above) that a mobile node sends a packet with
IP src = COA  and HoA dst option with its home-address 
IP dst  = CN's address (fixed for now)

Is this correct ?

> > 
> > pattern1)
> >   CoA via IPV6_PKTINFO
> >   HoA via IPV6_DSTOPTS
> > 
> > pattern2)
> >   HoA via IPV6_PKTINFO
> >   HoA via IPV6_DSTOPTS
> > 
> > pattern3)  <== this is ryuji's idea
> >   HoA via IPV6_PKTINFO
> >   CoA via IPV6_DSTOPTS
> 
> I meant getpeername() instead of IPV6_PKTINFO in the above table.

Ok, so do you agree that IPV6_PKTINFO on receive will contain the destination
address of the IP packet (CN in this example) ?

For getpeername(), it is tricky, I agree. (draft does not mention about it ) 

For user applications that are transparent of MIPv6 activity underneath, should
expect getpeername() to return the home-address.
Thus, I agree that getpeername() returns the home address of the peer if there 
is
a HOA destination option present in the packet, otherwise it follows the default
getpeername() behavior.

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

For alternate COA, of-course there is no API defined yet. It is
expected that the application will parse the MH options and find
out. Does anyone think a separate API for finding COA would be useful here?

>  If so, I don't agree.  If we take pattern1,
> the application loses the transparency of Mobile IPv6.  An application
> must check the existence of HOA dstopt, when it want to know the
> (logical) source address of the peer.  I think the source address
> should be a home address for any applications to keep transparency.
> 
> If you idea is pattern2, there is a transparency.  But in pattern2, we
> cannot know the CoA by any means.
> 
> So, I support pattern3.
>  

If the user-level MIP6 apps wants the transparency of MIP in the kernel,
then pattern3 works. But, I am afraid then we will be changing the
meaning of home-address destination option. 

I am eager to find out what other implementors and RFC3542 authors think
on pattern3?

> > > The same question can be applied to the processing of a routing header
> > > option. Which address is stored in the routing header option? I
> > > believes it is CoA.
> > > 
> > 
> > I'd think it'd be the same logic here as well. Thus the kernel will process
> > the basic check of the routing hdr option and process one copy to replace
> > source address with the HoA while another copy is sent up which contains the
> > HoA.
> 
> In routing header type 2 case, I don't see any problem.  The
> destination address of a input packet should be the final destination
> address (e.g. HoA), and the routing header contains the address of a
> intermediate node(CoA).  This is the same manner with routing header
> type 0.
> 
> If the kernel passes a routing header type 2 with HoA, how can we get
> CoA of the packet?
> 
>

I think either way it should work. We need to define one.

We need comments on the two choices:

1) Should the copy of MH and routing hdr or Hoa destination be sent up
   as it was received on the wire for RAW  sockets ?
   
2) Should the copy of MH and routing hdr or HOA destination options be
    passed after kernel does the RTHDR and HOA processing?

> 
> In the latter case, the app just ignore HOA dstopt because the opt is
> unknown to the app.  In rthdr2 case, the app can handle the routing
> header with no problem, as long as the rthdr2 contains CoA and the
> destination address of the packet is HoA.
> 
> My idea is that the source address/destination address are always HoA.
> 

Are you talking about MIP6 user level apps ?

>  
> > To address routing hdr, we have introduced a new gettype function to 
> > distinguish between routing hdr type2 and type 0 data. Thus if the routing
> > hdr type2, then the app should process that accordingly.
> > int inet6_rth_gettype(const void *bp);
> 
> This is of course useful and necessary for Mobile IPv6 aware
> applications.
>  
> > But we don't have such distiction at the api level for destination option
> > unless the app checks the option type value of destoption and process
> > accordingly. (we have PAD1, PADn, HOA setoption defined so far).
> 
> The application which utilize hopopts or dstopts must check its option
> type before processing.  Otherwise, we cannot provide a backward
> compatibility. 

Yes. Does the AdvAPI appl currently check the option type ? 
This is a good point that the draft is missing.

Thanks for the useful comments,
-Samita

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

---

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

Hi Charlie,

> Do you have ideas about what the application would
> do with the care-of address information?

Normally legacy applications would not know about the MN
movement and thus they don't need to know about COA.

For mobility-aware applications (to-be built in future), COA
knowledge may be necessary. Thus, it might be useful to have
a separate API funtion to retrieve COA from the system for those
cases.

Besides, some implementations (one on linux and other for
small devices) may want to do the MIPv6 signalling packet
processing in the user level and then send down appropriate
info down to kernel for binding cache processing. Or they may
choose to do binding cache processing at the user level as well-
who knows.
Other than that, we need the API for snooping and diagnostic or policy
based applications which would like to know the hoa and coa both.

> 
> Presumably, there is a separate interface that enables
> applications to get access to binding cache information.
> Is that sufficient for the purposes you have in mind, or
> does it have to be per-packet?

As mentioned by Ryuji, that per-packet is necessary for the
MIP6 user level implementation and also needed for any MIP6
policy based apps which may reside on CN and determine flow/access/
resource allocation policies for the roaming MNs based on initial or
 final binding updates/renewals etc.

Thanks,
-Samita

> 
> I thought that, generally speaking, applications that
> opened up a socket for using the home address should
> not be messing with the care-of address.  Debugging
> is, I guess, a different matter with specialized needs.

> 
> >Hello Ryuji,
> >
> >  
> >
> >>When an application gets a HoA dest option through your socket API,
> >>which address is stored in the HoA dest option? CoA or HoA?
> >>
> >>When the application processes the received packet at raw socket, the
> >>home address is stored in the IP Source address field. Thus, the HoA
> >>dest option should contain CoA. Otherwise, there is no way to retrieve
> >>CoA from your socket API. 
> >>
> >>    
> >>
> >
> >I am not sure if I understood your question correctly. Here is my
> >interpretation - you want to know the content of HOA dst option on
> >the receive side of the application. 
> >I would assume that the dest option field that is received as an
> >ancillary data item would contain the same field as the IP would have
> >received from the network, i.e Home address.
> >
> >Thus the implemention in the kernel, after the security check, would pass
> >the information up as it was received - ie, source address as COA and
> >home-address with the HOA option. It depends on the implementation, but
> >policy might be such that one copy is processed at the kernel and a copy
> >is sent up. Or if the implementation is completely done in upper layer,
> >all the information is passed up and the the application processes the 
> >information and sends down some msgs to the kernel to update the binding
> >cache info. 
> >
> >For example, if the application in this case, is a debugging app, then
> >definitely, the packet actually is processed at the kernel and one copy of
> >it sent up at the application.
> >
> >  
> >
> >That was the thoughts.
> >Although you brought up the interesting points which the draft does not
> >clearly address -- i,e. what would be the source address of the msg at the
> >socket layer when RECV_DSTOPTION is set and there is a HOA option?
> >
> >Case1: Kernel does all the processing and the apps are running as normal
> >apps -- no knowledge of HOA or Routing hdr underneath - all taken care by
> >the IP layer.
> >
> >Case2: Kernel does all the processing, but the application sets RECV_RTHDR
> >or RECV_DSTOPTS for some-reason and this is just an app without any knowledge
> >of MIP6.
> >
> >One problem, I can see that existing advapi apps may also need to update to
> >check type, otherwise they will break if the kernel receives packets
> >with HOA or RTHDR_TYPE2. Alternatively we can add new RECV_* option type for 
> >routing hdr type2 and HOA dst option to distinguish the uniqueness of
> >this situation. Thus the existing apps or RFC3542 does not need any 
> >modification- but that may not be an issue.
> >All other cases, there is no-swapping of source address.
> >
> >Comments ?
> >
> >
> >Thanks,
> >-Samita
> >
> >
> >  
> >
> >>At Fri, 16 Apr 2004 15:38:30 -0700 (PDT),
> >>Samita Chakrabarti wrote:
> >>    
> >>
> >>>We have just submitted the second revision of the 
> >>>      
> >>>
> >draft-ietf-mip6-mipext-advapi
> >  
> >
> >>>draft. The changes are nominal. This version is ready for WG last call.
> >>>
> >>>The following changes are made as per suggestions from the implementors
> >>>at the March Connectathon.
> >>>
> >>>  * Section 2.1.11.2 now  defines alternate COA address data structure
> >>>     as struct in6_addr for consistency. It was defined as 16 unit
> >>>     of bytes.
> >>>
> >>>   * Added Binding Update Authdata of 12 bytes in the
> >>>     struct ip6_mh_opt_auth_data
> >>>
> >>>   * Added a new function inet6_rth_gettype() in section 3.1 in order
> >>>     to distinguish routing header type 2 ancillary data items from
> >>>     type 0 routing header ancillary data items on the receive side.
> >>>     The suggestion was made by Anti Tuominen of Helsinki University as he
> >>>     found this function was necessary while writing the MIPv6 
> >>>      
> >>>
> >implementation
> >  
> >
> >>>     in the user level.
> >>>
> >>>
> >>>The draft should be available in the ID directory in a few days.
> >>>
> >>>
> >>>Thanks,
> >>>-Samita
> >>>
> >>>

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 30 Apr 2004 14:17:01 -0700 (PDT)

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

Yes. Currently the draft is unclear about that.

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

My thinking was that a new *RECV_COA option for receiving source COA would be a
cleaner approach. But I agree that  specifying the overloading on
hoA on the receive side may be easier to implement without adding much code
on the exisitng IPv6 implementation - this is quite useful for small
device implementation in the user level as well. 

Thanks,
-Samita