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