Subject: [MOBILE-IP] Proposal for new Destination Options placement

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 4 Oct 2000 08:11:13 -0700

Hello Francis et al.,

I am writing this note in response to your note, appended after
the main body of this note.  I have been studying the issues
relevant to the placement of the Home Address option and the
Binding Update option, in preparation for making a new revision
for Mobile IPv6.  It is a tough problem.

I agree with you that the existing choices for ordering AH
and Destination Options are not sufficient.  In my mind,
the first and most serious error, that affects the placement
of the Home Address option, is it has to go before AH, but
there is no need at all for it to be processed by the
intermediate routing points of a routing header.

Therefore, I'd like to suggest that in the Mobile IPv6
specification, we enable the placement of Destination Options
after the Routing Header, but before the Fragment Header.
This will enable the correct placement of the Home Address
destination option, and it will greatly simplify any needed
firewall treatment.

Regards,
Charlie P.

-------- Original Message --------
Subject: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec
Date: Tue, 1 Aug 2000 21:16:56 +0200
From: Francis Dupont <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]

 In your previous mail you wrote:

   > => this point was signaled by me and others... The final document
   > is supposed to fix it.

     So, the care-of-address is used as the IP source address for the
   authentication calculations. Correct?

=> we need both the home and the care-of address, one will be in the
source address field, the other in the home address option.
But we have to wait for the final document to know the exact order
(ie. swapped (me) or not (Microsoft)).

   > => I disagree because you put more in "Binding Update option processing"
   > than it should be. In fact when you decode the BU you don't know if there
   > is an AH after or (the argument :-) a HA option.

     Now, I am confused ... Since we propose to put the BU in the 2nd
   Destination Options header, this problem wouldn't occur.

=> you can put the BU in the first/only DO header before the HA: you have
replaced "MUST include" by "MUST be before" which is far stronger... (*)
The only constraint in the order is there MUST be a DO header with
a HA option before the AH header, you can put the BU where you'd like
(before or after, in the same header than the HA or in an other one.
In my code I put it in the same header than the HA in the order which
gives the smallest length).

   By the time we get
   to the BU message, we have already processed the HA option (which MUST be in
   the 1st Destination Options header) and the AH (which MUST occur before the
   2nd Destination Options header).

=> the second MUST is yours and obviously is incorrect because I can implement
this with only one DO header...

   > I execute the BU only
   > when I see the upper layer header, the processing itself is restricted
   > to length/alignement checks.

     So, what would you say are the advantages of putting the BU in the 1st
   Destination Options header?

=> simpler, smaller, ...

   Or is it just convenience since only one of the
   Destination Options headers must be processed then?

=> of course it is convenience. But if you have an ESP header too
our firewall implementors want to have all DO headers in clear, ie
before the ESP. Then they convince me to keep the way I built the DO
header before IPsec introduction and just add some code which:
 - puts the AH after the DO header
 - supports DO headers (and DO themselves) in *any* order on input

     Could anybody working on the "final document" respond to this question?

=> I'll try to catch Dave Johnson who is here (IETF, mobileip 1st session).

   >    2. It should clarify which address, the mobile node's Home Address or
   >    care-of-address, must be used for the SA/SP lookup.
   >
   > => this is clearly specified in the I-D (home address must be used).

     Could you please point out the respective section?

=> section 10.2 (inbound processing must be symmetrical).
Beware that IKE rules are a bit hairy (but less than IKE itself :-).

Regards

[email-masked],

PS *: to put the HA option after the BU option is a favorite in
the UNH mobile IPv6 test suite...

---

From: Francis Dupont <[email-masked]>
Date: Thu, 5 Oct 2000 14:17:45 +0200

=> we agree. We'll get three kinds of destination options extension
headers:
 - "note 1" which are not used (IMHO we should garbage collected them).
 - new DO headers between the routing header (if any) and the fragmentation
   header (if any). I believe the tunnel encapsulation limit should
   go there too (ie. with the home address option) because this will
   limit over-encapsulated fragments (and over-encapsulation would produce
   fragments).
 - "note 3" well known DO headers which will be used today only for
   binding options then should get a new value for its next-header type
   (this will not introduce major interoperability problems and will
    make things far simpler to understand ans to implement).

Thanks

[email-masked]

PS: this mail is the result of a meeting at IPv6 bake-off organized by ETSI
between all present mobile IPv6 gurus...