Network Working Group T. Kauppinen Internet-Draft H. Mahkonen Expires: April 19, 2007 M. Kuparinen C. Larsson H. Levkowetz Ericsson AB October 16, 2006 Filter Interface Identifier Binding in Mobile IPv6 draft-kauppinen-monami6-binding-filter-rule-00.txt 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 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Mobile nodes using more than one interface for communicating with other nodes in the network need a mechanism that controls how these interfaces are used. One way of controlling the interface usage is to define rules that map flows to network interfaces. These rules can also be called filter rules that are bound to Filter Interface Kauppinen, et al. Expires April 19, 2007 [Page 1] Internet-Draft BFIID October 2006 Identifiers. This document describes a mechanism to associate Filter Interface Identifiers with the current location information of a mobile node in case when the mobility protocol used by the mobile node is Mobile IPv6. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Additions to BID Sub-option . . . . . . . . . . . . . . . . . 7 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Filter Interface Identifier Binding . . . . . . . . . . . 10 5.1.1. Sending FIID Bindings in a Binding Update . . . . . . 10 5.1.2. Receiving FIID Bindings in a Binding Update . . . . . 11 5.1.3. Creating and updating FIID Bindings . . . . . . . . . 12 5.1.4. Removing FIID Bindings . . . . . . . . . . . . . . . . 12 5.1.5. Error Handling in FIID Bindings . . . . . . . . . . . 13 5.1.6. Storing FIID Bindings . . . . . . . . . . . . . . . . 13 5.2. Binding an FIID to multiple BIDs . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Kauppinen, et al. Expires April 19, 2007 [Page 2] Internet-Draft BFIID October 2006 1. Requirements notation 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]. Kauppinen, et al. Expires April 19, 2007 [Page 3] Internet-Draft BFIID October 2006 2. Introduction A Mobile Node (MN) is said to be simultaneous multiaccess capable if it can attach to the Internet with several network interfaces at the same time. In addition, the MN might have a need to route different traffic flows trough different network interfaces simultaneously. The Filter Rules draft [4] describes a way to perform flow distribution between multiple interfaces of an MN. It describes how a traffic flow can be represented by using the OpenBSD Packet Filter syntax. The syntax is used to define rules called Filter Rules that bind a flow to a Filter Interface Identifier (FIID). The functionality specified in the draft is designed to be mobility protocol independent and it therefore lacks details how to bind FIIDs to network interfaces. The Multiple Care-of Address (MCoA) draft [3] presented in the Monami6 WG adds support for Mobile IPv6 [2] MNs to register multiple CoAs for a single Home Address (HoA). The draft specifies a Binding Unique Identifier (BID) which is used to uniquely identify a single CoA. The BID can be reused when the MN performs a handover and the CoA associated with the BID is changed. The BID can also be used to remove the CoA from Mobile IPv6 data structures if the CoA is no longer configured on any of the MNs network interfaces. The association between a CoA and a Filter Rule is done by using the BID of the CoA [3] and the FIID of the Filter Rule [4]. This document describes how FIID to BID associations are distributed in the Binding Update (BU) message inside a BID sub-option that has the additional fields for FIIDs. Figure 1 shows how different entities are related to each other. It also shows where these entities are defined. This document defines the association between the FIID ([4]) and the BID ([3]) entities. Kauppinen, et al. Expires April 19, 2007 [Page 4] Internet-Draft BFIID October 2006 MN Filter MN FIIDs BUL/BC HA FIIDs HA Filter +-------+ +-------+ |Rule 1 |---+ +-------+ +---------+ +-------+ +---|Rule 1 | +-------+ +--| fiid1 |--|BID1 CoA1|--| fiid1 |--+ +-------+ |Rule 2 |--+ +-------+ +---------+ +-------+ +--|Rule 2 | +-------+ | +-------+ +---------+ +-------+ | +-------+ |Rule 3 |--+---| fiid2 |--|BID2 CoA2|--| fiid2 |---+--|Rule 3 | +-------+ +-------+ +---------+ +-------+ +-------+ | ... | +-------+ +---------+ +-------+ | ... | +-------+ +--| fiidN |--|BIDn CoAN|--| fiidN |--+ +-------+ |Rule n |---+ +-------+ +---------+ +-------+ +---|Rule n | +-------+ +-------+ <----------------------> <---------> Filter Rule [4] MCoA [3] <--> This document Figure 1: Overview of Filter Interface Identifier Binding in Mobile IPv6 The solutions described in [4] and in this document enable one FIID (Filter Rule) to be mapped to one or more BIDs (one or more CoAs) or several FIIDs to be mapped to one BID. Therefore, bi-casting and load balancing functionality for the MN must also be considered. In addition, the mechanism supports also bulk registration, i.e. sending more than one flow binding in a single BU, with the home agent (HA) and the correspondent node (CN). The importance of the bulk registration with both the HA and the CN is pointed out in [5]. Kauppinen, et al. Expires April 19, 2007 [Page 5] Internet-Draft BFIID October 2006 3. Terminology Binding Unique Identification number (BID) Binding Unique Identifier (BID) identifies a binding between a HoA and a CoA. The BID is used when multiple CoAs are bound to a single HoA. These bindings can be referenced with a BID. The BID is specified in [3]. Filter Rule Filter Rule distinguishes a traffic flow from one node to another. A traffic flow is typically defined by the source and destination addresses and ports and the used protocol. The Filter Rule creation and distribution is specified in [4]. Filter Interface Identifier (FIID) A Filter Interface Identifier (FIID) identifies a Filter Rule. The creation of FIIDs is described in [4] whereas this document describes a way to associate FIIDs with BIDs [3]. This association is called an FIID binding. Kauppinen, et al. Expires April 19, 2007 [Page 6] Internet-Draft BFIID October 2006 4. Additions to BID Sub-option The Binding Unique Identifier sub-option is added into a BU message by an MN when it is registering new CoAs with its HA or CNs [3]. This section proposes a few modifications to the BID sub-option in order to support FIID bindings. The sub-option is extended by adding a new field and introducing two new flags which are allocated from the Reserved field. The size of the Reserve field is therefore reduced by two bits. 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 = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Unique ID (BID) |Priority/Status|C|R|D|F| Res. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Address (CoA) + | | +---------------------------------------------------------------+ | Filter Interface ID 1 | FIID2 | +---------------------------------------------------------------+ ... +-------------------------------+ + FIIDN | +-------------------------------+ Type Type value for Filter Rule Identifier sub-option will be assigned later. Length Length value is 4+N*2 when the C flag is unset. Length value is 20+N*2 when the C flag is set. N is the number of included FIIDs. Binding Unique ID (BID) The BID which is assigned to the binding carried in the BU with this sub-option. BID is 16-bit unsigned integer. A value of zero is reserved. Kauppinen, et al. Expires April 19, 2007 [Page 7] Internet-Draft BFIID October 2006 Priority/Status When the Binding Unique Identifier sub-option is included in a Binding Update, this field indicates the priority field assigned to each binding. The receiver can utilize this priority to determine which binding is used to deliver packets. The priority is 8-bit unsigned integer. A value of zero indicates No Priority. The higher value has higher priority. When the Binding Unique Identifier sub-option is included in a Binding Acknowledgment, this field indicates the status correspondent to each binding in a bulk registration mode. The mobile node can know the registration status of each binding. The status is 8-bit unsigned integer. The possible status codes are listed below. If the status field is below 128, it indicates that the binding registration was successful. ACCEPTING BID SUB-OPTION (0) The registration of the correspond binding is successfully operated. INCOMPLIANT BID SUB-OPTION (128) Registration failed because Binding Unique Identifier sub- option is not compliant ([3]). UNKNOWN FIID (129) Flow binding failed because no filter rule matching the specified FIID exists. Filter Interface Identifier (FIID) A set of Filter Interface Identifiers (here 16 bits are used for a single FIID). Delete (D) flag When set, this flag indicates that bindings for specified FIIDs MUST be removed. The MN can use this flag to remove binding for a specific FIID or FIIDs. If the D flag is set then the F flag MUST NOT be set. Kauppinen, et al. Expires April 19, 2007 [Page 8] Internet-Draft BFIID October 2006 Flush All (F) flag When set, this flag indicates that all existing FIID bindings for a specific BID MUST be removed prior to adding listed FIIDs. The MN can use this flag to quickly substitute all existing bindings for a specific BID with specified FIIDs. If the F flag is set then the D flag MUST NOT be set. Res. 4 bits Reserved field. Reserved field must be set with all 0. It should be noted that both the D flag and the F flag MUST NOT be set at the same time. Use of these flags is further described in Section 5.1.1 and Section 5.1.4. Kauppinen, et al. Expires April 19, 2007 [Page 9] Internet-Draft BFIID October 2006 5. Protocol Overview This section describes how FIID bindings are maintained and managed. FIID bindings are sent inside the BID sub-option which is included in the Binding Update message. Binding Update messages are sent when the Mobile Node changes its location in the network or when FIIDs are created or removed. 5.1. Filter Interface Identifier Binding A Mobile Node (MN) creates and distributes Filter Rules with the described in [4]. When the MN creates a Filter Rule it binds the rule to an Filter Interface Identifier (FIID). This FIID must also be associated with a network interface. The MCoA draft [3] describes how multiple Care-of Addresses (CoAs) can be associated with a Home Address by defining a Binding Unique Identifier (BID). In this document we refer to a network interface with one of its CoAs. Therefore the association between the FIID and the BID effectively creates a binding between a FIID and a network interface. This binding is called a Filter Interface Identifier Binding or an FIID binding. 5.1.1. Sending FIID Bindings in a Binding Update When an MN is sending a normally scheduled BU message it MUST check if the message is going to be sent to the Home Agent (HA) or the Correspondent Node (CN). In addition, the MN checks if the CoAs which are being registered in the BU message have FIID bindings which has not yet been sent to the peer node (HA or CN). If the peer node is an HA of the MN it must always have all the FIID bindings up to date. If the peer node is a CN only the FIID bindings used between these nodes need to be up to date. FIID bindings are added to the BU message inside a BID sub-option which is described in the MCoA draft [3]. The additional fields to carry FIIDs in BID sub-option are described in Section 4. Each FIID which is associated with a specific BID MUST be added into a BID sub- option carrying the BID in question. This means that the same FIID MAY be added into more than one BID sub-option and that one BID sub- option MAY hold more than one FIID. If an MN creates a new FIID it MUST be sent to the peer nodes even if the MN has no normally scheduled BU messages. For this purpose the MN sends an unscheduled BU message which contains all the BIDs in BID sub-options which are associated with the new FIID. In this case it's possible to leave the CoAs out of the BID sub-options because the receiver is already aware of the BID to CoA mapping. Kauppinen, et al. Expires April 19, 2007 [Page 10] Internet-Draft BFIID October 2006 The MN MAY have a need to update (remove/replace) several BIID bindings in one BU message. The MN can use the D and F flags in the BID sub-option (Section 4) to manage these simultaneous updates. Use of the D flag is described in Section 5.1.4. The D flag is used to remove specific BIID bindings from a specific BID. It should, however, be noted that both the D flag and the F flag MUST NOT be set at the same time. The F flag can be used to replace all BIID bindings for a specific BID with a set of new ones. When the F flag is set in the BID sub- option all existing BIID bindings MUST BE removed prior to adding new bindings. If the F flag is not set in the BID sub-option, BIID bindings MUST be appended to the set of existing BIID bindings for the specified BID. 5.1.2. Receiving FIID Bindings in a Binding Update When a node receives a BU message containing BID sub-option(s) which carry a number of FIIDs it MUST first proceed with the normal processing of BID sub-options [3]. It MUST then check that the FIIDs included in the sub-options are known to the node. If an FIID is known to the node it associates the FIID with the specified BID. If the FIID is unknown, the node MUST inform this to the MN by adding the unknown FIID into a BID sub-option. The BID sub-option is added into a Binding Acknowledgement (BA) message that is sent in reply to the BU sent by the MN. Because the mechanisms described in [3] and in this document MUST be compliant with legacy MIPv6 nodes the receiver of a BU message MUST reply with a BA message which contains at least one BID sub-option. The existence of the BID sub-option in the BA message indicates that the peer node (HA or CN) is MCoA and FIID compliant. If the BA message contains no BID sub-options the MN MUST assume that the peer node does not support MCoA and FIID binding mechanisms. In this case the MN MUST NOT send BID sub-options to this peer node and therefore FIID bindings cannot be made. If the peer node supports only the MCoA mechanism and not the FIID binding mechanism a BID sub-option which includes one or more FIIDs will result to an error. This is due to the fact that valid lengths of the BID sub-option specified in [3] are either 4 or 20 depending on the state of the C flag. However, the BID sub-option specified in this document has the length of 4+N*2 when the C flag is unset and 20+N*2 when the C flag is set. In the case when the peer node receives a BID sub-option which is of invalid size, it should reply with an error. This error will be signaled inside a BID sub-option to the MN. In this case the MN MUST NOT resend FIID bindings in the BID sub-option for this peer node. Kauppinen, et al. Expires April 19, 2007 [Page 11] Internet-Draft BFIID October 2006 5.1.3. Creating and updating FIID Bindings FIID bindings on the node receiving the BU can be created and updated by including FIID in the BID sub-options. If either the D nor the F flag is set, FIID listed in the BID sub-option are appended to the list of existing FIID bindings for the specified BID. If the F flag is set, the current list of FIID bindings for the specified BID is purged prior to adding listed FIID bindings. The FIID(s) SHOULD NOT be added into the BID option every time BU message is sent because the MCoA draft [3] describes a way to reuse the BID when the CoA referenced with it changes. Normally the traffic flows of the MN remain the same even when the MN moves between attachment points to the Internet. Therefore the MN does not have to update FIID bindings after every handover. The association between BID(s) and FIID(s) MUST be updated only if either FIIDs or BIDs are added or removed. 5.1.4. Removing FIID Bindings There are a few cases that result in FIID bindings being removed. An FIID binding can either be removed explicitly or implicitly, i.e. as a result of another action. FIID bindings, for example, do not have a timer of their own but their existence is limited to the existence of the filter rule and the BID they are linked to. When a filter rule is removed, either due to a timeout or a delete command, the FIID binding will be removed only if there are no other filter rules associated with it. Filter rule timeout issues are handled via the filter rule management [3]. If a BID is removed, all FIID bindings to the BID in question MUST also be removed. It should, however, be noted that removing an FIID binding does not necessitate the removal of the FIID (and the filter rule) it's linked to. An FIID (and the filter rule) can exist without being associated with any of the BIDs. In this case a default binding should be used. The default binding is set by using the Priority field of the BID sub-option [3]. However, if a BID which is associated with a disabled FIID binding(s) is removed, the disabled FIID binding(s) is/are also removed (Section 5.1.5). The final case that results in FIID bindings being removed is when either D or F flag is specified in the BID sub-option. If the D flag is specified, the FIID bindings listed in the sub-option are removed. In the case the F flag is set, all existing FIID bindings for a specific BID are removed prior to adding any of the new FIID bindings. Kauppinen, et al. Expires April 19, 2007 [Page 12] Internet-Draft BFIID October 2006 5.1.5. Error Handling in FIID Bindings If the MN sends an FIID to a peer node in the BID sub-option which does not match with any of the Filter Rules the peer node has, the peer node must signal this error case to the MN. The peer node might not have the Filter Rule because the Filter Rule might have expired or the Filter Rule distribution might have failed. In either case the peer node must signal the MN that the Filter Rule is not present at the peer node which means that the MN SHOULD not expect the peer node to direct the matching traffic flows to the CoA associated with the Filter Rule. The peer node adds the erroneous FIIDs into a BA message which is sent to the MN in reply to the received BU message. The Status fields in BA message header and BID sub-option must be used to indicate an error in the FIID to the MN. To indicate the error in the FIID a new status field value must be defined Section 4. Even if the peer node could not match the FIID with any of the Filter Rules it has it SHOULD add the FIID binding but disabled it. This would make the FIID binding not to be useable until the corresponding Filter Rule is received. This way the MN does not have to resend the FIID binding after the Filter Rule has been sent to the peer node. There SHOULD be a timer which expiration would trigger a removal of disabled FIID bindings. When an MN receives a BA message containing one or more BID sub- options indicating the FIID(s) carried in the option were erroneous it should check that these Filter Rules are still present. If the MN has the associated Filter Rule(s) it must distribute these Filter Rules to the peer node. If the MN does not have these Filter Rules anymore it SHOULD send a BU message to remove the disabled FIID binding sent in the first BU message. If the MN chooses not to send a new BU message to remove the disabled FIID bindings the expiration timer will eventually trigger the removal of these bindings. 5.1.6. Storing FIID Bindings The actual location to store FIID bindings is outside the scope of this document and is considered as an implementation specific detail. It can be done by adding FIID to the Binding Cache or Binding Update List [2] or by maintaining a pointer in the Filter Rule database entry which points to a right BC/BUL entry etc. It is however important that each Filter Rule is matched with an IP address which should be used for the traffic flow matching the rule. Kauppinen, et al. Expires April 19, 2007 [Page 13] Internet-Draft BFIID October 2006 5.2. Binding an FIID to multiple BIDs This document does not limit the number of BIDs an single FIID is bound to. If an FIID is bound to multiple BIDs, however, a mechanism to determine which of the BIDs to choose in any particular case must then be applied. This feature enables such functionality as load balancing and bi-casting. However, these topics are outside the scope of this document. Kauppinen, et al. Expires April 19, 2007 [Page 14] Internet-Draft BFIID October 2006 6. Security Considerations The mechanism described in this document uses the same security as the Binding Update. It can therefore be used to prevent rogue nodes from providing false FIID binding information to the HA and/or CN. Kauppinen, et al. Expires April 19, 2007 [Page 15] Internet-Draft BFIID October 2006 7. IANA Considerations None. Kauppinen, et al. Expires April 19, 2007 [Page 16] Internet-Draft BFIID October 2006 8. Conclusions This document describes a mechanism to associate Filter Interface Identifiers (FIIDs) of the Mobile Node ([4]) with Binding Unique Identifiers (BIDs) [3]. This is achieved by extending the BID sub- option to carry an FIID in order to create an association, which in this document is called an FIID binding. The design in this document makes it possible to transfer Filter Rules independently of Mobile IPv6 signaling, which is of interest in order to widen the applicability of the mechanism. Kauppinen, et al. Expires April 19, 2007 [Page 17] Internet-Draft BFIID October 2006 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 9.2. Informative References [3] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006. [4] Larsson, C., "A Filter Rule Mechanism for Multi-access Mobile IPv6", draft-larsson-monami6-filter-rules-00 (work in progress), June 2006. [5] Kuparinen, M., "Multiple CoA Performance Analysis", draft-kuparinen-monami6-mcoa-performance-00 (work in progress), April 2006. Kauppinen, et al. Expires April 19, 2007 [Page 18] Internet-Draft BFIID October 2006 Authors' Addresses Tero Kauppinen Ericsson AB Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 299 3057 Email: tero.kauppinen@ericsson.com Heikki Mahkonen Ericsson AB Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 299 3213 Email: heikki.mahkonen@ericsson.com Martti Kuparinen Ericsson AB Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 299 2191 Email: martti.kuparinen@ericsson.com Conny Larsson Ericsson AB Torshamnsgatan 23 Stockholm S-164 80 Sweden Phone: +46 8 404 8458 Email: conny.larsson@ericsson.com Kauppinen, et al. Expires April 19, 2007 [Page 19] Internet-Draft BFIID October 2006 Henrik Levkowetz Ericsson AB Torshamnsgatan 71 Stockholm S-113 37 Sweden Phone: +46 708 32 16 08 Email: henrik@levkowetz.com Kauppinen, et al. Expires April 19, 2007 [Page 20] Internet-Draft BFIID October 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kauppinen, et al. Expires April 19, 2007 [Page 21]