One document matched: draft-nomad-mobileip-filters-03.txt
Differences from draft-nomad-mobileip-filters-02.txt
Mobile IP Working Group N. A. Fikouras (editor)
INTERNET DRAFT A. Udugama
Expires: October 2003 A. J. Koensgen
C. Goerg
ComNets-ikom, Uni. Bremen
W.Zirwas
J. M. Eichinger
Siemens AG
April 2003
Filters for Mobile IPv4 Bindings (NOMADv4)
draft-nomad-mobileip-filters-03.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 their
establishment (registration, binding update). 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 among its
available points of attachment or to request that such flows are
dropped before traversing the Internet fabric, with or without
notification to their source. Finally, it is possible for a mobile
node to select whether it wishes to turn off routing optimization
for specific communications in order to avoid giving away its
location.
NOMADv4 Expires Octoner 2003 1
Internet Draft Filters for Mobile IPv4 Bindings April 2003
Table of Contents
1 Introduction.....................................................3
2 Terminology......................................................4
3 NOMAD Protocol Overview..........................................5
3.1 Protocol Description.............................................5
3.2 Model of Operation...............................................7
4 Backwards compatibility with RFC3344.............................9
5 Associating Filters with Mobility Bindings......................10
5.1 Mobile Node Considerations......................................10
Creating a new mobility binding with Filters.......................10
Replacing a Filter of a mobility binding by Index..................10
Adding new Filters to an existing mobility binding.................11
Renewing a mobility binding with Filters...........................11
Flushing all Filters or deleting a Filter from a mobility binding..11
Transferring a Filter between mobility bindings....................11
5.2 Filtering Agent Considerations..................................11
Home Agent Considerations..........................................12
Filters For Mobile IPv4 Bindings Registration Flag.................13
Regional Registration Considerations................................13
GFA/RFA Considerations.............................................13
6 NOMAD Extensions to RFC3344 Registration Messages...............13
6.1 Behavior Aggregate Filters (BAF) Extension......................15
6.2 Protocol Extension..............................................15
6.3 Source Address Extension........................................16
6.4 Source Network Extension........................................16
6.5 Source Port Extension...........................................17
6.6 Source Port Range Extension.....................................17
6.7 Destination Port Extension......................................18
6.8 Destination Port Range Extension................................18
6.9 Free-Form Extension.............................................19
6.10 Filter Target Extension........................................20
6.11 Filter Control Extension.......................................20
6.12 Filter Reply Extension.........................................21
Code Values for Filter Reply Extension..............................21
7 Routing Optimization Extensions.................................22
7.1. Routing Optimization Extension for Simultaneous Bindings.......22
8 Intellectual Property Considerations............................22
9 Acknowledgements................................................23
References........................................................23
A. Changes from Previous Versions.................................23
Authors' Addresses................................................24
NOMADv4 Expires October 2003 2
Internet Draft Filters for Mobile IPv4 Bindings April 2003
1 Introduction
This document extends the Mobile IPv4 [1] protocol by providing the
means for mobile nodes that have requested simultaneous bindings 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, or originating from 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)
or to restrict flows for which it wishes to receive routing
optimization services. This is done in order to avoid giving away
the mobile nodeÆs location.
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.
A functionality similar to the one described earlier can be provided
through the routing optimization extension [3] whereby the mobile
node is enabled to communicate directly with a correspondent node
(CN), bypassing the Home Agent. In that case, it is possible for the
mobile node to register a different (collocated) care-of address
with each CN, therefore associating all of a Correspondent Node's
communications with one of its points of attachment. However, with
this approach it is not possible to distribute the communications of
a given Correspondent Node between multiple points of attachment.
Correspondent Nodes, just like mobility agents, are equally unable
to distinguish between individual flows in spite of being their
origin.
An additional problem that arises in routing optimization conditions
is caused by the fact that Home Agents may inconsiderately issue
Binding Updates to all Correspondent Nodes, thus revealing the
mobile nodeÆs position. This process occurs even without some prior
security association between the Home Agent and the Correspondent
Node. As such, malicious Correspondent Nodes with the ultimate
purpose of tracking a mobile node may at arbitrary time periods
NOMADv4 Expires October 2003 3
Internet Draft Filters for Mobile IPv4 Bindings April 2003
query its Home Agent about the mobile nodeÆs current position. With
the help of filters for Mobile IPv4 bindings it is possible to
define a set of criteria matched only by communications for which a
mobile node would like to have routing optimization.
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 (Correspondent Nodes, Home or Mobility
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.
In order to provide simultaneous bindings to Correspondent Nodes
with routing optimization support, the 'S' bit is introduced in the
binding update message. The consideration presented in this document
are collectively referred to as the NOMADv4 Extension.
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].
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].
NOMADv4 Expires October 2003 4
Internet Draft Filters for Mobile IPv4 Bindings April 2003
Mobility Binding
As defined in [1].
Filtering Agent (FLA)
Mobile IPv4 entities that can maintain Filters for mobility
bindings such as the HA, RFA, GFA or CNs when routing
optimization is present.
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 (DB)
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 0.
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 an acquired
(collocated) care-of address are required to issue a registration
request or binding update including 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 Target Extension. A Filter Module may contain
several predicates. There is an OR relationship between predicates
NOMADv4 Expires October 2003 5
Internet Draft Filters for Mobile IPv4 Bindings April 2003
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.
With the help of the Filter Target Extension, the FilterÆs purpose
can be defined. It contains the FilterÆs Index, and a Target. The
Index identifies uniquelly a Filter for a given mobile node while
the Target indicates how a flow should be handled when it matches
the Filter (i.e. drop, forward).
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. In the case of overlapping
Filters, the one with the highest Index is considered applicable.
Filter management is performed with the help of the Filter Control
Extension. One or more such extensions may be included in any
Filtering Request interleaving with any Filter declarations. The
purpose of the Filter Control Extension is to delete or refresh one
or more Filters or to define the Index of the Default Filter.
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, 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 Default Filter. If a mobile node fails to promptly
define a Default Filter or if the associated mobility binding
expires then a new one will automatically be configured by each
involved Filtering Agent to the lowest possible Index of 0.
Different Filtering Agents may apply different Default Filter
definitions, however it is recommended that the Default Filter be
associated with the mobility binding with the longest outstanding
lifetime with the Target set to forward.
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.
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.
A Filtering Agent that receives a Filtering Request is required to
establish a mobility binding and set up a tunnel as per [1]. Filters
and Filter Control Extensions contained in the Filtering Request
should be applied with the sequence in which they appear in the
Filtering Request. Newly declared Filters should be associated with
the registered mobility binding.
NOMADv4 Expires October 2003 6
Internet Draft Filters for Mobile IPv4 Bindings April 2003
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 deletion requests 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 contains one or more Filter Reply Extensions
indicating the Index of a Filter along with a Code signifying the
result of the respective Filtering Request. The Code is used to
relay success or the reason of rejection to the mobile node. If
routing optimization is supported then in the case of declined
Filters a Binding Acknowledgment with one or more Filter Reply
Extensions must be generated independently of whether the 'A' bit
was set in the Binding Update or not.
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 requested Filters. If a mobile node wishes to reuse a deleted
Filter then it will have to be reissued with the corresponding
Filtering Request.
This document defines five different targets for Filters. These
represent different ways to handle flows that match a Filter. As
such, all packets of a flow(s) matching a Filter would either be
forwarded through the available tunnel or get rejected with or
without notification to their source. In addition, a mobile node may
request that it does not wish to receive routing optimization
services for specific flows. In that case, the Filtering Agent would
seize to issue Binding Update messages to CNs. Finally, the
Masquerading target option is used to perform remote private address
management. As such, one or more mobiles nodes would remain
reachable on a single globally routable address while roaming within
a private network.
3.2 Model of Operation
The general model of operation is illustrated in figure 1. It shows
a mobile node that maintains multiple points of attachment in
NOMADv4 Expires October 2003 7
Internet Draft Filters for Mobile IPv4 Bindings April 2003
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 registers an acquired 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'.
For communications with CN1, routing optimization has been assumed.
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 HA. As such, the GFA as well as the HA
maintain a list of Filters requested by the mobile node. Their
difference is that the GFA maintains two separate simultaneous
mobility bindings with Filters for two different registered
(collocated) care-of addresses while the HA maintains a single
mobility binding with two Filters, indicating the GFA as the
(collocated) 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. Similarly, flows
denoted with 'c' and 'd' that do not use routing optimization are
filtered at the HA and tunneled to different visited domains. In the
opposite manner, incoming flow 'e' from CN3 is terminated at the HA
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. This rejection of a flow can take place
either with or without notification to the sender on request by the
mobile node.
To return traffic a mobile node may choose any of the available
points of attachment.
NOMADv4 Expires October 2003 8
Internet Draft Filters for Mobile IPv4 Bindings April 2003
+---------------------+ +-------+
| Visited Domain A | | CN1 |
| | +-------+
| | |a
a a a a a a +------+ a a a | |b
-----------| FA |----- | +------|a-----+
a| | +------+ |a | |b |
| | +-------+ | |a |
a| | | GFA |------------ b |
| | +-------+ babababababa |
a| | +------+ |b | | |
| --------| FA |----- | | |
a| |b b b b +------+b b b b | | |
| | | | | |
a| |b +---------------------+ | Public | +-----------+
+------+ | Network | | |
| MN | +---------------------+ | | | Home |
+------+ | Visited Domain B | | | | Network |
|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 ------------| HA | |
|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 care-of
address. In addition, mobile node chooses to have its HA
block flow 'e' . Blocking a flow may occur with or without
notification to the sender.
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. Such registration
requests establish mobility bindings without Filters, considered in
this document as Idle Mobility Bindings. Such are mobility bindings
not in use, waiting to be allocated a Filter, expire or be
deregistered by a mobile node. In order to preserve backwards
compatibility with the basic protocol [1] it is stated in (section
NOMADv4 Expires October 2003 9
Internet Draft Filters for Mobile IPv4 Bindings April 2003
3.1) 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 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.
5.1 Mobile Node Considerations
A mobile node that acquires a (collocated) care-of address within a
visited domain may issue a Filtering Request 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 on in its Filtering Requests. However, each of the
Filtering Requests must contain its own list of filters. Should the
Filtering Request be rejected then the mobile node will receive a
Filtering Reply with a Filter Reply Extension indicating the Index
of the Filter that was rejected along with the resulting for
rejection. If routing optimization is supported then a Binding
Acknowledgment with the failed Filters will be received
independently of whether the 'A' bit was set in the Binding Update.
It is important for a mobile node to keep a record of the Filters
and their corresponding Index numbers.
For the management of Filters six 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 Filter
Target Extension). Each of the Filters must be allocated a different
Index number. A higher Index indicates a Filter with a higher
priority. In the case of overlapping Filters, the one with the
highest Index is applicable.
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
NOMADv4 Expires October 2003 10
Internet Draft Filters for Mobile IPv4 Bindings April 2003
new Filter. The Filter Target Extension of the Filter must indicate
the Index of the Filter to be replaced. The Target of the new Filter
may be different then the Target of the previous Filter definition.
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 an 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]. Filtering Requests
with the purpose of renewing Filters and mobility binding are
required to include a Filter Control Extension indicating the mobile
nodeÆs intention to either renew all Filters or include a list of
Filter Indexes that need to be renewed. Filters associated with the
mobility binding whose Indexes are not included in the Filter
Control Extension will be automatically deleted.
Flushing all Filters or deleting a Filter from a mobility binding
In order for a mobile node to delete an existing Filter it is
required to issue a Filtering Request with one or more Filter
Control Extensions indicating the mobile nodeÆs intention to either
flush all Filters associated with the mobility binding or include a
list of Filter Indexes that need to be deleted.
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.
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.
5.2 Filtering Agent Considerations
This section contains considerations for Filtering Agents. These are
Mobile IPv4 entities that can maintain mobility bindings such as
HA,s GFAs, RFAs or CNs when routing optimization is supported.
Filtering Agents that receive a Filtering Request containing one or
more previously unknown Filters are required to make a record of the
Filters and forward it 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
NOMADv4 Expires October 2003 11
Internet Draft Filters for Mobile IPv4 Bindings April 2003
mobile node. The address of the next Filtering Agent is determined
with the mechanisms described in [5].
Upon receiving a Filtering Reply indicating that another Filtering
Agent has accepted the Filtering Request, Filtering Agents are
required to either establish a new mobility binding associated with
the corresponding Filters or update the one referred to by the
Filtering Request. Mobility binding management is performed with the
help of the 'S' bit as described in [1].
Should the Filtering Agent fail to apply any of the Filters then for
each such Filter a Filter Reply Extension must be included in the
Filtering Reply indicating the Index of the rejected Filter along
with the reason of rejection. If authentication of the Filtering
Request fails then none of the Filters must be applied.
Filtering Agents that receive a Filtering Request containing one or
more Filter Control Extensions are required to renew, delete or set
a Default Filter as indicated by the Action field of the Filter
Control Extension and the list of Filter Indexes. If the Filtering
Agent does not maintain a record of any of the defined Filter
Indexes then it is required to ignore the Filter Control Extension,
flush all Filters for the mobile node and return a Filtering Request
with a Filter Reply Extension indicating an error message of UNKNOWN
FILTER (section 5.12). Filtering Agents receiving a Filtering Reply
containing a Filter Reply Extension with an error code of UNKNOWN
FILTER should flush all Filters for the mobile node and forward the
Filtering Reply.
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 handled as described by
the target of the corresponding Filter. If no matching Filter is
found then the packet is handled as indicated by the Default Filter.
When a mobility binding expires or is deregistered by a mobile node
then all associated Filters are deleted with it. Whenever a
Filtering Agent received a Filtering Request without any Filters
then it is required to establish an Idle Mobility Binding. If a
Filtering Agent maintains only Idle Mobility Bindings for a mobile
node then it is required to ignore the behavior described in this
document and to act as per [1].
Home Agent Considerations
When an HA receives a Filtering Request that does not contain any
Filter declarations then it is required to process it as defined in
[1]. If the Filtering Request contains any Filter declarations then
these Filters must be associated with the registered (collocated)
care-of address. If these Filters can not be applied then the HA
must issue a Filtering Request including one or more Filter Reply
Extensions indicating the Index of the Filter that it failed to
apply along with the reason of rejection.
NOMADv4 Expires October 2003 12
Internet Draft Filters for Mobile IPv4 Bindings April 2003
Filters For Mobile IPv4 Bindings Registration 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 flag 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.
6 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, eleven types of registration 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 is used
for Filter control and may appear more then once in a registration
request interleaving with Filter declarations.
Filter Modules of the same type may not appear in a Filter more than
once. 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 the predicates in it. In addition, there is an AND
relationship between Filter Modules of a Filter. As such, in order
NOMADv4 Expires October 2003 13
Internet Draft Filters for Mobile IPv4 Bindings April 2003
for a flow to match a Filter it is required to qualify for all its
Filter Modules.
All registration extensions defined in this document follow the
short extension format defined in [1]. In Filter Modules, the first
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 Target Extension
It contains a FilterÆs unique identifier, called the Index along
with the FilterÆs Target.
11. Filter Control Extension
It allows for the management of existing Filters. It contains a
list of Filter Indexes along and an indication of an action to
be taken on the respective Filters.
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
NOMADv4 Expires October 2003 14
Internet Draft Filters for Mobile IPv4 Bindings April 2003
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 5.12).
6.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 end 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.
6.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 end of the Sub-Type
NOMADv4 Expires October 2003 15
Internet Draft Filters for Mobile IPv4 Bindings April 2003
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].
6.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 end 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.
6.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.
NOMADv4 Expires October 2003 16
Internet Draft Filters for Mobile IPv4 Bindings April 2003
I (INVERT)A single bit at the end 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.
6.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 end 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.
6.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
NOMADv4 Expires October 2003 17
Internet Draft Filters for Mobile IPv4 Bindings April 2003
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 end 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.
6.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 end 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.
6.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destionation Port Min | Destionation Port Max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOMADv4 Expires October 2003 18
Internet Draft Filters for Mobile IPv4 Bindings April 2003
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 end 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
6.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 end 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
NOMADv4 Expires October 2003 19
Internet Draft Filters for Mobile IPv4 Bindings April 2003
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
6.10 Filter Target 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 | Target |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index |
+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 125.
Length 2.
Target Target of the filter
Index FilterÆs index number
Admissible values for the Target field are as follows:
Value FilterÆs Target
0 Reject incoming packets without notification
1 Reject incoming packets with notification
2 Accept incoming packets
3 Accept incoming packets but avoid route
optimization
4 Masquerade
6.11 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 | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index |
+-+-+-+-+-+-+-+-+
Type The type, which describes a collection of extensions
having a common data type. (To Be Defined).
Sub-Type 126.
NOMADv4 Expires October 2003 20
Internet Draft Filters for Mobile IPv4 Bindings April 2003
Length (N+1), where N is the number of Index entries
Action Action to be undertaken to the listed Filter(s)
Index A list of one or more FiltersÆ index numbers
Admissible values for the Action field are as follows:
Value Filter Control Action
0 Delete Filter
1 Flush all Filters
2 Refresh Filter
3 Refresh all Filters
4 Make default Filter
6.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.
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
---------------------- ----- -------------------
TOO MANY FILTERS TBD
INVALID FILTER SYNTAX TBD
UNKNOWN FILTER TBD
CAN NOT DROP MIP SIG TBD
NOMADv4 Expires October 2003 21
Internet Draft Filters for Mobile IPv4 Bindings April 2003
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.
7 Routing Optimization Extensions
Due to the lack of support for simultaneous bindings in routing
optimization for CNs requires the introduction of the 'S' bit to
binding update messages.
7.1. Routing Optimization Extension for Simultaneous Bindings
The Binding Update message is defined in [3]. With this message it
is possible for a mobile node to establish a mobility binding at a
CN with routing optimization support. However, with every subsequent
Binding Update the CN is required to cancel the older mobility
binding and to establish a new one. In order to enable simultaneous
binding support the 'S' bit is introduced in the Binding Update
message.
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 |A|I|M|G|S| Rsv | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| care-of address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
S Simultaneous bindings. If the 'S' bit is set on, the
mobile node is requesting that the correspondent
node retains its prior mobility bindings.
All other fields are defined in [3].
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
NOMADv4 Expires October 2003 22
Internet Draft Filters for Mobile IPv4 Bindings April 2003
patent claims it owns covering such technology, to the extent such
technology is essential to comply with such standard.
9 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 October 2003 23
Internet Draft Filters for Mobile IPv4 Bindings April 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.
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
NOMADv4 Expires October 2003 24
Internet Draft Filters for Mobile IPv4 Bindings April 2003
D-28219 Bremen, Germany Email: adu@comnets.uni-bremen.de
Andreas J. Koensgen
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: ajk@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 October 2003 25 | PAFTECH AB 2003-2026 | 2026-04-22 23:21:29 |