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

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 25 Feb 2003 14:19:49 -0800 (PST)

Hi Brian,

> 
> Thanks for writing up the draft.  While I'm not sure many user-space
> apps need to know about mobility (since they won't typically be able
> to do anything about it), I guess we shouldn't stop them from
> snooping on the messages.  Getting the data structures defined for

It's true that we don't see many application level of MIPv6 implementation
today. But the debugging tools and snooping would need to access the
protocol headers for reading the data. Besides, in future may be some
policy setting apps would need to know the home-address present in the
binding updates and based on that it may grant some action. 

> consistency is a good thing (ala 2292, etc.), I have a lot of
> comments on that though...
> 

Thanks for the detail review comments. Editorial suggestions are accepted.
I am  replying to the part we need more discussion on.

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

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

> Maybe "ip6_mobility" ?

Do you mean the structure name ?

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

> >     struct mh_binding_update {
> >        struct mh_hdr mh_bu_hdr;
> >        uint16_t    mh_bu_seqno;      /* Sequence Number */
> >        uint16_t
> >           mh_bu_flags_ack : 1,    /* Request a binding ack */
> >           mh_bu_flags_home : 1,   /* Home Registration */
> >           mh_bu_flags_ll : 1,     /* Link Local address capability */
> >           mh_bu_flags_sa : 1,     /* Key management capability */
> >           mh_bu_flags_resvd : 12; /* Reserved */
> >        uint16_t     mh_bu_lifetime; /* Time in unit of 4 sec */
> >         /* Followed by optional Mobility Options */
> >     };
> 
> Embedding the common elements of the Mobility Header structure
> is also something that isn't done in 2292 either, I'd rather
> see this separated (this will also bring it inline with all the
> other implementations I've seen).  Flags should be broken out
> as well.

makes sense.

> I'll skip repeating myself for the BRR, HoTI, CoTI, HoT, CoT and BE,
> you get the point.  My only other recommendation would be to look
> at the KAME definitions in netinet/ip6.h and netinet6/mip6.h since
> I think they're well-defined there.
> 

I'll check. Thanks for the pointer.

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

> > 
> >        Mobility Header Message Types:
> >        <netinet/mh.h>
> > 
> >        #define MH_TYPE_BRR       0   /* Binding Request */
> >        #define MH_TYPE_HOTI      1   /* HOTI Message   */
> >        #define MH_TYPE_COTI      2   /* COTI Message  */
> >        #define MH_TYPE_HOT       3   /* HOT Message   */
> >        #define MH_TYPE_COT       4   /* COT Message  */
> >        #define MH_TYPE_BU        5   /* Binding Update */
> >        #define MH_TYPE_BACK      6   /* Binding ACK */
> >        #define MH_TYPE_BERROR    7   /* Binding Error */
> 
> I recommend:
> 
> /* Mobility Header Message Types */
> #define IP6M_BINDING_REQUEST    0x00    /* Binding Refresh Request */
> #define IP6M_HOME_TEST_INIT     0x01    /* Home Test Init */
> #define IP6M_CAREOF_TEST_INIT   0x02    /* Care-of Test Init */
> #define IP6M_HOME_TEST          0x03    /* Home Test */
> #define IP6M_CAREOF_TEST        0x04    /* Care-of Test */
> #define IP6M_BINDING_UPDATE     0x05    /* Binding Update */
> #define IP6M_BINDING_ACK        0x06    /* Binding Ack */
> #define IP6M_BINDING_ERROR      0x07    /* Binding Error */
> 

I am not sure, if I agree with this naming style. MH_TYPE* are clearly different
type values of Mobility Header messages. IP6M_*  does not quite convey that.

> 
> Unique ID is no longer in draft 20.

Yes, I missed that while updating this draft for draft20.

> >        #define MH_BAS_SEQNO_BAD  135  /* Sequence number out of range */
> >        #define MH_BAS_EXP_HOME_NI  136 /* Expired Home nonce index */
> >        #define MH_BAS_EXP_COA_NI   137 /* Expired Care-of nonce index */
> >        #define MH_BAS_EXP_NI       138 /* Expired Nonce Indices */
> 
> See KAME netinet6/mip6.h
> 

Will check.

> > 2.3.  IPv6 Home Address Destination Option
> > 
> >       <netinet/ip6.h>
> > 
> >       /* Home Address Destination Option */
> >       struct ip6_opt_hoa {
> >          uint8_t           ip6hoa_type;
> >          uint8_t           ip6hoa_len;
> >          uint8_t           ip6hoa_addr[16];
> >       }
> 
> I recommend "struct ip6_opt_home_address".

What do others think ?  Any comments on this naming proposal ?

> >       /* Type 2 Routing header for Mobility Protocol */
> >        struct ip6_rthdr2 {
> >          uint8_t  ip6r2_nxt;       /* next header */
> >          uint8_t  ip6r2_len;       /* length : always 2 */
> >          uint8_t  ip6r2_type;      /* always 2 */
> >          uint8_t  ip6r2_segleft;   /* segments left: always 1 */
> >          uint32_t ip6r2_reserved;  /* reserved field */
> >          struct in6_addr ip6r2_homeaddr;  /* Home Address */
> >        };
> 
> I don't think the address should be included in the struct,
> just a comment:
> 
> 	/* followed by one struct in6_addr */
> 
> This makes it extensible in the future to hold more addresses.
> 

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 ?

> >    socket() call and IPV6_CHECKSUM option is not set, the application
> >    needs to fill the checksum field of the mobility header for outbound
> >    data. Similarly the application needs to do checksum validity check
> >    for the received packet.
> 
> I don't think you need this last sentence, it the MH checksum is
> invalid the system will have dropped the packet (as you said a few
> sentences earlier).
>

Ok.

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

> >    The protocol number for Mobility is pending IANA
> >    (http://www.iana.orgassignments/protocol-numbers) assignment.
> > 
> >           ipv6-mh           62(?)      # Mobility Protocol Header
> 
> I recommend "ipv6-mobility".

I was tempted to do so. Only point is that what if we define some other
mobility header or protocol in future ?

> 
> > 7.  Security Considerations
> > 
> >    The setting of Home Address Destination option and route header
> >    Type 2 IPV6_RTHDR socket option may not be allowed at the
> >    application level in order to prevent denial-of-service attacks
> >    or man in the middle attacks by hackers.
> 
> Yes, I would assume most/all kernel implementations of Mipv6 would
> not allow a user to set any of these options since it could
> interfere with the correct operation of the protocol.
> 

Ok.

Thanks again,
-Samita

---

From: Brian Haley <[email-masked]>
Date: Tue, 25 Feb 2003 18:18:15 -0500

>   represent the whole MIPv6 protocol--hence we discarded mip6.h during

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

> mobility data structure defined ?

I would like to see them defined in ip6.h with possibly their flags
defined in mip6.h.

> Do you mean the structure name ?

Yes.

> OK, we can change the ordering to match that.

Yes, it's an editorial nit.

> alright too. But, what if in future MIPv6 defines another "mobility" related

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.

> type values of Mobility Header messages. IP6M_*  does not quite convey that.

IP6M == IPv6 Mobility

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

> messages carried by Mobility Header.

Can you add "For example," then?

> mobility header or protocol in future ?

It should match the IPPROTO_* definition that is decided upon.

I based most of my struct naming comments on the implementations I've seen,
as well as ours, assuming we wanted to make this draft similar to what's
been done.  I haven't seen Sun's code of course :)

-Brian