One document matched: draft-larsson-monami6-filter-rules-00.txt
Monami6 C. Larsson
Internet-Draft H. Levkowetz
Expires: December 21, 2006 H. Mahkonen
T. Kauppinen
Ericsson
June 19, 2006
A Filter Rule Mechanism for Multi-access Mobile IPv6
draft-larsson-monami6-filter-rules-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document suggests a mechanism that could be used to direct flows
from and to multi-homed nodes. A clear distinction is made between
policies, filter rules and filters.
In order to be able to use filter rules in a multi-access mobility
context without excessive overhead, it is advantageous to be able to
Larsson, et al. Expires December 21, 2006 [Page 1]
Internet-Draft Monami6 Filter Rules June 2006
define match functions and bindings separately, as it is expected
that it may be necessary to update the bindings much more often than
the match functions. If the binding is expressed in terms of filter
rule identifier and care-of address, the bindings must be updated on
a handover to a new care-of address, while the match function will
not.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4
2.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Filter rules and Filter . . . . . . . . . . . . . . . . 6
2.3. Updating the peer with binding information . . . . . . . 7
3. Protocol Outline . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Binding Filter Rules to Care-of Addresses . . . . . . . 8
3.2. Sending Binding Update . . . . . . . . . . . . . . . . . 8
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Informative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Larsson, et al. Expires December 21, 2006 [Page 2]
Internet-Draft Monami6 Filter Rules June 2006
1. Introduction
Mobile IPv6 [RFC3775] allows a mobile node to remain reachable while
moving around in the IPv6 Internet. The mobile node is identified by
its home address, regardless of its current point of attachment to
the Internet. While situated away from its home network it is also
associated with a care-of address, which provides information about
its current location. By sending a Binding Update to its home agent
the mobile node creates a binding between its home address and
care-of address.
Mobile IPv6 only allows one care-of address (the primary care-of
address) at the time to be associated with each home address. The
multiple care-of registration protocol [I-D.ietf-monami6-multiplecoa]
extends the Mobile IPv6 protocol with an option allowing multiple
care-of addresses to be associated with a single home address.
When multiple care-of addresses are associated with one home address,
effectively multiple paths are created between the mobile node and
the home agent. Multiple paths between two nodes imply that, unless
all traffic is sent over all links, there must exist rules which for
each packet determine which path should be used to send the packet.
These rules apply to all involved nodes, i.e. the mobile node, the
home agent and the correspondent node.
The purpose of this document is to analyze the problem scope that a
mobile node and home agent are faced with when having several
possible care-of addresses to chose between for sending data packets.
We propose a mechanism, including filter rules, which may be used by
monami6, by which a multi-homed node can instruct the home agent and
the correspondent nodes about the preferred path to use depending on
the type of traffic. The approach taken could also be applicable for
other mobility management protocols, e.g. HIP [I-D.ietf-hip-base]
and MOBIKE [RFC4555].
1.1. Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
This document frequently uses the following terms:
Larsson, et al. Expires December 21, 2006 [Page 3]
Internet-Draft Monami6 Filter Rules June 2006
Policy
In the context of Multi-Access for Mobile-IP nodes, Policy
is a overall information which govern how packets are
forwarded from home agent to mobile node, from mobile node
to home agent, and from mobile node to correspondent node.
Policy may cover such things as access network preferences,
use and operator preferences, security restrictions, and
more. Application of policy will in many cases result in
definition of filter rules which implement the policy for
specific traffic flows.
Filter Rule
A filter rule is a rule which specifies that traffic with
certain characteristics is to be handled in a certain
manner. As an example, a filter rule might specify that
any traffic with destination port 80 should be sent out
through a certain care-of address.
A filter rule could be said to be composed of a match
expression and a binding. The match expression defines
which packets match the filter rule. The binding specifies
where to route the packet if it matches the match
expression.
In order to be able to use filter rules in a multi-access
mobility context without excessive overhead, it is
advantageous to be able to define match functions and
bindings separately, as it is expected that it may be
necessary to update the bindings much more often than the
match functions. If the binding is expressed in terms of
filter rule ID and care-of address, the bindings must be
updated on a handover to a new care-of address, while the
match function will not.
Filter
A filter is a collection of filter rules which is
associated with a certain decision point in the IP stack,
such as the point where a multi-access capable Mobile-IP
implementation have to decide through which care-of address
a packet should be routed.
2. Architecture Overview
When a mobile node has multiple care-of addresses, either assigned to
one interface or to different interfaces, the mobile node must have
some additional internal information enabling it to make a decision
of which care-of address (i.e. network interface) to use for sending
Larsson, et al. Expires December 21, 2006 [Page 4]
Internet-Draft Monami6 Filter Rules June 2006
the data packet.
Additionally, if the mobile node has registered multiple care-of
addresses with its home agent or correspondent nodes, as proposed in
[I-D.ietf-monami6-multiplecoa], there exist multiple paths between
the mobile node and the home agent and correspondent nodes. For the
home agent and correspondent nodes to know which path to use for
packets destined to mobile node it would need additional internal
information enabling it to choose a specific path.
The term 'Policy' is often used to refer to the internal rules that
would apply to the data packets. In this document we will use the
term 'Filter rule' and 'Filter' to refer to the internal rules being
applied to each data packet.
When looking into the problem scope of setting up and exchanging
policies and filters between nodes one realizes that that it is
possible and desirable to make a clear separation between the
following actions:
* Definition and exchange of policies.
* Definition and exchange of filter rules.
* Binding of filter rule with care-of address.
Figure 1 shows the suggested approach. There will be separate means
for the exchange of policies and filter rules. This exchange may
happen independently of a mobile nodes movement. When a mobile node
changes its current point of attachment to the Internet it will send
a Binding Update to inform its home agent about its current location.
The Binding update will include the binding between the filter rule
ID and the care-of address.
Initiator Responder
+--------------+ +--------------+
| | Exchange of Policies | |
| |<------------------------->| |
| | | |
| | Exchange of Filter rules | |
| |<------------------------->| |
| | | |
| | Mapping of FRID <-> CoA | |
| |<------------------------->| |
+--------------+ +--------------+
Larsson, et al. Expires December 21, 2006 [Page 5]
Internet-Draft Monami6 Filter Rules June 2006
Figure 1: Information exchange between initiator and responder
By applying this approach we would achieve a clear separation between
the definition and the exchange of policies and filter rules, and the
mapping of a filter rule to a care-of address.
2.1. Policy
In the context of this document a policy is a high level information
which governs how traffic is sent from/to a mobile node. Policies
would typically be translated into a set of filter rules (see next
section) which would be applied to each data packet sent from/to the
mobile node.
One could think of policies as describing the preferred actions that
should be taken if certain conditions are fulfilled. E.g. a mobile
node could have a policy that states that if WLAN is available then
this interface is the preferred interface for sending http traffic.
If WLAN is not available then the 3G interface is the preferred
interface for sending http traffic.
The filter rules are expected to be updated only if the policy is
updated. A policy could be installed at a node prior to delivery
and/or it could be dynamically updated in runtime. Typically a node
would have a set of static policies installed while others are
dynamically installed when needed.
Both the host and the network have interest in how policies are
defined and applied. Consequently the exchange of policies could be
initiated by either the host or a node in the network.
Policies must be available in every node that should do an
intelligent filtering of a data packet. In case of a mobile node it
would be used for defining which interface to use for outgoing
traffic. In the case of a home agent or a correspondent node it
would be used for defining which interface at the mobile node to send
the traffic to.
The specific means used for the exchange of policies is out of the
scope of this document.
2.2. Filter rules and Filter
Filter rules are generated from (a set of) policies. A filter rule
would be realized as a Packet Filter (PF) and assigned a unique
filter rule identifier (FRID). The FRID is a way of referencing a
specific filter rule and it is used when associating a care-of
address with a specific filter rule.
Larsson, et al. Expires December 21, 2006 [Page 6]
Internet-Draft Monami6 Filter Rules June 2006
A filter rule may only be associated with one care-of address, but a
care-of address can be associated with multiple filter rules.
Whenever a Policy is changed or an event occurs that causes new
filter rules to be generated or existing filer rules to be updated
these changes must be applied to outgoing packets. Additionally,
peering nodes must be updated with the new filter rules. E.g., if
the filter rules are modified in a mobile node it would have to
inform the home agent and the correspondent nodes about the new
filter rules that apply for packets being sent to it.
The reason for defining filter rules, assigning each filter rule a
FRID and associating them with a care of address is that we believe
that the best way to exchange filter rules between nodes is by using
separate means for this, not overloading the Mobile IPv6 protocol
with tasks that it was not originally designed for. A more detailed
discussion about the reasons for chosen this approach can be found in
[I-D.mitsuya-monami6-flow-distribution-policy], section 1.
The specific means used for exchanging filter rules is for the
working group to decide. Example of protocols that could be used is
IKEv2 and UDP, but other protocols may be used as well.
2.3. Updating the peer with binding information
As stated in section 3.2 there exist a mapping between filter rules
and care-of addresses. Whenever a filter rule is created or an
existing filter rule is updated causing a new care-of address to be
associated with the filter rule this must be propagated to the
affected nodes.
In the multiple care-of address registration protocol [I-D.ietf-
monami6-multiplecoa] a Binding Unique Identifier (BID) is introduced
and uniquely assigned with each care-of address. The previously
introduced FRID could be seen as a BID since it is syntactically and
semantically handled in the same way. However, in this draft we
propose to extend the definition associate the FRID with a unique
filter rule.
The FRID would in this proposal be used as proposed in [I-D.ietf-
monami6-multiplecoa] (replacing the BID) to create a binding between
a care-of address and a (set of) filter rule(s). The multiple
care-of registration protocol [I-D.ietf-monami6-multiplecoa]
discusses how this can be done for Mobile IPv6. However, we see no
reasons for why the approach described in this document could not be
used for other mobility management protocols, such as HIP [I-D.ietf-
hip-base] and MOBIKE [RFC4555].
Larsson, et al. Expires December 21, 2006 [Page 7]
Internet-Draft Monami6 Filter Rules June 2006
3. Protocol Outline
This specification allows a mobile node to update its home agent and
other nodes about preferred network interfaces to be used while
connecting to the mobile node.
Each filter rule is associated with a FRID. The exact mechanism to
achieve this is an internal node implementation and out of scope of
this draft. However, the result of processing the policy for the
mobile node is a set of filter rules, each of one associated with a
FRID.
The mobile node will typically be equipped with multiple network
interfaces. Whenever a network interface is activated and connected
to an access network it will have multiple addresses assigned to the
interface. When multiple network interfaces are available
simultaneously there must exist a mechanism to associate a filter
rule with an available care-of address. The exact mechanism to
decide which filter rule to associate with which network interface
(and care-of address) is a node internal issue and out of scope for
this draft. However, the result of this procedure is an association
between a filter rule and a care-of address.
3.1. Binding Filter Rules to Care-of Addresses
The current mobile node's internal binding between a filter rule and
a care-of address must be propagated to the home agent and the
correspondent nodes.
In the multiple care-of address registration protocol draft
[I-D.ietf-monami6-multiplecoa] a Binding Unique Identifier (BID) is
introduced to refer to a path between the mobile node and the home
agent. In this draft the FRID can syntactically and semantically be
viewed as a BID but in this proposal it is instead used as a
reference to a filter rule.
3.2. Sending Binding Update
The mobile node would typically have to inform its home agent and
correspondent nodes about a change of the care of addresses either
when an existing care-of address is changed due to a change of point
of attachment to the Internet, or if a new interface becomes
available and the mobile node decides to take the interface in
operational use.
The Binding Update is sent according to [I-D.ietf-monami6-
multiplecoa] informing the home agent that a specific filter rule
(identified with a FRID) will be associated with the specified
Larsson, et al. Expires December 21, 2006 [Page 8]
Internet-Draft Monami6 Filter Rules June 2006
care-of address. It is possible to associate multiple filter rules
with one care-of address.
4. IANA considerations
This document does not require any new number assignments from IANA,
and does not define any new numbering spaces to be administered by
IANA.
RFC-Editor: Please remove this section before publication.
5. Security Considerations
The transport used to exchange the flow distribution policy MUST be
secured to the same extent as the binding updates, and preferably
using the same security association.
6. Informative References
[I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-06 (work in progress), June 2006.
[I-D.ietf-monami6-multiplecoa]
Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-00 (work in progress),
June 2006.
[I-D.mitsuya-monami6-flow-distribution-policy]
Mitsuya, K., "A Schema Fragment for Flow Distribution",
draft-mitsuya-monami6-flow-distribution-policy-00 (work in
progress), February 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
Larsson, et al. Expires December 21, 2006 [Page 9]
Internet-Draft Monami6 Filter Rules June 2006
Authors' Addresses
Conny Larsson
Ericsson AB
Torshamnsgatan 23
Stockholm S-164 80
SWEDEN
Phone: +46 8 404 8458
Email: conny.larsson@ericsson.com
Henrik Levkowetz
Ericsson AB
Torsgatan 71
Stockholm S-113 37
SWEDEN
Phone: +46 708 32 16 08
Email: henrik@levkowetz.com
Heikki Mahkonen
Oy L.M. Ericsson
Hirsalantie 11
Jorvas FI-02420
Finland
Phone: +358 9 299 3213
Email: heikki.mahkonen@ericsson.com
Tero Kauppinen
Oy L.M. Ericsson
Hirsalantie 11
Jorvas FI-02420
Finland
Phone: +358 9 299 3057
Email: tero.kauppinen@ericsson.com
Larsson, et al. Expires December 21, 2006 [Page 10]
Internet-Draft Monami6 Filter Rules June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Larsson, et al. Expires December 21, 2006 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 10:51:20 |