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

Ahmad Muhanna <> Thu, 21 March 2013 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB4F921F8E57 for <>; Thu, 21 Mar 2013 09:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aAONJYqV1Ui7 for <>; Thu, 21 Mar 2013 09:43:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 617E821F8CF9 for <>; Thu, 21 Mar 2013 09:43:59 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 21 Mar 2013 09:43:59 PDT
Received: from ([fe80::a1f1:7708:4a71:9fee]) by ([fe80::a1f1:7708:4a71:9fee%11]) with mapi id 14.01.0438.000; Thu, 21 Mar 2013 11:43:56 -0500
From: Ahmad Muhanna <>
To: "Charles E. Perkins" <>, Alexandru Petrescu <>
Thread-Topic: [Mip4] One implementation of RREQ/RREP time synchronization
Thread-Index: AQHOJkwGJ0hYhYSpQ02WtFAVfQ+vZ5iwujGA//+cvUA=
Date: Thu, 21 Mar 2013 16:43:55 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:44:00 -0000

Hi Alex,

I agree with Charlie, No need to change anything.

Your proposed procedure is what many implementation has been using for a long time.
In addition, I have the following comments:

1. Adjusting the MR timer considering the half the trip time is a good idea and implementation specific. If I remember correctly, I believe the HA allows for a difference of 7 seconds and that's a lot of time.

2. Since you started by saying that the MR lost its time, I would suggest that when you build the Identification field of the RRG to use a good random number generator for the 32 lower bits of the Identification ID. If that random number generator is expensive for such MR, then you can have the MR uses just a counter and keep track of that counter so it does not send a RRQ with the same counter twice; unless the 32 lower bits rolls and if that ever happens, it will take a very looooong time before ever happened. <more than 4 billion available in these 32 bits> 

This simple implementation will for sure eliminate any fear of replay protection.

Best Regards,

-----Original Message-----
From: [] On Behalf Of Charles E. Perkins
Sent: Thursday, March 21, 2013 12:28 PM
To: Alexandru Petrescu
Cc: Mobile IPv4 Mailing List
Subject: Re: [Mip4] One implementation of RREQ/RREP time synchronization

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

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.

Mip4 mailing list:
    Web interface:
     Charter page:
Supplemental site: