Network Working Group R. Lehtonen Internet-Draft J. Soini Expires: December 14, 2004 TeliaSonera J. Majalainen H. Vatiainen M. Tammi Tampere University of Technology June 15, 2004 MCOP operation for first hop routers draft-lehtonen-mboned-mcop-operation-02.txt 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. This Internet-Draft will expire on December 14, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft defines Multicast Control Protocol (MCOP) operation for first hop routers. In this context, MCOP may be used as a tool for multicast network management. MCOP provides multicast network remote management with centralized information database located at Multicast Control Server (MCS). It allows gradual, group and network specific multicast network deployment. The control is done by MCOP enabled first hop routers, Multicast Control Clients (MCC), based on the Lehtonen, et al. Expires December 14, 2004 [Page 1] Internet-Draft MCOP operation for first hop routers June 2004 information received from the MCS. MCC can filter IGMP/MLD reports and multicast packets before they reach the IGMP/MLD processing layer or multicast routing stack of the router. MCOP is independent of multicast routing protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 MCOP controlled groups and channels . . . . . . . . . . . 5 3.2 MCOP controlled multicast addresses . . . . . . . . . . . 5 3.3 Multicast Control Server (MCS) . . . . . . . . . . . . . . 5 3.4 Multicast Control Client (MCC) . . . . . . . . . . . . . . 5 3.5 Connection Holdtime . . . . . . . . . . . . . . . . . . . 5 3.6 Cache Entry Lifetime . . . . . . . . . . . . . . . . . . . 5 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 4.1 Threat Scenarios . . . . . . . . . . . . . . . . . . . . . 6 4.2 Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 4.3 Limitations and Known Issues . . . . . . . . . . . . . . . 7 5. MCC Functionality . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Initialization Phase . . . . . . . . . . . . . . . . . . . 9 5.2 Processing IGMP/MLD Messages . . . . . . . . . . . . . . . 9 5.3 Processing Multicast Traffic . . . . . . . . . . . . . . . 11 5.4 Creating Multicast Group Member Information . . . . . . . 12 5.5 Removing Multicast Group Member Information . . . . . . . 13 5.6 Updating Multicast Group Member Information . . . . . . . 13 5.7 Connection between MCC and MCS . . . . . . . . . . . . . . 13 6. MCS Functionality . . . . . . . . . . . . . . . . . . . . . . 15 6.1 General Description . . . . . . . . . . . . . . . . . . . 15 6.2 MCS Database . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Normative References . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 20 Lehtonen, et al. Expires December 14, 2004 [Page 2] Internet-Draft MCOP operation for first hop routers June 2004 1. Introduction Currently IP multicast architecture has insufficient dynamic control management capabilities over the multicast networks. This draft introduces Multicast Control Protocol (MCOP) operation for first hop routers that may be used as a tool for multicast network management. MCOP provides access control to multicast networks by remote "access-lists" as well as with special purpose multicast parameters. MCOP approaches multicast control by selectively filtering the IGMP/ MLD Reports and multicast traffic before multicast state information is created at MCC. The filtering is based on the information received from the MCS. MCOP is designed for multicast control within one domain or autonomous system (AS). In addition, by controlling multicast receiving within one domain or AS operators can limit and control multicast traffic propagation into the area. On the other hand multicast sourcing control allows operators to control the multicast traffic that is originated from the domain or AS. MCOP allows gradual, group and network specific multicast network deployment. It may be used to block misbehaving host from sourcing traffic to certain multicast group. Lehtonen, et al. Expires December 14, 2004 [Page 3] Internet-Draft MCOP operation for first hop routers June 2004 2. 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 [1]. Lehtonen, et al. Expires December 14, 2004 [Page 4] Internet-Draft MCOP operation for first hop routers June 2004 3. Terminology 3.1 MCOP controlled groups and channels MCOP may be used to control some or all any-source multicast groups and source-specific multicast (SSM) [2] channels. Those any-source multicast groups that are controlled by MCOP are called MCOP controlled groups. Those SSM channels that are controlled by MCOP are called MCOP controlled channels. When the specification refers collectively to both any-source groups and SSM channels, they are called MCOP controlled groups and channels. 3.2 MCOP controlled multicast addresses We refer to all MCOP controlled groups and channels using term MCOP controlled multicast addresses. MCOP is not applicable to multicast addresses that belong to scopes that are equal or lower than link-local scope. 3.3 Multicast Control Server (MCS) MCS may be a standalone server or it may be built in a router. MCS defines the MCOP controlled multicast addresses and informs MCC about them. MCS is also responsible for storing the multicast group information for MCOP controlled groups and channels. MCS functionality can be divided to multiple servers for redundancy. 3.4 Multicast Control Client (MCC) In this specification the first hop multicast routers that support MCOP are called MCCs. MCCs control multicast traffic destined to the MCOP controlled multicast addresses. The MCOP controlled multicast addresses are sent to MCCs by MCS. MCCs apply the control only to the directly connected networks. One MCC can connect to one and only one MCS at a given time. One MCS can be connected to multiple MCCs. Router implementations should allow to manually enable/disable MCOP functionality. 3.5 Connection Holdtime Connection holdtime specifies the time that group information is valid in MCC after connection is lost to MCS. 3.6 Cache Entry Lifetime Cache entry lifetime specifies the time that group information is valid in MCC when there are no active members for it. Lehtonen, et al. Expires December 14, 2004 [Page 5] Internet-Draft MCOP operation for first hop routers June 2004 4. Applicability Statement 4.1 Threat Scenarios MCOP protects multicast groups from unwanted sources. This could be a DoS attack to a certain group or just a misbehaving source flooding traffic to a single or multiple multicast groups. MCOP protects also from unwanted multicast transmissions or groups (unintentional DoS e.g. receiving a high bandwidth stream by accident). Generally networks and hosts are not interested in receiving unwanted and unneeded traffic. That could be avoided by configuring certain multicast groups to be used only in certain networks (allow receiving for only some subnets). MCOP may be also used to restrict the multicast group state information in routers to a certain level by limiting the number of possible multicast groups that can be listened and send to (state information based DoS). MCOP may also be used to deliver rate limits to multicast sources, reducing the amount of sourced multicast traffic (traffic based DoS). Group based control functions apply to MCOP controlled multicast addresses only. Therefore it is recommended to use MCOP for all multicast addresses. 4.2 Usage Scenarios MCOP is designed for intra-domain multicast network control. MCOP allows us to control both SSM and ASM multicast groups in intra-domain context. Operators may use MCOP to control their multicast network usage by selectively enabling multicast traffic receiving and sourcing. MCOP allows group and network based control and makes gradual multicast network deployment possible within the domain. In addition MCOP may be used to block unwanted sources/networks from sending traffic to specific multicast group or groups. MCOP may be used to control multicast parameters like maximum number of active groups that individual hosts can join or send traffic to. With centralized multicast control information (MCS) we have consistent multicast group information in our routers throughout the domain. This allows easy modifications to existing control information (e.g. block ASM within the domain). To sum up MCOP provides the following functions: Lehtonen, et al. Expires December 14, 2004 [Page 6] Internet-Draft MCOP operation for first hop routers June 2004 o 1. Group based control: which networks or hosts can or can't send traffic to a group. (applicable only to MCOP controlled groups and channels) o 2. Group based control: which networks can receive traffic from a group. (applicable only to MCOP controlled groups and channels) o 3. Network based control of the maximum number of groups that an individual host can receive traffic from. o 4. Network based control of the maximum number of groups that an individual host can send traffic to. o 5. Network based control of the total rate of traffic to multicast groups that an individual source can send. Items 1. and 2. can be implemented to some extent using normal access lists. However, access lists are difficult to manage and dynamic changes to access list information require a lot of work. The other items are more or less new control parameters that aid network management in various control needs. 4.3 Limitations and Known Issues If the source, which needs to be blocked for some reason, is outside of the controlled domain, it is not possible to filter that source with MCOP without implementing MSDP SA controlling at the MSDP Peer. MSDP SA controlling is not part of this specification. MCOP could be used to limit certain receivers from joining a specific multicast group, but the use of this functionality is limited, because the discrepancies in IGMP [3] and MLD [4] reporting mechanisms in different versions. This draft does not specify a protocol between MCC and MCS, only the operation of the MCC. This draft does not specify a protocol between MCSs (e.g. between domains). Control issues are based on local policies, which generally are not applicable to other domains. The control information is not immediately loaded to the routers, but only upon request because the multicast information database at MCS can be quite large and the control information can change dynamically. Multicast group join is postponed until receiver's network is validated. Use of MCOP may cause first multicast packets sent by the source be dropped if validation information is not available locally at MCC (e.g. multicast source is the first active source/receiver for the multicast group). MCOP is limited to IP layer control. It can't validate upper layer information like UDP ports used on multicast group. Lehtonen, et al. Expires December 14, 2004 [Page 7] Internet-Draft MCOP operation for first hop routers June 2004 5. MCC Functionality This chapter describes the functionality of a MCC including state machines for multicast receivers and sources. Multicast control performed by a MCC happens before multicast traffic is given to multicast traffic processing or before the MCC processes IGMP/MLD packets. See Figure 1. +-------+-------+-----+-------+---------------------------------+ |PIM-SM |PIM-DM | CBT | MOSPF |other multicast routing protocol | +-------+-------+-----+-------+---------------------------------+ | IGMP/MLD processing or multicast traffic forwarding | +---------------------------------------------------------------+ | MCOP processing (filtering layer) | +---------------------------------------------------------------+ | IP packet processing | +---------------------------------------------------------------+ Figure 1: MCOP processing within MCC Multicast control is applied to a specific multicast address range that is specified by MCS. The MCC behavior discussed within this chapter is applied only to the multicast groups that belong to the MCOP controlled multicast address space. MCOP processing can be extracted from the router operation and implemented as a transparent filtering bridge between router and directly connected hosts, see Figure 2. Lehtonen, et al. Expires December 14, 2004 [Page 8] Internet-Draft MCOP operation for first hop routers June 2004 +--------------+ | | | IP multicast | | router | | | +------+-------+ | | +--------------+ +---------+ | standalone | | | | MCOP | | MCS | | processing +------> "MCOP protocol" <------+ | | device (MCC) | | | +------+-------+ +---------+ | +--------------------------| e.g. Ethernet segment Figure 2: MCOP processing with transparent filtering bridge 5.1 Initialization Phase MCC is responsible for connecting MCS. MCC MUST inform MCS about all its connected networks that have directly connected hosts. This information is used by MCS to reply with the correct multicast parameters, which can be network specific. If the connected network information changes the MCC MUST inform MCS about the update. MCS MUST keep track of reported networks per MCC to be able to send multicast parameter updates to correct MCCs. MCS informs MCC about all MCOP controlled multicast addresses as well as general multicast parameters (source/receiver send/join limits and multicast rate limits for sources). These general parameters SHOULD be used for all multicast addresses, not only for MCOP controlled multicast addresses. MCS informs MCC if there are any changes to this information. 5.2 Processing IGMP/MLD Messages When MCC receives IGMP/MLD Report from a directly connected host sent to a multicast group that is configured as a MCOP controlled group or channel, MCC MUST validate the status of this new receiver. If the multicast group status exists in MCC's cache the remote validation procedure with MCS is not needed. If the receiver is found from the list of valid receivers for this multicast group and the number of joined groups of the host is below the address range parameter value, Lehtonen, et al. Expires December 14, 2004 [Page 9] Internet-Draft MCOP operation for first hop routers June 2004 the IGMP/MLD Report is passed for further IGMP/MLD processing. MCC continues passing IGMP/MLD Reports from that receiver unless the group status changes for the receiver. If the status changes the MCOP layer SHOULD generate IGMP/MLD Leave for that host and then start to discard further IGMP/MLD packets for this multicast group originating from the receiver. If the status changes from non-valid receiver to valid receiver, MCC SHOULD send IGMP/MLD Query for that multicast group to speed up the process of getting corresponding IGMP/MLD Reports. If the receiver is not found from the list of valid receivers. MCC starts to discard IGMP/MLD Reports. MCC doesn't need to analyse IGMP/MLD Queries, it is enough that IGMP/ MLD Report and Leave messages are analysed. The Figure 3 depicts the state machine for individual receiver as maintained by MCC. The state machine is used for each MCOP controlled multicast group and channel. +-------------++--------------------------------------------------------+ | || Event | | ++--------------+--------------+-------------+------------+ | State ||IGMP Report |Remote Valid. |IGMP Leave |Query Timer | | || |Result | |Expires | +-------------++--------------+--------------+-------------+------------+ | ||start Query |Cache Result |Drop Leave | - | | || Timer | | | | | ||if (max joins | | | | | || reached) | | | | | || Drop Report | | | | | || -> F state | | | | | ||else if (no | | | | | || cache entry) | | | | | || Remote | | | | | || Validation, | | | | |Init (I) || Buffer Report| | | | | || -> V state | | | | | ||else if (OK) | | | | | || Forward | | | | | || Report | | | | | || -> P state | | | | | ||else | | | | | || Drop Report | | | | | || -> F state | | | | +-------------++--------------+--------------+-------------+------------+ | ||restart |Cache Result |Flush Buffer,|Flush Buffer| | || Query Timer, |if (OK) |Drop Leave |-> I state | Lehtonen, et al. Expires December 14, 2004 [Page 10] Internet-Draft MCOP operation for first hop routers June 2004 |Validate (V) ||Flush Buffer | Forward |-> I state | | | ||Buffer Report | Buffer.Report| | | | ||-> V state | -> P state | | | | || |else | | | | || | Flush Buffer | | | | || | -> F state | | | +-------------++--------------+--------------+-------------+------------+ | ||Forward Report|Cache Result |Forward Leave|-> I state | | ||restart |if (OK) |-> I state | | | || Query Timer | -> P state | | | |Pass (P) ||-> P state |else | | | | || | Generate | | | | || | Leave | | | | || | -> F state | | | +-------------++--------------+--------------+-------------+------------+ | ||Drop Report, |Cache Result |Drop Leave |-> I state | | ||restart |if (OK) |-> I state | | |Filter (F) || Query Timer | Generate | | | | ||-> F state | Query | | | | || | -> P state | | | | || |else | | | | || | -> F state | | | +-------------++--------------+--------------+-------------+------------+ Figure 3: State machine for receiver 5.3 Processing Multicast Traffic When MCC receives multicast traffic from a directly connected host to a MCOP controlled group or channel, MCC MUST validate the status of this new source. If the multicast group cache entry exists in MCC the remote validation procedure with MCS is not needed. During the remote validation MCC SHOULD discard multicast packets originated from the source. If the source is found from the list of valid sources for this multicast group and the number of groups the host is allowed to send is below the address range parameter, the traffic can be forwarded for further processing (multicast traffic forwarding). MCC continues forwarding the multicast traffic unless the group status changes for the source. If the source is not found from the list, the MCC MUST discard the multicast traffic originated from the source, which was sent to this multicast group. MCC continues to discard the traffic unless the group status changes for the source. Lehtonen, et al. Expires December 14, 2004 [Page 11] Internet-Draft MCOP operation for first hop routers June 2004 The Figure 4 depicts the state machine for individual source as maintained by MCC. The state machine is used for each MCOP controlled multicast group and channel. The state machine does not include rate limiting functionality, which should be handled by specific rate limiting functionality of the router. +-------------++-------------------------------------------------------+ | || Event | | ++-------------------+------------------+----------------+ | State || Multicast traffic | Remote Validation| Source Timer | | || arrival | Result | Expires | +-------------++-------------------+------------------+----------------+ | ||start Source Timer |Cache Result | - | | ||if (max sends | | | | || reached) | | | | || -> F state | | | | ||else if (no cache | | | | || entry) | | | | || Remote | | | |Init (I) || Validation | | | | || -> F state | | | | ||else if (OK) | | | | || Forward Traffic | | | | || -> P state | | | | ||else | | | | || -> F state | | | +-------------++-------------------+------------------+----------------+ | ||restart |Cache Result |-> I state | | || Source Timer, |if (OK) | | |Pass (P) ||Forward Traffic | -> P state | | | ||-> P state |else | | | || | -> F state | | +-------------++-------------------+------------------+----------------+ | ||restart |Cache Result |-> I state | | || Source Timer, |if (OK) | | |Filter (F) ||Drop Traffic | -> P state | | | ||-> F state |else | | | || | -> F state | | +-------------++-------------------+------------------+----------------+ Figure 4: State machine for source 5.4 Creating Multicast Group Member Information If MCC does not have any status information about MCOP controlled group or channel members (new group or channel), the MCC MUST Lehtonen, et al. Expires December 14, 2004 [Page 12] Internet-Draft MCOP operation for first hop routers June 2004 validate the status from the MCS for the whole subnet where it received the traffic. The MCS returns information about the valid receivers and sources for that multicast group. The multicast group information is created by storing this information locally in MCC (cache entry). The multicast group information is valid unless MCS updates the group status or cache entry lifetime expires for inactive groups or the connection to MCS is disconnected and connection holdtime has elapsed. 5.5 Removing Multicast Group Member Information Any individual source information MUST always be removed if the MCC has not received any multicast traffic from a directly connected source within time that is specified by the source timer. The default value for source timer is 600 seconds, which should allow low rate and bursty sources to operate. The individual receiver information is removed when the receiver leaves the group (active or passive leaving). The query timer specifies the time limit for passive leaving (host does not send IGMP/MLD Leave message), which is 125 seconds by default. The whole multicast group member information is removed, when there are no active receivers and sources for that multicast group and cache entry lifetime expires. When the whole multicast group member information is removed, MCC MUST inform the MCS that it no longer needs updates for this combination. Then the MCS can remove the corresponding MCC from its update list for this multicast group. MCC may still get updates for this multicast group, if there are active members in other directly connected subnets for the MCC. MCC router MUST also remove all multicast group information for MCOP controlled multicast addresses if the connection to MCS is lost more than connection holdtime ago. 5.6 Updating Multicast Group Member Information The updating procedure is managed by MCS. Updates are sent when there are changes to valid sources or receivers for that multicast group. MCC MUST replace its local member information according that information. The change in group member information affects directly the management of active receivers and sources, which are either set to passing or filtering state by this message. 5.7 Connection between MCC and MCS This draft does not specify the protocol used between MCC and MCS. However, if the connection between MCC and MCS is disconnected, all multicast group information for MCOP controlled multicast addresses Lehtonen, et al. Expires December 14, 2004 [Page 13] Internet-Draft MCOP operation for first hop routers June 2004 MUST be removed from MCC after connection holdtime seconds if the connection to MCS can not be re-established. Connection holdtime is set by MCS and it is sent to MCC. MCC is responsible for re-establishing the connection to MCS. When the connection to the MCS is re-established, all multicast group information for MCOP controlled multicast addresses MUST be removed and gathered again. This is because the multicast group information (including the MCOP controlled multicast addresses) may have changed while the connection was disconnected. Lehtonen, et al. Expires December 14, 2004 [Page 14] Internet-Draft MCOP operation for first hop routers June 2004 6. MCS Functionality This chapter describes briefly the functionality of Multicast Control Server (MCS). It also covers the information that MUST be stored on the MCS's database in order to the MCOP mechanism to work. 6.1 General Description MCS contains information about MCOP controlled multicast addresses and valid receivers and sources for MCOP controlled groups and channels. MCC validates the group members against the information stored within MCS. If information changes for MCOP controlled group or channel in MCS, MCS is responsible for updating the information to MCCs that have validated the group status earlier. The fact that MCS contains information about configured multicast groups prevents unwanted multicast state to be appearing in the multicast routers, because the multicast tree is not created if the multicast information is not found from the MCS (MCS MUST deny the access from receivers and sources by default for MCOP controlled multicast addresses). 6.2 MCS Database MCS database information for each multicast group consists of the following parameters: o multicast group address o multicast source address (only for source-specific groups) o valid receivers (default = none) o valid sources (default = none) o address range specific host group join and send limits o connected MCCs and validated subnets, which are needed to update the multicast group status to MCC. Lehtonen, et al. Expires December 14, 2004 [Page 15] Internet-Draft MCOP operation for first hop routers June 2004 7. Security Considerations Maximum rate limit for an individual host, maximum number of joined multicast groups and maximum number of groups a host can send to can be circumvented using forged source IP addresses in shared networks. Malicious host could make DoS attack by sending a large number of bogus IGMP/MLD Reports to the MCC. MCC should implement an IGMP/MLD Report rate limitation mechanism that notices these kind of attacks and filters all IGMP/MLD Reports with too high arrival rate. MCOP mechanisms don't prevent a malicious host from getting multicast traffic if one or more valid and active receivers locate on the same broadcast network segment (e.g. Ethernet). Some encryption framework for IP multicast should be considered, if that is a requirement. Current multicast model in the Internet is equal or more vulnerable to attacks than the worst-case model for controlled multicast. Lehtonen, et al. Expires December 14, 2004 [Page 16] Internet-Draft MCOP operation for first hop routers June 2004 8. IANA Considerations This document has no actions for IANA. Lehtonen, et al. Expires December 14, 2004 [Page 17] Internet-Draft MCOP operation for first hop routers June 2004 9. Acknowledgements The authors would like to thank Dave Thaler, Beau Williamson, Brian Haberman, Mark Handley, Dave Meyer, Takeshi Takahashi, Thomas Eriksson, MAGMA WG and MBONED WG for their valuable feedback. 10 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [3] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [4] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Authors' Addresses Rami Lehtonen TeliaSonera Hatanpaan valtatie 20 Tampere 33100 Finland EMail: rami.lehtonen@teliasonera.com Jyrki Soini TeliaSonera Kumpulantie 3 Sonera 00051 Finland EMail: jyrki.soini@teliasonera.com Lehtonen, et al. Expires December 14, 2004 [Page 18] Internet-Draft MCOP operation for first hop routers June 2004 Juha Majalainen Tampere University of Technology Korkeakoulunkatu 1 Tampere 33720 Finland EMail: majis@cs.tut.fi Heikki Vatiainen Tampere University of Technology Korkeakoulunkatu 1 Tampere 33720 Finland EMail: hessu@cs.tut.fi Miikka Tammi Tampere University of Technology Korkeakoulunkatu 1 Tampere 33720 Finland EMail: miikka.tammi@tut.fi Lehtonen, et al. Expires December 14, 2004 [Page 19] Internet-Draft MCOP operation for first hop routers June 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement 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 assignees. 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 Lehtonen, et al. Expires December 14, 2004 [Page 20] Internet-Draft MCOP operation for first hop routers June 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lehtonen, et al. Expires December 14, 2004 [Page 21]