Subject: Re: [mobile-ip] Mobile IPv6 draft 15

From: Brian Haley USG <[email-masked]>
Date: Tue, 20 Nov 2001 13:48:15 -0500

Charlie Perkins wrote:
> Hello folks,
> 
> A new revision of Mobile IPv6 has been prepared.  It is currently
> available at the following URL:
>     http://people.nokia.net/~charliep/txt/mobilev6/mobilev6.txt

Hi Charlie,

I believe there is a clarification that needs to be made in
Home Address option processing.  This week at ETSI there was a
test case where this option sequence was sent:

  IPv6 header
  Destination Options header
    Binding Update option
    Home Address option

Of course it was dropped since during Binding Update processing we
noticed we didn't have a Home Address (ala Section 8.2)...

I believe this ordering is invalid according to Section 4.2 of RFC 2460:

  The sequence of options within a header must be processed strictly in
  the order they appear in the header; a receiver must not, for
  example, scan through the header looking for a particular kind of
  option and process that option prior to processing all preceding
  ones.

(thanks to Ken Powell for pointing this out to me)

But the Mobile IPv6 draft does not say the Home Address option must
be "in front" of a Binding Update option.  I believe that Section 5.4,
and maybe 10.1 and 10.2, need to clarify the ordering requirements of
the Home Address Option:

[5.4]
 The Home Address option MUST be placed as follows:

  - After the Routing Header, if that header is present
  - Before the Fragment Header, if that header is present
  - Before the AH or ESP Header, if either one of those
    headers is present
  - Before any headers or options that require Home Address
    option information, such as a Binding Update option

While one might think I just don't want to do more work since there is
one implementation that handles this case, I can't believe the Home
Address option was intended to be used in this way.

Thanks,

-Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 21 Nov 2001 14:18:22 +0100

=> you had it but you didn't already processed it. This is more
a proof that BU should not be destination options (:-), at least
you should agree that to support this case BUs should be processed
only when the terminal header is reached.

   
   
=> I disagree, the meaning of the Section 4.2 is not what you suggest.

   [5.4]

=> note this clause is a good reason to put the home address option
in a destination option before the one with the BU. And as there can
be an IPsec header a lot of implementations will apply this in all cases.

   
=> I disagree: this case (BU then HA) is so funny (and takes less bytes)!

Regards

[email-masked]

PS: as this issue is in mobile IPv6 drafts since years, I believe
we should wait for security problem resolution before revisiting
this point.