Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track May 17, 2011 Expires: November 18, 2011 Distributed Mobility Management Protocol with Multicast Support draft-sarikaya-mext-multicastdmm-00.txt Abstract As networks are moving towards flat architectures, a distributed approach is needed to Mobile IPv6. This document defines a distributed mobility management protocol with multicast support. Protocol is based on Mobile IPv6 and its extensions for multiple care of address registration, flow mobility and dual stack mobile IPv6 with minimum extensions. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 18, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Sarikaya Expires November 18, 2011 [Page 1] Internet-Draft DMM with Multicast May 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Multicast State Mobility Option . . . . . . . . . . . . . 6 5. Correspondent Node Operation . . . . . . . . . . . . . . . . . 9 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 9 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 10 7.1. Multiple Interface Operation . . . . . . . . . . . . . . . 11 8. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 12.2. Informative references . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Sarikaya Expires November 18, 2011 [Page 2] Internet-Draft DMM with Multicast May 2011 1. Introduction Mobile IPv6 defines client based mobility support to the mobile nodes and is defined in [RFC3775]. There are several extensions to Mobile IPv6 such as multiple Care-of Address registration for multi-homed mobile nodes [RFC5648], flow mobility [RFC6089] and Dual Stack Mobile IPv6 [RFC5555]. Mobile IPv6 is based on a centralized mobility anchoring architecture. Centralized mobility anchoring has several drawbacks such as single point of failure, routing in a non optimal route, overloading of the centralized data anchor point due to the data traffic increase, low scalability of the centralized route and context management [I-D.liu-mext-distributed-mobile-ip]. In this document, we define a client based distributed mobility management protocol. The protocol assumes a flat network architecture as shown in Figure 1 [I-D.liu-mext-distributed-mobile-ip]. Access router on each link mobile node visits is expected to have the home agent capabilities. Unlike in Mobile IPv6, mobile node at a given time may be registered with more than one home agent and may be receiving data tunneled from these home agents. Mobile IPv6 used in such a flat architecture removes the need for route optimization which has many flaws such as revealing the mobile nodes location to the outside [I-D.liu-mext-distributed-mobile-ip]. Client based distributed mobility management protocol is designed based on Mobile IPv6 protocols and its many extensions with a minimum amount of extensions. Due to the popularity of mobile nodes with multiple interfaces client based distributed mobility management protocol must support multi- homed mobile nodes. In this document, this is achieved by way of using [RFC5648]. Flow mobility among the interfaces need to be supported and this is accomplished using [RFC6089]. Mobile nodes in IPv4 only networks also need to be supported and this is done using [RFC5555]. Access to a content delivery network (CDN) is done using multicasting. Mobile node operation for multicasting is needed for a client based distributed mobility management protocol. The current trend is that service providers tend to relieve the core network traffic by placing the content closer to the users in the access network in the form of cache or local CDN servers. Multicast support in the client based distributed mobility management protocol is designed to facilitate local access to the multicast groups. Sarikaya Expires November 18, 2011 [Page 3] Internet-Draft DMM with Multicast May 2011 +---+ +---+ +---+ |CN1| |CN2| |CN3| +---+ +---+ +--,+ _.---------+----------. \ ,----'' | `---'-. ,-' | \ `-. ,' | ' `. ( IP Network| \ `. | ' ,' `-. ; ,\' ;-----. ; _.----' ' ,' `---------+----------'' | / | ' +---'---+ +---:---+ +-------+ | AR1 | | AR2`--|------------| AR3 | | HA | | HA |------------|HA | +-------+ +-------+ +-------+ \\ \ \\ ' +-----+ +--\--+ | MN | ----move-------> | MN | +-----+ +-----+ Figure 1: Architecture of Distributed Mobile IPv6 Protocol 2. Terminology This document uses the terminology defined in [RFC3775]. 3. Overview This section presents an overview of the protocol. Home agent capable access routers (AR) send router advertisements (RA) with Home Agent Information Option. Mobile node caches the home agent address when it receives such an RA. Cache entries expire after a timeout period. Only the first entry from MN's home link does not expire. Mobile node uses a home agent after it moves to another link and if it still has ongoing communication with a correspondent node. MN gets a new Care-of Address (CoA) on the new link and MN sends a Binding Update message to the HA on the previous link to register CoA with HA. Binding Acknowledgement received from HA completes the registration. MN starts to receive the packets over HA-MN link from CN and MN starts to send packets with a destination option containing Sarikaya Expires November 18, 2011 [Page 4] Internet-Draft DMM with Multicast May 2011 the previous Care-of Address as MN's Home Address (HoA) to the CN. At each link, mobile node goes through bootstrapping if the router advertisement from the access router does not contain Home Agent Information Option. Using [RFC5026] MN either does DNS lookup by home agent name or by service name. MN gets the local domain name during link establishment. This constitutes dynamic assignment of the home agent and [RFC5026] allows such a dynamic assignment as mentioned in Section 5.1.1. Alternatively, MN can use stateless DHCP for Home Info discovery as in [I-D.ietf-mip6-hiopt]. Dynamic home agent address assignment using DHCP is allowed as mentioned in Section 1. After the bootstrapping, MN gets a new Care-of Address. MN uses this new address as its new Home Address and registers it in the DNS. HA can register MN's address in the DNS if MN sets DNS Update Mobility Option defined in [RFC5026] and sends it in the binding update to HA. MN sets R bit to zero. The procedure for sending a dynamic DNS update message is specified in [RFC2136]. AAA server could also register MN's new address in the DNS. MN also removes DNS entries with MN's Home Addresses that are no longer used. MN sends BU with DNS Update Mobility Option. MN sets the R flag in the option and sets its old address as the FQDN in the option. MN uses Cryptographically Generated Addresses if the link is a public multi-access link. Wireless LAN links especially in public hotspots are examples of such links. Mobile nodes join multicast groups by sending join messages (MLD Report) to the the MLD Querier currently available on the link. MLD Querier after successfully joining the group receives multicast data packets addressed to the group and delivers them to the mobile node. The delivery could be made using Layer 2 means avoiding IPv6 packet duplication. When the mobile node moves to a new link and creates a binding with the home agent in the previous link, MN sets Multicast State mobility option with all ongoing multicast group subscriptions of the mobile node. The home agent as MLD Querier adds multicast state into the binding cache entry for this mobile node and starts tunneling multicast data to MN as in [RFC3775]. If there are more than one mobile nodes that are members of the same multicast group then the data packets are duplicated. Sarikaya Expires November 18, 2011 [Page 5] Internet-Draft DMM with Multicast May 2011 4. Option Format 4.1. Multicast State Mobility Option The multicast state mobility option is a new mobility option and it is included in the binding update and acknowledgement messages. Mobile node places its MLD multicast listener state in this option before sending BU message. The receiver, the home agent uses this option to establish the multicast state for this mobile node as MLD Querier and starts serving the mobile node over the tunnel. 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 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 143 | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Nr of Mcast Address Records (M)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [2] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [M] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The Multicast State Mobility Option Sarikaya Expires November 18, 2011 [Page 6] Internet-Draft DMM with Multicast May 2011 Option Type TBA1 for MULTICAST-STATE-TYPE Option Length 8-bit unsigned integer indicating the length of the option excluding the type and length fields. Multicast State Option Fields Defined in [RFC3810]. Multicast address record has the following fields and each field is as defined in [RFC3810]. Sarikaya Expires November 18, 2011 [Page 7] Internet-Draft DMM with Multicast May 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Type | Aux Data Len | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * * | | * Multicast Address * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * * | | * Source Address [1] * | | * * | | +- -+ | | * * | | * Source Address [2] * | | * * | | +- -+ . . . . . . . . . +- -+ | | * * | | * Source Address [N] * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Auxiliary Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sarikaya Expires November 18, 2011 [Page 8] Internet-Draft DMM with Multicast May 2011 5. Correspondent Node Operation This protocol removes the need for route optimization. Correspondent nodes do not need to maintain a binding cache of bindings for other nodes. Correspondent nodes when communicating with the same mobile node may receive regular IPv6 data packets with no mobility headers and then they may start receiving IPv6 data packets with mobility headers. Correspondent nodes process such packets as specified in Section 9.3.1 in [RFC3775]. 6. Home Agent Operation Home agent provides mobility support to the mobile nodes as defined in [RFC3775]. Home agent receiving the DNS Update mobility option MUST process the option as described in Section 6 of [RFC5026]. The dynamic DNS update SHOULD be performed in a secure way. After the DNS update, the home agent MUST send a Binding Acknowledgement message to the Mobile Node, including the DNS Update mobility option with the correct value in the Status field. Home agent receiving the DNS Update mobility option with R-flag set the Home Agent MUST remove the DNS entry and MUST send Binding Acknowledgement message to the Mobile Node, including the DNS Update mobility option with the correct value in the Status field. Home agent MUST remove the DNS entry upon receiving a deregistration BU from the mobile node. Home agent MAY use the binding cache entry expiration as a trigger to remove the DNS entry. In this specification route optimization is DISABLED. Home agent MUST support MLD as MLD Querier for the mobile node. Multicast state for the mobile node is usually established when mobile node was on the link and the state in Multicast State mobility option normally must match this state and the multicast state sent by the mobile node becomes the multicast state of the mobile node when communicating over MN-HA tunnel. In this specification, home agent does not receive multicast join messages tunneled to the home agent. Home agent gets this information from the multicast state mobility option in the binding update message. After receiving this message home agent makes sure that the mobile node has already subscribed to each group from MLQ Querier protocol state. Home agent changes IPv6 source address field in each source record in the set of records to the Care-of Address of the mobile node as taken from the binding Sarikaya Expires November 18, 2011 [Page 9] Internet-Draft DMM with Multicast May 2011 update message. A binding cache entry MUST exist for each such Care-of Address. Home agent sends all multicast group management messages such as MLD Report messages to the Care-of Address over the tunnel due to the binding cache entry. Multicast data packets addressed to the groups the mobile node is subscribed, i.e. Multicast Address is in Multicast Address Record field of the multicast state the mobile node sends, MUST be tunneled to the mobile node. Home agent MUST support multiple Care-of address registration [RFC5648] and flow mobility for multi homed mobile nodes [RFC6089]. Home agent MUST maintain several flow bindings for a given home address and to direct packets to different care-of addresses according to flow bindings. Home agent MUST keep a flow binding list which is associated with the mobile node with an entry for each flow that is registered. Dual stack home agent MUST support Dual Stack Mobile IPv6 protocol defined in [RFC5555]. When home agent receives Binding Update message with IPv4 CoA option and IPv4 Home Address option home agent sets a home address and/or prefix, creates a binding cache entry for this mobile node and then sends back a binding acknowledgement message with IPv4 Address Acknowledgement option which includes an IPv4 home address. 7. Mobile Node Operation Mobile nodes keep a cache of home agent addresses. This cache is called Binding Update List in [RFC3775] and is used for route optimization. In this specification, home agent cache or binding update list is used to keep track of the home agents with which the mobile node is currently registered and not for route optimization. Mobile node sends periodic binding update messages to each home agent in the home agent cache if the sessions initiated when mobile node was on home agent's link. This keeps the HA-MN tunnel active. Mobile node MAY send a deregistration BU when the sessions initiated with the home agent are no longer active. If mobile node receives a router advertisement with Home Agent Information option it adds an entry to the home agent cache. Mobile node does not establish a binding with a home agent until it moves to a new link and still has active sessions initiated when on link. On the new link, if a binding update message is not sent the cache entry for this home agent is removed. Sarikaya Expires November 18, 2011 [Page 10] Internet-Draft DMM with Multicast May 2011 On a new link, mobile node does a DNS lookup for a Home Agent address if it is configured with a DNS server address. If the Mobile Node is configured with the Fully Qualified Domain Name of the Home Agent it does DNS lookup by home agent name. Otherwise mobile node does DNS lookup by service name and constructs a request with QNAME set to "_mip6._ipv6.example.com" and QTYPE to SRV. On a new link, mobile node does home agent address discovery using stateless DHCP if configured. Mobile node as DHCP Client exchanges home network information with DHCP server. Mobile node sends Information-request message including the Home Network Information option. Mobile node indicates its preference about the requested home network with the Id-type in the Home Network Information option. Mobile node MUST set the Id-type to 2 to indicate that the mobile node has no preferred home network. Such a value is needed for bootstrapping on any link. DHCP server returns the Reply message including a Home Network Information option which contains home agent address and home network prefix. In the registration binding update message mobile node MUST set DNS Update mobility option so that home agent does DNS update on its behalf. Mobile node does not set the flag R in the option. Mobile node sets the MN identity field in DNS Update option with its FQDN and sets its Home Address in the Home Address Option. DNS update is made based on these values. 7.1. Multiple Interface Operation When a new interface becomes active such as Wi-Fi the mobile node forms an address and starts using that interface for communication on that link. No home agent is involved. When the mobile node starts to use a home agent any new communication on the new interface MUST use the registered home address. Mobile node MUST register its care-of address with this home agent as described in [RFC5648]. In the Binding Update message, Binding Identifier Mobility option defined in MUST be used. Mobile node MUST assign a BID for this Care-of Address which is unique. Mobile node also MUST assign a BID- PRI for this BID with lower value indicating a higher priority. If the registration is successful mobile node receives a binding acknowledgement with Status set to zero in the Binding Identifier Mobility option. Multiple Care-of address registration allows flow mobility between interfaces of a mobile node. Mobile node can then move flows by sending BU with flow identification mobility option. Multiple interfaces and possible use of multiple home address registered with the home agents makes it important for the mobile Sarikaya Expires November 18, 2011 [Page 11] Internet-Draft DMM with Multicast May 2011 node to select the correct source address in sending packets. 8. IPv4 Support Dual stack home agent MUST support IGMP for multicasting. Home agent is IGMP Querier for the mobile node. Mobile nodes or IGMP listeners could be supported over tunnel interface. Reception state for the mobile node is initialized to the value received in the multicast state mobility option received in the registration binding update. For IGMP, the type value is 0x22 containing the same fields as in Figure 2 also as defined in [RFC3376] Section 4.2. In IPv4 only foreign networks mobile node gets an IPv4 care-of address. It registers this address with a dual stack home agent only after moving to a new link and with open sessions with the correspondent nodes. Mobile node includes IPv4 CoA option and IPv4 Home Address option in the binding update message when registering and gets an IPv4 Home Address assigned. Mobile node does a DNS update registering its IPv4 home address on the DNS. In IPv4 only foreign networks mobile node does stateless DHCP in order to receive the home network information. Mobile node MUST use Home Network Information DHCPv4 option defined in [I-D.xia-mext-hioptv4]. 9. Security Considerations TBD. 10. IANA Considerations TBD. 11. Acknowledgements TBD. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Sarikaya Expires November 18, 2011 [Page 12] Internet-Draft DMM with Multicast May 2011 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. [I-D.ietf-mip6-hiopt] Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP Options for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-17 (work in progress), May 2008. [I-D.xia-mext-hioptv4] Xia, F. and B. Sarikaya, "DHCPv4 Options for Home Information Discovery in Dual Stack MIPv6", draft-xia-mext-hioptv4-02 (work in progress), April 2011. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. 12.2. Informative references [I-D.liu-mext-distributed-mobile-ip] Liu, D., "Distributed Deployment of Mobile IPv6", draft-liu-mext-distributed-mobile-ip-00 (work in progress), March 2011. Sarikaya Expires November 18, 2011 [Page 13] Internet-Draft DMM with Multicast May 2011 Author's Address Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 175 Plano, TX 75074 Phone: +1 469 277 5839 Email: sarikaya@ieee.org Sarikaya Expires November 18, 2011 [Page 14]