Subject: [mobile-ip] closing issue 81 (shorten mobile cookies from 64->32 bits)

From: Jari Arkko <[email-masked]>
Date: Mon, 23 Sep 2002 17:59:51 +0300

Hi,

I'm trying to close the issue 81 which Vijay raised a long time ago.
This issue (http://www.piuha.net/~jarkko/publications/mipv6/issues/issue81.txt)
reopens a part of what we decided back in issue 51
(http://www.piuha.net/~jarkko/publications/mipv6/issues/issue51.txt).
Namely, back then we said that mobile cookies should be at least 32
bits but that due to alignment reasons we might as well make them
64 bits without wasting any more bandwidth.

Vijay made the point that even if we are not wasting any bandwidth
*now*, we might be doing that in the future. If there are some new mobility
options that could fit to the packet if the cookies are 32 bits, but
with 64 bits an additional 8 bytes is allocated for the option.

Analysing the impacts of the proposed change we can note the following:

+ 32 bit cookies are likely sufficient for security purposes, for now;
   see issue 51 for more information
- All other cookies are 64 bits, so it would look nice if the mobile
   cookies were 64 bits too
+ If cookies are 32 bits then the HOTI/HOT, COTI/COT messages can
   fit an extra 1-4 byte option without a size increase. In practise
   we can send a mobility option with a 16 bit value, when the tag
   and length fields are considered.
- The mobile cookies are not used in the BUs and BAs, so the only
   effects are in the HOTI/HOT, COTI/COT messages.
- It is perhaps less likely that new useful options are invented
   for HOTI/HOT, COTI/COT than the BUs and BAs. None are currently
   defined.
- Given that the home and care-of cookies still need to be 64 bits,
   they should be aligned on an 8-byte boundary. This seems to imply
   that HOT/COT must have the home/care-of cookie first, followed
   by the mobile cookie. However, in HOTI/COTI the mobile cookie
   is alone. This complicates the implementation technique where
   a home/care-of cookie is simply added to the HOTI/HOTI and the
   message type is changed, since the mobile cookie field would have
   to move.

RECOMMENDATION

In conclusion this doesn't matter much either way. However, I'd
like to recommend that we keep the format as is, simply to keep
all cookies similar, and to make the construction of the response
easier from the request.

Comments?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Sep 2002 17:46:00 -0700

> (http://www.piuha.net/~jarkko/publications/mipv6/issues/issue51.txt).

when I wrote that email, issue 51 was still open. infact the 
subject on that mail was 'issue 51'.

> - All other cookies are 64 bits, so it would look nice if the mobile

this is not a strong argument.

>    message type is changed, since the mobile cookie field would have

this implementation technique is bad. I dont do a byte copy 
of the MH contents from the incoming HoTi message onto the 
outgoing HoT message. when I construct a HoT message, I fill
in each field.

reducing it to 32 bits saves me a few 64 bit operations.

> all cookies similar, and to make the construction of the response

dont agree.

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 26 Sep 2002 09:45:41 -0400

Jari

I agree with the recomendation of keeping all cookies
at 64 bits.

-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07