MIP6 Working Group K. Kuladinithi INTERNET DRAFT N. A. Fikouras Expires: November 2004 C. Goerg ComNets-ikom, Uni. Bremen May 2004 Filters for Mobile IPv6 Bindings (NOMADv6) draft-nomadv6-mobileip-filters-02.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 IPv6 Bindings (NOMADv6) introduces a set of extensions for MIPv6 protocol that allows the intelligent use of multiple points of attachment simultaneously, on a mobile node. It specifies a set of rules (filters) that are transmitted to binding agents, who in turn use this information to determine whether and where to route flows associated with the mobile node. 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 flow is dropped before traversing the Internet fabric, with or without notification to their source. These extensions mirror a similar extension defined for Mobile IPv4 (NOMADv4) but has been extended to cater to the behavior of IPv6. NOMADv6 Expires November 2004 1 Internet Draft Filters for Mobile IPv6 Bindings May 2004 Table of Contents 1.Introduction 3 2 Terminology 4 3.Comparison with Filters for Mobile IPv4 (NOMADv4 vs NOMADv6) 5 4 NOMADv6 Protocol Overview 6 4.1 Protocol Description 6 4.1.1 Multiple network interface support and N bit 6 4.1.2 Sending Filtering Rules 7 4.1.3 Processing at the Filtering Agent 8 4.1.4 Lifetime of the filter 8 4.1.6 Filters that split flows between different home addresses. 8 4.1.7 De-registration when a single PoA is at the home network 9 4.2 Model of Operation 9 5 Backword compatibility with basic Mobile IPv6 11 6 Associating Filters with Bindings 11 6.1 Mobile Node Considerations 11 6.1.1 Creating a new mobility binding with Filters 12 6.1.2 Replacing a Filter of a mobility binding by Index 12 6.1.3 Adding new Filters to an existing mobility binding 12 6.1.4 Sharing a Filter between mobility binding 12 6.1.5 Renewing a mobility binding with Filters 12 6.1.6 Deleting a defined Filter/s for a mobility binding 13 6.1.7 Deleting all Filters for a mobility binding 13 6.1.8 Transferring a Filter between mobility bindings 13 6.2 Filtering Agent Considerations 13 7 NOMADv6 Extensions to MIPv6 Binding Messages 14 7.1 Filter Module Extensions 15 7.1.1 Traffic Class Filter Extension. 15 7.1.2 Flow Label Filter Extension 15 7.1.3 Protocol Extension 16 7.1.4 Source Address Extension 17 7.1.5 Source Network Extension 17 7.1.6 Source Port Extension 18 7.1.7 Source Port Range Extension 18 7.1.8 Destination Port Extension 19 7.1.9 Destination Port Range Extension 20 7.1.10 Free-Form Extension 20 7.2 Filter Control Extension 21 7.3 Filter Deletion Extension 22 7.4 Filter Acknowledgement Extension 22 8. Security considerations 23 References 23 Authors' Addresses 24 Intellectual Property Statement 25 NOMADv6 Expires November 2004 2 Internet Draft Filters for Mobile IPv6 Bindings May 2004 1.Introduction This document extends Mobile IPv6 protocol, introducing a set of rules (called filters) that are transmitted with the binding update by the mobile node. When receiving the binding update with filters, the binding agent (Mobile IPv6 entities that can maintain bindings, HA, CN, MAP) route flows associated with the mobile node, based on these rules. This draft enables a mobile node to use its active points of attachment simultaneously and efficiently. In a filter enabled environment, a mobile node MAY include in its binding update, a list of filters as mobility options. Flows that match the conditions listed in the filters are associated with the care-of-addresses as specified in the binding update. In this manner, binding agent becomes aware of the relationship between certain flows and specific bindings. The binding agent, which maintain these relationships and acts on them, is called a filtering agent. Flows intercepted by, or originating from a Filtering Agent (HA, CN, MAP) 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 care-of address indicated by the respective binding. This enables mobile nodes to distribute flows or to distribute packets of a single flow, 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). Mobile IPv6 draft [3] does not consider catering for multiple points of attachment with single home address as in Mobile IPv4 [6]. This is not considered mainly due to the duplication of each packet to the available active points of attachment when the mobile node has a single home address, as specified in [6]. The advantage of using single home address compared to multiple homing is that the mobile node is addressable by one single address and thereby, is able to maintain continuity of communication, when moving flows to any active point of attachment. This draft introduces the mechanism of avoiding IP packet duplication and enabling the mobile node to select its point of attachment intelligently, while using a single home address for multiple active points of attachment and also the redirection of flows among multiple home addresses. The benefits and goals of using multiple interfaces simultaneously are explained in [9] and [10], with real life scenarios. This draft introduces the `N³ bit to the binding update mobility header. This bit, when set, informs the filtering agent to hold multiple simultaneous binding for the given home address of the mobile node and then manipulate the IP traffic based on the filtering rules sent as mobility options. The operation of filtering for Mobile IPv6 is intended to mirror the operation of filtering for Mobile IPv4 [2], with changes necessary to NOMADv6 Expires November 2004 3 Internet Draft Filters for Mobile IPv6 Bindings May 2004 provide a similar behavior. The considerations presented in this document are collectively referred to as the NOMADv6 Extensions. 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 [1]. This document uses the following terms: Destination Option As defined in [3] Domain A collection of networks sharing a common network administration. Home link As defined in [3]. Foreign link As defined in [3]. Home Agent (HA) As defined in [3]. Correspondent Node (CN) As defined in [3]. Mobile Node (MN) As defined in [3]. Mobility Anchor Point (MAP) As defined in [4]. Care-Of-Address As defined in [3]. Mobility Binding As defined in [2]. Binding Agent (BA) Any Mobile IP entity (HA,CN,MAP) that can maintain mobility bindings. Binding Update Mobile IP signaling with the purpose of establishing or updating a mobility binding. Binding Acknowledgement A Binding Acknowledgement is used to acknowledge receipt of a Binding Update, if an acknowledgement was requested in the Binding Update, the binding update was sent to a home agent, or an error occurred. NOMADv6 Expires November 2004 4 Internet Draft Filters for Mobile IPv6 Bindings May 2004 Filtering Agent (FLA) Any binding agent that can maintain filters for mobility bindings in its binding cache, such as the HA, CN or MAP. Filter Module (FLM) A single filtering criteria that specifies the condition to check for filtering data. Filter (FL) A collection of filter modules. Each filter module is interpreted as having an AND relationship with the other filter modules inside the filter. The relationship between filters of a mobile node, is OR. Filtering Update (FLU) Mobile IPv6 signaling (binding update) with the purpose of establishing a new mobility binding that contains one or more Filter extensions as mobility options. Each Filtering Update should include the N bit ON on the binding update mobility header. Filtering Acknowledgement (FLAC) Mobile IPv6 signaling (binding acknowledgment) for returning the result of a Filtering Update. 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 0. Idle Mobility Binding (IMB) A mobility binding without Filters. 3.Comparison with Filters for Mobile IPv4 (NOMADv4 vs NOMADv6) a. In MIPv6, there are no dedicated FAs, GFAs, or RFAs. The roles of these entities have been taken over by the particular routers, which are located along the path which a packet traverses from the HA to the MN or CN to MN. These special routers are called MAPs. Therefore, in an MIPv6 environment, MN destined packet filtering SHOULD be done by an HA, CN or an MAP. b. Mobile IPv6 route optimization can be deployed on a global scale between all mobile nodes and correspondent nodes. Therefore, CN can act also as a filtering agent, similar to an HA. A Filtering extension of routing optimization of simultaneous bindings is not required in MIPv6 as the mobile node sends binding to CN similar to the normal binding to HA. All the other filtering rules defined in NOMADv4[2] are applicable here, with changes required for IPv6. d. Multiple simultaneous bindings are not specified in the MIPv6 protocol, as in the MIPv4 protocol [6]. The S bit in MIPv4 registration request informs the binding agent to keep existing NOMADv6 Expires November 2004 5 Internet Draft Filters for Mobile IPv6 Bindings May 2004 bindings for the same home address, when updating the binding list with the new care-of-address. The filtering concept described in this draft MUST require that all binding agents are able to cater for simultaneous bindings. The new flag called ôNö is introduced to the binding update mobility header to hold simultaneous bindings in NOMADv6. e. Sub types of the Filter extensions are defined on the first byte of the Data field in NOMADv6. NOMADv4 uses standard short and long TLV format as defined in [6] for including sub types. 4 NOMADv6 Protocol Overview This section provides an overview of how filters for MIPv6 bindings can be realized. 4.1 Protocol Description 4.1.1 Multiple network interface support and N bit Filters for Mobile IPv6 is applicable only in the context of the mobile node having multiple points of attachment to the Internet. These attachments MAY have one single home agent or multiple home agents or a combination between these two. In the first case, each network interface of the mobile node, will have the same home address or MAY have multiple home addresses with the same home agent. In latter cases, each interface will have it³s own home address or again, a combination of single home address and multiple home addresses. The `N³ bit, which has been introduced in this draft, provides the major task of informing the binding agent about the actions to be taken for the filters attached in an incoming binding update. The secondary task of the `N³ bit is to inform the binding agent to hold multiple bindings for the same home address. In the latter case, the binding agent MUST keep a new entry without deleting the existing entries for the mobile node³s home address specified in the home address destination option. The format of the Message Data field in the binding update mobility header is as follows [3]: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|K||L|N| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N When set, the binding agent MUST act based on the functions described in this draft (4.1.3) and to add this entry to the binding cache without deleting any existing entries for the mobile node³s home address which is specified in the home address destination option. NOMADv6 Expires November 2004 6 Internet Draft Filters for Mobile IPv6 Bindings May 2004 4.1.2 Sending Filtering Rules Mobile nodes that wish to associate Filters with an acquired care-of address are required to issue a binding update including a list of Filters that indicate which flows are associated with the registered care-of-address. Such signaling is termed as Filtering Updates. 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. With the help of the Filter Control Extension, the Filter³s purpose can be defined. It contains the 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 the filter is applicable. If the Weight field is set to zero, then all matching flows will be dropped without notification to their source. A mobile node may define more than one Filter for a specific mobility binding. The declaration of these Filters may take place during one or more Filtering Updates. In the case of shared Filters, packets of matching flows will get distributed between multiple points of attachment with respect to the Weight value of each filter. A mobile node may share a Filter between mobility bindings by issuing a Filtering Request from each respective point of attachment. The first one will contain the full Filter (Filter Body + Filter Control Extension) while all subsequent Filtering Requests will contain only a Filter Control Extension indicating the Index number of the Filter to be shared. Flows that fail to match any of the defined Filters are handled as defined by the Filter with the lowest possible Index of zero, termed as Default Filter. A mobile node may define some of the attributes of the Default Filter such as the associated mobility binding and its Weight field by issuing a Filtering Request. Otherwise, these will be configured by each Filtering Agent (4.1.3). When a mobile node needs to delete filters, it sends the Filtering Update only with the Filter Control Extension. The index of the filter to be deleted should be send in the index field. If a mobile node wishes to delete all filters, index should be set to 255. All the filtering rules which have to be set in the mobility options of a binding update will be described in the section 7.1. 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. NOMADv6 Expires November 2004 7 Internet Draft Filters for Mobile IPv6 Bindings May 2004 4.1.3 Processing at the Filtering Agent Filtering Updates will be processed by one or more Filtering Agents. A Filtering Agent can be any Mobile IPv6 entity that can maintain mobility bindings with Filters, like a HA, CN or MAP. 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 Weight field set to 1. 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 Acknowledgement contains one or more Filter Acknowledgment Extensions indicating the Index of a Filter along with a Code signifying the result of the respective Filtering Update. The Code is used to relay success or the reason of rejection to the mobile node. If a mobile node sends a binding update without setting a N bit, a Filtering agent should act as per [3] to ignore the behavior presented in this document. A mobility binding in that state is termed as an Idle Mobility Binding. 4.1.4 Lifetime of the filter 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 the binding cache. When renewing mobility binding, a mobile node is not required to include any reference to any requested Filters. A mobile node SHOULD set the N bit on in its Binding Update and then the Filtering Agent SHOULD refresh the lifetime of the binding and all filters, related to the home address sent on the Destination option of the Binding Update. 4.1.6 Filters that split flows between different home addresses. A MN with more than one point of attachment, MAY have different home addresses (multi-homed mobile node) for each of those points of attachment. These addresses MAY be registered with different HAs or with the same HA. In this situation, if MN wishes to split its flows coming to one point of attachment (A) to another (B), MN MUST send a Filtering Update via A, including an alternate CoA mobility option NOMADv6 Expires November 2004 8 Internet Draft Filters for Mobile IPv6 Bindings May 2004 with the CoA of the point of attachment B. The HA of the point of attachment A, upon receival of this binding update, MUST tunnel the matching flows to the CoA of the point of attachment B. If the filtering agent is a CN instead of a HA, then packets will be delivered to the CoA of the point of attachment B using a Type 2 Routing Header as stated in [3]. (Refer Fig. 1) 4.1.7 De-registration when a single PoA is at the home network When a mobile node is connected to its home network by one of its points of attachment, the mobile node MUST de-register all the other bindings that belong to the same home IP address. In this way, mobile node SHOULD delete all filters that utilized the above bindings (being deleted and filters of point of attachment at home now), and revert to operations as defined in [3]. 4.2 Model of Operation Filters for Mobile IPv6 Bindings has two modes of operation that can be seamlessly combined but for the sake of simplicity are covered in this section separately. The first model of operation concerns the management of whole flows while the second model addresses the distribution of the individual packets of flows between points of attachment. The distribution of multiple flows is illustrated in figure 1. It shows a mobile node that maintains multiple access interfaces simultaneously. Each interface provides a point of attachment through a foreign network (FN-A, FN-B and FN-C). The extensions presented do not provide any restriction as to how many points of attachment a mobile node may maintain or how many home agents it can be attached to. For example, the mobile node in figure 1 has two separate points of attachment through FN-A and FN-B, communicating with CN-1 and CN-2 via HA-1. In addition, the mobile node maintains another point of attachment through FN-C, corresponding with CN3 via HA2. MN uses one home address (HoA-1) for two interfaces, while the other interface is connected to the HA2 via HoA-2. In figure 1, the mobile node maintains five communication sessions with correspondent nodes of CN1, CN2 and CN3. Flows associated with CN1 are denoted by 'a' and CN2 are denoted by 'b' & 'c' while the respective flows for CN3 are denoted by 'd' and 'e'. When MN requires to transfer flows `a³ & `b³ (Filter1) to the interface connected to the FN-A, while receiving all the other flows (Default filter) over FN-B, MN sends a new binding as defined in 4.1.2 with N bit set. When MN requires transferring flow `d³ to the interface connected to FN-B, MN sends a binding update with HoA-2 and CoA-C, together with CoA-B in the Alternate care-of-address mobility option and with the required filtering extensions (refer 4.1.6). This causes the addition of a new binding entry (HOA-2:CoA-B:Filter1) at HA2. This will not result in any deletion of existing binding entries (HoA-2:CoA-C will remain). HA2, will now intercept all flows (d & e), but will tunnel NOMADv6 Expires November 2004 9 Internet Draft Filters for Mobile IPv6 Bindings May 2004 flow `d³ through FN-B, while flow `e³ or any other flows continues through FN-C. +-------+ +-------+ +-------+ | CN1 | | CN2 | | CN3 | +-------+ +-------+ +-------+ |a b| |d |a c b c b c b c b c| |e |a b ----------------- |d |a c| |e +--------+ |d | HA1 |HoA-1:CoA-A:Filter1(a,b) |e | |HoA-1:CoA-B:Default(c) |d +--------+ |e |b c| |d |a c| +--------+ |b c| HoA-2:CoA-B:Filter1(d)| HA2 | |a c| HoA-2:CoA-C:Default(e)| | |b c| +--------+ |a c| +-------------+ |d e| |b c| | | |d e| |a c ------------| FN-B |----------------------- d e| |b c c c c c c c| | d d d d d d d d d d d d e| |a +-------------+ e| |b c| e| |a d| e| |b c| e| |a d|HoA-1 e| +------------+ +--------+ +------------+ | |a b a b a | MN | e e e e e e e e e e| | | FN-A |----------| |--------------------| FN-C | | | HoA-1+--------+HoA-2 | | +------------+ +------------+ Figure 1: A mobile node with three points of attachment in different foreign networks (CoA-A, CoA-B & CoA-C) with 2 home addresses (HoA-1 & HoA-2). Incoming flows are redirected by the respective filtering agents (HA1, HA2) to different care-of- addresses, based on the filtering rules. In the example presented in figure 1, the HA1 & HA2 act as the filtering agents. But, any Mobile IPv6 binding agent (HA, MAP, CN) can act as filtering agents. To return traffic, a mobile node may choose any of the available points of attachment. Figure 2, illustrates the second model of operation. It shows the mobile node that maintains two points of attachment in visited domain A and B, while maintaining one active flow from CN1, denoted with æaÆ. In this example, MN maintains two bindings with the CN1 for visiting domain A and B. NOMADv6 extensions are applied to share a Filter (Flow æaÆ) over point of attachment A and B. NOMADv6 Expires November 2004 10 Internet Draft Filters for Mobile IPv6 Bindings May 2004 +-------------------------+ | Public | | Network | +---------------------+ | | | 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 | +------+ | |aaaaaa+------+ | MN | +---------------------+ | ------| CN1 | +------+ | | | | | +------+ |a | a a a | a a | | --------------------------------------------------------- | | | | | | Visited Domain B | | | +---------------------+ +-------------------------+ 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 (HA,CN or MAP) to a different care-of address. 5 Backword compatibility with basic Mobile IPv6 If the binding update does not have the N flag set, the processing of the BU is same as [3]. But if the binding agent has already registered multiple care-of addresses for the same home address, the binding agent MUST overwrite all the bindings for the home address specified in the destination option. Binding updates without N flag set are considered as idle mobility bindings. In order to preserve backward compatibility with the basic protocol [3], it is stated in (section 4.1.3) that a Filtering Agent maintaining only idle Mobility Bindings for a mobile is required to act as per [3] and to ignore the behavior presented in this document. 6 Associating Filters with Bindings This section gives a detailed description of the steps taken by a mobile node that wishes to associate filters with its bindings. Furthermore, it presents how a filtering agent reacts to the receipt of a binding update containing a list of filters. 6.1 Mobile Node Considerations A mobile node that acquires a care-of address within a visited domain may issue a Filtering Update containing a list of Filters. All included Filters will be associated with the registered care-of address at all Filtering Agents (HA,CN,MAP). A mobile node that maintains multiple points of attachment may request for simultaneous NOMADv6 Expires November 2004 11 Internet Draft Filters for Mobile IPv6 Bindings May 2004 mobility bindings by setting the 'N' bit on in its Filtering Updates. However, each of the Filtering Updates must contain its own list of filters. Should the Filtering Update be rejected then the mobile node will receive a Filtering Acknowledgement with a Filter Acknowledgement Extension indicating the Index of the Filter that was rejected along with the reason for rejection. It is important for a mobile node to keep a record of the Filters and their corresponding Index numbers per home address. For the management of Filters eight scenarios are identified. These are presented along with the actions to be undertaken by the mobile node. 6.1.1 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 Update including one or more full Filter definitions (one or more Filter modules with Filter Control Extension) as mobility options, attached to the binding update mobility header. Each of the Filters MUST be allocated a different Index number. The destination of the Filtering Update is identified as described in [3]. 6.1.2 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 Update 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. The Weight value of the new Filter MAY be different from the Weight of the previous Filter definition. 6.1.3 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. 6.1.4 Sharing a Filter between mobility binding A mobile node may share a Filter between mobility bindings by issuing a Filtering Request from each respective point of attachment. The first one will contain the full Filter (Filter Body + Filter Control Extension) while all subsequent Filtering Requests will contain only a Filter Control Extension indicating the Index number of the Filter to be shared. 6.1.5 Renewing a mobility binding with Filters NOMADv6 Expires November 2004 12 Internet Draft Filters for Mobile IPv6 Bindings May 2004 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 [3]. The mobile node sets N bit on, when sending a binding update in order to renew all filters allocated for the home address defined in the destination option. 6.1.6 Deleting a defined Filter/s 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 any care-of address. The Filtering Request must include a Filter Deletion Extensions indicating the Index of each Filter to be deleted. 6.1.7 Deleting all Filters for a mobility binding In order for a mobile node to delete all existing Filters for a mobility binding, it is required to issue a Filtering Request from any care-of address. The Filtering Request must include a Filter Deletion Extensions with the Index field set to zero. 6.1.8 Transferring a Filter between mobility bindings It is required to act as if creating a new mobility binding with Filters and send out a Filtering Update from the point of attachment to which it wants to transfer the Filter to the other. The Filtering Update must attach the Alternate Care-of-Address mobility option and must contain the full Filter. Alternate care-of-address option contains the care-of-address of the point of attachment, which the filter should be transferred. In this way, the transferring of filters are possible irrespective of the same or different home addresses used for each of attachment. The Weight field of the Filter Control Extension indicates the relative amount of traffic for which a Filter is applicable. If the Weight field is set to zero then all matching flows will be dropped without notification to their source. For any other value of Weight, matching flows will get forwarded to the point of attachment indicated by the corresponding mobility binding. In the case of shared Filters, packets of matching flows will get distributed between multiple points of attachment with respect to the Weight value of each Filter. 6.2 Filtering Agent Considerations This section contains considerations for Filtering Agents. These are Mobile IPv6 entities that can maintain mobility bindings such as HAs, CNs or MAPs when hierarchical Mobile IPv6 is supported. Should the Filtering Agent fail to apply any of the Filters then for each such Filter a Filter Acknowledgement Extension must be included in the Filtering Acknowledgement indicating the Index of the rejected Filter along with the reason of rejection. If authentication of the Filtering Update fails, then none of the Filters MUST be applied. NOMADv6 Expires November 2004 13 Internet Draft Filters for Mobile IPv6 Bindings May 2004 Should the Filtering Agent succeed in applying the Filters, then the Filtering Acknowledgement indicating the index of the success MUST be sent, only if `A³ bit is set on the Binding Update. 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, the packet is handled as described by the Weight value 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 Update without setting the N bit (i.e. Binding Update), it is required to overwrite all the bindings set for the home address and keep the binding for the new care-of-address, sent. This binding is called the Idle Mobility Binding and it is required to ignore the behavior described in this document and to act as per [3]. 7 NOMADv6 Extensions to MIPv6 Binding Messages In this section, the new Mobile IPv6 extensions required to support the Filters for Mobile IPv6 bindings are specified. All filtering extensions are sent as mobility options of the binding update or binding acknowledgment mobility header as defined in [3]. The filtering extensions are encoded using a type-length-value (TLV) format in the mobility options. A complete mobility header, once filter extensions are attached SHOULD be an integer multiple of 8 octets long. Filter extensions can be categorized into 4 types, o Filter Module Extensions o Filter Control Extension o Filter Deletion Extension o Filter Acknowledgement Extension The Filter Module Extensions specify the different filtering rules that the mobile node wishes to inform the Filtering Agent. There are 10 such filter extensions. These extensions are always attached to the Binding Update mobility header as mobility option/s. To form a valid Filter, at least one of the filter module extensions must be included. The Filter Control Extension must appear once in every Filter following all Filter Modules. Filter control extension may appear more than once in a binding update 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 NOMADv6 Expires November 2004 14 Internet Draft Filters for Mobile IPv6 Bindings May 2004 any of the predicates in it. 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. In Filter Modules, the first byte of the data is allocated to define the types of the Filter Modules. The left most 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 is applied. The Filter Deletion extension is an extension sent to the Filtering Agent by the mobile node to deleted filter/s. This extension is attached to Binding Update mobility header. The Filter Acknowledgement extension is an extension sent to the mobile node by the Filtering Agent to inform of success or any failure of filter accommodation. This extension is attached to Binding Acknowledgement mobility header. 7.1 Filter Module Extensions 7.1.1 Traffic Class Filter Extension. Specifies the extension required to filter IPv6 packets, based on the value placed on the Traffic Class field of a packet. This has an alignment requirement of 2n. The format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Type | Option Len |I| Sub-Type |Traffic Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length N+1, where N is the number of Traffic Class entries. I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 0 for given Module, 128 for inverted Module Traffic Class Values, related to different classes or priorities of IPv6 packets.[7] 7.1.2 Flow Label Filter Extension Specifies the extension required to filter IPv6 packets based on the value placed on the Flow Label field of a IPv6 packet. This has an alignment requirement of 4n+1. The format is as follows. NOMADv6 Expires November 2004 15 Internet Draft Filters for Mobile IPv6 Bindings May 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Option Type| Option Len |I| Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length 4N+1, where N is the number of Flow Label entries. Each Flow Label entry is assumed to take 4 bytes (including the Reserved bits) I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 1 for given Module, 129 for inverted Module Flow Label Any value which is labelled on this field of a IPv6 packet. Refer [7] for what and how flow label is in IPv6. 7.1.3 Protocol Extension Specifies one or more protocol to be filtered. This has an alignment requirement of 2n. The format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Type | Option Len |I| Sub-Type | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length N+1, where N is the number of Protocol entries. I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 2 for given Module, 130 for inverted Module Protocol Identifies the next level protocol used in the data portion of the IPv6 datagram. The values NOMADv6 Expires November 2004 16 Internet Draft Filters for Mobile IPv6 Bindings May 2004 for various protocols are specified in [7] 7.1.4 Source Address Extension Specifies one or more source addresses to be filtered. This has an alignment requirement of 8n+5. The format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Option Type| Option Len |I| Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length 16N+1, where N is the number of source addresses. I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 3 for given Module, 131 for inverted Module Source Address Identifies the source address/es to be filtered. 7.1.5 Source Network Extension Specifies one or more source network/s to be filtered. This has an alignment requirement of 8n+4. The format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Type | Option Len |I| Sub-Type | Network Prefix| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Address | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length 9N+1, where N is number networks. NOMADv6 Expires November 2004 17 Internet Draft Filters for Mobile IPv6 Bindings May 2004 I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 4 for given Module, 132 for inverted Module Network Prefix Identifies the network prefix to be filtered. Network Address Identifies the first 64 bits of the Source network address. 7.1.6 Source Port Extension Specifies one or more source ports to be filtered. This has an alignment requirement of 2n+3. The format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Option Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Len |I| Sub-Type | Source Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length 2N+1, where N is number of port entries. I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 5 for given Module, 133 for inverted Module Source Port Identifies the Source Port Number/s to be filtered. 7.1.7 Source Port Range Extension Specifies one or more source ports to be filtered. This has an alignment requirement of 2n+1. The format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Option Type| Option Len |I| Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number Min | Source Port Number Max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NOMADv6 Expires November 2004 18 Internet Draft Filters for Mobile IPv6 Bindings May 2004 Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length 4N+1, where N is number of port range entries. I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 6 for given Module, 134 for inverted Module Port Number Min Identifies the start point of a range of port numbers. Port Number Max Identifies the end point of a range of port numbers. 7.1.8 Destination Port Extension Specifies one or more destination ports to be filtered. This has an alignment requirement of 2n+3. The format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Option Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Len |I| Sub-Type | Destination Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length 2N+1, where N is number of port entries. I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 7 for given Module, 135 for inverted Module Destination Port Identifies the destination Port Number/s to be filtered. NOMADv6 Expires November 2004 19 Internet Draft Filters for Mobile IPv6 Bindings May 2004 7.1.9 Destination Port Range Extension Specifies one or more destination ports to be filtered. This has an alignment requirement of 2n+1. The format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Option Type| Option Len |I| Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Port Number Min | Destination Port Number Max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length 4N+1, where N is number of port range entries. I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 8 for given Module, 136 for inverted Module Port Number Min Identifies the start point of a range of port numbers. Port Number Max Identifies the end point of a range of port numbers. 7.1.10 Free-Form Extension Specifies the value of an area anywhere within a packet. The alignment requirement is based on the number of bytes on Value field. The format is as follows. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask .... Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length Is variable, depends on the length of the Value and Mask. NOMADv6 Expires November 2004 20 Internet Draft Filters for Mobile IPv6 Bindings May 2004 I Invert. A left most bit of the Sub-Type field is used to invert each predicate of the Filter Module. Due to this bit, two different Sub-Type values are given. Sub-Type 9 for given Module, 137 for inverted Module Offset Indicates the starting octet location within an IPv6 packet to use to mask with the Mask and check with Value. Value Indicates the value to be checked, once masked. Mask Indicates the value to use as the mask to mask the octets starting from the offset. 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, the length of the Value and Mask may vary with every free-form filter. For the sizes of Value and Mask the following condition holds: Value = Mask = (Length - 4) / 2 7.2 Filter Control Extension Specifies a filter³s unique identifier, called the index along with the Filter³s Target. 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 | Sub-Type | Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weight | +-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined). Option Length 3 Sub-Type 125 Index FilterÆs index number Weight Relative amount of traffic for which forwarding Filter is applicable NOMADv6 Expires November 2004 21 Internet Draft Filters for Mobile IPv6 Bindings May 2004 7.3 Filter Deletion 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 | 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.4 Filter Acknowledgement Extension Specifies the format of an acknowledgement extension which is sent with the binding acknowledgement mobility header to inform the MN about the status of Filters processed at the Filtering Agent. This has an alignment requirement of 2n+3. The format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Option Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Len | Sub-Type | Code | index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type The type which describes a collection of NOMADv6 extensions (To be defined) Option Length 3 Sub-Type 127. Index Filter³s index number Code Values to indicate the status of the Filter accommodation The following section specifies the values to use within the Code field of the Filter Acknowledgement Extension are defined: Successful Filtering Update Codes: Code Name Value ---------------------- ----- REQUEST ACCEPTED TBD NOMADv6 Expires November 2004 22 Internet Draft Filters for Mobile IPv6 Bindings May 2004 Failed Filtering Update Codes: Error Name Value ---------------------- ----- 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 Update requesting the drop of flows corresponding to Mobile IPv6 signalling such as Router Advertisements, Binding Update, Binding Refresh Request, Binding Acknowledgement or Binding Error. 8. Security considerations Since the filter extensions defined in this document only concern the messaging between the home agent (or correspondent node with route optimization) and the MN, all security mechanisms that are defined in [3] is considered sufficient to protect the integrity and authenticity of filter extensions that are attached with Binding Update and Binding acknowledgement messages. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, March 1997. [2] N.A. Fikouras, A. Udugama, K. Kuladinithi, C. Goerg, W. Zirwas. Filters for Mobile IP Bindings (NOMAD).draft-nomad-mobileip- filters-05.txt, IETF, October 2003. [3] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-24.txt, IETF, January 2003. [4] H. Soliman, C. Castelluccia, K. Malki, L. Bellier. Hierarchical MIPv6 Mobility management. Draft-ietf-mobileip-hmipv6-06.txt, IETF, July 2002. [5] K. Malki, H. Soliman. Simultaneous Binding for Mobile Ipv6 Fast Handoffs. draft.emalki-mobileip-bicasting-v6-02.txt, IETF, June 2002. [6] C. Perkins, IP Mobility Support for IPv4. RFC 3220, January 2002. [7] S. Deering, R. Hinden. Internet Protocol Version 6 Specification, RFC 2460, December 1998. [8] J. Reynolds and J. Postel. Assigned Numbers. Request for Comments 1700, STD 2, IETF, October 1994. [9] T. Ernst, N. Montavont, R. Wakikawa, C. Ng, E. Paik, and K. Kuladinithi,T. Noel, "Goals and Benefits of Multihoming," IETF http://www.ietf.org/internet-drafts/draft-multihoming- generic-goals-and-benefits-00, February 2004 [10] N. Fikouras, K. Kuladinithi, C. Goerg and C. Bormann, "Mobile IPv4 Flow Mobility", draft-nomad-mip4-flow-mobility-pb-00.txt (work in progress), Feb 2004. NOMADv6 Expires November 2004 23 Internet Draft Filters for Mobile IPv6 Bindings May 2004 A. Changes from Previous Versions The following updates and changes were made in this version of the Filters for Mobile IPv6 Bindings draft, compared to earlier versions. A.1. Updates from version 00 Removed the Target field from the Filter Control Extension Introduced the Weight field in the Filter Control Extension. Introduced the Filter Deletion Extension Introduced shared Filters based on the Index field. Extended the section 4.2 to explain the distribution of packets of a flow. A.2. Updates from version 01 Clarified what happens if one interface is attached to the home network (section 4.1.7) Added references to the problem statement drafts of multi-homing goals and benefits in the introduction Added the security section Authors' Addresses Koojana Kuladinithi Department of Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen Phone: +49-421-218-8264 D-28219 Bremen, Germany Email: koo@comnets.uni-bremen.de Niko A. Fikouras Departmnt 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 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 NOMADv6 Expires November 2004 24 Internet Draft Filters for Mobile IPv6 Bindings May 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an ôAS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION NOMADv6 Expires November 2004 25