Subject: Re: [Mip6] mipext-advapi-04: sending HAO

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 08 Nov 2005 23:27:20 -0800

Hi Jean-Mickael,

Section  5.5 of the draft  states clearly  what should be the content of 
the home
address destination option when it is received by the application layer.

Is  this good enough for what you're looking for?

Thanks,
-Samita

Jean-Mickael Guerin wrote:

> Hi,
>
> Quoting section 3:
>
>    For sending Home Address destination option, ancillary data can be 
>    used to specify the option content for a single datagram. This
>    only applies to datagram and raw sockets; not to TCP sockets.
>    Advanced API [1] document restricts one IPV6_xxx ancillary data
>    object for a particular extension header in the control buffer.
>    Thus there would be a single ancillary data object for Home address
>    destination option in a ancillary data buffer. If the kernel
>    implementation supports this API, it is responsible for extracting
>    the Home address destination option data object and placing it as
>    destination option extension header in compliance with section
>    6.3 of Mobile IPv6 [2] base specification.
>
> I believe there is one assumption that should be explicitly written - 
> when a system supports mip advanced api, then the kernel is in charge 
> of swapping source
> address and HAO content before sending the packet.
>
> I would like to be sure that my MIP6 application behaves the same 
> across all systems,
> which sets HoA as source address and care-of address as HAO before the 
> call to sendmsg().
>
> Regards,
>
> Jean-Mickael
>
>
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6

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

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 08 Nov 2005 23:53:43 -0800

Please note that  we have a new version 05 available. This clarifies a 
bit about the
applicability and  sending and receiving of home address destination 
options.

-Samita

> Hi Jean-Mickael,
>
> Section  5.5 of the draft  states clearly  what should be the content 
> of the home
>> which sets HoA as source address and care-of address as HAO before 
>> the call to sendmsg().
>>
>> Regards,
>>
>> Jean-Mickael
>>
>>

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Wed, 09 Nov 2005 10:23:02 +0100

Hi Samita,

> applicability and  sending and receiving of home address destination 

I consider the application implementing MH header processing at user 
lever (section 2.1). Although the draft "encourages" to implement HAO in 
kernel, I think the application can take advantage to specify the 
content of HOA on sending, using ancillary data and ip6_opt_home_address 
structure.
In this case, I believe that kernel is still in charge of swapping 
source address (Home address) and the address in HOA before sending the 
packet.
So it may worth highlighting that the content of "ip6_opt_home_address" 
is not a Home Address (it is a care-of address), despite the name of the 
structure. Or I miss the part that clarifies this point ?

Regards,

Jean-Mickael

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 09 Nov 2005 16:17:07 -0800

Hi Jean-Mickael:

I'll update the home-address content section to clarify the content of 
home address
option  in ancillary data object on outbound path.  The assumption is 
that only those which implements
MIPv6 partly at the user level will send the home-address option for 
MObile IPv6.
No other user-level program is supposed to use this socket option on 
sending side.
When sent from the application level, on the outbound path, my 
understanding is
that it will be just used as IPv6 home address destination option in the 
kernel in
the order it was sent. That is why we added a section on ext. header 
ordering.

On the inbound path, the kernel does process the home-address option data
and swaps the addresses first ( for IPSec processing and passing up info).

-Samita

Jean-Mickael Guerin wrote:

> Hi Samita,
>
>> Please note that  we have a new version 05 available. This clarifies 
>> a bit about the
> lever (section 2.1). Although the draft "encourages" to implement HAO 
> in kernel, I think the application can take advantage to specify the 
> content of HOA on sending, using ancillary data and 
> ip6_opt_home_address structure.
> source address (Home address) and the address in HOA before sending 
> the packet.
> So it may worth highlighting that the content of 
> "ip6_opt_home_address" is not a Home Address (it is a care-of 
> address), despite the name of the structure. Or I miss the part that 
> clarifies this point ?
>
> Regards,
>
> Jean-Mickael

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 10 Nov 2005 01:09:53 -0800 (PST)

Hi Samita,

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 09 Nov 2005 16:17:07 -0800

> the order it was sent. That is why we added a section on ext. header 

Do you mean a program need to include a home address in the Home
Address Option when sending packets (e.g. MH messages)?

Last time we discussed the content of the HAO option in the mip6 ML,
Ryuji suggested that the HAO should include a care-of address even on
the sending side.  What do you think about that?  I didn't see any
explicit reply from authors about that suggestion at that time.

I quote the mail bellow.  I personally think we should include a home
address in the HAO even when sending and our current implementation do
so.

--quote--------------------------------------------------------------
From: Ryuji Wakikawa <[email-masked]>
Subject: Re: [Mip6] Update on MIP6 API draft
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
> 
> 
> 
> > 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)
> > 
> > > > 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.
> > 
> > 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.
> > > > 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?
> > 
> >  
> > > 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.
> > 
> > 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.
> > 
> >  
> > > 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.  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.
> >  
> > > 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 ?
> > 
> > ---
> > Keiichi SHIMA
> > IIJ Research Laboratory <[email-masked]>
> > KAME Project <[email-masked]>
> > 
> > https://www.ietf.org/mailman/listinfo/mip6
> 
> 
> 
> https://www.ietf.org/mailman/listinfo/mip6
--quote--------------------------------------------------------------

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Thu, 10 Nov 2005 12:07:51 +0100

>address in the HAO even when sending and our current implementation do
The impact on IPsec should be taken into account:
o If we set care-of in HAO, it allows the kernel to apply IPsec rules as 
described in RFC3776, but it requires the kernel to lookup HAO and swap 
addresses before sending. (btw I thought KAME/shisa did this way?).
o If we set home address in HAO, either security policies have to be 
updated with care-of address dynamically, or IPsec rules allow to filter 
HAO content as selector, or kernel swaps before and after IPsec processing.

First option looks more consistent with inbound path, while second 
option may help routing by setting just one rule to tunnel all traffic 
whose source address is home address.

Regards,

Jean-Mickael

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 10 Nov 2005 10:10:27 -0800 (PST)

From: Jean-Mickael Guerin <[email-masked]>
Subject: Re: [Mip6] mipext-advapi-04: sending HAO
Date: Thu, 10 Nov 2005 12:07:51 +0100

> >address in the HAO even when sending and our current implementation do

Oh, I said an opposite thing.

I wanted to say, 'I personally think we should include a care-of
address in the HAO even when sending and our current implementation do
so.'

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

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 10 Nov 2005 12:27:32 -0800

Hi Keiichi,
Please see my comments  in-line.

>Address Option when sending packets (e.g. MH messages)?

No.  The applicability section should say that the application program 
should never have to
send the home-address destination option, since this is taken care by 
the MIP6 implementation.  If  one decided to implement  part of MIP6 at 
the user level - only then
it may require to send home address destination option explicitly. The 
draft generally
recommends that  user-level applications do not send home-address 
destination options
or route headers.

>explicit reply from authors about that suggestion at that time.

We thought receiving side is what was proposed. I don't think it makes 
sense for the transmit side. According to base protocol, the MIP6 
implementation will take care
of  mapping the home-address into the home address destination option 
and doing the
correct IPSec processing based on the home address and then send data 
using the
COA as the source address when  roaming.

>address in the HAO even when sending and our current implementation do

Agreed.  We  will update the Home Address access section of the draft to 
clarify that.
Also mention that the IPSec processing should be done based on home 
address option
content on the sending side.

Thanks for  your comment.
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 10 Nov 2005 12:34:58 -0800

Jean-Mickael Guerin wrote:

> o If we set care-of in HAO, it allows the kernel to apply IPsec rules 
> as described in RFC3776, but it requires the kernel to lookup HAO and 
> swap addresses before sending. (btw I thought KAME/shisa did this way?).
> updated with care-of address dynamically, or IPsec rules allow to 
> filter HAO content as selector, or kernel swaps before and after IPsec 
> processing.
>

On outbound path,  HAO option will contain Home address and the IPSec 
processing will have to be done using the content of Home-address option 
when a MIP6 implementation
chooses to have a partial implementation at the user-level. For example, 
it sends MH , RH
and HOA option from user-level and rest of the MIP6 processing is done 
at the  kernel
on the outbound path.

-Samita