Monami6 C. Larsson Internet-Draft H. Levkowetz Intended status: Standards Track H. Mahkonen Expires: April 26, 2007 T. Kauppinen Ericsson October 23, 2006 A Filter Rule Mechanism for Multi-access Mobile IPv6 draft-larsson-monami6-filter-rules-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document suggests a mechanism that could be used to control per- flow interface selection for communication to and from multi-homed nodes. A clear distinction is made between policies, filter rules and filters. In order to be able to use filter rules in a multi-access mobility Larsson, et al. Expires April 26, 2007 [Page 1] Internet-Draft Monami6 Filter Rules October 2006 context without excessive overhead, it is advantageous to be able to define filter definitions and bindings separately, as it is expected that it may be necessary to update the bindings much more often than the filter definitions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 2.1. Policy and Policy Exchange . . . . . . . . . . . . . . . 7 2.2. Packet Filter and Packet Filter Exchange . . . . . . . . 8 2.3. Binding FIID to Physical Interface . . . . . . . . . . . 10 3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 11 3.1. PF Message format . . . . . . . . . . . . . . . . . . . 12 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 13 4.1. When to send a Packet Filter to a Filtering Peer . . . . 14 4.2. Packet Filter Content . . . . . . . . . . . . . . . . . 14 4.3. Sending Packet Filter Update . . . . . . . . . . . . . . 15 4.4. Receiving Packet Filter Update . . . . . . . . . . . . . 16 5. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Larsson, et al. Expires April 26, 2007 [Page 2] Internet-Draft Monami6 Filter Rules October 2006 1. Introduction When a node is equipped with multiple network interfaces or has multiple addresses assigned to one network interface the node is said to be multi-homed. When a multi-homed node establishes a session with a peer there exist several potential communication paths between the nodes. Multiple communication paths between two nodes imply that unless all traffic is sent over all links, there must exist rules in the multi-homed node that for each packet determine which network interface should be used to send the packet. This draft introduces filter rules as a mean for a multi-homed node to perform per flow interface selection. Per flow interface selection is typically needed when there exist multiple network interfaces, each with different network characteristics, and an application has specific performance requirements for a data flow that makes one network interface more suitable than another. This document proposes the use of OpenBSD Packet Filter [PF] syntax to describe the filtering rules used for per flow interface selection. The mechanism described in this document will be used by the mobile node to communicate preferred communication paths for IP data flows to its filtering peers. 1.1. Applicability The protocol proposed in this draft could be applied to either a multi-homed stationary or mobile node. A multi-homed stationary node would have at least one address assigned to each network interface. The filter rules could in this case be used for selecting the preferred network interface for an IP packet data flow. However, the primary usage for the filter rules, and the focus of this draft, is how to use filter rules for mobile nodes in the context of Mobile IP [RFC3775] [RFC3344] To identify a mobile node some kind of identity is used. One example of an identity would be the home address in Mobile IPv6 [RFC3775] and the Host Identity Tag (HIT) in HIP [I-D.ietf-hip-base]. Let us use the expression 'identity tag' as a name for this node identity. Additionally, the multi-homed node would have local interface addresses associated with each network interface. The binding between the identity tag and the local interface addresses is handled by mechanisms specific to each mobility management protocol (e.g. Mobile IPv6, Mobile IPv4, HIP). The primary use of flow filtering rules, as described in this document, is to specify separate communication paths for multiple flows which pass through or originate at one single node (such as for Larsson, et al. Expires April 26, 2007 [Page 3] Internet-Draft Monami6 Filter Rules October 2006 instance the HA in a Mobile-IP context) where the different flows have different requirements for bandwidth, latency, and QoS (quality of service). We will call the node which applies filtering to select the appropriate path for IP packets the 'Filtering Peer'. Flow filtering rules may however also be useful in other contexts, such as for instance between a moving multi-homed HIP-enabled node, when it has many sessions with different QoS requirements towards the same server. The name 'Filtering Peer' would refer to the server in this context. The proposed mechanism is agnostic with respect to the particular mobility management mechanism used, and could therefor be used not only for MIPv6, but also for other mobility management protocols, e.g., Mobile IPv4 [RFC3344], HIP [I-D.ietf-hip-base] and MOBIKE [RFC4555]. It is also IP version agnostic and works equally well for IPv4 and IPv6. The specific details of how the filter rule mechanism could be used for Mobile IPv6 is further detailed in the multiple care-of registration protocol [I-D.ietf-monami6-multiplecoa] together with [I-D.draft-kauppinen-monami6-binding-filter-rule]. Other mobility management protocols would need to write separate documents to outline how the filter rules are used with that specific mobility management protocol. 1.2. Terminology In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119]. This document frequently uses the following terms: Policy In the context of multi-access for mobile nodes, Policy is an overall information which govern how packets are forwarded from the mobile node to the intermediate node and the reverse path and from the mobile node to the destination node and the reverse path. Policy may cover such things as access network preferences, user and operator preferences, security restrictions, and more. Application of policy will in many cases result in definition of filter rules which implement the policy for specific traffic flows. Larsson, et al. Expires April 26, 2007 [Page 4] Internet-Draft Monami6 Filter Rules October 2006 Filter Rule A filter rule is a rule which specifies that traffic with certain characteristics is to be handled in a certain manner. As an example, a filter rule might specify that any traffic with destination port 80 should be sent out through a certain interface. In the context of multi-access IP mobility, a filter rule could be said to be composed of a match expression and a binding. The match expression defines which packets match the filter rule. The binding specifies the access at a specific point in time, which should be used for the matching packets. In order to be able to use filter rules in a multi-access mobility context without excessive overhead, it is advantageous to be able to define match functions and bindings separately, as it is expected that it may be necessary to update the bindings much more often than the match functions. If the binding is expressed in terms of a relation between filter interface ID and local address, the bindings can be updated on a handover to a new local address, while the match function does not need to change. Filter A filter is a collection of filter rules which is associated with a certain decision point in the IP stack, such as the point where a multi-access capable Mobile-IP implementation have to decide through which care-of address a packet should be routed. Filter Interface Identifier (FIID) A Filter Interface Identifier (FIID) identifies a virtual interface which is a possible exit point from a filter rule. A FIID is constructed by concatenating a name and a 16-bit unsigned integer value. The FIID is created by the mobile node and its uniqueness is guaranteed by associating it with the mobile node's identity tag. This procedure will ensure that two FIIDs sent to a filtering peer of the mobile node will not collide. Filtering Peer A filtering peer could be any node in the Internet that the mobile node decides to exchange filter rules with. In case of Mobile IPv6 the filtering peer is the intermediate node, i.e. the home agent, and it may also be the correspondent node. Larsson, et al. Expires April 26, 2007 [Page 5] Internet-Draft Monami6 Filter Rules October 2006 Identity Tag The identity tag is the identity at which the mobile node is addressable. One example of an identity tag would be the home address in Mobile IPv6 [RFC3775] and the Host Identity Tag (HIT) in HIP [I-D.ietf-hip-base]. 2. Architecture Overview When a mobile node has multiple addresses, either assigned to one interface or to different interfaces, the mobile node must have some additional internal information enabling it to make a decision of which address (i.e. network interface) to use for sending data packets. Additionally, in the case of Mobile IPv6, if the mobile node has registered multiple care-of addresses with its home agent or correspondent nodes, as proposed in [I-D.ietf-monami6-multiplecoa], there exist multiple paths between the mobile node and the home agent and the mobile node and the correspondent nodes. For the home agent and correspondent nodes to know which path to use for packets destined to the mobile node it would need additional internal information enabling it to choose a specific path. The term 'Policy' is often used to refer to the internal rules that would apply to the data packets. In this document the term 'Filter Rule' and 'Filter' are used to refer to the internal rules being applied to each data packet. When looking into the problem scope of setting up and exchanging policies and filters between nodes one realizes that it is possible and desirable to make a clear separation between the following actions: o Definition and exchange of policies. o Definition and exchange of filter rules. o Binding of filter rule to network interface. Figure 1 shows the suggested approach. There will be separate means for the exchange of policies and filter rules. This exchange may happen independently of a mobile node's movement. When a mobile node changes its current point of attachment to the Internet it will send binding information to the nodes concerned with its current location. The binding include information about the binding between filter interface ID and IP address. Larsson, et al. Expires April 26, 2007 [Page 6] Internet-Draft Monami6 Filter Rules October 2006 Initiator Responder +-------------+ +-------------+ | | Exchange of Policies | | | |<----------------------------->| | | | | | | | Exchange of Filter rules | | | |<----------------------------->| | | | | | | | Binding FIID <-> IP Address | | | |<----------------------------->| | +-------------+ +-------------+ Figure 1: Information exchange between initiator and responder By applying this approach we would achieve a clear separation between the definition and exchange of policies and filter rules, and the binding of a filter rule to an IP address. 2.1. Policy and Policy Exchange In the context of this document a policy is a high level information which governs how traffic is sent from/to a mobile node. The policy, in addition to other information (such as events, access network characteristics, etc.), would be input to a mobile node internal algorithm, which would generate a set of filter rules. The filter rules for a node specify the possible (virtual) output interfaces for packets sent out from the node. For each virtual output interface there must also exist a binding to a local IP address (Care-of Address in the MIP case) which completes the specification of how to route the packet if it matches the match expression in the filter rule. One could think of policies as describing the preferred actions that should be taken if certain conditions are fulfilled. E.g. a mobile node could have a policy that states that if WLAN is available then this interface is the preferred interface for sending HTTP traffic. If WLAN is not available then the 3G interface is the preferred interface for sending HTTP traffic. A policy could be installed at a node prior to delivery and/or it could be dynamically updated in runtime. Typically a node would have a set of static policies installed while others are dynamically installed when needed. Both the mobile node and the network side have interest in how policies are defined and applied. Consequently the policy exchange could be initiated by either the mobile node or the network side. Larsson, et al. Expires April 26, 2007 [Page 7] Internet-Draft Monami6 Filter Rules October 2006 Policies must be available in every node which is required to do specific filtering of data packets. In case of a mobile node it would be used to determine which interface to use for outgoing traffic. The specific means used for the exchange of policies is out of the scope of this document. 2.2. Packet Filter and Packet Filter Exchange PF ('Packet Filter') [PF] is OpenBSD's system for filtering TCP/IP traffic. Packet filters are widely used in the Internet and the OpenBSD PF specification exist as open source and has been used for deployment of packet filter implementations on several different platforms. The OpenBSD specification includes a rich set of functionality and offers great flexibility in the way packet filters are created. By using OpenBSD's PF syntax to define filter rules, all features already defined by OpenBSD can be utilized when defining filter rules for handling of simultaneous multi-access. The creation of filter rules is logically separated from mobility management since the creation of a new filter rule does not necessarily require any action from the mobility management protocol. E.g., an event, such as the opening of a socket, would trigger the creation of a new filter rule that identifies the flow. The internal binding of this filter rule to a specific network interface would not necessarily cause any binding update information to be sent by the mobile node. However, the mobile node would need to update the filter definition at nodes with which it is communicating. Typically, in the case of Mobile IPv6, it would be the home agent that needs to be updated. Since filter rule handling and mobility management are orthogonal it makes sense to use separate means for transferring of filter rules. The suggested approach will ensure that the mobility management protocol is not overloaded with tasks that it was not originally designed for. It will also make it possible to use the filter definition mechanism with any mobility management protocol, e.g., MIPv6 [RFC3775], MIPv4 [RFC3344], HIP [I-D.ietf-hip-base] and MOBIKE [RFC4555]. An additional benefit of having separate means for transferring of filter rules is that the solution proposed in this document is IP version agnostic and works equally well for IPv4 and IPv6. Larsson, et al. Expires April 26, 2007 [Page 8] Internet-Draft Monami6 Filter Rules October 2006 2.2.1. Creating Filter Rules How a Filter Rule is created is outside the scope of this document. For this document the assumption is that Filter Rules have been created based on existing policy, for instance as a result of an application opening a socket, and that the filter rule syntax is according to [PF]. 2.2.2. Changes to the Filter Rule The Packet Filter syntax includes the 'interface' parameter used for identification of the physical or virtual network interface that the IP data packet is being transmitted over. The interface name is specified as the name of the interface appended with an integer number, for instance 'fxp2'. By using virtual interfaces in the filter rule, a dynamic binding between the interface in the filter rule and the actual physical interface may be achieved. The Filter Interface Identifier (FIID) identifies a virtual interface, which is the exit point from a filter rule, and is in turn associated with a local physical interface and IP address, such as a MIP care-of address. 2.2.3. Filter Rule Identifier Syntax The FIID follows the same syntax as the 'interface' parameter in the filter rule syntax, i.e., the interface name consists of the name of the interface appended with an integer number. Accordingly, the proposed FIID syntax is as follows: fiid# where "fiid" is the name of the virtual interface and '#' is an integer number. The integer number is an unsigned integer generated by the mobile node. It MUST be unique within the mobile node and its uniqueness is preserved at the Filter Peer by being tied to the identity tag of the mobile node. 2.2.4. Storing Filter Rules All filter rules needed by the mobile node to handle simultaneous multi-access are stored as ASCII text. The collection of all filter rules constitute a Packet Filter specification. There is one filter specification generated for the mobile node and one filter specification generated for each filtering peer (e.g. in case of Mobile IPv6 it would be separate files for the home agent and the correspondent node(s)). The content of the filter specification for the filtering peer will often be a "mirrored" version of the file Larsson, et al. Expires April 26, 2007 [Page 9] Internet-Draft Monami6 Filter Rules October 2006 used by the mobile node. 2.2.5. Sending Filter Rule updates to the peer Each time a new filter rule is created, due to some event in the mobile node, the filtering peers MUST be updated. Section 3 outlines a filter rule transfer mechanism based on on the User Datagram Protocol (UDP). The UDP protocol is used to carry plain ASCII text Packet Filter rules with some meta information. The proposal is to send over the entire file when a filter rule is updated. It is assumed that the PF-file is limited in size and that the required update frequency is low. If these assumptions do not hold it would be possible to send only the modified parts of the file to the filtering peers. 2.3. Binding FIID to Physical Interface This draft does not attempt to specify how the FIID should be bound to a specific IP address. The reason for not doing this is that the binding depends on the mobility management protocol being used. One example of how this binding can be realized for Mobile IPv6 is described here. Figure 2 shows the relation between filter rule, FIID and Binding Unique Identifier (BID). There exist an internal node algorithm, which is outside the scope of this draft, that decides the binding between the FIID and the BID. This draft defines the filter rule syntax, the FIID syntax and the protocol for sending filter rules to the filtering peers. The specific protocol details of how the FIID, BID and care-of address are associated with each other is outlined in two separate drafts ([I-D.ietf-monami6-multiplecoa] and [I-D.draft-kauppinen-monami6-binding-filter-rule]). Larsson, et al. Expires April 26, 2007 [Page 10] Internet-Draft Monami6 Filter Rules October 2006 +---------------+ +-------+ +-------+ | Filter Rule 1 |---+--->| FIID1 |------->| BID 1 | +---------------+ | +-------+ +-------+ | +---------------+ | | Filter Rule 2 |---+ +---------------+ +---------------+ +-------+ +-------+ | Filter Rule 3 |------->| FIID2 |---+--->| BID 2 | +---------------+ +-------+ : +-------+ : +---------------+ +-------+ : +-------+ | Filter Rule n |------->| FIIDn |...+...>| BID n | +---------------+ +-------+ +-------+ Figure 2: Relation between filter rule, FIID and BID. Why having multiple level of indirections when mapping FIID to BID to CoA? The main motivation is that updates to the filter rules are independent of the bindings between a FIID and a BID. For instance, let's assume that there exist a set of filter rules as shown in Figure 2. If an event occurs in the mobile node that causes a new filter rule to be created this filter rule will specify that output will go to a FIID. If this FIID already exist, then a binding between the FIID and the BID also exist. As a result of creating this new filter rule the modified filter rule set must be sent to the filtering peer, however, the binding information does not need to be updated. Another example is when a physical interface is either added or removed. In this case the filter rules and the associated FIIDs are not updated. However, the binding between the FIIDs and the BID may need to be updated. If other mobility management protocols than Mobile IPv6 is preferred, e.g., HIP, a specific document would have to be written detailing how the FIID is bound to the specific mechanisms used in the mobility protocol to achieve simultaneous multi-access. 3. Protocol Definition This specification defines the protocol used for sending filter rules between the mobile node and its filtering peers. The filter rules are defined using the PF format, as defined in [PF]. The filter rules are stored in an ASCII file and sent to the filtering peer as payload to the User Datagram Protocol (UDP), as Larsson, et al. Expires April 26, 2007 [Page 11] Internet-Draft Monami6 Filter Rules October 2006 defined in [RFC0768]. The motivation for using the UDP protocol is that the application responsible for mapping of the fiid# to the actual physical network interface normally resides in user space. Another reason for using the UDP is that it's an IP version independent protocol. Although this draft is targeting simultaneous multi-access for IPv6 mobility management protocols there is no technical reason for limiting the transfer of filter rules to a specific IP version. 3.1. PF Message format The format of the UDP protocol with payload 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PF Payload ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP Fields: Source Port 16-bit unsigned integer. The Source Port is an optional field and indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted. Destination Port 16-bit unsigned integer. The receiving port. Port number is TBD. Length 16-bit unsigned integer. The length in octets of the user datagram including this header and the data, i.e., the minimum value of the length is eight. Larsson, et al. Expires April 26, 2007 [Page 12] Internet-Draft Monami6 Filter Rules October 2006 Checksum 16-bit unsigned integer. The UDP checksum. See [RFC2460]. PF Specification Fields: Option Type 8-bit unsigned integer. Indicates if this message is sent from the mobile node to update a filtering peer or if it's an acknowledgement of a previously sent Packet Filter update. 0 Packet Filter Update 1 Packet Filter Acknowledgement Status 8-bit unsigned integer. Indicates the disposition of the Packet Filter Update. Values of the Status field less than 128 indicate that the Packet Filter Update was accepted by the receiving node. Values greater than or equal to 128 indicate that the Packet Filter Update was rejected by the receiving node. The following Status values are currently defined: 0 Packet Filter Update accepted 128 Rejected, reason unspecified 129 Administratively prohibited 130 Packet Filter included syntax error 131 Mobile node not allowed to update Packet Filter Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. PF Payload ASCII text containing filter rules. The syntax is described in [PF]. 4. Protocol Operations This section describes how filter rules are sent from the mobile node to the filtering peers. Filter rules and the required mapping to an IP address is handled by the mobile node. How this is achieved is Larsson, et al. Expires April 26, 2007 [Page 13] Internet-Draft Monami6 Filter Rules October 2006 not within the scope of this draft. The assumption is that such a mapping exist and can be distributed by other means, e.g., for Mobile IPv6 as described in [I-D.draft-kauppinen-monami6-binding-filter-rule] and [I-D.ietf-monami6-multiplecoa]. 4.1. When to send a Packet Filter to a Filtering Peer There are several events that may trigger the creation of a new filter rule. For example when an application requests to open a socket an internal, node specific, algorithm detects this event and based on a set of parameters, such as available network interfaces, network interface characteristics, policies, etc., a filter rule is created. The filter rule specifies to which FIID output is sent. In case of Mobile IPv6, a binding to a BID is created. There may be other events that causes a filter rule to be created. However, when a new filter rule has been created this information needs to be sent to the filtering peers to make sure that these nodes knows which destination address to use in the case when there exist multiple local addresses associated with the mobile node's identity tag. 4.2. Packet Filter Content When sending the Packet Filter specification to the filtering peers there are two options. Either the entire file or a delta could be sent. In the case when a delta is sent only the filter rules that have been created or deleted since the last update needs to be sent. This specification suggests that the entire Packet Filter file is sent each time an update is required. By sending the entire Packet Filter file to the filtering peer there is no need to specify specific protocol behavior for how to add, modify and refresh filter rules. The approach taken in this specification could be further optimized in later revisions if needed. The suggested proposal would be simple but in case of frequent filter updates it would also generate extra traffic. At this stage it is not assumed that sending frequent updates of the packet filter would be needed. However, if this assumptions turns out to be wrong there is always the opportunity to optimize the Packet Filter updates. This optimization could consist of sending the delta in relation to a previous Packet Filter update. This optimization would lead to a more complex protocol, with state and synchronization requirements, but would on the other hand generate less traffic. Larsson, et al. Expires April 26, 2007 [Page 14] Internet-Draft Monami6 Filter Rules October 2006 4.3. Sending Packet Filter Update To add a new or update an existing Packet Filter specification at a filtering peer the multi-homed node sets the Option Type to 0 (Packet Filter Update), the Status field is cleared and the Payload field includes the entire Packet Filter specification. The Length field is set to the actual length (in octets) of the UDP packet, i.e. including the UDP header and the data following the UDP header. To remove an existing Packet Filter at a filtering peer the multi- homed node sets the Option Type to 0 (Packet Filter Update), the Status field is cleared and the Payload field is empty. The Length of the UDP header is set to twelve. 4.3.1. Retransmission If the multi-homed node fails to receive a valid matching response within the selected initial retransmission interval (INITIAL_PFU_TIMER), the multi-homed node SHOULD retransmit the message until a response is received. The retransmissions by the multi-homed node MUST use an exponential back-off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_PFUACK_TIMEOUT. The multi-homed node MAY continue to send these messages at this slower rate indefinitely. If the status code indicates that a Packet Filter Update was rejected it may be possible to resend the Packet Filter Update after appropriate modifications of the specification. The decision on whether a Packet Filter should be modified and resent or if no further actions are taken is a node internal issue and not specified in this draft. 4.3.2. Filtering Peer node types Depending on the filtering peer node type either the entire Packet Filter specification or relevant parts of the specification is sent to the node. An example is Mobile IPv6 where the Home Agent needs the full set of filter rules even though route optimization is used between the mobile node and some or all of its correspondent nodes. The reason for sending the entire set of filter rules to the home agent is that the return routability procedure may fail and then the traffic would by default be routed through the home agent. The correspondent node would not require all filter rules from the mobile node. Instead, the relevant filter rules which apply to the specific correspondent node, would be enough. Larsson, et al. Expires April 26, 2007 [Page 15] Internet-Draft Monami6 Filter Rules October 2006 As long as a mobile node only has traffic with the same bandwidth, latency and QoS requirements, there is no need for filters at the correspondent node at all. 4.4. Receiving Packet Filter Update Upon receiving a packet carrying a Packet Filter Update the packet MUST be validated according to the following tests: If the 'Length' field is greater than 12 then the content of the 'PF Payload' field is added as Packet Filter information for the multi- homed node. If the 'Length' field is equal 12 then the any existing filter specifications for the mobile node MUST be removed. When no filter rule specifications are available normal processing of the packets will be performed, i.e. there will be no support for simultaneous multi-access 4.4.1. Packet Filter Lifetime There is no timer associated with the Packet Filter specification defining how long time the specification is valid. Instead, it's assumed that the specification is stored at the destination node as long as this node has ongoing communications with the multi-homed node. 5. Protocol Constants INITIAL_PFU_TIMER 3 seconds MAX_PFUACK_TIMEOUT 48 seconds 6. IANA considerations This document requires the following new number assignments from IANA: UDP Destination Port number This document also defines two message types: 0 Packet Filter Update 1 Packet Filter Acknowledgement Larsson, et al. Expires April 26, 2007 [Page 16] Internet-Draft Monami6 Filter Rules October 2006 Finally, this document creates a third new name space "Status Code" for the Status field in the Packet Filter Acknowledgement message. The following values have been defined: 0 Packet Filter Update accepted 128 Rejected, reason unspecified 129 Administratively prohibited 130 Packet Filter included syntax error 131 Mobile node not allowed to update Packet Filter 7. Security Considerations The transport used to exchange the flow distribution policy MUST be secured to the same extent as the binding updates, and preferably using the same security association. 8. References 8.1. Normative References [I-D.draft-kauppinen-monami6-binding-filter-rule] Kauppinen, T., "Filter Rule Identifier Binding in Mobile IPv6", draft-kauppinen-monami6-binding-filter-rule (work in progress), June 2006. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006. [PF] "PF: The OpenBSD Packet Filter", May 2006, . [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 (work in progress), June 2006. Larsson, et al. Expires April 26, 2007 [Page 17] Internet-Draft Monami6 Filter Rules October 2006 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. Authors' Addresses Conny Larsson Ericsson AB Torshamnsgatan 23 Stockholm S-164 80 SWEDEN Phone: +46 8 404 8458 Email: conny.larsson@ericsson.com Henrik Levkowetz Ericsson AB Torsgatan 71 Stockholm S-113 37 SWEDEN Phone: +46 708 32 16 08 Email: henrik@levkowetz.com Heikki Mahkonen Oy L.M. Ericsson Hirsalantie 11 Jorvas FI-02420 Finland Phone: +358 9 299 3213 Email: heikki.mahkonen@ericsson.com Larsson, et al. Expires April 26, 2007 [Page 18] Internet-Draft Monami6 Filter Rules October 2006 Tero Kauppinen Oy L.M. Ericsson Hirsalantie 11 Jorvas FI-02420 Finland Phone: +358 9 299 3057 Email: tero.kauppinen@ericsson.com Larsson, et al. Expires April 26, 2007 [Page 19] Internet-Draft Monami6 Filter Rules October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Larsson, et al. Expires April 26, 2007 [Page 20]