One document matched: draft-nomad-mobileip-filters-04.txt
Differences from draft-nomad-mobileip-filters-03.txt
Mobile IP Working Group N. A. Fikouras (editor)
INTERNET DRAFT A. Udugama
C. Goerg
ComNets-ikom, Uni. Bremen
W.Zirwas
J. M. Eichinger
Siemens AG
July 2003
Filters for Mobile IPv4 Bindings (NOMADv4)
draft-nomad-mobileip-filters-04.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 January 2004 1
Internet Draft Filters for Mobile IPv4 Bindings July 2003
Table of Contents
2 Terminology......................................................3
3 NOMADv4 Protocol Overview........................................5
3.1 Protocol Description............................................5
3.2 Model of Operation..............................................7
4 Backwards compatibility with RFC3344.............................9
5 Support for Multihoming...........................................9
6 Associating Filters with Mobility Bindings......................10
6.1 Mobile Node Considerations.....................................10
Filters for Mobile IPv4 Bindings Registration Flag................10
Creating a new mobility binding with Filters......................11
Replacing a Filter of a mobility binding by Index.................11
Adding new Filters to an existing mobility binding................11
Renewing a mobility binding with Filters..........................11
Deleting a Filter for a mobility binding..........................11
Deleting all Filters for a mobility binding.......................12
Transferring a Filter between mobility bindings...................12
6.2 Filtering Agent Considerations.................................12
Processing Filtering Requests.....................................12
Processing Filtering Replies......................................12
Applying Filters..................................................13
6.3 Home Agent Considerations......................................13
Filters for Mobile IPv4 Bindings Flag.............................14
Regional Registration Considerations...............................14
GFA/RFA Considerations............................................14
7 NOMADv4 Extensions to RFC3344 Registration Messages.............14
7.1 Behavior Aggregate Filters (BAF) Extension.....................16
7.2 Protocol Extension.............................................16
7.3 Source Address Extension.......................................17
7.4 Source Network Extension.......................................17
7.5 Source Port Extension..........................................18
7.6 Source Port Range Extension....................................18
7.7 Destination Port Extension.....................................19
7.8 Destination Port Range Extension...............................19
7.9 Free-Form Extension............................................20
7.10 Filter Control Extension......................................21
7.11 Filter Deletion Extension.....................................21
7.12 Filter Reply Extension........................................21
Code Values for Filter Reply Extension............................22
8 Intellectual Property Considerations............................22
8 Acknowledgements................................................23
References........................................................23
A. Changes from Previous Versions.................................23
A.1. Updates from version 02.......................................23
A.2. Updates from version 03.......................................24
Authors' Addresses................................................25
NOMADv4 Expires January 2004 2
Internet Draft Filters for Mobile IPv4 Bindings July 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 (collocated) 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, with or without notification to
source).
Home Agents are unable to distinguish between individual flows and
therefore redirect all intercepted traffic for a mobile node to the
(collocated) 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
(collocated) care-of address. Furthermore, if a mobile node requests
for simultaneous bindings, it will receive at each registered
(collocated) 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 (collocated) 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.
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
As defined in [5].
NOMADv4 Expires January 2004 3
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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 (FL)
A collection of Filter Modules 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 contains 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
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)
NOMADv4 Expires January 2004 4
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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 (collocated)
care-of address are required to issue a registration request or
binding update with the æNÆ bit set, containing a list of Filters
that indicate which flows are associated with the registered
(collocated) care-of address. Such signaling is termed as Filtering
Requests.
A Filter is consisted of one or more Filter Modules 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. Moreover, there is an AND
relationship between Filter Modules of the same Filter.
Consequently, 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 overlapping Filters, packets of matching
flows will get distributed between multiple points of attachment
with respect to the Weight value of each Filter.
If a mobile node needs to delete a Filter, then it is required to
add a Filter Deletion Extension at the end of all Filter
declarations. The Filter Deletion Extension contains a list of
Filter indexes that the mobile node wants to have deleted.
A mobile node may define more than one Filters for a specific
mobility binding. The declaration of these Filters may take place
during one or more Filtering Requests.
Filtering Requests will be processed by one or more Filtering
Agents. A Filtering Agent can be any Mobile IPv4 entity that can
maintain mobility bindings with Filters, like a HA, RFA or GFA.
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
NOMADv4 Expires January 2004 5
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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.
Binding management is performed with the help of the æSÆ bit as
described in [1]. RFAs and GFAs receiving Filtering Requests
containing new Filter definitions or Solo Filter Control Extensions
are required to handle them as Home Registrations [5] and forward
them all the way to the HA. In this manner it is assured that
Filtering Agents throughout the registration path maintain a
consistent set of Filters for a mobile node. In the case that an RFA
or GFA receives a Filtering Request with the purpose of transferring
one or more known Filters between two mobility bindings within its
hierarchy then it is required to handle it locally and issue a
Filtering Reply.
A Filtering Reply is a registration reply with the æNÆ bit set.
Filtering Replies are used in order to relay the results of a
Filtering Request. As such, a Filtering Reply contains 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
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.
A Filter remains valid for the lifetime of the corresponding
mobility binding. If the lifetime of a binding expires or it is
cancelled by the registration of another mobility binding then all
associated Filters are deleted from record. When renewing a mobility
binding a mobile node is not required to include any reference to
any Filters. If a mobile node wishes to reuse a deleted Filter then
it will have to reissue a Filtering Request.
The rules by which a mobile node decides on the set of Filters are
considered beyond the scope of this document. The extensions
NOMADv4 Expires January 2004 6
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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
problem of load balancing 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 at 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. The Filtering Requests
that established these mobility bindings and defined the
corresponding Filters where treated by the GRA as Home Registrations
and where forwarded to the HA1. As such, the GFA as well as the HA1
maintain a list of Filters for the mobile node. The difference is
that the GFA maintains two separate simultaneous mobility bindings
with Filters for two different registered (collocated) care-of
addresses while HA1 maintains a single mobility binding with two
Filters, indicating the GFA as the care-of address. In this manner,
Filter information is kept in all Filtering Agents in the
registration path but filtering occurs at the most appropriate
Filtering Agent. That is, flows denoted with 'a' and 'b' are
distributed between the available points of attachment at the GFA,
as this is the last common Filtering Agent on their path to the
mobile node.
NOMADv4 Expires January 2004 7
Internet Draft Filters for Mobile IPv4 Bindings July 2003
Flows denoted with 'c', 'd' and 'e' are addressed at 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
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
(collocated) care-of address. In addition, mobile node
chooses to have its HA2 block flow 'e' . Blocking a flow
NOMADv4 Expires January 2004 8
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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
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 (collocated) 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
NOMADv4 Expires January 2004 9
Internet Draft Filters for Mobile IPv4 Bindings July 2003
addressed to the same home address from same or different CNs, for
one or more home addresses.
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 (collocated) 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 (collocated) 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
NOMADv4 Expires January 2004 10
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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 with the æNÆ bit set
containing a Filter Reply Extension for each Filter contained in the
respective Filtering Request indicating the Index of the Filter that
it refers to along with its result Code.
For the management of Filters seven scenarios are identified. These
are presented along with the actions to be undertaken by the mobile
node.
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 (one or more Filter modules with a 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. It is necessary for the new Filter to adopt an
unallocated Index number otherwise it would be replacing the
existing Filter with that Index.
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 but not include any reference to the
Filters associated with the mobility binding.
Deleting a Filter for 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
NOMADv4 Expires January 2004 11
Internet Draft Filters for Mobile IPv4 Bindings July 2003
any (collocated) 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 (collocated) 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. RFAs and GFAs receiving Filtering Requests with the aim
of transferring known Filters between mobility bindings must issue a
Filtering Reply and avoid forwarding to the HA.
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.
Processing Filtering Requests
Filtering Agents that receive a Filtering Request containing one or
more previously unknown Filter declarations or a Filter Deletion
Extension are required to cache them and forward the Filtering
Request to the next Filtering Agent until it reaches the HA. In this
manner it is ensured that all Filtering Agents in the registration
path maintain the same record of Filters for a mobile node. The
address of the next Filtering Agent is determined with the
mechanisms described in [5].
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 and need to be forwarded to
the next Filtering Agent until they reach the HA. 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.
Processing Filtering Replies
Upon receiving a Filtering Reply, a Filtering Agent needs to look
into the attached Filter Reply Extensions in order to determine the
outcome of the Filtering Request. That is, if the Filtering Agent
NOMADv4 Expires January 2004 12
Internet Draft Filters for Mobile IPv4 Bindings July 2003
encounters a Filter Reply Extension with the Code field set to the
error code UNKNOWN FILTER (section 7.12) then it is required to
flush all Filters of all mobility bindings for the mobile node and
immediately forward the Filtering Reply to the next Filtering Agent.
For every Filter Reply Extension with a successful code, the
Filtering Agent is required to apply the corresponding Filter. For
Filter Reply Extensions with error codes, the Filtering Agent is
required to take no action. Once all Filter Reply Extensions have
been processed, a Filtering Agent may proceed with the processing of
Filter Deletion Extensions and the deletion of all Filters whose
Indexes are enlisted in the extension. . If the Index field is set
to zero then all Filters of the corresponding mobility binding must
be deleted. If the Index does not correspond to any defined Filter
then no Filter is deleted. Finally, a Filtering Agent must forward
the Filtering Reply to the next Filtering Agent until it reaches the
mobile node.
no Filter is deleted.
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 (collocated) care-of address.
Following that, all Solo 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
NOMADv4 Expires January 2004 13
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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.
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 (collocated) 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.
Regional Registration Considerations
GFA/RFA Considerations
All Filtering Requests with the aim of defining, updating or
deleting Filters must be handled as Home Registrations and be
forwarded all the way to the HA. RFAs and GFAs receiving Filtering
Requests with the aim of transferring known Filters between mobility
bindings must issue a Filtering Reply and avoid forwarding to the
HA.
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.
NOMADv4 Expires January 2004 14
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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)
Specifies to Filters data packets dependent of the content of the
DSCP 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.
NOMADv4 Expires January 2004 15
Internet Draft Filters for Mobile IPv4 Bindings July 2003
If a Filter 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. Should a
Filtering Agent receive a Filtering Request with that configuration
of Filtering Modules, it is required to issue a Filtering Reply with
a Filter Control Extension indicating the FilterÆs Index and the
error code INVALID SYNTAX (section 7.12).
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
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
NOMADv4 Expires January 2004 16
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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
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).
NOMADv4 Expires January 2004 17
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOMADv4 Expires January 2004 18
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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
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 |
NOMADv4 Expires January 2004 19
Internet Draft Filters for Mobile IPv4 Bindings July 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
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.
NOMADv4 Expires January 2004 20
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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
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
NOMADv4 Expires January 2004 21
Internet Draft Filters for Mobile IPv4 Bindings July 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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 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 January 2004 22
Internet Draft Filters for Mobile IPv4 Bindings July 2003
8 Acknowledgements
The editor of this document would like to thank Mrs. Koojana
Kuladinithi for her precious input to this version of the draft. In
addition, the authors would like to thank all reviewers for their
help.
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.
NOMADv4 Expires January 2004 23
Internet Draft Filters for Mobile IPv4 Bindings July 2003
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
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
NOMADv4 Expires January 2004 24
Internet Draft Filters for Mobile IPv4 Bindings July 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
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
Josef Martin Eichinger
Siemens AG
ICM N PG SP RC FR
Gustav-Heinemann Ring 11
D-81730 M’nchen Phone: +49-89-636 44838
Germany Email: josef-m.eichinger@siemens.com
NOMADv4 Expires January 2004 25
Internet Draft Filters for Mobile IPv4 Bindings July 2003
NOMADv4 Expires January 2004 26 | PAFTECH AB 2003-2026 | 2026-04-22 23:18:42 |