Subject: Re: [mobile-ip] IPv6 advanced socket API extension for MIPv6

From: Brian Haley <[email-masked]>
Date: Sat, 01 Mar 2003 13:25:55 -0500

Samita Chakrabarti wrote:

> > > It may be a good point in general for IPv6 routing header.
> > > But the Routing header type 2 says that it must contain
> > > only one address. Do we envision it to change ?
> >
> > I know 2292-bis defines rthdr0 with just a comment there, I think
> > this should follow that as someone might expand rthdr2 later (isn't
> > there a draft on this?).
> 
> I am not aware of such draft. Would appreciate if someone sends a pointer.

Took me a while, it was a NEMO draft:

http://www.nal.motlabs.com/nemo/drafts/draft-ng-nemo-access-router-option.txt

I was just trying to point out that future drafts *might* want to update
such things, even if we can't think of a reason to do it today.

-Brian

---

From: "Suvidh Mathur" <[email-masked]>
Date: Sun, 2 Mar 2003 21:13:14 +0530

Hi,

Some comments about the draft:

1. Shouldn't the Home Agent Info option structure (to be carried in RA sent
by Home Agents)
      also be included in the draft?
2. Going by the reason for allowing MH packets to be created from user
space, doesn't it make
      sense to allow creation of Routing header and Home Address Option
also from the user space?

regards,
Suvidh

                      Samita Chakrabarti                                                                                                      
                      <Samita.Chakrabarti@eng.        To:       [email-masked]                                                            
                      sun.com>                        cc:       [email-masked], [email-masked]                          
                      Sent by:                        Subject:  Re: [mobile-ip] IPv6 advanced socket API extension for MIPv6                  
                      owner-mobile-ip@sunroof.                                                                                                
                      eng.sun.com                                                                                                             

                      01/03/2003 07:21 AM                                                                                                     
                      Please respond to Samita                                                                                                
                      Chakrabarti                                                                                                             

>
> mip6.h more clearly identifies the file as being IPv6-related to me.
> Also, Icmpv6 is different in that it has no "next" header field,
> Mobility is more like Destination options since it's not restricted
> to being a final header (some day).
>

But it has got 'checksum' like upper layer protocols which are also
looked up at the destination.

> > You mean I did not follow the order in MIPv6 base protocol draft ?
> >
> > OK, we can change the ordering to match that.
>
> Yes, it's an editorial nit.

Ok. will re-order.

> > > >   If the program likes to handle HOTI/HOT and COTI/COT message
> > > >   processing, it can do so by using IPv6 RAW Sockets for
IPPROTO_MH.
> > >
> > > Why do you single-out these four messages?  The user process will see
> > > all messages.
> > >
> >
> > Just for example. Yes the user process should be able to see the entire
> > messages carried by Mobility Header.
>
> Can you add "For example," then?

Sure.

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 4 Mar 2003 19:11:26 -0800 (PST)

Hi Suvidh,

>       also be included in the draft?

We have not considered the RA extensions and options and other HA ICMP messages
as part of this API draft. But I see that draft-ietf-ipngwg-rfc2292bis-08.txt
discusses APIs for ND definitions. So, it might make sense to have similar
definition here as well for the MIPv6 part for consistency. 

> also from the user space?

Good point for discussion. Technically it makes sense to allow the priviledged
apps to send the home-addr options and routing-hdr type 2 option. But the 
assumption is that kernel is the place which takes care of finding the
correct COA for HOA for CN and correct home address for the roaming MN.
In that case, giving priviledge to the apps can create conflict with what
kernel is doing. But this is a policy question, it'd be good to know
the working group input on this. 

Thanks for your comments,
-Samita