Re: [Mobopts] MIPv6 IPsec Route Optimization (IRO) (Arnaud Ebalard) Mon, 17 November 2008 22:47 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 1A49F28C191; Mon, 17 Nov 2008 14:47:46 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B61028C172; Mon, 17 Nov 2008 14:47:43 -0800 (PST)
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=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SJI4rkdTvP01; Mon, 17 Nov 2008 14:47:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 80B713A6922; Mon, 17 Nov 2008 14:47:42 -0800 (PST)
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1L2Csc-0003LC-9N; Mon, 17 Nov 2008 23:47:38 +0100
From: (Arnaud Ebalard)
To: "Haddad\, Wassim Michel" <>
References: <>
X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026
Date: Mon, 17 Nov 2008 14:45:54 -0800
In-Reply-To: <> (Wassim Michel Haddad's message of "Mon, 17 Nov 2008 12:57:23 -0800")
Message-ID: <>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Cc: IPsec IETF WG ML <>, Mobopts IRTF WG ML <>, IETF MEXT WG ML <>
Subject: Re: [Mobopts] MIPv6 IPsec Route Optimization (IRO)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


"Haddad, Wassim Michel" <> writes:

> I have just submitted a new I-D [1] which certainly requires an
> introduction (and disclaimer): it specifies a MIPv6 Route Optimization
> procedure *dedicated* to environments where IPsec/IKE is used between
> peers (MN-HA, MN-CN, MN-MN) for protecting both signaling and data
> traffic.
> Some of the improvements provided by this "IPsec Route Optimization"
> mechanism (IRO) are also proposed for the IPsec communications between
> the MN and its HA.
> Among the features provided by IRO (introduction of the document as
> a more accurate list):
>   * Complete removal of RH2 and HAO (resulting in simplified packet
>     handling on both sides and possibly better compatibility with
>     filtering implemented in the network),
> => You can have complete removal of both options without introducing a
> new RO mode.

Sure. But there are additional reasons (and advantages, as provided in
my previous list) to introduce a new RO mode. IMHO, those advantages are
worth the introduction. But I am interested on feedback about those
specific parts of my I-D.

> Please check

I already read version -00. I basically took a look at all I-D and
reference documents associated with tunneling optimizations and MIPv6 RO 
(always in an IPsec context): ERO, BEET, RO design history, your draft

Your proposal may have an interest for the common RO case if one intend
to keep the RRP. I just don't. I am convinced that removing the
duplicated states and exchanges when IPsec/IKE are used in a MIPv6
context can provide a far better solution.

>From my perspective, I just don't feel the need to introduce additional
states and exchanges (the PaT) because those are already available
locally (and synchronized over time) on the IPsec/MIPv6 entities
(SA/Bindings). Obviously, this is only true for IPsec entities, which
are (as presented before) my targets.

Thanks for your comments.



ps: note that my -00 lacks pictures to ease the understanding of what
    happens. That's on the todo list for -01.
Mobopts mailing list