MIP4 Working Group (editor) N. A. Fikouras
INTERNET DRAFT A. Udugama
K. Kuladinithi
C. Goerg
ComNets-ikom, Uni. Bremen
W.Zirwas
Siemens AG
October 2003
Filters for Mobile IPv4 Bindings (NOMADv4)
draft-nomad-mobileip-filters-05.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
Filters for Mobile IPv4 bindings enables mobile nodes to associate
one or more Filters with mobility bindings during registration.
Flows that match a Filter will be processed as defined by the
Filter. In this manner, it is possible for a mobile node to
distribute flows or packets of a flow among its available points of
attachment, or to request that such flows are dropped before
reaching the mobile node.
NOMADv4 Expires April 2004 1
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Table of Contents
1 Introduction.....................................................4
2 Terminology......................................................4
3 NOMADv4 Protocol Overview........................................6
3.1 Protocol Description............................................6
3.2 Model of Operation..............................................8
4 Backwards compatibility with RFC3344............................10
5 Support for Multihoming..........................................10
6 Associating Filters with Mobility Bindings......................11
6.1 Mobile Node Considerations.....................................11
Filters for Mobile IPv4 Bindings Registration Flag................11
Creating a new mobility binding with Filters......................12
Replacing a Filter of a mobility binding by Index.................12
Adding new Filters to an existing mobility binding................12
Sharing a Filter between mobility binding.........................12
Renewing a mobility binding with Filters..........................12
Deleting one or more Filters of a mobility binding................13
Deleting all Filters for a mobility binding.......................13
Transferring a Filter between mobility bindings...................13
The Weight field of the Filter Control Extension..................13
6.2 Filtering Agent Considerations.................................13
Determining the validity of a Filter Body.........................13
Processing Filtering Requests.....................................13
Filtering Request contains a Filter declaration with a new Index..14
Filtering Request containing Filter declarations with allocated Index
..................................................................14
Filtering Request containing only Filter Control Extension........14
Filtering Request containing only Filter Deletion Extension.......14
Filtering Request without any Filter declarations or Extensions...15
Applying Filters..................................................15
6.3 Home Agent Considerations......................................15
Filters for Mobile IPv4 Bindings Flag.............................16
7 NOMADv4 Extensions to RFC3344 Registration Messages.............16
7.1 Behavior Aggregate Filters (BAF) Extension.....................17
7.2 Protocol Extension.............................................18
7.3 Source Address Extension.......................................18
7.4 Source Network Extension.......................................19
7.5 Source Port Extension..........................................20
7.6 Source Port Range Extension....................................20
7.7 Destination Port Extension.....................................21
7.8 Destination Port Range Extension...............................21
7.9 Free-Form Extension............................................22
7.10 Filter Control Extension......................................23
7.11 Filter Deletion Extension.....................................23
7.12 Filter Reply Extension........................................23
Code Values for Filter Reply Extension............................24
NOMADv4 Expires April 2004 2
Internet Draft Filters for Mobile IPv4 Bindings October 2003
8. Security Considerations........................................24
9 Intellectual Property Considerations............................24
References........................................................25
A. Changes from Previous Versions.................................25
A.1. Updates from version 02.......................................25
A.2. Updates from version 03.......................................26
A.3. Updates from version 04.......................................26
Authors' Addresses................................................27
NOMADv4 Expires April 2004 3
Internet Draft Filters for Mobile IPv4 Bindings October 2003
1 Introduction
This document extends the Mobile IPv4 [1] protocol by providing the
means for mobile nodes to notify Filtering Agents (Mobile IPv4
entities that can maintain simultaneous bindings with Filters) of an
association between Filters and specific mobility bindings. As such,
traffic intercepted by a Filtering Agent will be filtered and
individual flows will be handled as indicated by the control
information of the Filter. In the most typical scenario, individual
flows will be redirected to the (co-located) care-of address
indicated by the respective binding. This enables mobile nodes to
distribute active flows among their available points of attachment.
Alternatively, the mobile node may request when registering bindings
and filters that it does not wish to receive certain flows (it
wishes to have them dropped, without notification to their source).
Home Agents are unable to distinguish between individual flows and
therefore redirect all intercepted traffic for a mobile node to the
(co-located) care-of address indicated by its binding. Consequently,
as the binding is updated with every hand-off, the total of a mobile
node's active flows are redirected to the most recently registered
(co-located) care-of address. Furthermore, if a mobile node requests
for simultaneous bindings, it will receive at each registered (co-
located) care-of address a duplicate copy of every active flow.
However, a mobile node that maintains multiple points of attachment
may wish to associate certain flows with specific access interfaces.
As these access interfaces vary their (co-located) care-of address a
mobile node should be able to perform a Mobile IPv4 (IP-layer) hand-
off for only a subset of its active flows. In addition, a mobile
node that has exhausted the bandwidth of a point of attachment
should be able to expand a flow across multiple points of attachment
to take advantage of the resources available in these networks.
Filters for bindings require that a mobile node includes in its
registration requests or binding updates a list of Filters. In this
manner, Filtering Agents (Home or Hierarchy Agents) become aware of
the relationship between certain flows and specific bindings.
However, the existence of those Filters does not affect in any way
the mobile node's choice on the point of attachment to be utilized
for the return path.
2 Terminology
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 RFC-2119 [2].
This document uses the following terms:
Domain A collection of networks sharing a common network
administration.
Home domain
NOMADv4 Expires April 2004 4
Internet Draft Filters for Mobile IPv4 Bindings October 2003
As defined in [5].
Visited domain
The domain where the mobile node has one or more points of
attachment.
Home Agent (HA)
As defined in [1].
Correspondent Node (CN)
As defined in [1].
Gateway Foreign Agent (GFA)
As defined in [5].
Regional Foreign Agent (RFA)
As defined in [5].
Home Network
As defined in [1].
Mobile Node (MN)
As defined in [1].
Mobility Binding
As defined in [1].
Filtering Agent (FLA)
Mobile IPv4 entities that can maintain Filters for mobility
bindings such as the HA, RFA, and GFA.
Filter Module (FLM)
The smallest module from which complex Filters are
defined.
Filter Body (FB)
A collection of Filter Modules in a Filter.
Filter (FL)
A collection of a Filter Body and control information
describing how a flow(s) should be handled.
Filtering Request (FLRQ)
Mobile IPv4 signaling (registration request, binding
update) with the purpose of establishing a new mobility
binding that may contain one or more Filters.
Filtering Reply (FLRP)
Mobile IPv4 signaling (registration reply, binding
acknowledgment) for returning the result of a Filtering
Request.
Default Filter (DF)
A special Filter applicable for all flows not matching any
NOMADv4 Expires April 2004 5
Internet Draft Filters for Mobile IPv4 Bindings October 2003
other Filter. Is either defined by mobile node or
automatically allocated from Filtering Agents to the
lowest defined Index of zero.
Idle Mobility Binding (IMB)
A mobility binding without Filters.
3 NOMADv4 Protocol Overview
This section provides an overview of how Filters for Mobile IPv4
bindings can be realized.
3.1 Protocol Description
Mobile nodes that wish to associate Filters with a (co-located)
care-of address are required to issue a registration request or
binding update with the æNÆ bit set that may contain a list of
Filters that indicate which flows are associated with the registered
(co-located) care-of address. Such signaling is termed as Filtering
Requests.
A Filter is consisted of one or more Filter Modules (Filter Body)
and is terminated by a Filter Control Extension. A Filter Module may
contain several predicates. There is an OR relationship between
predicates of a Filter Module. There is an AND relationship between
Filter Modules of the same Filter. In order for a flow to match a
Filter, it is required to qualify for all of the Filter Modules
contained in the Filter.
Filter management is performed with the help of the Filter Control
Extension. It contains a FilterÆs Index and a Weight field. The
Index identifies uniquely a Filter for a given mobile node while the
Weight field indicates the relative amount of traffic for which a
Filter is applicable. If the Weight field is set to zero then all
matching flows will be dropped without notification to their source.
For any other value of Weight, matching flows will get forwarded to
the point of attachment indicated by the corresponding mobility
binding. In the case of shared Filters, packets of matching flows
will get distributed between multiple points of attachment with
respect to the Weight value of each Filter. A mobile node may share
a Filter between mobility bindings by issuing a Filtering Request
from each respective point of attachment. The first one will contain
the full Filter (Filter Body + Filter Control Extension) while all
subsequent Filtering Requests will contain only a Filter Control
Extension indicating the Index number of the Filter to be shared.
If a mobile node needs to delete a Filter, then it is required to
issue a Filtering Request with a Filter Deletion Extension. The
Filter Deletion Extension contains a list of Filter indexes that the
mobile node wants to have deleted.
NOMADv4 Expires April 2004 6
Internet Draft Filters for Mobile IPv4 Bindings October 2003
A mobile node may define more than one Filter for a specific
mobility binding. The declaration of these Filters may take place
during one or more Filtering Requests.
Filtering Requests is processed by Filtering Agents. A Filtering
Agent can be any Mobile IPv4 entity that can maintain mobility
bindings with Filters, like a HA, RFA, GFA or a CN when routing
optimization is supported.
Flows that fail to match any of the defined Filters are handled as
defined by the Filter with the lowest possible Index of zero, termed
as Default Filter. A mobile node may define some of the attributes
of the Default Filter such as the associated mobility binding and
its Weight field by issuing a Filtering Request. Otherwise, these
will be configured by each Filtering Agent. In that case, the
Default Filter is associated with the mobility binding with the
longest outstanding lifetime and the Weight will be set to the value
of 1. However, different Filtering Agents may use different
algorithms to determine the Default Filter.
A mobile node may issue Filters corresponding to flows that do not
yet exist. When such a flow is initiated it will be handled by the
Filtering Agents as indicated by the respective Filter.
A Filtering Agent that receives a Filtering Request is required to
establish a mobility binding and set up a tunnel as per [1]. Newly
declared Filters should be associated with the registered mobility
binding.
A Filter remains valid for the lifetime of the corresponding
mobility binding. If the lifetime of a binding expires then all
associated Filters are deleted from record.
Binding management is performed with the help of the æSÆ bit as
described in [1]. Filtering Agents that receive a Filtering Request
with the æSÆ bit set are required to establish a new mobility
binding while maintain all existing ones. Incoming flows should not
get duplicated as defined in [1] rather than filtered and where
necessary forwarded to the appropriate point of attachment.
Filtering Agents that receive a Filtering Request without the æSÆ
bit are required to delete any existing mobility bindings and the
associated Filters. When renewing a mobility binding a mobile node
must issue a Filtering Request that is not required to contain any
reference to any Filters. If a mobile node wishes to reuse a deleted
Filter then it will have to reissue a Filtering Request.
A Filtering Reply is a registration reply containing a Filter Reply
Extension for each of the Filters contained in the corresponding
Filtering Request indicating the Index of a Filter along with a Code
signifying the result. The Code is used to relay success or the
reason of rejection to the mobile node.
Successive updates to the Filters of a mobility binding may lead to
a mobility binding without any Filters. Such bindings remain idle
NOMADv4 Expires April 2004 7
Internet Draft Filters for Mobile IPv4 Bindings October 2003
until either allocated a Filter, expire or deregistered by the
mobile node. A mobility binding in that state is termed as an Idle
Mobility Binding. When a Filtering Agent maintains exclusively Idle
Mobility Bindings for a mobile node then it is required to act as
per [1] and to ignore the behavior presented in this document.
The rules by which a mobile node decides on the set of Filters are
considered beyond the scope of this document. The extensions
presented in this document do not affect in any way the mobile
nodeÆs choice on the point of attachment to be used when returning
traffic.
3.2 Model of Operation
Filters for Mobile IPv4 Bindings has two modes of operation that can
be seamlessly combined but for the sake of simplicity are covered in
this section separately. The first model of operation concerns the
management of whole flows while the second model addresses the
distribution the individual packets of flows between points of
attachment.
Figure 1 illustrates the first model of operation. It shows a mobile
node with two home addresses each originating from a different home
network (multihoming). The mobile node maintains multiple points of
attachment in several visited domains. A visited domain may consist
of several different IP administrative domains (subnetworks). The
extensions presented do not provide any restriction as to how many
points of attachment a mobile node may maintain within a visited
domain as long as each point of attachment belongs to a different
subnetwork. When a mobile node acquires point of attachment in the
home network then it is required to give up all other points of
attachment.
In figure 1, the mobile node has two separate points of attachment
in the Mobile IPv4 hierarchy of visited domain A. In addition, the
mobile node maintains two more points of attachment through visited
domains B and C. The mobile node maintains five incoming flows from
correspondent nodes CN1, CN2 and CN3. Flows associated with CN1 are
denoted with 'a' and 'b' while the respective flows for CN2 are
denoted with 'c' and 'd'. The flow associated with CN3 is denoted
with 'e'.
Communications originating CN1 are addressed to the mobile nodeÆs
home address from home network 1. For that home address the mobile
node maintains two simultaneous mobility bindings at the GFA each
associated with a Filter indicating that flows 'a' and 'b' should be
delivered to different points of attachment.
Flows denoted with 'c', 'd' and 'e' are addressed to the mobile
nodeÆs home address from home network 2. These are filtered at HA2
and tunneled to different visited domains. The mobile node has
indicated in its Filters that it does not wish to receive flow 'e'.
As such, flow 'e' is terminated at the HA2 as this the first
Filtering Agent encountered in the path to the mobile node and there
NOMADv4 Expires April 2004 8
Internet Draft Filters for Mobile IPv4 Bindings October 2003
is no need for that traffic to propagate further into the network.
The rejection of a flow will take place either without any
notification to its source.
To return traffic a mobile node may choose any of the available
points of attachment.
+---------------------+ +-------------+ +-------+
| Visited Domain A | | | | CN1 |
| | | | +-------+
| | | | a|
a a a a a a +------+ a a a | | | b|
-----------| FA |----- | | | +-----a|----+
a| | +------+ |a | | | b| |
| | +-------+ | | | +------+ |
a| | | GFA |--------------------------| HA1 | |
| | +-------+ babababababababababababab+------+ |
a| | +------+ |b | | | | |
| --------| FA |----- | | | | Home |
a| |b b b b +------+b b b b | | | | Network 1 |
| | | | | | +-----------+
a| |b +---------------------+ | Public |
+------+ | Network | +-----------+
| MN | +---------------------+ | | | Home |
+------+ | Visited Domain B | | | | Network 2 |
|d |c | | | | | |
| | c c c +------+ c c c c c c c c c c c c c c c c c c c c c |
|d --------| FA |----------------------------------------- |
| | +------+ | | d d d d d d d d d d |c |
|d | | | d ------------------ | |
| | | | | | | |d |c |
|d | | | d| dcdcdcdcdcdc +------+ |
| +---------------------+ | | c ------------| HA2 | |
|d | d| d| | | +------+ |
| +---------------------+ +-- |--c|-----+ | e| |
|d | | d| d| +------|----+
| d d d d d d d d d d d d d d d d d d | c| e|
-------------------------------------- d| |
| | c| e|
| Visited Domain C | +-------+ +-------+
| | | CN2 | | CN3 |
+---------------------+ +-------+ +-------+
Figure 1: A mobile node with multiple points of attachment in
different visited domains. Incoming flows are redirected
by the respective Filtering Agents to a different
(co-located) care-of address. In addition, mobile node
chooses to have its HA2 block flow 'e' . Blocking a flow
occurs without notification to the sender.
Figure 2, illustrates the second model of operation. It shows a
mobile node that maintains two points of attachment in visited
domains A and B. In addition, the mobile node maintains one active
flow from CN1, denoted with 'a'. It can be seen that this flow gets
NOMADv4 Expires April 2004 9
Internet Draft Filters for Mobile IPv4 Bindings October 2003
distributed at the HA and variable amounts of the flow are delivered
to a different point of attachment.
+-------------+ +-------+
| Public | | CN1 |
| Network | +-------+
+---------------------+ | | |a
| Visited Domain A | | | |
| | | | +------|a---+
a a a |a a a a a a a a a| a a a a a a| a | |
------------------------------------------------------- a |a |
a| | | | | | | | |
| +---------------------+ | | | |a |a |
+------+ | | | +------+ |
| MN | +---------------------+ | | | | HA | |
+------+ | | | | | +------+ |
|a | a a a | a | a | | |
-------------------------------------------------------- |
| | | | | Home |
| Visited Domain B | | | | Network |
+---------------------+ +-------------+ +-----------+
Figure 2: A mobile node with multiple points of attachment in
different visited domains. A single incoming flow is
distributed by the respective Filtering Agents to a
different (co-located) care-of address.
4 Backwards compatibility with RFC3344
A domain that supports Filters for Mobile IPv4 Bindings should also
be backwards compatible. In Mobile IPv4, mobile nodes issue
registration requests without any Filters and without the æNÆ bit
set. Any such registration request would cause a Filtering Agent to
act as per [1] and to provide normal Mobile IPv4 services. In
addition, it is stated that a Filtering Agent maintaining only Idle
Mobility Bindings for a mobile is required to act as per [1] and to
ignore the behavior presented in this document.
5 Support for Multihoming
The extension presented in this document are compatible with the
multihoming support of Mobile IPv4. In multihoming support a mobile
node may use different home addresses in order to distribute
incoming flows from different CNs. Filters for Mobile IPv4 Bindings
builds on top of that to enable mobile nodes to distribute flows
addressed to the same home address from same or different CNs, for
one or more home addresses.
NOMADv4 Expires April 2004 10
Internet Draft Filters for Mobile IPv4 Bindings October 2003
6 Associating Filters with Mobility Bindings
This section gives a detailed description of the steps taken by a
mobile node that wishes to associate Filters with its mobility
bindings. Furthermore, it is presented how a Filtering Agent reacts
to the receipt of a Filtering Request.
6.1 Mobile Node Considerations
A mobile node that acquires a (co-located) care-of address within a
visited domain may issue a Filtering Request with the æNÆ bit set,
containing a list of Filters. All included Filters will be
associated with the registered (co-located) care-of address at all
Filtering Agents encountered on the path to the HA. A mobile node
that maintains multiple points of attachment may request for
simultaneous mobility bindings by setting the æSÆ bit in its
Filtering Requests.
Filters for Mobile IPv4 Bindings Registration Flag
The only change to the Registration Request defined in [1] is a flag
indicating that the mobile node wishes to receive Filters for Mobile
IPv4 Bindings services. The flag is inserted after the flags defined
in [5].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|r|T|N| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
The flag is defined as follows:
N NOMADv4 Extension. The mobile node wishes to receive
Filters for Mobile IPv4 Bindings, services
Filter declarations and Filter Deletion Extensions are included in a
Registration Request after any security extensions. In addition, a
Filter Deletion Extension may follow any Filter declarations.
A Filtering Reply is a Registration Reply containing a Filter Reply
Extension for each Filter contained in the respective Filtering
NOMADv4 Expires April 2004 11
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Request indicating the Index of the Filter that it refers to along
with its result Code.
For the management of Filters eight scenarios are identified. These
are presented in the following sections along with the actions to be
undertaken by the mobile node. Following that, the use and different
values of the Weight value of the Filter Control Extension are
explained.
Creating a new mobility binding with Filters
In order to create a new mobility binding with associated Filters
the mobile node must issue a Filtering Request including one or more
full Filter definitions (Filter Body with Filter Control Extension).
Each of the Filters must be allocated a different Index number.
The destination of the Filtering Request is identified as described
in [1] or [5]. If the mobile node already maintains a mobility
binding that it wishes to keep then it should set the æSÆ bit in the
Filtering Request.
Replacing a Filter of a mobility binding by Index
In order for a mobile node to replace an existing Filter it is
required to issue a Filtering Request with a full definition of the
new Filter. The Filter Control Extension of the Filter must indicate
the Index of the Filter to be replaced.
Adding new Filters to an existing mobility binding
In order for a mobile node to add new Filters to an existing
mobility binding it is required to act as if creating a new mobility
binding with Filters. The æSÆ bit of the Filtering Request must be
set. It is necessary for the new Filter to adopt an unallocated
Index number otherwise it would be replacing the existing Filter
with that Index.
Sharing a Filter between mobility binding
A mobile node may share a Filter between mobility bindings by
issuing a Filtering Request from each respective point of
attachment. The first one will contain the full Filter (Filter Body
+ Filter Control Extension) while all subsequent Filtering Requests
will contain only a Filter Control Extension indicating the Index
number of the Filter to be shared.
Renewing a mobility binding with Filters
Periodically, a mobile node is required to renew its mobility
bindings in order to extend their lifetime. Renewing a mobility
binding may occur as described in [1] or [5]. Registration Requests
with the purpose of renewing Filters and mobility binding are
required to set the æNÆ bit and may not include any reference to the
Filters associated with the mobility binding.
NOMADv4 Expires April 2004 12
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Deleting one or more Filters of a mobility binding
In order for a mobile node to delete an existing Filter for a
mobility binding, it is required to issue a Filtering Request from
any (co-located) care-of address. The Filtering Request must include
a Filter Deletion Extensions indicating the Index of each Filter to
be deleted.
Deleting all Filters for a mobility binding
In order for a mobile node to delete all existing Filter for a
mobility binding, it is required to issue a Filtering Request from
any (co-located) care-of address. The Filtering Request must include
a Filter Deletion Extensions with the Index field set to zero.
Transferring a Filter between mobility bindings
In order for a mobile node to transfer an existing Filter between
two mobility bindings it is required to act as if creating a new
mobility binding with Filters and send out a Filtering Request from
the point of attachment to which it wants to have the Filter
transferred. The Filtering Request must contain the full Filter
definition.
The Weight field of the Filter Control Extension
The Weight field indicates the relative amount of traffic for which
a Filter is applicable. If the Weight field is set to zero then all
matching flows will be dropped without notification to their source.
For any other value of Weight, matching flows will get forwarded to
the point of attachment indicated by the corresponding mobility
binding. In the case of shared Filters, packets of matching flows
will get distributed between multiple points of attachment with
respect to the Weight value of each Filter.
6.2 Filtering Agent Considerations
This section contains general considerations for Filtering Agents.
These are Mobile IPv4 entities that can maintain mobility bindings
such as Has, GFAs and RFAs.
Determining the validity of a Filter Body
If a Filter Body contains a Protocol Extension with the Protocol
field set to the corresponding value for ICMP then the Filter may
not include any of the Filter Modules from 5-8 as they refer to
sender and receiver port numbers that are not applicable for ICMP.
Processing Filtering Requests
A Filtering Request is a Registration Request with the æNÆ bit set
that may contain a collection of Filter declarations, Filter Control
Extensions or Filter Deletion Extensions.
NOMADv4 Expires April 2004 13
Internet Draft Filters for Mobile IPv4 Bindings October 2003
A Filtering Agent is first required to determine the validity of the
Filter Body. If the Filter is considered valid then the Filtering
Request must be processed like a normal Registration Request, as
described in [1]. If the æSÆ bit is set then the Filtering Agent
should refrain from deleting any existing mobility bindings for the
mobile node. If the æSÆ is not set then all existing mobility
bindings must be deleted along with all associated Filters. If the
Filter Body is not valid then the Filtering Agent must issue a
Filtering Reply with a Filter Control Extension indicating the
FilterÆs Index and the error code INVALID SYNTAX (section 7.12).
For the processing of the Filter Body(s) in a Filtering Request five
distinct cases are identified and the actions that a Filtering Agent
should undertake are described.
Filtering Request contains a Filter declaration with a new Index
A new Filter should be created with the Index and Filter Body
contained in the Filtering Request. Newly declared Filters should be
associated with the (co-located) care-of address indicated by the
Filtering Request.
Filtering Request containing Filter declarations with allocated Index
The Filter indicated by the Index contained in the Filtering Request
is overwritten and replaced with the Filter Body contained in the
Filtering Request.
Filtering Request containing only Filter Control Extension
A sole Filter Control Extension indicates the mobile nodes wishes to
share the Filter indicated by the Index field of the Filter Control
Extension. If the Index refers to an existing Filter, then the
Filter should be shared between (co-located) care-of addresses
already maintaining an association with the Filter and the (co-
located) care-of address registered in the Filtering Request. If the
Index number indicates a non-existent Filter then the Filtering
Request should be denied and a Filtering Reply should be returned to
the mobile node containing a Filter Reply Extension with the Index
field set to the Index of the non-existent Filter and the Code field
set to the NO FILTERS error code.
Filtering Request containing only Filter Deletion Extension
A Filtering Agent encountering a Filter Deletion Extension in a
Filtering Request should remove the Filter indicated by the Index
field in the Filter Deletion Extension. If the indicated Filter does
not exist then the Filtering Request should be denied and a
Filtering Reply should be returned to the mobile node containing a
Filter Reply Extension with the Index field set to the Index of the
non-existent Filter and the Code field set to the NO FILTERS error
code.
NOMADv4 Expires April 2004 14
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Filtering Request without any Filter declarations or Extensions
Filtering Requests that do not contain any Filter declarations or a
Filter Deletion Extensions are intended for refreshing the lifetime
of a mobility binding and its Filters. If the mobile node does not
maintain any Filters for this mobility binding then the Filtering
Agent must issue a Filtering Reply including a Filter Reply
Extension with the Index set to zero and the Code field set to the
NO FILTERS error code indicating that the mobile node does maintain
any Filters.
Applying Filters
When a Filtering Agent intercepts a packet for a mobile node for
which it maintains a mobility binding it is required to identify
whether the packet matches any of the Filters associated with the
mobility binding. If so, then the packet is forwarded to the
respective point of attachment with respect to the Weight value of
the Filter. If the Weight value is zero then the flow gets dropped
without any notification to its source. If no matching Filter is
found then the packet is handled as indicated by the Default Filter.
If a flow matches more then one Filter then its packets are
distributed between the multiple points of attachment with respect
to the Weight value of each Filter.
When a mobility binding expires or is deregistered by a mobile node
then all associated Filters are deleted. Mobility bindings that have
been stripped of their Filters are considered to be Idle Mobility
Bindings. This means that they remain unused until either allocated
a Filter or expire.
6.3 Home Agent Considerations
When a HA receives a Filtering Request that contains one or more
Filter declarations then these Filters must be associated with the
registered (co-located) care-of address. Following that, all Filter
Control Extensions must be processed. Then the HA is required to
issue a Filtering Reply including a Filter Reply Extension for each
Filter in the Filtering Request indicating the Index of the Filter
and its result Code.
When a HA receives a Filtering Request without any Filter
declarations and Filter Deletion Extensions then it is required to
renew the lifetime of the corresponding mobility binding along with
its Filters and to issue a Filtering Reply. If the mobility binding
has no associated Filters then the HA must issue a Filtering Reply
including a Filter Reply Extension with the Index set to zero and
the Code field set to the NO FILTERS error code indicating that the
mobile node does maintain any Filters.
For each Filter in a Filtering Request, a Filtering Agent must
include a Filter Reply Extension indicating its Index and its result
Code. If authentication of the Filtering Request fails then none of
the Filters must be applied.
NOMADv4 Expires April 2004 15
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Filters for Mobile IPv4 Bindings Flag
The only change to the Mobility Agent Advertisement Extension
defined in [1] is a flag indicating that the HA supports Filters for
Mobile IPv4 Bindings. The flag is inserted after the flags defined
in [5].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|V|T|S|I|N|reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more (co-located) care-of addresses |
| ... |
The flag is defined as follows:
N NOMADv4 Extension. This domain supports Filters for Mobile
IPv4 Bindings as specified in this document.
7 NOMADv4 Extensions to RFC3344 Registration Messages
In this section the new Mobile IPv4 registration extensions required
for the support of Filters for Mobile IPv4 bindings are specified.
In NOMADv4, twelve types of extensions are defined. To form a valid
Filter, at least one of the extensions 1 to 9, termed as Filter
Modules, must be included. Extension 10 must appear once in every
Filter following all Filter Modules. Extension 11 may appear only
once in a Filtering Request after any Filter declarations. Finally,
extension 12 may appear several times within a Filtering Reply.
Filter Modules of the same type may not appear in a Filter more than
once. However, a Filter Module may include one or more predicates.
There is an OR relationship between Filter Module predicates. That
is, in order for a flow to match a Filter Module it is required to
qualify for any of its predicates. In addition, there is an AND
relationship between Filter Modules of a Filter. As such, in order
for a flow to match a Filter it is required to qualify for all its
Filter Modules.
All extensions defined in this document follow the short extension
format defined in [1]. In Filter Modules, the leftmost bit of the
Sub-Type field is used to determine whether the rules included in
the Filter Module are positive or negative. In the first case a flow
is required to match exactly the predicates included in the Filter
Module while in the second, the inverted (NOT) rule.
1. Behavior Aggregate Filters Extension (BAF)
Identifies data packets dependent of the content of the DSCP
NOMADv4 Expires April 2004 16
Internet Draft Filters for Mobile IPv4 Bindings October 2003
field.
2. Protocol Extension
Specifies one or more protocols to be filtered.
3. Source Address Extension
Specifies one or more source adresses to be filtered.
4. Source Network Extension
Specifies one or more source networks (i.e. a interval of
IP addresses) to be filtered.
5. Source Port Extension
Specifies one or more source ports to be filtered.
6. Source Port Range Extension
Specifies one or more ranges of source ports to be filtered.
7. Destination Port Extension
Specifies one or more destination ports to be filtered.
8. Destination Port Range Extension
Specifies one or more ranges of destination ports to be filtered.
9. Free-Form Extension
It allows for the definition of complex Filters based on the
value of an area anywhere within a packet. The mobile node
is required to provide the packet offset, the qualifying
value as well as a mask.
10. Filter Control Extension
It contains a FilterÆs unique identifier, called the Index along
with the FilterÆs Weight factor.
11. Filter Deletion Extension
It contains a list of Filter Index numbers to be deleted.
7.1 Behavior Aggregate Filters (BAF) Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |I| Sub-Type | DSCP |RSV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Length (N), where N is the number of DSCP entries
Sub-Type 0 for given predicates, 128 for inverted predicates.
I (INVERT)A single bit at the beginning of the Sub-Type field
used to invert predicates of Filter Module. Due to
NOMADv4 Expires April 2004 17
Internet Draft Filters for Mobile IPv4 Bindings October 2003
this bit two different Sub-Type values are given.
DSCP Differentiated Services CodePoint
In Differentiated Services (DS) [7] the DS header field is defined
as a replacement for the IPv4 TOS [6] octets. Six bits of the DS
field are used as a codepoint (DSCP) to select the per-hop-behavior
that a packet receives at each node. For the purposes of NOMADv4 the
DSCP along with other header fields is used to construct Filters
that identify a specific flow or groups of them.
This Filter Module does not in any way alter or affect the DSCP
value of intercepted packets.
7.2 Protocol Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |I| Sub-Type | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Length (N), where N is the number of Protocol fields
Sub-Type 1 for given predicates, 129 for inverted predicates
I (INVERT)A single bit at the beginning of the Sub-Type
field used to invert predicates of Filter Module.
Due to this bit two different Sub-Type values are
given.
Protocol Identifies the next level protocol used in the data
portion of the internet datagram. The values for
various protocols are specified in [4].
7.3 Source Address Extension
The Source Address Extension is defined for IPv4 and IPv6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |I| Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Length (4*N), where N is the number of source IP address
NOMADv4 Expires April 2004 18
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Fields.
Sub-Type 2 for given predicates, 130 for inverted predicates.
I (INVERT)A single bit at the beginning of the Sub-Type field
used to invert predicates of Filter Module. Due to
this bit two different Sub-Type values are given.
Source IP Address
Identifies the source IP address contained in the IP
header of an incoming flow.
7.4 Source Network Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |I| Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 3 for given predicates, 131 for inverted predicates.
I (INVERT)A single bit at the beginning of the Sub-Type
field used to invert predicates of Filter Module.
Due to this bit two different Sub-Type values are
given.
Length (8*N), where N is the number of pairs of a
source IP address and a corresponding source
IP address mask entry.
Source IP Address
Identifies the base network IP address of a range of
source IP addresses.
Source IP Address Mask
Based on the source IP address field, identifies the
range of source IP addresses.
NOMADv4 Expires April 2004 19
Internet Draft Filters for Mobile IPv4 Bindings October 2003
7.5 Source Port Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |I| Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 4 for given predicates, 132 for inverted predicates.
I (INVERT)A single bit at the beginning of the Sub-Type
field used to invert predicates of Filter Module.
Due to this bit two different Sub-Type values are
given.
Length (2*N), where N is the number of port entries.
Source Port
Identifies the source port number contained in the
IP header of an incoming flow.
7.6 Source Port Range Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |I| Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Min | Source Port Max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 5 for given predicates, 133 for inverted predicates.
I Invert. A single bit at the beginning of the Sub-
Type
field used to invert predicates of Filter Module.
Due to this bit two different Sub-Type values are
given.
Length (4*N), where N is the number of port range entries.
Source Port Number Min
Defines the start point of a range of source port
numbers.
Source Port Number Max
NOMADv4 Expires April 2004 20
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Defines the end point of a range of source port
Numbers.
7.7 Destination Port Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |I| Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 6 for given predicates, 133 for inverted predicates.
I (INVERT)A single bit at the beginning of the Sub-Type
field used to invert predicates of Filter Module.
Due to this bit two different Sub-Type values are
given.
Length (2*N), where N is the number of port entries
Destination Port
Identifies the destination port number contained in
the IP header of an incoming flow.
7.8 Destination Port Range Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |I| Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port Min | Destination Port Max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 7 for given predicates, 134 for inverted predicates.
I (INVERT)A single bit at the beginning of the Sub-Type
field used to invert predicates of Filter Module.
Due to this bit two different Sub-Type values are
given.
Length (4*N), where N is the number of port range entries
Destination Port Number Min
Defines the start point of a range of destination
port numbers
NOMADv4 Expires April 2004 21
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Destination Port Number Max
Defines the end point of a range of destination port
numbers
7.9 Free-Form Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |I| Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask
....
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 7 for given predicates, 134 for inverted predicates.
I (INVERT)A single bit at the beginning of the Sub-Type
field used to invert predicates of Filter Module.
Due to this bit two different Sub-Type values are
given.
Length Is variable, depends on the length of Value and
Mask.
Offset Indicates a location within a packet to be filtered
in bytes.
The area indicated by the offset and for a length equivalent to that
of Mask is compared against Mask with the bitwise operator AND. The
result of this operation is compared against Value. A match would
indicate that the packet qualifies the filter.
Value and Mask fields MUST have exactly the same size. However, this
size may vary with every free-form filter. For the sizes of Value
and Mask the following condition holds:
Value = Mask = (Length - 2) / 2
NOMADv4 Expires April 2004 22
Internet Draft Filters for Mobile IPv4 Bindings October 2003
7.10 Filter Control Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Length | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight |
+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 125.
Length 2.
Index FilterÆs index number
Weight Relative amount of traffic for which forwarding
Filter is applicable
7.11 Filter Deletion Extension
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 126
Length N, where N is the number of Index entries
Index A FilterÆs index number
7.12 Filter Reply Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Length | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index |
+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 127.
NOMADv4 Expires April 2004 23
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Length 2.
Index A FilterÆs index number.
Code Values for Filter Reply Extension
In this section the values to use within the Code field of the
Filter Control Extension are defined:
Successful Filtering Request Codes:
Code Name Value Section of Document
---------------------- ----- -------------------
REQUEST ACCEPTED TBD
Failed Filtering Request Codes:
Error Name Value Section of Document
---------------------- ----- -------------------
NO FILTERS TBD
TOO MANY FILTERS TBD
INVALID FILTER SYNTAX TBD
UNKNOWN FILTER TBD
CAN NOT DROP MIP SIG TBD
The Error Code CAN NOT DROP MIP SIG is used when the mobile node
issues a Filtering Request requesting the drop of flows
corresponding to Mobile IPv4 signaling such as Agent Advertisements
or Registration Requests and Replies.
8. Security Considerations
This draft is based on the security considerations provided in [1]
for mobile node registration and as such does not specifically
address any security concerns.
9 Intellectual Property Considerations
This proposal is in full conformity with [9].
Siemens may have patent rights on technology described in this
document which employees of Siemens contribute for use in IETF
standard discussions. In relation to any IETF standard incorporating
any such technology, Siemens hereby agrees to license on fair,
reasonable and non-discriminatory terms, based on reciprocity, any
patent claims it owns covering such technology, to the extent such
technology is essential to comply with such standard.
NOMADv4 Expires April 2004 24
Internet Draft Filters for Mobile IPv4 Bindings October 2003
References
[1] C. Perkins. IP Mobility Support. RFC (Proposed Standard) 3344,
IETF, August 2002.
[2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, IETF, March 1997.
[3] C. Perkins and D. Johnson. Route Optimization in Mobile IP.
(work in progress). draft-ietf-mobileip-optim-11.txt,
IETF, September 2001. (expired; not updated)
[4] J. Reynolds and J. Postel. Assigned Numbers. Request for
Comments 1700, STD 2, IETF, October 1994.
[5] E. Gustafsson, A. Jonsson and C. Perkins. Mobile IP Regional
Registration. (work in progress).
draft-ietf-mobileip-reg-tunnel-07.txt, IETF, October 2002.
[6] Postel, J. Internet Protocol. STD 5, RFC 791, IETF,
September 1981.
[7] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers. RFC 2474, IETF, December 1998.
[8] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6)
Specification. RFC 2460, IETF, December 1998.
[9] S. Brander. The Internet Standards Process -- Revision 3. RFC
2026, IETF, October 1996
A. Changes from Previous Versions
The following updates and changes were made in this version of the
Filters for Mobile IPv4 Bindings draft, compared to earlier
versions.
A.1. Updates from version 02
Version 3 is almost a complete rewrite of version 2, based on
experience acquired from the implementation of version 2.
Renamed Binding Agents to Filter Agents and Binding Requests &
Replies to Filtering Requests & Replies.
Defined in section 3.2 Model of operation that a mobile node may not
maintain more then one points of attachment in a single subnetwork.
Should the mobile node acquire one point of attachment in the home
network then all other must be given up.
Defined in section 3.1 Protocol Description and in the beginning of
section 5 NOMADv4 Extensions to RFC3344 Registration Messages the
structure of a Filter and the relation between Filter Module
predicates, Filter Modules and Filters. In addition, the Filter
Control Extension was renamed as Filter Target Extension while a new
extension by the name Filter Control Extension was defined. Removed
NOMADv4 Expires April 2004 25
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Action field from Filter Target Extension and increased Target and
Index fields to occupy 8 bits.
Removed P and A bits from Free Form Filter.
Added section 4 Backwards compatibility with RFC3344
Extended section on Mobile Node Considerations and Filtering Agent
Considerations in section 5 Associating Filters with Mobility
Bindings. Described specific actions undertaken by mobile node.
Renamed Default Binding to Default Filter and redefined it. Now
Fitlerless mobility bindings may not be Default Bindings.
Clarified that Index number denotes priority. 0 is lowest priority.
Index 0 is reserved for Default Filter.
Introduced the Filter Reply Extension for the relay of success and
error codes from Filtering Agents to mobile nodes. Defined success
and error codes.
Included INVERT flag in Filter Modules.
Introduced destination port and destination port range Filter
Modules.
Remove all reference to Filters for Mobile IPv6 bindings as this be
the purpose of a separate Internet draft.
A.2. Updates from version 03
Removed all reference to Mobile IPv4 routing optimization.
Merged the Filter Target and Filter Control Extensions.
Introduced the æNÆ bit in the Registration Request and Reply
messages.
Removed the Target field from the Filter Control Extension
Introduced the Weight field in the Filter Control Extension.
Introduced the Filter Deletion Extension
Edited the sections for mobile node and filtering agent
considerations
Added a section on determining the validity of Filter Bodies.
A.3. Updates from version 04
Introduced shared Filters based on the Index field.
Introduced a section for compatibility issues with multihomming
NOMADv4 Expires April 2004 26
Internet Draft Filters for Mobile IPv4 Bindings October 2003
Authors' Addresses
Niko A. Fikouras
Department of Communication Networks (ComNets)
Center for Information and Communication Technology (ikom)
University of Bremen Phone: +49-421-218-3339
D-28219 Bremen, Germany Email: niko@comnets.uni-bremen.de
Asanga Udugama
Department of Communication Networks (ComNets)
Center for Information and Communication Technology (ikom)
University of Bremen Phone: +49-421-218-8665
D-28219 Bremen, Germany Email: adu@comnets.uni-bremen.de
Koojana Kuladinithi
Department of Communication Networks (ComNets)
Center for Information and Communication Technology (ikom)
University of Bremen Phone: +49-421-218-8264
D-28219 Bremen, Germany Email: koo@comnets.uni-bremen.de
Carmelita Goerg
Department of Communication Networks (ComNets)
Center for Information and Communication Technology (ikom)
University of Bremen Phone: +49-421-218-2277
28219, Bremen, Germany Email: cg@comnets.uni-bremen.de
Wolfgang Zirwas
Siemens AG
ICM N MR-ST 8
Werner-von-Siemens Ring 20
D-85630 Grasbrunn Phone: +49-89-722-34369
Germany Email: wolfgang.zirwas@icn.siemens.de
NOMADv4 Expires April 2004 27