[Int-area] Lifting up a filter discussion from Monami6

Jari Arkko <jari.arkko@piuha.net> Wed, 14 February 2007 12:59 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHJjo-0007mj-MY; Wed, 14 Feb 2007 07:59:56 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHJjn-0007mN-7c for int-area@ietf.org; Wed, 14 Feb 2007 07:59:55 -0500
Received: from p130.piuha.net ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHJjb-0001HY-OX for int-area@ietf.org; Wed, 14 Feb 2007 07:59:55 -0500
Received: from p130.piuha.net (localhost []) by p130.piuha.net (Postfix) with ESMTP id 2E338198777; Wed, 14 Feb 2007 14:59:43 +0200 (EET)
Received: from [] (p130.piuha.net []) by p130.piuha.net (Postfix) with ESMTP id CBBFF198775; Wed, 14 Feb 2007 14:59:42 +0200 (EET)
Message-ID: <45D307BE.4060903@piuha.net>
Date: Wed, 14 Feb 2007 14:59:42 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird (X11/20070104)
MIME-Version: 1.0
To: Internet Area <int-area@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: monami6-chairs@tools.ietf.org
Subject: [Int-area] Lifting up a filter discussion from Monami6
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Errors-To: int-area-bounces@lists.ietf.org

I would like to lift up one issue from the Monami6 WG
to a more general discussion. Monami6 is developing an
extension to Mobile IPv6 / Nemo so that a mobile node could
register its presence in multiple locations simultaneously.
One of things that they expect to be able to do is to control
what traffic goes to what care-of address; this flow to this
address, and the other flow to that other address. Mobile nodes
can obviously decide by themselves what outgoing interface to use.
However, in order for a home agent to deal with return traffic
properly, the mobile node has to tell it what policy to

The working group has debated between a number of different
approaches for doing this. In one approach, draft-soliman-
monami6-flow-binding the mobile node adds a filter to a Mobile
IPv6 Binding Update to tell what traffic should use this binding.
Another approach, draft-larsson-monami6-filter-rules, decouples
the policy exchange from the mobility protocol. The policies are
exchanged at a different time (typically earlier) and carried by a
different protocol (in this case over UDP). Yet another draft,
draft-mitsuya-monami6-flow-distribution-policy also separates
the mobility protocol and policy transfer, and carries
the policies in HTTP.

Monami6 should of course decide how they want to design this.
But this may be an interesting debate from a more generic point
of view. Do we have input for them? For instance, are there needs
in HIP/Shim6/Mobike space for similar functionality? Should the
designs be tailored for each of these situations? Is there some
advantage or disadvantage in looking at a generic solution?
Would a generic solution be doable?

Without going into too much detail about the specific proposals
it seems that there are actually a number of different topics here:
- carrier protocol choice
- policy container format
- timing of the policy exchange
- securing the transfer
- etc



Int-area mailing list