Monami6 C. Larsson
Internet-Draft H. Levkowetz
Intended status: Standards Track H. Mahkonen
Expires: April 26, 2007 T. Kauppinen
Ericsson
October 23, 2006
A Filter Rule Mechanism for Multi-access Mobile IPv6
draft-larsson-monami6-filter-rules-01
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 April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document suggests a mechanism that could be used to control per-
flow interface selection for communication to and from 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
Larsson, et al. Expires April 26, 2007 [Page 1]
Internet-Draft Monami6 Filter Rules October 2006
context without excessive overhead, it is advantageous to be able to
define filter definitions and bindings separately, as it is expected
that it may be necessary to update the bindings much more often than
the filter definitions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6
2.1. Policy and Policy Exchange . . . . . . . . . . . . . . . 7
2.2. Packet Filter and Packet Filter Exchange . . . . . . . . 8
2.3. Binding FIID to Physical Interface . . . . . . . . . . . 10
3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 11
3.1. PF Message format . . . . . . . . . . . . . . . . . . . 12
4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 13
4.1. When to send a Packet Filter to a Filtering Peer . . . . 14
4.2. Packet Filter Content . . . . . . . . . . . . . . . . . 14
4.3. Sending Packet Filter Update . . . . . . . . . . . . . . 15
4.4. Receiving Packet Filter Update . . . . . . . . . . . . . 16
5. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Larsson, et al. Expires April 26, 2007 [Page 2]
Internet-Draft Monami6 Filter Rules October 2006
1. Introduction
When a node is equipped with multiple network interfaces or has
multiple addresses assigned to one network interface the node is said
to be multi-homed. When a multi-homed node establishes a session
with a peer there exist several potential communication paths between
the nodes. Multiple communication paths between two nodes imply that
unless all traffic is sent over all links, there must exist rules in
the multi-homed node that for each packet determine which network
interface should be used to send the packet.
This draft introduces filter rules as a mean for a multi-homed node
to perform per flow interface selection. Per flow interface
selection is typically needed when there exist multiple network
interfaces, each with different network characteristics, and an
application has specific performance requirements for a data flow
that makes one network interface more suitable than another.
This document proposes the use of OpenBSD Packet Filter [PF] syntax
to describe the filtering rules used for per flow interface
selection. The mechanism described in this document will be used by
the mobile node to communicate preferred communication paths for IP
data flows to its filtering peers.
1.1. Applicability
The protocol proposed in this draft could be applied to either a
multi-homed stationary or mobile node. A multi-homed stationary node
would have at least one address assigned to each network interface.
The filter rules could in this case be used for selecting the
preferred network interface for an IP packet data flow. However, the
primary usage for the filter rules, and the focus of this draft, is
how to use filter rules for mobile nodes in the context of Mobile IP
[RFC3775] [RFC3344]
To identify a mobile node some kind of identity is used. One example
of an identity would be the home address in Mobile IPv6 [RFC3775] and
the Host Identity Tag (HIT) in HIP [I-D.ietf-hip-base]. Let us use
the expression 'identity tag' as a name for this node identity.
Additionally, the multi-homed node would have local interface
addresses associated with each network interface. The binding
between the identity tag and the local interface addresses is handled
by mechanisms specific to each mobility management protocol (e.g.
Mobile IPv6, Mobile IPv4, HIP).
The primary use of flow filtering rules, as described in this
document, is to specify separate communication paths for multiple
flows which pass through or originate at one single node (such as for
Larsson, et al. Expires April 26, 2007 [Page 3]
Internet-Draft Monami6 Filter Rules October 2006
instance the HA in a Mobile-IP context) where the different flows
have different requirements for bandwidth, latency, and QoS (quality
of service). We will call the node which applies filtering to select
the appropriate path for IP packets the 'Filtering Peer'.
Flow filtering rules may however also be useful in other contexts,
such as for instance between a moving multi-homed HIP-enabled node,
when it has many sessions with different QoS requirements towards the
same server. The name 'Filtering Peer' would refer to the server in
this context.
The proposed mechanism is agnostic with respect to the particular
mobility management mechanism used, and could therefor be used not
only for MIPv6, but also for other mobility management protocols,
e.g., Mobile IPv4 [RFC3344], HIP [I-D.ietf-hip-base] and MOBIKE
[RFC4555]. It is also IP version agnostic and works equally well for
IPv4 and IPv6.
The specific details of how the filter rule mechanism could be used
for Mobile IPv6 is further detailed in the multiple care-of
registration protocol [I-D.ietf-monami6-multiplecoa] together with
[I-D.draft-kauppinen-monami6-binding-filter-rule]. Other mobility
management protocols would need to write separate documents to
outline how the filter rules are used with that specific mobility
management protocol.
1.2. 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:
Policy
In the context of multi-access for mobile nodes, Policy is
an overall information which govern how packets are
forwarded from the mobile node to the intermediate node and
the reverse path and from the mobile node to the
destination node and the reverse path. Policy may cover
such things as access network preferences, user 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.
Larsson, et al. Expires April 26, 2007 [Page 4]
Internet-Draft Monami6 Filter Rules October 2006
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 interface.
In the context of multi-access IP mobility, 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 the access at a
specific point in time, which should be used for the
matching packets.
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 a
relation between filter interface ID and local address, the
bindings can be updated on a handover to a new local
address, while the match function does not need to change.
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.
Filter Interface Identifier (FIID)
A Filter Interface Identifier (FIID) identifies a virtual
interface which is a possible exit point from a filter
rule. A FIID is constructed by concatenating a name and a
16-bit unsigned integer value. The FIID is created by the
mobile node and its uniqueness is guaranteed by associating
it with the mobile node's identity tag. This procedure
will ensure that two FIIDs sent to a filtering peer of the
mobile node will not collide.
Filtering Peer
A filtering peer could be any node in the Internet that the
mobile node decides to exchange filter rules with. In case
of Mobile IPv6 the filtering peer is the intermediate node,
i.e. the home agent, and it may also be the correspondent
node.
Larsson, et al. Expires April 26, 2007 [Page 5]
Internet-Draft Monami6 Filter Rules October 2006
Identity Tag
The identity tag is the identity at which the mobile node
is addressable. One example of an identity tag would be
the home address in Mobile IPv6 [RFC3775] and the Host
Identity Tag (HIT) in HIP [I-D.ietf-hip-base].
2. Architecture Overview
When a mobile node has multiple 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 address (i.e. network interface) to use for sending data
packets.
Additionally, in the case of Mobile IPv6, 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 the mobile node and the correspondent nodes. For the home agent
and correspondent nodes to know which path to use for packets
destined to the 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 the term 'Filter
Rule' and 'Filter' are used 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 it is possible
and desirable to make a clear separation between the following
actions:
o Definition and exchange of policies.
o Definition and exchange of filter rules.
o Binding of filter rule to network interface.
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 node's movement. When a mobile node
changes its current point of attachment to the Internet it will send
binding information to the nodes concerned with its current location.
The binding include information about the binding between filter
interface ID and IP address.
Larsson, et al. Expires April 26, 2007 [Page 6]
Internet-Draft Monami6 Filter Rules October 2006
Initiator Responder
+-------------+ +-------------+
| | Exchange of Policies | |
| |<----------------------------->| |
| | | |
| | Exchange of Filter rules | |
| |<----------------------------->| |
| | | |
| | Binding FIID <-> IP Address | |
| |<----------------------------->| |
+-------------+ +-------------+
Figure 1: Information exchange between initiator and responder
By applying this approach we would achieve a clear separation between
the definition and exchange of policies and filter rules, and the
binding of a filter rule to an IP address.
2.1. Policy and Policy Exchange
In the context of this document a policy is a high level information
which governs how traffic is sent from/to a mobile node. The policy,
in addition to other information (such as events, access network
characteristics, etc.), would be input to a mobile node internal
algorithm, which would generate a set of filter rules. The filter
rules for a node specify the possible (virtual) output interfaces for
packets sent out from the node. For each virtual output interface
there must also exist a binding to a local IP address (Care-of
Address in the MIP case) which completes the specification of how to
route the packet if it matches the match expression in the filter
rule.
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.
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 mobile node and the network side have interest in how
policies are defined and applied. Consequently the policy exchange
could be initiated by either the mobile node or the network side.
Larsson, et al. Expires April 26, 2007 [Page 7]
Internet-Draft Monami6 Filter Rules October 2006
Policies must be available in every node which is required to do
specific filtering of data packets. In case of a mobile node it
would be used to determine which interface to use for outgoing
traffic. The specific means used for the exchange of policies is out
of the scope of this document.
2.2. Packet Filter and Packet Filter Exchange
PF ('Packet Filter') [PF] is OpenBSD's system for filtering TCP/IP
traffic. Packet filters are widely used in the Internet and the
OpenBSD PF specification exist as open source and has been used for
deployment of packet filter implementations on several different
platforms. The OpenBSD specification includes a rich set of
functionality and offers great flexibility in the way packet filters
are created.
By using OpenBSD's PF syntax to define filter rules, all features
already defined by OpenBSD can be utilized when defining filter rules
for handling of simultaneous multi-access.
The creation of filter rules is logically separated from mobility
management since the creation of a new filter rule does not
necessarily require any action from the mobility management protocol.
E.g., an event, such as the opening of a socket, would trigger the
creation of a new filter rule that identifies the flow. The internal
binding of this filter rule to a specific network interface would not
necessarily cause any binding update information to be sent by the
mobile node. However, the mobile node would need to update the
filter definition at nodes with which it is communicating.
Typically, in the case of Mobile IPv6, it would be the home agent
that needs to be updated.
Since filter rule handling and mobility management are orthogonal it
makes sense to use separate means for transferring of filter rules.
The suggested approach will ensure that the mobility management
protocol is not overloaded with tasks that it was not originally
designed for. It will also make it possible to use the filter
definition mechanism with any mobility management protocol, e.g.,
MIPv6 [RFC3775], MIPv4 [RFC3344], HIP [I-D.ietf-hip-base] and MOBIKE
[RFC4555].
An additional benefit of having separate means for transferring of
filter rules is that the solution proposed in this document is IP
version agnostic and works equally well for IPv4 and IPv6.
Larsson, et al. Expires April 26, 2007 [Page 8]
Internet-Draft Monami6 Filter Rules October 2006
2.2.1. Creating Filter Rules
How a Filter Rule is created is outside the scope of this document.
For this document the assumption is that Filter Rules have been
created based on existing policy, for instance as a result of an
application opening a socket, and that the filter rule syntax is
according to [PF].
2.2.2. Changes to the Filter Rule
The Packet Filter syntax includes the 'interface' parameter used for
identification of the physical or virtual network interface that the
IP data packet is being transmitted over. The interface name is
specified as the name of the interface appended with an integer
number, for instance 'fxp2'.
By using virtual interfaces in the filter rule, a dynamic binding
between the interface in the filter rule and the actual physical
interface may be achieved. The Filter Interface Identifier (FIID)
identifies a virtual interface, which is the exit point from a filter
rule, and is in turn associated with a local physical interface and
IP address, such as a MIP care-of address.
2.2.3. Filter Rule Identifier Syntax
The FIID follows the same syntax as the 'interface' parameter in the
filter rule syntax, i.e., the interface name consists of the name of
the interface appended with an integer number. Accordingly, the
proposed FIID syntax is as follows:
fiid#
where "fiid" is the name of the virtual interface and '#' is an
integer number. The integer number is an unsigned integer generated
by the mobile node. It MUST be unique within the mobile node and its
uniqueness is preserved at the Filter Peer by being tied to the
identity tag of the mobile node.
2.2.4. Storing Filter Rules
All filter rules needed by the mobile node to handle simultaneous
multi-access are stored as ASCII text. The collection of all filter
rules constitute a Packet Filter specification. There is one filter
specification generated for the mobile node and one filter
specification generated for each filtering peer (e.g. in case of
Mobile IPv6 it would be separate files for the home agent and the
correspondent node(s)). The content of the filter specification for
the filtering peer will often be a "mirrored" version of the file
Larsson, et al. Expires April 26, 2007 [Page 9]
Internet-Draft Monami6 Filter Rules October 2006
used by the mobile node.
2.2.5. Sending Filter Rule updates to the peer
Each time a new filter rule is created, due to some event in the
mobile node, the filtering peers MUST be updated. Section 3 outlines
a filter rule transfer mechanism based on on the User Datagram
Protocol (UDP). The UDP protocol is used to carry plain ASCII text
Packet Filter rules with some meta information.
The proposal is to send over the entire file when a filter rule is
updated. It is assumed that the PF-file is limited in size and that
the required update frequency is low. If these assumptions do not
hold it would be possible to send only the modified parts of the file
to the filtering peers.
2.3. Binding FIID to Physical Interface
This draft does not attempt to specify how the FIID should be bound
to a specific IP address. The reason for not doing this is that the
binding depends on the mobility management protocol being used.
One example of how this binding can be realized for Mobile IPv6 is
described here. Figure 2 shows the relation between filter rule,
FIID and Binding Unique Identifier (BID). There exist an internal
node algorithm, which is outside the scope of this draft, that
decides the binding between the FIID and the BID. This draft defines
the filter rule syntax, the FIID syntax and the protocol for sending
filter rules to the filtering peers. The specific protocol details
of how the FIID, BID and care-of address are associated with each
other is outlined in two separate drafts
([I-D.ietf-monami6-multiplecoa] and
[I-D.draft-kauppinen-monami6-binding-filter-rule]).
Larsson, et al. Expires April 26, 2007 [Page 10]
Internet-Draft Monami6 Filter Rules October 2006
+---------------+ +-------+ +-------+
| Filter Rule 1 |---+--->| FIID1 |------->| BID 1 |
+---------------+ | +-------+ +-------+
|
+---------------+ |
| Filter Rule 2 |---+
+---------------+
+---------------+ +-------+ +-------+
| Filter Rule 3 |------->| FIID2 |---+--->| BID 2 |
+---------------+ +-------+ : +-------+
:
+---------------+ +-------+ : +-------+
| Filter Rule n |------->| FIIDn |...+...>| BID n |
+---------------+ +-------+ +-------+
Figure 2: Relation between filter rule, FIID and BID.
Why having multiple level of indirections when mapping FIID to BID to
CoA? The main motivation is that updates to the filter rules are
independent of the bindings between a FIID and a BID. For instance,
let's assume that there exist a set of filter rules as shown in
Figure 2. If an event occurs in the mobile node that causes a new
filter rule to be created this filter rule will specify that output
will go to a FIID. If this FIID already exist, then a binding
between the FIID and the BID also exist. As a result of creating
this new filter rule the modified filter rule set must be sent to the
filtering peer, however, the binding information does not need to be
updated. Another example is when a physical interface is either
added or removed. In this case the filter rules and the associated
FIIDs are not updated. However, the binding between the FIIDs and
the BID may need to be updated.
If other mobility management protocols than Mobile IPv6 is preferred,
e.g., HIP, a specific document would have to be written detailing how
the FIID is bound to the specific mechanisms used in the mobility
protocol to achieve simultaneous multi-access.
3. Protocol Definition
This specification defines the protocol used for sending filter rules
between the mobile node and its filtering peers. The filter rules
are defined using the PF format, as defined in [PF].
The filter rules are stored in an ASCII file and sent to the
filtering peer as payload to the User Datagram Protocol (UDP), as
Larsson, et al. Expires April 26, 2007 [Page 11]
Internet-Draft Monami6 Filter Rules October 2006
defined in [RFC0768]. The motivation for using the UDP protocol is
that the application responsible for mapping of the fiid# to the
actual physical network interface normally resides in user space.
Another reason for using the UDP is that it's an IP version
independent protocol. Although this draft is targeting simultaneous
multi-access for IPv6 mobility management protocols there is no
technical reason for limiting the transfer of filter rules to a
specific IP version.
3.1. PF Message format
The format of the UDP protocol with payload is as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PF Payload .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Fields:
Source Port
16-bit unsigned integer. The Source Port is an optional
field and indicates the port of the sending process, and
may be assumed to be the port to which a reply should be
addressed in the absence of any other information. If not
used, a value of zero is inserted.
Destination Port
16-bit unsigned integer. The receiving port. Port number
is TBD.
Length
16-bit unsigned integer. The length in octets of the user
datagram including this header and the data, i.e., the
minimum value of the length is eight.
Larsson, et al. Expires April 26, 2007 [Page 12]
Internet-Draft Monami6 Filter Rules October 2006
Checksum
16-bit unsigned integer. The UDP checksum. See [RFC2460].
PF Specification Fields:
Option Type
8-bit unsigned integer. Indicates if this message is sent
from the mobile node to update a filtering peer or if it's
an acknowledgement of a previously sent Packet Filter
update.
0 Packet Filter Update
1 Packet Filter Acknowledgement
Status
8-bit unsigned integer. Indicates the disposition of the
Packet Filter Update. Values of the Status field less than
128 indicate that the Packet Filter Update was accepted by
the receiving node. Values greater than or equal to 128
indicate that the Packet Filter Update was rejected by the
receiving node. The following Status values are currently
defined:
0 Packet Filter Update accepted
128 Rejected, reason unspecified
129 Administratively prohibited
130 Packet Filter included syntax error
131 Mobile node not allowed to update Packet Filter
Reserved
These fields are unused. They MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
PF Payload
ASCII text containing filter rules. The syntax is
described in [PF].
4. Protocol Operations
This section describes how filter rules are sent from the mobile node
to the filtering peers. Filter rules and the required mapping to an
IP address is handled by the mobile node. How this is achieved is
Larsson, et al. Expires April 26, 2007 [Page 13]
Internet-Draft Monami6 Filter Rules October 2006
not within the scope of this draft. The assumption is that such a
mapping exist and can be distributed by other means, e.g., for Mobile
IPv6 as described in
[I-D.draft-kauppinen-monami6-binding-filter-rule] and
[I-D.ietf-monami6-multiplecoa].
4.1. When to send a Packet Filter to a Filtering Peer
There are several events that may trigger the creation of a new
filter rule. For example when an application requests to open a
socket an internal, node specific, algorithm detects this event and
based on a set of parameters, such as available network interfaces,
network interface characteristics, policies, etc., a filter rule is
created. The filter rule specifies to which FIID output is sent. In
case of Mobile IPv6, a binding to a BID is created.
There may be other events that causes a filter rule to be created.
However, when a new filter rule has been created this information
needs to be sent to the filtering peers to make sure that these nodes
knows which destination address to use in the case when there exist
multiple local addresses associated with the mobile node's identity
tag.
4.2. Packet Filter Content
When sending the Packet Filter specification to the filtering peers
there are two options. Either the entire file or a delta could be
sent. In the case when a delta is sent only the filter rules that
have been created or deleted since the last update needs to be sent.
This specification suggests that the entire Packet Filter file is
sent each time an update is required. By sending the entire Packet
Filter file to the filtering peer there is no need to specify
specific protocol behavior for how to add, modify and refresh filter
rules.
The approach taken in this specification could be further optimized
in later revisions if needed. The suggested proposal would be simple
but in case of frequent filter updates it would also generate extra
traffic. At this stage it is not assumed that sending frequent
updates of the packet filter would be needed. However, if this
assumptions turns out to be wrong there is always the opportunity to
optimize the Packet Filter updates. This optimization could consist
of sending the delta in relation to a previous Packet Filter update.
This optimization would lead to a more complex protocol, with state
and synchronization requirements, but would on the other hand
generate less traffic.
Larsson, et al. Expires April 26, 2007 [Page 14]
Internet-Draft Monami6 Filter Rules October 2006
4.3. Sending Packet Filter Update
To add a new or update an existing Packet Filter specification at a
filtering peer the multi-homed node sets the Option Type to 0 (Packet
Filter Update), the Status field is cleared and the Payload field
includes the entire Packet Filter specification. The Length field is
set to the actual length (in octets) of the UDP packet, i.e.
including the UDP header and the data following the UDP header.
To remove an existing Packet Filter at a filtering peer the multi-
homed node sets the Option Type to 0 (Packet Filter Update), the
Status field is cleared and the Payload field is empty. The Length
of the UDP header is set to twelve.
4.3.1. Retransmission
If the multi-homed node fails to receive a valid matching response
within the selected initial retransmission interval
(INITIAL_PFU_TIMER), the multi-homed node SHOULD retransmit the
message until a response is received.
The retransmissions by the multi-homed node MUST use an exponential
back-off process in which the timeout period is doubled upon each
retransmission, until either the node receives a response or the
timeout period reaches the value MAX_PFUACK_TIMEOUT. The multi-homed
node MAY continue to send these messages at this slower rate
indefinitely.
If the status code indicates that a Packet Filter Update was rejected
it may be possible to resend the Packet Filter Update after
appropriate modifications of the specification. The decision on
whether a Packet Filter should be modified and resent or if no
further actions are taken is a node internal issue and not specified
in this draft.
4.3.2. Filtering Peer node types
Depending on the filtering peer node type either the entire Packet
Filter specification or relevant parts of the specification is sent
to the node. An example is Mobile IPv6 where the Home Agent needs
the full set of filter rules even though route optimization is used
between the mobile node and some or all of its correspondent nodes.
The reason for sending the entire set of filter rules to the home
agent is that the return routability procedure may fail and then the
traffic would by default be routed through the home agent. The
correspondent node would not require all filter rules from the mobile
node. Instead, the relevant filter rules which apply to the specific
correspondent node, would be enough.
Larsson, et al. Expires April 26, 2007 [Page 15]
Internet-Draft Monami6 Filter Rules October 2006
As long as a mobile node only has traffic with the same bandwidth,
latency and QoS requirements, there is no need for filters at the
correspondent node at all.
4.4. Receiving Packet Filter Update
Upon receiving a packet carrying a Packet Filter Update the packet
MUST be validated according to the following tests:
If the 'Length' field is greater than 12 then the content of the 'PF
Payload' field is added as Packet Filter information for the multi-
homed node.
If the 'Length' field is equal 12 then the any existing filter
specifications for the mobile node MUST be removed. When no filter
rule specifications are available normal processing of the packets
will be performed, i.e. there will be no support for simultaneous
multi-access
4.4.1. Packet Filter Lifetime
There is no timer associated with the Packet Filter specification
defining how long time the specification is valid. Instead, it's
assumed that the specification is stored at the destination node as
long as this node has ongoing communications with the multi-homed
node.
5. Protocol Constants
INITIAL_PFU_TIMER 3 seconds
MAX_PFUACK_TIMEOUT 48 seconds
6. IANA considerations
This document requires the following new number assignments from
IANA:
UDP Destination Port number
This document also defines two message types:
0 Packet Filter Update
1 Packet Filter Acknowledgement
Larsson, et al. Expires April 26, 2007 [Page 16]
Internet-Draft Monami6 Filter Rules October 2006
Finally, this document creates a third new name space "Status Code"
for the Status field in the Packet Filter Acknowledgement message.
The following values have been defined:
0 Packet Filter Update accepted
128 Rejected, reason unspecified
129 Administratively prohibited
130 Packet Filter included syntax error
131 Mobile node not allowed to update Packet Filter
7. 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.
8. References
8.1. Normative References
[I-D.draft-kauppinen-monami6-binding-filter-rule]
Kauppinen, T., "Filter Rule Identifier Binding in Mobile
IPv6", draft-kauppinen-monami6-binding-filter-rule (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.
[PF] "PF: The OpenBSD Packet Filter", May 2006,
<ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-06 (work in progress), June 2006.
Larsson, et al. Expires April 26, 2007 [Page 17]
Internet-Draft Monami6 Filter Rules October 2006
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[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.
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
Larsson, et al. Expires April 26, 2007 [Page 18]
Internet-Draft Monami6 Filter Rules October 2006
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 April 26, 2007 [Page 19]
Internet-Draft Monami6 Filter Rules October 2006
Full 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Larsson, et al. Expires April 26, 2007 [Page 20]