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