Internet Draft C. Janneteau Document: draft-janneteau-nemo-multicast-mldproxy-00.txt E. Riou Expires: October 2004 A. Petrescu A. Olivereau H.-Y. Lach Motorola Labs April 2004 IPv6 Multicast for Mobile Networks with MLD-Proxy Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document addresses the problem of delivering IPv6 multicast traffic to nodes inside a mobile network. An approach based on the deployment of "MLD-based Multicast Forwarding (MLD-proxying)" [1] in the mobile network, combined with the use of MLD [2][3] between the mobile router (MR) and the visited network, is proposed. Such a configuration allows multicast support for mobile networks, without the need to run a multicast routing protocol. In addition of being simple to implement and deploy, this approach provides global mobility in the Internet, and optimal multicast routing with nested mobile networks, while optimizing network and radio resources. This document does not specify new protocols, nor extensions to existing protocols. Janneteau et al. Expires October 2004 [Page i] INTERNET-DRAFT Multicast for Mobile Networks April 2004 Table of Contents Status of this Memo................................................i Abstract...........................................................i Conventions Used in this Document..................................1 1. Introduction....................................................1 2. Multicast Configuration in the Mobile Network...................3 3. Example.........................................................4 4. Discussion......................................................6 4.1 Simplicity.....................................................6 4.2 Global Mobility in the Internet................................6 4.3 Optimal Routing with Nested Mobile Networks....................7 4.4 Optimization of Network and Radio Resources....................7 4.5 Seamless Mobility..............................................8 4.6 Fault Tolerance................................................8 4.7 Operation in Disconnected Mode................................10 4.8 Independence from the NEMO Basic Support Protocol.............10 4.9 Support of Multicast Sources inside the Mobile Network........10 5. Security Considerations........................................11 6. Conclusion.....................................................11 Acknowledgements..................................................11 Copyright Notice..................................................13 Conventions used in this document 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 [4]. Some terms from the NEMO terminology [5] are used in this document; as well as the following definitions from [1]: Upstream Interface: A proxy device's interface in the direction of the root of the tree. Also called the "Host interface". Downstream Interface: Each of a proxy device's interfaces that is not in the direction of the root of the tree. Also called the "Router interfaces". 1. Introduction The NEMO Basic Support protocol [6] specifies extensions to Mobile IPv6 [7] in order to provide reachability at a permanent address and unicast session continuity for nodes in a mobile network, while the mobile router (MR) moves between IPv6 subnets. The protocol relies on the establishment of a bi-directional tunnel between the mobile router (MR) and its home agent (HA). MR forwards outgoing IPv6 packets through the tunnel, towards its home network. Similarly, any packet arriving on the MR's home link are intercepted by the HA and forwarded through the tunnel, if the packet's destination address matches the mobile network prefix Janneteau et al. Expires October 2004 [Page 1] INTERNET-DRAFT Multicast for Mobile Networks April 2004 (MNP). This is achieved by extending the MR's HA to support redirection for the whole MNP, in addition to the MR's home address. While mobility support for IPv6 unicast sessions is fully addressed by the above mentioned mechanism, [6] (up to now) does not discuss the case of IPv6 multicast traffic. The issue here is to enable session continuity both for multicast receivers and multicast sources located inside a mobile network, while MR is moving. Since multicast routing highly differs from unicast routing, the HA forwarding mechanism defined by [6] for unicast packets does not serve the forwarding of multicast packets. The key reason is that multicast packets are sent to a multicast address that is unrelated to the prefixes of the networks where potential multicast receivers are located (e.g. the mobile network prefix). A possible solution is the use of the MR-HA bi-directional tunnel for the forwarding of multicast traffic too, in both directions, between the MR and its home link. By co-locating a multicast routing function on both the MR and its HA, multicast routing protocol messages can be exchanged over the MR-HA tunnel. This allows the creation of multicast branches from the Internet to receivers in the mobile network, as well as from sources in the mobile network to receivers in the Internet. This solution is somehow similar to running a dynamic unicast routing protocol over the MR-HA tunnel as described in section 8 of [6]. This document addresses the problem of delivering IPv6 multicast traffic to nodes inside mobile networks. It proposes an attractive alternative, in situations where the above mentioned approach is either not possible (e.g. due to MR or HA capabilities), or the network and radio overhead (i.e. sub-optimal routing, and encapsulating header) introduced by the MR-HA tunnel is not acceptable. Up to now, two main approaches have been identified by the IETF community enabling delivery of multicast traffic to mobile multicast hosts [8][9]. The first one, sometimes called Bi-directional Tunnelling (BT), relies on the Mobile IPv6 tunnel to forward the multicast traffic to the mobile host. This is the same principle as what has been discussed above. The second approach, sometimes called Remote Subscription (RS), proposes that the mobile host joins the multicast group via a local multicast router on the visited link. For this purpose, the mobile host behaves like any other fixed multicast receiver in the visited network, e.g. sending MLD Report messages [2][3] to the local multicast router using an IPv6 link-local source address. Our approach proposes to apply the Remote Subscription principle to the case of a mobile router, serving a mobile network. The MR uses MLD messages to re-subscribe to the ongoing multicast sessions through the local multicast router in the visited network. In the case of the mobile network however, the two following requirements have to be considered: Janneteau et al. Expires October 2004 [Page 2] INTERNET-DRAFT Multicast for Mobile Networks April 2004 o First, MR must be able to discover which multicast groups nodes in the mobile network are interested in, in order to subscribe to them and forward the traffic to all interested receivers inside the mobile network. o Second, the multicast routing inside the mobile network should be optimal. That is, routing multicast packets only in parts of the mobile network where receivers are located; and thus avoiding flooding. Our approach bases on the deployment of "MLD-based Multicast Forwarding (MLD-proxying)" [1] inside the mobile network, in order to solve the above mentioned issues. Such a configuration, combined with the use of Remote Subscription at MR, allows multicast support for mobile networks, without the need to run a multicast routing protocol. In addition of being simple to implement and deploy, this approach provides global mobility in the Internet and optimal multicast routing with nested mobile networks. In addition, it optimizes the usage of network and radio resources. In the following sections, we will first review the details of the multicast configuration inside the mobile network, as proposed in our approach. Then, we will present some of the advantages foreseen. 2. Multicast Configuration in the Mobile Network The multicast configuration in the mobile network bases on the deployment of the "MLD-based Multicast Forwarding" function (or MLD-proxy) both on internal fixed routers and on the MR, in such a way that group membership information will propagate router-by- router (being aggregated at each router) from the routers serving multicast receivers towards the MR. This approach allows to route multicast traffic inside the mobile network without the need to run a multicast routing protocol. It is sufficient for each intermediate router to learn and proxy group membership information and simply forward multicast traffic based upon that information. As opposed to multicast routing protocols, the MLD-based Multicast Forwarding mechanism does not define a tree buidling algorithm, as a way to avoid forwarding loops. The consequence is that the MLD- based Multicast Forwarding approach can be used only in tree topologies. Hence, routers inside the mobile network must be manually configured to form a tree rooted at the MR, for the purpose of multicast forwarding within the mobile network. This configuration process consist in (1) selecting which routers should run the MLD-proxy function, and (2) designating the unique upstream interface and the downstream interface(s) on each of these proxy devices. A proxy device performs the Host part of the MLD protocol on the upstream interface, and the Router part of MLD on each of Janneteau et al. Expires October 2004 [Page 3] INTERNET-DRAFT Multicast for Mobile Networks April 2004 its downstream interfaces. Especially, ingress interfaces of the MR should be configured as downstream interfaces, while the egress interface must be configured as the upstream interface. The reader should refer to [1] for more details on the behaviors of MLD-proxy devices. 3. Example This section illustrates, through an example, the multicast operations in a mobile network supporting the above mentioned approach. Let's assume the mobile network of Figure 1, with a quite complex internal topology. The mobile network is made of 5 different IPv6 subnets (link1 to link5), interconnected by fixed routers FR1 to FR4. MR is attached to Foreign Link A, served by the access router AR1. Both AR1 and AR2 are multicast routers. No assumption is made whether AR1 and AR2 run the same multicast routing protocol or not. It may be the case if they are located in the same multicast domain. If they are located in different domains, it is assumed that an appropriate inter-domain multicast routing protocol is deployed in the multicast inter-network. CN | "====================================" " " " Multicast Inter-network " " " "====================================" | | AR1 AR2 Foreign | | Foreign Link A ----------- ----------- Link B |i1 MR --- |i2 | ------------------------------------- link1 | |i1 |i1 |i1 | FR1 FR2 FR3 | Mobile i2| |i3 |i2 |i2 | Network link2 ----- ----- link3 -------------- link4 | | |i1 | `--------------- FR4 | i2 |i3 | ------------- link5 | | | MNN | --- Figure 1: Mobile Network with Complex Internal Topology Janneteau et al. Expires October 2004 [Page 4] INTERNET-DRAFT Multicast for Mobile Networks April 2004 In order to support delivery of multicast traffic to MNN with the MLD-based Multicast Forwarding scheme, the tree of MLD-proxies must be configured in the mobile network. The configuration of Table 1 can be used. ============================================================== | MLD-proxy? | Upstream Interface | Downstream Interface(s) | | | (MLD Host Part) | (MLD Router Part) | ================================================================== | MR | YES | i1 | i2 | |FR1 | YES | i1 | i2, i3 | |FR2 | YES | i1 | i2 | |FR3 | NO | none | none | |FR4 | YES | i1 | i3 | ================================================================== Table 1: Example #1 of MLD-based Multicast Forwarding Configuration In this configuration, it is worth noting that FR3 is operating the MLD protocol (either Host or Router part) on none of its interfaces. Similarly, FR4 does not operate the MLD protocol on its interface i2. From the multicast routing perspective, the topology in the mobile network is then a tree, as depicted in Figure 2. Of course, this has no impact on the unicast routing inside the mobile network. For instance, unicast packets may still be routed through FR3. CN | "====================================" " " " Multicast Inter-network " " " "====================================" | | AR1 AR2 Foreign | | Foreign Link A ----------- ----------- Link B |i1 MR --- |i2 | ------------------------------------- link1 | |i1 |i1 | FR1 FR2 | Mobile i2| |i3 |i2 | Network link2 ----- ----- link3 -------------- link4 | |i1 | FR4 | |i3 | ------------- link5 | | | MNN | --- Figure 2: Tree Multicast Routing Topology in the Mobile Network Janneteau et al. Expires October 2004 [Page 5] INTERNET-DRAFT Multicast for Mobile Networks April 2004 Once the above configuration is in place, multicast traffic can be delivered to receivers in the mobile network. Let's consider CN as the source of a multicast group G, served by a multicast tree in the multicast inter-network. Let's consider that none of the nodes in the mobile network have yet subscribed to group G. When MNN subscribes to group G, it sends an MLD Report message on link5. FR4, which is the proxy device for this link, intercepts this message, determines that this group is not yet received at FR4, and thus sends its own MLD Report message for group G through its upstream interface i1. The membership subscription for group G propagates router-by-router (FR4 -> FR2 -> MR) within the mobile network up to MR. Similarly, MR determines that this group is not yet received, and thus sends its own MLD Report message for group G through its upstream/egress interface towards its access router (AR1) on the Foreign Link A. This will trigger establishment of a new delivery branch for multicast group G towards AR1 along which multicast packets will be forwarded. Upon reception of the multicast packets, MR will look at the group membership information associated with each of its downstream interfaces and forward the packets through the interfaces for which the group G is mentioned. Other routers in the mobile network will apply the same forwarding mechanism. Finally, the packet will be received by MNN. When MR moves to a new network, for instance to Foreign Link B, it must re-subscribe to all multicast groups it was receiving through its old access router (AR1). This is the Remote Subscription. For this purpose MR sends new MLD Report messages for all the groups (and related source lists) listed in its aggregated group list towards the Foreign Link B. Upon reception of these messages, AR2 will trigger establishment of new multicast branches so that multicast packets for these groups can be delivered to MR. Then MR forwards these packets inside the mobile network as before. Note that the mobility of the mobile network is transparent to the multicast receivers in the mobile network since MR handles the re- subscription on its own. 4. Discussion 4.1 Simplicity The approach proposed is quite simple to implement on any type of system thanks to the widespread availability of MLD. It is quite simple to deploy and operate too, because no multicast routing protocol is needed inside the mobile network. In addition, the required configuration to form the tree of MLD-proxies seems affordable in the context of mobile networks, which are typically small-to-medium leaf networks. 4.2 Global Mobility in the Internet The approach bases on the use of the MLD protocol between the MR and the visited network, in order to maintain multicast session continuity. This allows global mobility in the multicast inter- Janneteau et al. Expires October 2004 [Page 6] INTERNET-DRAFT Multicast for Mobile Networks April 2004 network since MLD is expected to be supported in any IPv6 subnet. With this approach the mobile network can roam in any visited network, irrespective of the type of multicast routing protocol locally deployed. If the mobile network moves to a foreign link where multicast is not supported, MR can still maintain ongoing multicast sessions by performing re-subscription to the group, with MLD Report messages, through the MR-HA bi-directional tunnel. Several approaches can be envisaged for the multicast support on the HA. It can be configured as a multicast router, or simply as an MLD-proxy. In the later case, the HA would then issue its own MLD Reports towards the multicast-enabled Border Router (BR) on the MR's home link. 4.3 Optimal Routing with Nested Mobile Networks The approach provides optimal routing both in the infrastructure and inside the mobile network. Optimal routing is achieved in the infrastructure thanks to the Remote Subscription concept, by reconstructing a new multicast branch at the current location of MR. Optimal routing inside the mobile network is achieved by the "MLD- based Multicast Forwarding" mechanism which routes packets on the shortest-possible-path (according to the tree topology configured), and only in subnets where receivers are located. It is worth noting that optimality of the path is preserved even in scenarios of nested mobile networks. It is acknowledged that under certain circumstances the remote subscription process may involve overload in the network, for instance when the MR moves frequently into foreign networks which are topologically far from the existing multicast tree. In the context of this document, however, it is considered that this inconvenient is largely overcome by the advantages of offering optimal routing paths outside the mobile network (no mandatory long path to Home Agent) and inside an aggregation of mobile networks. 4.4 Optimization of Network and Radio Resources The approach preserves native multicast routing of the traffic all along the path from the source to the receivers, even when located under several nested mobile routers. Flooding is avoided both in the infrastucture thanks to the routing protocol (e.g. PIM-SM), and inside the mobile network thanks to MLD-based Multicast Forwarding, which optimizes network resources. In addition, radio resources are also optimized since the sending of native IPv6 multicast (i.e. not unicast-encapsulated) over the air interface, between the infrastructure and MR or even within the mobile network, avoids header overhead and allows to take full advantage of a potential multicast support available at the link level. Janneteau et al. Expires October 2004 [Page 7] INTERNET-DRAFT Multicast for Mobile Networks April 2004 4.5 Seamless Mobility The fact that MR aggregates group membership information (from nodes inside the mobile network) and subscribes to those groups using MLD, makes the MR behave like an individual mobile host with respect to the multicast routing in the infrastructure. One advantage is that seamless multicast handover mechanisms (such as [10] and [11]) that have been defined for mobile hosts still work for mobile networks that implement MLD-proxying locally. For instance, in [10], seamless mobile multicast is achieved thanks to the forwarding of multicast traffic through a temporary tunnel established between the previous and the new multicast access routers, while the multicast branch at the new access router is under construction. 4.6 Fault Tolerance Although the multicast delivery mechanism inside the mobile network, based on "MLD-based Multicast Forwarding", requires an appropriate designation of upstream and downstream interfaces on internal routers in order to form a multicast tree, it features some form of robustness against failure. Indeed, this approach allows several routers on the same link to be configured as MLD-proxy (and thus as MLD Router). In order to avoid redundant traffic on the link, coming from those different proxies, only one of them must be authorized to propagate the group membership information upstream and to forward the multicast traffic on the link. This is achieved by electing a single forwarding MLD-proxy per link. The solution proposed in [1] is to "piggy-back" this forwarder proxy election on the MLD Querier election. In case of failure of the forwarder/querier router, another one is automatically elected. This new one will then start to propagate upstream the group membership information it had previously collected on the link, and delivered the related multicast traffic on this link. If later the former router recovers, it will automatically win the Querier election (smaller IP address), and thus take the role of forwarder on the link. Considering the mobile network of Figure 1, another possible multicast configuration is given in Table 2. Parentheses "()" indicate the changes with respect to the configuration of Table 1. ============================================================== | MLD-proxy? | Upstream Interface | Downstream Interface(s) | | | (MLD Host Part) | (MLD Router Part) | ================================================================== | MR | YES | i1 | i2 | |FR1 | YES | i1 | i2, i3 | |FR2 | YES | i1 | i2 | |FR3 | (YES) | (i1) | (i2) | |FR4 | YES | i1 | (i2), i3 | ================================================================== Table 2: Example #2 of MLD-based Multicast Forwarding Configuration Janneteau et al. Expires October 2004 [Page 8] INTERNET-DRAFT Multicast for Mobile Networks April 2004 According to [2] and [3], if the IPv6 adress assigned to FR1's i3 interface is smaller than the one of FR4's i2 interface, then FR1 will be the Forwarder/Querier for link3. Similarly, if the IPv6 address assigned to FR2's i2 interface is smaller than the one of FR3's i2 interface, FR2 will be the Forwarder/Querier for link4. The multicast tree is then equivalent to the one depicted in Figure 2. Now, if FR1 fails for any reason, FR4 will automatically becomes the Forwarder/Querier for link3. Similarly, if FR2 fails, FR3 will become the Forwarder/Querier for link4. This new multicast tree is depicted in Figure 3. Ongoing multicast sessions are maintained. CN | "====================================" " " " Multicast Inter-network " " " "====================================" | | AR1 AR2 Foreign | | Foreign Link A ----------- ----------- Link B |i1 MR --- |i2 | ------------------------------------- link1 | |i1 |i1 | FR1 FR3 | Mobile i2| |i2 | Network link2 ----- ----- link3 -------------- link4 | | |i1 | `--------------- FR4 | i2 |i3 | ------------- link5 | | | MNN | --- Figure 3: Another Multicast Tree in the Mobile Network When configuring several MLD-proxy devices on the same link, it should be ensured that the overall multicast topology inside the mobile network will always form a tree rooted at MR (i.e. no loop), irrespective of the outcome of the forwarder election process. If this rule is met, then an appropriate support for failure recovery can be provided. It is worth mentioning that, from the multicast delivery perspective, this forwarder election mechanism also allows to duplicate the mobile router serving the mobile network, and to automatically switch to the backup mobile router only when the master one fails. Janneteau et al. Expires October 2004 [Page 9] INTERNET-DRAFT Multicast for Mobile Networks April 2004 4.7 Operation in Disconnected Mode Another capability that may be expected from a mobile network, is to allow establishment of new communications between nodes inside the mobile network, and maintain existing ones, in situations where MR is disconnected from the fixed infrastructure. This is referred to as operating in disconnected (or autonomous) mode. The MLD-proxy approach for multicast routing inside the mobile network supports the disconnected mode, since the multicast packets from a local source can be delivered to local receivers (fixed, and mobile ones using remote subscription) without the need for the packets to be routed outside of the mobile network. Indeed, [1] recommends that each MLD-proxy device, receiving a multicast packet on a downstream interface which is in the Forwarder/Querier mode, forwards this packet through its upstream interface in addition to through all its other downstream interfaces (in Forwarder/Querier mode) which have a subscription pertaining to this packet. This rule allows multicast packets from a local source to propagate hop-by-hop to the MR, and be redistributed at each hop in the downstream direction, so that all local receivers can be reached. Again, it is worth noting that the proposed approach supports multicast communications in disconnected mode, even in cases of nested mobile networks. Indeed, if the top-level Mobile Router of an aggregation of nested mobile networks is disconnected from the infrastructure, multicast communications are still possible between any sources and receivers inside this aggregation, irrespective of their location. In addition, multicast routing will again be optimal. 4.8 Independence from the NEMO Basic Support Protocol This proposed mobile multicast scheme for mobile networks is completely independent of the protocol used to maintain ongoing unicast communications, be it the NEMO Basic Support [12] or another. This independence allows flexibility. 4.9 Support of Multicast Sources inside the Mobile Network The MLD-proxy forwarding rule discussed in section 4.7 allows delivery of multicast traffic from a local source to all local receivers in a mobile network. In order to reach receivers outside of the mobile network, the MR intercepting the multicast packet from the local source should then forward this packet towards the multicast delivery tree in the multicast inter-network. Because of the loop-avoidance mechanism of multicast routing protocols (i.e. RPF check), multicast packets must enter the multicast delivery tree through a point wherefrom the source is considered topologically correct and subsequent RPF checks of multicast routers in the delivery tree will complete. Janneteau et al. Expires October 2004 [Page 10] INTERNET-DRAFT Multicast for Mobile Networks April 2004 A possible solution is that MR forwards outgoing multicast packets towards its home network, for instance by taking advantage of the MR-HA tunnel of the NEMO Basic Support protocol. 5. Security Considerations The proposed solution for delivery of multicast to mobile networks relies on the use of MLD-based Multicast Forwarding inside the mobile network, combined with the use of MLD at the MR. Security aspects of MLD and MLD-based multicast forwarding are discussed in [2][3], and [1] respectivelly. 6. Conclusion This document has discussed the support of IPv6 multicast for mobile networks. The approach presented is also applicable in the IPv4 context, where IGMP is used instead of MLD. This approach, including MLD-based Multicast Forwarding inside the mobile network and remote subscription at MR, has been demonstrated during various public events including the HyWiN workshop [12], on December 2003. The implementation was based on the LIVSIX [13] open source IPv6 stack. Acknowledgements The authors would like to thank their colleagues in the OverDRiVE project, in the framework of which this work has been partly performed. Thanks too to Daniel Negru and Greg Daley, for the discussion held on the NEMO mailing list that has encouraged the publication of this document. Janneteau et al. Expires October 2004 [Page 11] INTERNET-DRAFT Multicast for Mobile Networks April 2004 References [1] Fenner, B., He, H., Haberman, B. and Sandick, H., "IGMP/MLD- based Multicast Forwarding ("IGMP/MLD Proxying")", work in progress, draft-ietf-magma-igmp-proxy-06.txt, April 2004. [2] Deering, S., Fenner, W. and Haberman, B., "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [3] Vida, R. and Costa, L., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", work in progress, draft-vida-mld-v2-08.txt, December 2003. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Ernst, T. and Lach, H.-Y., "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01.txt, work in progess, February 2004. [6] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P., "Network Mobility (NEMO) Basic Support Protocol", work in progress, draft-ietf-nemo-basic-support-02.txt, December 2003. [7] Johnson, D., Perkins, C. and Arkko, J, "Mobility Support in IPv6", work in progress, draft-ietf-mobileip-ipv6-24.txt, June 2003. [8] Daley, G., Kurup, G., "Requirements for Mobile Multicast Clients", work in progress, draft-daley-magma-mobile-00.txt, June 2003, (Expired). [9] Janneteau, C., Tian, Y., Csaba, S., Lohmar, T., Lach, Y.-H., Tafazolli, R., "Comparison of Three Approaches Towards Mobile Multicast", IST Mobile Summit 2003, Aveiro, Purtugal, 15-18 June 2003, http://www.mobilesummit2003.org. [10] Simon, C., Vida, R., Kersch, P., Janneteau, C., Leijonhufvud, G., "Seamless IP Multicast Handovers in OverDRiVE", IST Mobile Summit 2004, Lyon, France, 27-30 June 2004, (accepted for publication), http://www.mobilesummit2004.org. [11] Suh, K., Kwon, D.-H., Suh, Y.-J. and Park, Y., "Fast Multicast Protocol for Mobile IPv6 in the fast handovers environments", work in progress, draft-suh-mipshop-fmcast-mip6-00.txt, January 2004. [12] Janneteau, C., Demonstration entitled "Multicast for Moving Networks", HyWiN 2003 workshop, Turin, Italy, 2 December 2003, http://www.ist-overdrive.org/HyWiN2003/. [13] LIVSIX IPv6 Stack, http://www.enrl.motlabs.com/livsix Janneteau et al. Expires October 2004 [Page 12] INTERNET-DRAFT Multicast for Mobile Networks April 2004 Authors' Addresses Christophe Janneteau Emmanuel Riou Motorola Labs Motorola Labs Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69352548 Phone: +33 1 69354829 Christophe.Janneteau@motorola.com Emmanuel.Riou@motorola.com Alexandru Petrescu Alexis Olivereau Motorola Labs Motorola Labs Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69354827 Phone: +33 1 69352516 Alexandru.Petrescu@motorola.com Alexis@motorola.com Hong-Yon Lach Motorola Labs Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 France Phone: +33 1 69352536 Hong-Yon.Lach@motorola.com Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC editor function is currently provided by the Internet Society. Janneteau et al. Expires October 2004 [Page 13]