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