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

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 27 Mar 2003 18:05:01 +0900 (JST)

Hi all,

# I just have seen this mail, maybe too late.

From: Brian Haley <[email-masked]>

> Samita Chakrabarti wrote:
> 
> > > >    A new header file : <netinet/mh.h>
> > >
> > > mip6.h or ip6_mobile.h ?
> > 
> > IMHO mip6.h sounds more appropriate compared to ip6_mobile.h.
> > Let's discuss about the choice between mip6.h and mh.h.
> > 
> > The ideas behind naming it "mh" ( short of mobility header)  are:
> > 
> > * It has no IPv4 counter part
> > 
> > * It carries Mobile IPv6 signaling. It performs similar action like
> >   ICMPv6. So we are viewing "mh" as Mobility control packet for IPv6.
> > 
> > * "mh" is short of "mobility header"
> > 
> >   Thus, in my view, it is a part of Mobile IPv6 protocol and does not
> >   represent the whole MIPv6 protocol--hence we discarded mip6.h during
> >   the draft writing.
> 
> 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).

I support Brian.  It is better if the name of header file represents
the protocol.  Since you are deciding the name of Mobile IPv6 header
file, mip6.h (or mobileip6.h?) is looks better for me.
 
> > > > 2.1.  The Mobility Header Data Structures
> > 
> > > I don't think you're following the precedence set in RFC 2292 for
> > > IPv6 extension headers, in that doc all structure names and elements
> > > start with "ip6".  I would change this to:
> > 
> > No. I didn't. The reason is that these data structures were not part of
> > netinet/ip6.h header file, as it is the case for other IPv6 advanced socket
> > API. Since we are introducing a new header file, the data structure has
> > prefix corresponding to that name.
> > 
> > Mobility header has a number of data structure and an average IPv6 adv.
> > socket API implementor may not implement MIPv6 APIs, thus it was chosen
> > to separate them out.
> > 
> > May be we can ask the working group where they would like to see the
> > mobility data structure defined ?
> 
> I would like to see them defined in ip6.h with possibly their flags
> defined in mip6.h.

I understand Mobility header is one of IPv6 extention headers.  It
looks natual for me that mobility header definitions have the 'ip6_'
prefix.  (And our implementation also does that, not important of
course)

Also, I like all mobility header related constans are defined in
ip6.h.  But, since the Mobile IPv6 spec is huge enough, defining
constans in a sparate file (like mip6.h) may be good.

> > > Maybe "ip6_mobility" ?
> > 
> > Do you mean the structure name ?
> 
> Yes.

We also uses the name 'ip6_mobility' in our implementation, but I'm
not sure if it is good name.  As Samita concerns, we may have a new
mobility related protocol in some day.

> > > > 2.1.2  Binding Update Mobility Message
> > >
> > > This doesn't follow the order specified in Section 2.2 below, you should
> > > define the data structures in numerically ascending order for
> > > consistency (BR, HoTI, ..., BE).
> > >
> > 
> > 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.
> 
> > > > 2.2  Mobility Header Constants
> > > >
> > > >        IPv6 Next Header Value for Mobility:
> > > >        <netinet/in.h>
> > > >
> > > >        #define IPPROTO_MH       62 /* IPv6 Mobility Header: IANA-TBD */
> > >
> > > I recomment IPPROTO_MOBILITY.
> > >
> > 
> > The idea was to match X of IPPROTO_X with the protocol. In this case, the
> > protocol is "Mobility Header" protocol. But I guess IPPROTO_MOBILITY can be
> > alright too. But, what if in future MIPv6 defines another "mobility" related
> > protocol header  ?
> 
> I guess this will depend on what the base Mobile IPv6 protocol uses
> since that will set the precedence.  Most implementations I've seen
> use IPPROTO_MOBILITY.

Again, we also uses IPPROTO_MOBILITY, but IPPROTO_MH may be better, I
think.

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 27 Mar 2003 16:38:21 +0100 (CET)

> prefix.  (And our implementation also does that, not important of

The mobility header is as much an IPv6 extension header as is tcp, udp, and
icmp.
But the history is that before the mobility header (with its own payload type)
the same function was accomplished using IPv6 destination options.
At that point in time using names with "ip6" prefixes made sense.
From a consistency perspective it makes less sense know when it is
a separate payload type.
Thus the question for the current and future MIPv6 implementors is
if it is more important to follow what folks have already implemented
or have the naming be more consistent across the board and switch to
a different prefix.
I don't have strong feelings either way; I just think it makes sense
to encourage implementations to use similar names and structures for the
packet headers. Thus to me it is more important to pick one than arguing
for picking a particular choice.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Mar 2003 18:20:32 +0100

Erik Nordmark wrote:
>>  looks natual for me that mobility header definitions have the 
>> 'ip6_' prefix.  (And our implementation also does that, not 
>> important of course)
> 
> if it is more important to follow what folks have already 
> implemented or have the naming be more consistent across the board
>  and switch to a different prefix. I don't have strong feelings 
> either way; I just think it makes sense to encourage 
> implementations to use similar names and structures for the packet
>  headers. Thus to me it is more important to pick one than arguing

One implementation has file name is mip.h and mobility header type is
a separate structure that is named mh.

Find replace with proper tools is easy to do too, so I can live with
other naming conventions.

When looking into homogenizing we might want to take into account that
whatever is decided will probably and eventually need to be suggested
to the Austing group too (if it will consider future releases of their
  current POSIX revision).

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 Mar 2003 10:49:24 +0100 (CET)

> to the Austing group too (if it will consider future releases of their

The Austin group has so far stayed away from all the material in rfc2292bis
(they haven't standardized things like raw sockets and not much for
socket options and ancillary data, and stayed completely away from
the "on the wire" data structures).

If they do want to cover more for socket options and/or ancillary data
then programmatic access to the MH packets might make sense for them,
but I doubt they want to get into the "on the wire" data stuctures.
So I don't think we have to worry about them for the particular details
about "ip6" vs. "mh" prefixes, header file name, etc.

  Erik

---

From: "Bryan Wang" <[email-masked]>
Date: Fri, 28 Mar 2003 18:00:19 -0800

Hi,

Could anyone give an update on the available testing suites for MIPv6?

I could get the TAHI testing suite for ID15, TIPI has the suite for ID18,
but the link is broken.
http://www.irisa.fr/tipi/Test_suites/ipv6-mipv6/IPv6-MIPv6-Draft18-IRISA.zip

Thanks,
Bryan Wang
Elmic Systems, USA

---

From: Yukiyo Akisada <[email-masked]>
Date: Mon, 31 Mar 2003 09:08:27 +0900

Hi, Bryan.

I'm a TAHI Project member developping MIPv6 test suite.

Actually, our current release contains MIPv6 test for ID15,
but I'm continuing to develop a MIPv6 test.

And we already have test for ID20.
Tests for ID21 are under developping.

Next suites will be available in April.
It will contain test for ID20.

Please wait a few weeks.

Best Regards.

On Fri, 28 Mar 2003 18:00:19 -0800

> http://www.irisa.fr/tipi/Test_suites/ipv6-mipv6/IPv6-MIPv6-Draft18-IRISA.zip

----
Yukiyo Akisada <[email-masked]>

---

From: "Bryan Wang" <[email-masked]>
Date: Mon, 31 Mar 2003 10:19:54 -0800

Hi Akisada-San,

Thank you for your quick response. Any chance to have a preview, or whatever
you might have now, it it doesn't cause you too much work? I don't mind
debugging the test suites while testing our implementation ;-)

Thank you for providing the excellent tool to the community.

Bryan

---

From: "Bryan Wang" <[email-masked]>
Date: Mon, 31 Mar 2003 10:48:34 -0800

Hi Akisada-San,

We have a Windows port of our statck, which runs as an application and
acesses the network devices through Winpcap driver. If you are interested to
test your test suites against it, we can provide you the biniary excecutable
that has the IPv6 and MIPv6 CN(draft 21) functionality. Expect bugs ;-)

Thanks,
Bryan

---

From: Yukiyo Akisada <[email-masked]>
Date: Tue, 1 Apr 2003 10:25:54 +0900

Hi, Bryan.

I can give you a current snapshot of our tool, if you hope so.
Please send e-mail to <[email-masked]> for our internal purpose.

Regards.

On Mon, 31 Mar 2003 10:19:54 -0800

----