Re: [Mip4] One implementation of RREQ/RREP time synchronization

"Charles E. Perkins" <> Thu, 21 March 2013 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B337721F8168 for <>; Thu, 21 Mar 2013 09:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I4+r7AzOCjsi for <>; Thu, 21 Mar 2013 09:28:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7751121F8DFA for <>; Thu, 21 Mar 2013 09:28:54 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <>) id 1UIiMH-0000er-RZ; Thu, 21 Mar 2013 11:28:53 -0500
Message-ID: <>
Date: Thu, 21 Mar 2013 10:28:21 -0700
From: "Charles E. Perkins" <>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Alexandru Petrescu <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8667053d3e88eed8c45142e65f6c0e5214350badd9bab72f9c350badd9bab72f9c
Cc: Mobile IPv4 Mailing List <>
Subject: Re: [Mip4] One implementation of RREQ/RREP time synchronization
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobility for IPv4 <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Mar 2013 16:28:59 -0000

Hello Alexandru,

The existing specification does not require NTP.  I think that it's not
required for replay protection, and that your suggested method
should be fine.  I don't think there should be any additional
protocol mandates placed on MIPv4, especially after so much time,
and that it would cause many existing implementations to become

Charlie P.

On 3/21/2013 8:51 AM, Alexandru Petrescu wrote:
> The specification RFC 5944 "Mobile IPv4" has a textual description about
> an error Code 133 'Denied by home agent, registration Identification
> mismatch'.  This is sent by the HA to MR when the MR's time is way back
> (or ahead) in time, like after having lost power.
> However, the spec doesn't say that the MR SHOULD send a new RREQ to the
> HA, and not neither does it say what to put in that RREQ.
> We wrote an implementation of a method to realize this: MR receive Code
> 133, update its time, send a new RREQ; this method is based on the
> discussion in this email list MIP4.
>   This code is executed in MR:
>   t0 = time (); obtain time of this computer
>   ID1 = t0;
>   Send to HA RREQ containing ID1;
>   Receive RREP Code-133, and extract ID2=RREP.Identification;
>   t1 = time ();
>   set local time on MR to be time()+(ID2-ID1)-(t1-t0)/2;
>   send RREQ to HA containing updated time;
>   receive RREP with Code = 0 (successful).
> This interoperates ok with a Home Agent from manufacturer.
> Remark there is a speculation at the calculation of time (t1-t0)/2 which
> means half of the total RTT.  But never an RTT is precisely half-half.
> We are not sure it is a good thing to synchronize time this way (rather
> than say NTP), and we are not sure either whether it is secure enough.
> Alex

Charlie P.