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

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 26 Apr 2004 11:06:55 -0700 (PDT)

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.

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

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.

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

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

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
> > 
> > 
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mip6
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mip6

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

---

From: Charlie P <[email-masked]>
Date: Mon, 26 Apr 2004 13:26:28 -0700

Hello Samita,

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

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?

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.

Regards,
Charlie P.

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Tue, 27 Apr 2004 11:14:33 +0900 (JST)

Hi Samita, Ryuji,

From: Samita Chakrabarti <[email-masked]>
Subject: Re: [Mip6] Update on MIP6 API draft
Date: Mon, 26 Apr 2004 11:06:55 -0700 (PDT)

> received from the network, i.e Home address.

Hum...  I may not agree on this point.

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?

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

Is your idea pattern1?  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.
 
> source address with the HoA while another copy is sent up which contains the

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?

> or RECV_DSTOPTS for some-reason and this is just an app without any knowledge

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.

> int inet6_rth_gettype(const void *bp);

This is of course useful and necessary for Mobile IPv6 aware
applications.
 
> 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.  If the app doesn't know Mobile IPv6, the app will
ignore HOA dstopt.  If the app knows Mobile IPv6, the app will use the
HOA dstopt, which contains CoA in fact.
 
> All other cases, there is no-swapping of source address.

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Tue, 27 Apr 2004 13:46:09 +0900 (JST)

Hi Samita,

Sorry, I had made a mistake in my previous mail.

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Subject: Re: [Mip6] Update on MIP6 API draft
Date: Tue, 27 Apr 2004 11:14:33 +0900 (JST)

> pattern3)  <== this is ryuji's idea

I meant getpeername() instead of IPV6_PKTINFO in the above table.

Regards,
---
Keiichi SHIMA

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 27 Apr 2004 16:10:40 +0900

Hello Samita

MIP6 stack can be implemented on userland like ICMP because MH is no
longer IP option. 

If somebody implements a MIP6 daemon (processing BU/BA) on the
application level. The daemon needs to get CoA on the userland. 
However, IP destination option and routing header are IP options and are
processed in the Kernel. Thus, when the daemon receive BU, the IPv6
source address will be HoA and the HoA destination option contain CoA. I
think this is reasonable operation.

regards
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 27 Apr 2004 16:25:06 +0900

Hi again.

The pattern3 works fine in our implementation.
We also uses the pattern3 for sending MH operation, too.

You don't need to make distiction at the api level for destination
option and rthdr type2. All appliactions should check type of options by
themselves.

regards
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 27 Apr 2004 16:29:59 +0900

Hello Charlie.

There is an application that is MIP6 control deamon.
Since MH is no longer IP options, we can implement 
MIP6 stack as an system deamon. 
The MIP6 deamon needs to access CoA per packet.

All protocols using MH can be implemented on userland.

regards,
ryuji