MEXT Working Group M. Eriksson Internet-Draft C. Larsson Intended status: Standards Track Ericsson Research Expires: December 21, 2008 R. Kuntz Louis Pasteur University June 19, 2008 Mobile IPv6 Flow Routing over Multiple Care-of Addresses draft-eriksson-mext-mipv6-routing-rules-00 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 December 21, 2008. Abstract This document specifies a mechanism to selectively route IP flows to and from Mobile IPv6 Mobile Nodes and NEMO Mobile Routers which have registered multiple care-of addresses. It explains how to apply the generic flow distribution language defined in a companion draft to Mobile IPv6, defines a transport mechanism to transmit the rules between Mobile IPv6 nodes, and describes how the rules are sent and handled upon reception. Eriksson, et al. Expires December 21, 2008 [Page 1] Internet-Draft MIPv6 Flow Routing June 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Application of the Flow Rule Language . . . . . . . . . . . . 4 3.1. Identity Tag . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Local Node . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Peer Node . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. The Path Identifier . . . . . . . . . . . . . . . . . . . 4 3.5. Rules and Binding Identifiers . . . . . . . . . . . . . . 4 4. Transmission of Flow Rules . . . . . . . . . . . . . . . . . . 5 4.1. Flow Rules Update Request . . . . . . . . . . . . . . . . 5 4.2. Flow Rules Update Acknowledgement . . . . . . . . . . . . 6 5. Endpoints Operations . . . . . . . . . . . . . . . . . . . . . 7 5.1. Sending Rules . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 8 6. Mobile Node Routing Controlled By Home Agent . . . . . . . . . 8 7. Rules and Bindings Independence . . . . . . . . . . . . . . . 9 8. Routing Rules Lifetime . . . . . . . . . . . . . . . . . . . . 9 9. Support for dual-stack MIPv6 . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Eriksson, et al. Expires December 21, 2008 [Page 2] Internet-Draft MIPv6 Flow Routing June 2008 1. Introduction The Multiple Care-of Registration Mechanism [7] makes it possible for Mobile IPv6 [3] Mobile Nodes and NEMO [4] Mobile Routers to register more than one care-of address. The care-of addresses can be from different network interfaces, then enabling concurrent traffic over more than one access network. It is also possible to register multiple care-of addresses from the same network interface (presumably with different network prefixes), allowing the use of more than one network path to the same interface. Goals and motivations to use multiple concurrent paths are further investigated in [6]. A Mobile Node or Mobile Router can decide for itself what outgoing interface and care-of address to use for each flow. For incoming traffic, it has to instruct its Home Agent and Corresponding Nodes which of its care-of addresses to use for different incoming flows. In some cases, it might also be useful to have the Home Agent influence or control what interfaces and care-of addresses that the Mobile Node or Mobile Router should use for outgoing traffic. It is thus necessary to be able to transport a set of routing rules between Mobile IPv6 nodes. This specification describes a mechanism to control which IP traffic goes over what path, i.e., to and from what care-of address. It also describes how the rules are transmitted between the network nodes (Mobile Node or Router, Home Agent and Correspondent Nodes). The paths to use for different flows are selected using the Flow Distribution Rule Language for Multi-Access Nodes [5]. The application of the rule language to Mobile IPv6 is described in Section 3. The rules are transmitted in MIPv6 Generic Notification Messages [2], see Section 4. How those rules are sent and handled upon reception is described in Section 5. It is also possible for the Home Agent to instruct the Mobile Node what care-of address to use for outgoing traffic, as described in Section 6. The main advantages of the proposed solution are the separation of rule updates from the handover management, and the possibility to send rules in a bidirectional manner. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Eriksson, et al. Expires December 21, 2008 [Page 3] Internet-Draft MIPv6 Flow Routing June 2008 document are to be interpreted as described in RFC 2119 [1]. 3. Application of the Flow Rule Language The routing of each IP flow is specified with rules written in the Flow Distribution Rule Language for Multi-Access Nodes [5], which is a generic language for path selection for multi-access nodes. This section describes how it is applied to MIPv6. 3.1. Identity Tag The "Identity Tag" is the Home Address of the Mobile Node or the prefix of the Mobile Network. It is derived implicitly from the header of the Flow Rules Update Request message (see Section 4.1), which is always sent in the context of an existing binding. 3.2. Local Node The rule language's "Local Node" maps to the MIPv6 Mobile Node. When a rule refers to "local", it implies checking the selector (port numbers, etc.) of the Mobile Node. A Mobile Router MAY specify separate handling for parts of its Mobile Network by giving an address prefix after the "local" keyword in some rules. A Mobile Node MUST NOT specify an address prefix after the "local" keyword. 3.3. Peer Node "Peer Node" maps to the MIPv6 Correspondent Node. Selectors for the "peer" side will thus always match the address, port number, etc., of the Corresponding Node. 3.4. The Path Identifier The target of the flow distribution rules is a Path Identifier. For MIPv6, the Path Identifier is identical to the Binding Identifier [7]. 3.5. Rules and Binding Identifiers A rule that refers to an unknown binding identifier MUST be ignored. This allows for "opportunistic" rules, which will route some traffic over a particular binding, when it is available. The rule language's support for conditional rule sets MAY be used as a more expressive way to have "adaptive" rules. Eriksson, et al. Expires December 21, 2008 [Page 4] Internet-Draft MIPv6 Flow Routing June 2008 A flow that does not match any rule MUST be forwarded over the care-of address that has the lowest numbered binding identifier. Rule generators SHOULD NOT rely on this fact, but instead use match- all rules to explicitly select a path for all flows. 4. Transmission of Flow Rules Flow routing rules signaling is transmitted in Generic Notification Messages [2] (GNM). A separate GNM sub-type is used for update requests, and the regular GNM Acknowledgement sub-type is used for acknowledgments. The use of GNM, and thereby the MIPv6 Mobility Header, puts a limit on the total size of the rules. The Header Len field of the Mobility Header is only 8 bits wide. As this field represents the message length in units of 8 octets (excluding the first 8 octets), the maximum length of an MH message is 2048 octets. After adjusting for the size of the MH and GNM headers, the maximum size of the rules are 2036 octets. If this shows to be too small, a way to extend the maximum size of GNM messages should be developed. 4.1. Flow Rules Update Request The rules for flow routing are transferred as a string of ASCII characters, according to the syntax in [5]. The string MUST be padded with spaces (ASCII 32) to have a length that is an even multiple of 8 octets. The Flow Rules Update Request uses the sub-type value (TBD). When this value is indicated in the Sub-Type field, the format of the Sub- Type specific data field in the Generic Notification message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Flow Distribution Rules . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Eriksson, et al. Expires December 21, 2008 [Page 5] Internet-Draft MIPv6 Flow Routing June 2008 Sequence Number A 16-bit unsigned integer used by the receiving node to sequence requests and by the sending node to match a returned Generic Notification Acknowledgement with this Flow Rules Update Request. The Flow Rules Update Request uses the same Sequence Number counter as the Generic Notification Request sub-type. Acknowledge (A) The Acknowledge (A) bit is set by the sender to request a Generic Notification Acknowledgement (see Section 4.2) be returned upon receipt of a Flow Rules Update Request. Reserved This field is unused. It MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Flow Distribution Rules A string of ASCII characters, containing rules for flow distribution in the format described in [5]. A Flow Rules Update Request message MUST NOT have any mobility options. 4.2. Flow Rules Update Acknowledgement A Flow Rules Update Request is acknowledged with a regular Generic Notification Acknowledgement sub-type message. The sequence number in the Generic Notification Acknowledgement is copied from the sequence number field in the Flow Rules Update Request. It is used by the receiving node in matching this Generic Notification Acknowledgement with an outstanding Flow Rules Update Request. In addition to the Status values defined for Generic Notification Acknowledgement in [2], the following Status values are defined for an acknowledgement of a Flow Rules Update Request: (TBD) The recipient failed to parse the rules Eriksson, et al. Expires December 21, 2008 [Page 6] Internet-Draft MIPv6 Flow Routing June 2008 5. Endpoints Operations 5.1. Sending Rules The defined rules are sent to a remote node using the Flow Rules Update Request message defined in Section 4.1. Each time the rules need to be updated in the remote node, the originating node sends the whole new set of rules, even if some of them have already been sent in a previous request message. This is because the remote node always delete the previously installed rules and install the whole new set of rules. Though this might seem redundant, this is a much simpler mechanism than an incremental solution. Thanks to the conditional rule sets in the rule language [5], rules updates can often be avoided. Incremental rule updates may be introduced as a future enhancement, if experience shows that they would be useful. The originating node sets the Acknowledge bit if it wishes to receive a Generic Notification Acknowledgement message from the remote node. When set, the node MUST follow the retransmission rules defined in [2]. If a Mobile Node or Mobile Router does not receive any acknowledgment message from a Home Agent after MAX_MH_NOTIFICATION_TIMEOUT (defined in [2]), it MAY try to register to another Home Agent. In any case, it MUST suppose that the rules were not installed on the remote node. Upon reception of a Generic Notification Acknowledgement message from a remote node, the originating node first checks that the sequence number set in the message matches the one set in the previously sent request. If it does not match, it silently drops the acknowledgment message and keep trying to send request messages. If the sequence number matches, it stops trying to send request messages to the remote node and processes the message as described hereinafter. If the status is set to "0 Notification Request accepted" (as defined in [2]), the originating node assumes that the rules have been correctly processed and installed by the remote node. If the status is set to 128, 129, 130, 131, or 132 (as defined in [2]), it stops sending request messages and MAY try to register to another Home Agent. In any case, it MUST suppose that the rules were not installed on the remote node. If the status is set to one of the error code defined in Section 4.2, it MAY try to solve the problem according to the corresponding error and MAY try sending a new request message as explained above. Eriksson, et al. Expires December 21, 2008 [Page 7] Internet-Draft MIPv6 Flow Routing June 2008 5.2. Receiving Rules Upon reception of a Flow Rules Update Request message defined in Section 4.1, a Home Agent or Correspondent Node first checks if there is an existing binding for the node that sent the message. If not, it discards the message and MUST send a Generic Notification Acknowledgement message with status code set to "132 Not home agent for this mobile node" [2]. More details about sending acknowledgment messages are explained later in this section. A Mobile Node or Mobile Router that receives a Flow Rules Update Request from its Home Agent MUST send a Generic Notification Acknowledgement message with the status code set to "129 Administratively prohibited" [2] if it is not accepting the rules. If the Flow Rules Update Request is accepted, the receiving node parses the set of rules included in the message. If an error occurs while processing the rules, the receiving node MUST send an Generic Notification Acknowledgment message with the status set to the appropriate error code defined in Section 4.2. In case of failure, the receiving node MUST NOT alter the active rules. If the set of rules was correctly parsed, the receiving node install them by deleting all the previously installed rules, and installing the whole new set of rules. Implementers may consider optimizing the installation of the rules by deleting, adding or replacing only the rules that actually need it. How the rules are setup on the system is out of scope for this specification and depends on the operating system that is used. If, for some reason, the rules cannot be installed on the system, the node MUST send an Acknowledgment message with the status set to "130 Insufficient resources" as defined in [2]. If the Acknowledge bit was set in the request message, the node MUST send a Generic Notification Acknowledgement message. It MUST follow the rules for sending an acknowledgment message defined in [2] by copying the sequence number from the request message and setting the proper status message. 6. Mobile Node Routing Controlled By Home Agent The Home Agent MAY send routing rules to the Mobile Node, to instruct it how to route its outgoing traffic. If the Mobile Node is not allowing or supporting this, it MUST send a Generic Notification Acknowledgement message with a suitable rejection code. Eriksson, et al. Expires December 21, 2008 [Page 8] Internet-Draft MIPv6 Flow Routing June 2008 If the Home Agent is controlling the flow routing of the Mobile Node, it is useful to have a prearranged agreement on the binding identifiers that the Mobile Node will use. The Home Agent can then know what access networks are available to the Mobile Node (by checking the binding identifiers in the Binding Cache entry of the MN), and make well founded routing decisions. In some cases, the Home Agent may have better knowledge about the load and other characteristics of the access networks, and thereby be able to make better routing decisions than the Mobile Node could do by itself. 7. Rules and Bindings Independence In general, it is expected that the flow rules will be changed independently of the care-of address bindings. The rules are used to select paths (and thereby often access networks) for the flows, and may change as the active traffic changes. The care-of address updates will normally reflect handovers after movements, and will not affect the rules, which refer to binding identifiers and not to care-of addresses. 8. Routing Rules Lifetime The lifetime of the flow routing rules is the same as the lifetime of the Home Address or Home Network Prefix binding that they are used for. When all bindings are deleted or the last Binding Cache entry times out, the corresponding rules are removed. 9. Support for dual-stack MIPv6 The Flow Distribution Rule Language for Multi-Access Nodes [5] currently only supports IPv6. In an upcoming revision, it will support rules also for IPv4 traffic. With that new revision, this specification will be updated to support dual-stack MIPv6 operation. 10. IANA Considerations A new Generic Notification Message sub-type is required, as described in Section 4.1: (TBD) Flow Rules Update Request The acknowledgments to Flow Rules Update Request reuses the Generic Notification Acknowledgement, see Section 4.2. We suggest that all new GNM requests reuse the Generic Notification Acknowledgement, if Eriksson, et al. Expires December 21, 2008 [Page 9] Internet-Draft MIPv6 Flow Routing June 2008 possible. For this, a part of the rejection code space should be allocated per request type, for example codes 192-255. These rejection codes from Section 4.2 need to be allocated for acknowledgments to a Flow Rules Update Request: (TBD) The recipient failed to parse the rules 11. Security Considerations The flow routing mechanism described in this document allows path selection for Mobile Nodes and Mobile Networks with multiple registered care-of addresses. It cannot be used to divert traffic, as the care-of address registrations are done outside this mechanism. However, it could be used for denial-of-service, if for example rules to drop all traffic are installed. The security of routing rule signaling depends on the security of the Generic Notification Messages [2]. The GNM does not yet specify protection for MN-CN signaling, and until the GNM specification is updated to support this, Corresponding Nodes SHOULD NOT allow the use of path selection rules. Home Agents for Mobile Networks MUST check any address prefixes used with the "local" keyword, so that they are entirely inside the Mobile Network's own prefix. 12. References 12.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Haley, B. and S. Gundavelli, "Generic Notification Message for Mobile IPv6", draft-haley-mext-generic-notification-message-00 (work in progress), April 2008. 12.2. Informative References [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. Eriksson, et al. Expires December 21, 2008 [Page 10] Internet-Draft MIPv6 Flow Routing June 2008 [5] Larsson, C., Eriksson, M., Mitsuya, K., Tasaka, K., and R. Kuntz, "Flow Distribution Rule Language for Multi-Access Nodes", draft-larsson-mext-flow-distribution-rules-00 (work in progress), November 2007. [6] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivation-scenario-03 (work in progress), May 2008. [7] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. Authors' Addresses Michael Eriksson Ericsson Research Torshamnsgatan 23 Stockholm SE-164 80 Sweden Phone: +46 8 757 5888 Email: michael.eriksson@ericsson.com Conny Larsson Ericsson Research Torshamnsgatan 23 Stockholm SE-164 80 Sweden Phone: +46 8 404 8458 Email: conny.larsson@ericsson.com Romain Kuntz Louis Pasteur University / LSIIT Strasbourg France Phone: +33 390 244 584 Email: kuntz@lsiit.u-strasbg.fr URI: http://clarinet.u-strasbg.fr/~kuntz/ Eriksson, et al. Expires December 21, 2008 [Page 11] Internet-Draft MIPv6 Flow Routing June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Eriksson, et al. Expires December 21, 2008 [Page 12]