Network Working Group J. Durand Internet-Draft GIP RENATER Expires: December 1, 2004 June 2, 2004 IPv6 multicast address assignment with DHCPv6 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 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 1, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides a simple solution to solve IPv6 multicast address assignment problem using the DHCPv6 protocol. Durand Expires December 1, 2004 [Page 1] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SSM considerations . . . . . . . . . . . . . . . . . . . . . . 3 3. Session announcement considerations . . . . . . . . . . . . . 3 4. Review of existing assignment protocols . . . . . . . . . . . 3 4.1 MADCAP . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2 SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3 GLOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.4 Random assignment . . . . . . . . . . . . . . . . . . . . 5 4.5 ZMAAP - Zeroconf Multicast Address Allocation Protocol . . 5 5. Assignment with DHCPv6 . . . . . . . . . . . . . . . . . . . . 6 5.1 New DHCPv6 options . . . . . . . . . . . . . . . . . . . . 6 5.1.1 IA_MA option for IPv6 Multicast Addresses . . . . . . 6 5.1.2 Scope Option for IPv6 multicast address . . . . . . . 8 5.2 Address timers . . . . . . . . . . . . . . . . . . . . . . 8 5.3 Client and server behavior . . . . . . . . . . . . . . . . 9 6. Group-ID consideration . . . . . . . . . . . . . . . . . . . . 9 7. Impact on the IPv6 multicast model . . . . . . . . . . . . . . 10 7.1 Impact on the multicast protocols . . . . . . . . . . . . 10 7.2 Impact on the multicast session . . . . . . . . . . . . . 10 8. Deployment scenarios - Case studies . . . . . . . . . . . . . 10 8.1 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3 Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security considerations . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 12 11. Open issues / Discussions . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1 Normative references . . . . . . . . . . . . . . . . . . . . 13 12.2 Informative references . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Durand Expires December 1, 2004 [Page 2] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 1. Introduction In the european IST project 6NET, the deliverable D3.4.3 [9] "IPv6 multicast address allocation study" was written after 18 months of practical experience with IPv6 multicast. This deliverable brought a complete analysis of the solutions existing for IPv6 multicast address assignment and highlighted the fact that no solution exists, matching the usual constraints: scalability, ease of use, deployment and configuration and availability of implementations. From the analysis of existing protocols, D3.4.3 [9] finally proposes, without details, mechanisms for IPv6 multicast address assignment. One of the proposal is to use the DHCPv6 protocol for IPv6 multicast address assignment. This document details how to assign IPv6 multicast addresses using the DHCPv6 protocol [7]. 2. SSM considerations The main need today for an assignment mechanism is address uniqueness in a defined part of a network. In the SSM model, as the channel is defined by the tuple (source address , group address), a collision can only occur if a host would like to be a sender for 2 different groups having the same address. Therefore, it is sufficient for a sender to choose different addresses for different channels, this is a decision local to the host. This document only considers the ASM model which is a bit more complex. 3. Session announcement considerations This document does not address the session announcement problem. It only answers the question of large scale address assignemnt of IPv6 multicast addresses. Announcement of the sessions can still be done using web pages, emails, directories, SAP, etc. 4. Review of existing assignment protocols 4.1 MADCAP MADCAP [1] is a client-server protocol for IP multicast address assignment. MADCAP is part of a complete address allocation architecture that includes MASC (to allocate blocks of multicast addresses to domains), and AAP (to allocate sub blocks to MADCAP servers) protocols. RFC 3306 [5] and Embedded-RP [10] make it possible to segment the IPv6 multicast address space without the need of any protocol. Using Durand Expires December 1, 2004 [Page 3] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 RFC 3306 [5], a site can derive IPv6 multicast addresses from its IPv6 unicast prefix. Embedded-RP [10] follows the same idea and the IPv6 multicast addresses depend on the RP address. These protocols avoid the need for MASC and AAP mentioned above. MADCAP could then handle the assignment of IPv6 multicast addresses on its own. Nevertheless, there have been no deployments of MADCAP for IPv4 and IPv6 since the release of the protocol's standard and the management of the client and MADCAP servers is too complex. However, it appears in contrast that DHCPv6 will be widely implemented and deployed (as DHCP for IPv4). Therefore, assigning IPv6 multicast addresses using DHCPv6 is a unique opportunity to solve the IPv6 multicast address assignment problem. 4.2 SAP SAP [3] is not per se an assignment mechanism. It was designed to announce multicast sessions. It is widely used to announce sessions and to assign multicast addresses in the IPv4 world. The SAP client fetches all the sessions advertised and chooses an address which is not yet assigned. This process means that: o Few sessions are advertised o All the sessions using addresses in the SAP assignment range are announced. Otherwise, a client could be assigned an address which is already used for another session. This is problematic as sessions are not always announced. o An RP is deployed for FF0X::/16 as SAP announcements are done on the address FF0X::2:7FFE. This is not compatible with Embedded-RP [10] It appears that SAP assignment can be done in a limited scope (site, ISP...) but not in the whole global IPv6 multicast network as SAP does not scale if millions of multicast addresses are being used. 4.3 GLOP GLOP is defined for IPv4 in RFC 3180 [4]. GLOP makes it possible to embed the AS number in the IPv4 multicast address. It is then possible in IPv4 to derive addresses from a specific AS (256 IPv4 multicast addresses per AS). GLOP is not really an assignment mechanism. It makes it possible to segment the multicast address space into chunks that can be then assigned locally. Durand Expires December 1, 2004 [Page 4] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 IPv6 would make it possible to have many more addresses per AS, given the length of the address. Nevertheless, there is no interest in GLOP when having the possibility to derive IPv6 multicast addresses from an IPv6 prefix (RFC 3306, see section below). Therefore we can consider that GLOP is irrelevant in the IPv6 world. 4.4 Random assignment A calculation that was made in D3.4.3 [9] shows that for a 32 bits group-ID, the probability that at least 2 hosts choose the same address is above 0.3% if there are 5000 hosts requiring an address. From this we can conclude that: o A random assignment could be used with IPv6 multicast addresses derived from /64 prefixes (RFC 3306). The chance that more than 5000 multicast addresses are needed on the same link can be considered as rare o This random assignment could also be used with embedded RP addresses if the RP is managing a few number of groups o Random assignments could be used for scoped addresses if the number of the groups needed in the zone is low o This form of assignment cannot be used in general for temporary addresses with a global scope as it would not be possible to assign more than 5000 IPv6 multicast addresses while keeping the probability of an address collision low 4.5 ZMAAP - Zeroconf Multicast Address Allocation Protocol This mechanism is very simple: when a node needs a multicast address, it asks its local multicast address allocation server (called the mini-MAAS) for an address, specifying the scope, the number of addresses needed and the desired lifetime. Then the mini-MAAS builds the IPv6 multicast addresses using a random function (at this stage the mini-MAAS uses addresses not assigned locally). Then the mini-MAAS checks that the address is not reserved by any other mini-MAAS in the same scope domain. The mini-MAAS does this by sending an address claim message (ACLM), specifying the leases locally assigned. This message is sent to the group of the mini-MAAS, using transport layer UDP. The scope of this mini-MAAS group address is the same as the one needed for address assignment. Every mini-MAAS must defend any assignment locally made. When a Durand Expires December 1, 2004 [Page 5] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 mini-MAAS receives an ACLM, it must verify that the lease requested does not overlap with any local assignment. If there is an overlap, the mini-MAAS must reply with an address-in-use message (AIU). This message is also sent to the multicast group of the mini-MAAS. A mini-MAAS considers the lease assigned locally to be valid if it does not receive any AIU message within a certain time frame. ZMAAP assignment is not scalable. The problem is exactly the same as with the use of SAP. It is not likely that all hosts exchange address usages on a given group. This solution could be used only for small scopes (admin-local or site-local). 5. Assignment with DHCPv6 5.1 New DHCPv6 options This section introduces new options for IPv6 multicast address assignment with DHCPv6. 5.1.1 IA_MA option for IPv6 Multicast Addresses RFC 3315 [7] defines the following options for Identity Associations (IA): o IA_NA option for Non temporary Addresses o IA_TA option for Temporary Addresses This document introduces a third option: the IA_MA option for IPv6 Multicast Addresses. It is used to carry an IA_MA, the parameters associated with the IA_MA, and the addresses associated with the IA_MA. The format of the IA_MA option is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | OPTION_IA_MA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | IAID (4octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | | . IA_MA-options =2E . =2E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + Durand Expires December 1, 2004 [Page 6] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 option-code: OPTION_IA_MA (21) option-len: 4 + length of IA_MA-options field IAID: The unique identifier for this IA_MA; the IAID must be unique among the identifiers for all of this client's IA_MAs. The number space for IA_MA IAIDs is separate from the number space for IA_NA and IA_TA IAIDs IA_MA-Options: Options associated with this IA_MA The IA_MA-options field encapsulates those options that are specific to this IA_MA. For example, all of the IA Address Options carrying the multicast addresses associated with this IA_MA are in the IA_MA-options field. Each IA_MA carries one "set" of multicast addresses; that is, at most one address per session created by the client requiring an address. An IA_MA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_MA options. The status of any operations involving this IA_MA is indicated in a Status Code option in the IA_MA-options field. Note that an IA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_MA have expired, the IA can be considered as having expired. An IA_MA option does not include values for T1 and T2. A client MAY request that the lifetimes of multicast addresses be extended by including the addresses in a IA_MA option sent in a Renew or Rebind message to a server. For example, a client would request an extension on the lifetime of a multicast address to allow an application to continue a multicast session. The client obtains new multicast addresses by sending an IA_MA option with a new IAID to a server. The server will generate new multicast addresses and return them to the client. The client should request new multicast addresses before the lifetimes on the previously assigned addresses expire. A server MUST return the same set of multicast address for the same IA_MA (as identified by the IAID) as long as those addresses are still valid. After the lifetimes of the addresses in an IA_MA have expired, the IAID may be reused to identify a new IA_MA with new multicast addresses. This option MAY appear in a Confirm message if the lifetimes on the Durand Expires December 1, 2004 [Page 7] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 multicast addresses in the associated IA have not expired. 5.1.2 Scope Option for IPv6 multicast address The scope option for IPv6 multicast addresses is used by the clients to request multicast addresses with a certain scope. It is included in the IA address option IAaddr-options field defined in section 22.5 of RFC 3315 [7]. A user can attach more than one scope option for IPv6 multicast address to an IA address option if the client does not know exactely the scope it wants to request but has a set of adequat scope values. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_SCOPE | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | scope | res | +-+-+-+-+-------+ option-code: OPTION_SCOPE (22) option-len: 1 scope: The scope value for the requested IPv6 multicast address, according to values defined in RFC 3513 [8] res: This field is reserved for future use. The 4 bits of this field MUST be set to 0 5.2 Address timers The IA address option defined in RFC 3315 [7] contains the following 32 bits fields: o preferred-lifetime: The preferred lifetime for the IPv6 address in the option, expressed in units of seconds o valid-lifetime: The valid lifetime for the IPv6 address in the option, expressed in units of seconds We suggest to use these fields, usually defined for unicast addresses, for IPv6 multicast addresses, with the definition written above. The maximum value for these lifetimes is 2^32 seconds or 49710 days equivalent to 136 years. Therefore a host that wants to be assigned Durand Expires December 1, 2004 [Page 8] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 an address for a 2 days session occuring in 30 days can request an address with a preferred lifetime value of 32 days. According to the IPv6 multicast addressing space available, servers should allow this type of requests, or at least should permit a certain number of long-term assignment per host or authenticated host. The address is directly assigned by the DHCP server when the request is received. We suggest here not using the parameters minDesiredStartTime and maxDesiredStartTime specified in RFC 2771 [2] which bring too much complexity for the assignment and don't really make sense for IPv6 where many addresses are available. 5.3 Client and server behavior The procedures to request an IPv6 multicast address is more or less the same than the ones described in RFC 3315 [7] to request a temporary IPv6 address. The differences are following: o The client uses IA-type IA_MA described above to ask for IPv6 multicast addresses. o The client SHOULD use the Scope Option in solicit and request messages to tell the server the scope wanted for the IPv6 multicast address requested. It can include more than one Scope Option for IPv6 multicast address per addresses requested in case the client does not know exactely the scope it wants to request but has a set of adequat scope values. o The client SHOULD specify the lifetimes for every address it wants to be assigned in solicit, request, renew and rebind messages. o The server MUST assign addresses only if it can assign an address matching one of the scope requested. In case the server can't assign an address with the requested scopes, it must include the Status Code Option NoAddrsAvail in the advertise and reply messages and should include a status message with the scopes that can be assigned by the server and their description. o If no scope option is specified by the client, the server can assign a multicast address with any scope. It can be a default scope value configured by the DHCP server administrator. 6. Group-ID consideration RFC 3307 [6] defines guidelines for the choice of IPv6 multicast group identifier (the last 32 bits of the IPv6 multicast address). It specifies that for dynamic IPv6 multicast address allocation, the group-ID MUST be in the range 0x80000000 to 0xFFFFFFF. Durand Expires December 1, 2004 [Page 9] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 Addresses assigned with DHCPv6 must not overlap with addresses assigned by another mechanism (MADCAP, multicast DAD, random assignment...). Therefore we propose to reserve the range from 0x90000000 to 0x9FFFFFFF for group-IDs assigned with DHCPv6, understanding that no other assignment mechanism can assign group-IDs in this range. These values were suggested in the document 6NET D3.4.3 [9]. 7. Impact on the IPv6 multicast model 7.1 Impact on the multicast protocols There is a strong interaction between the IPv6 multicast addresses and the IPv6 multicast protocols, for instance the group-to-RP mapping. Depending on the address choosen, a set of protocols and resources will be used. Assigning the IPv6 multicast address with DHCPv6 gives a network administrator the complete control of the multicast resources to be used. 7.2 Impact on the multicast session The continuous problem of multicast address assignment is depicted by the following scenario: one person initiates a multicast session and requests an address for it. Then, other people join the session and, finally, the person who asked for the address leaves the group. The other partipants that stay online are still using an address that can be released by the first participant, and reassigned by the server. This scenario is out of the scope of this document. This means that there is no way to be sure that the address assigned by DHCPv6 is not in use by other people. It is exactly the same that for IPv6 unicast. If you are assigned an IPv6 unicast address with DHCPv6, it is possible that another person on the same link manually configured the same address. Nevertheless, we can consider the technical and privacy issues. From a technical point of view, the consequence of IPv6 address overlapping in the same scoped zone is that clients will receive more flows, making it possible to overload links and/or CPU. From the privacy point of view, there is no impact at all. As the client are in the same scoped zone, they could join each other's sessions anyhow. Privacy for IPv6 multicast sessions is established by using encryption mechanisms. 8. Deployment scenarios - Case studies This section gives examples of DHCPv6 deployments for IPv6 multicast address assignment. Durand Expires December 1, 2004 [Page 10] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 8.1 Scenario 1 Consider a site having deployed a DHCPv6 server and having one RP for a site-local scope (scope 5). In this simple scenario, the DHCPv6 server can assign the complete set of addresses with a site-local scope. We have the same scenario if the site deploys one RP for global scope with embedded-RP technology. The DHCPv6 server of the site can assign the complete set of addresses derived from the RP's address (see Embedded-RP [10]). 8.2 Scenario 2 Consider a research center having deployed one DHCPv6 server for the entire site, and having several labs having each a multicast scope for their own usage. Every lab might have for example a scope admin-local (scope 4), and the global research center may have the scope site-local (scope 5). The problem of the DHCPv6 server is to assign appropriate addresses for each of the lab. The server can retrieve information about the location of the client according to the explanation given in section 11 of RFC 3315 [7]. The server can determine this way in which lab the client is and assign adequate addresses. This way a server can assign the same address twice to different clients in different labs. 8.3 Scenario 3 Consider an ISP providing a global RP service to its customers. The ISP decided to use embedded-RP technology for this RP. Every customers having deployed a DHCPv6 server would like to assign IPv6 multicast addresses based on the RP of their ISP. The problem is to avoid overlap between addresses assigned by every DHCPv6 servers. In this scenario, the ISP having deployed an RP would allocate a range of IPv6 multicast addresses based on its RP to every customer having subscribed for the service (as explained in section 5.2 of Embedded-RP [10]). This allocation would be typically hand-off allocation, as it is done between ISP and big customers (not end-users at home) for unicast. This way, every DHCPv6 server is configured with a different multicast address range, all matching the same RP. This means that ISPs need to allocate IPv6 multicast addresses to their customers, as they do today for IPv6 unicast. Nevertheless, we can note here that any customer could deploy its own embedded-RP rather than using the one of its ISP, which simplifies this scenario. Durand Expires December 1, 2004 [Page 11] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 Another similar scenario is a big organization that has set up multicast across many sites with the scope 8 (organization). Every site of the organization has a DHCPv6 server, and it must be ensured that addresses assigned in the different sites for scope 8 will not overlap. A solution to this problem is to allocate a subset of the complete organizational scope address space to each site. 9. Security considerations The security considerations related to the DHCPv6 protocol are discussed in the security considerations section of [7]. Security and pricacy considerations of the assignment of IPv6 multicast addresses are discussed in the Section 7.2 of this document. 10. Acknowledgement The author would like to thank Bernard Tuy, Stig Venaas, Christian Strauf and Pekka Savola for their good contributions to this memo. The author would also like to thank Ralph Droms who took time to consider the IPv6 multicast assignment problem and introduced the concept of the identity association for IPv6 multicast addresses. The author would also like to thank all the people having worked on the 6NET Deliverable 3.4.3, which was the initial document that raised the complete problematic of IPv6 multicast assignment. 11. Open issues / Discussions Here are the current discussions and questions about this document: o Split in 2 different drafts: one for the DHC WG with the description of the DHCPv6 options and mechanismsand; the other one for the MBoned WG talking of the existing assignment techniques and consequences on the model. o Maybe no need to give a range for group identifiers. We could leave things up to the network admin. Nevertheless, this feature is nice for not overlapping with protocols like "multicast DAD" and "random choice in a specific range for not necessary unique addresses". Also it is an interesting feature to see in a network the addresses that were assigned with DHCPv6 o Timers could be specified with a new DHCPv6 option rather than overloading the timers of the address o Scope option for DHCPv6 could be mandatory so that we are sure the Durand Expires December 1, 2004 [Page 12] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 user knows what he does. Another option is that the server could assign an address not in the scope requested, and the client could then decide weither he wants to keep it or not. Problem about this is that a user could be given o DHCPv6 usually has impacts on the kernel (IPv6 unicast address assignment, DNS address indication...) and the problem of multicast address assignment is in user space. Are there some problems that could be coming from this ? 12. References 12.1 Normative references [1] S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2970, December 1999. [2] R. Finlayson, "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000. [3] M. Handley, C. Perkins and E. Whelan, "Session Announcement Protocol (SAP)", RFC 2974, October 2000. [4] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", RFC 3180, September 2001. [5] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [6] B. Haberman, "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. [7] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [8] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. 12.2 Informative references [9] 6NET project partners, "6NET D3.4.3 - IPv6 multicast address allocation study", May 2003. [10] P. Savola and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", April 2004. Durand Expires December 1, 2004 [Page 13] Internet-Draft IPv6 multicast address assignment with DHCPv6June 2004 Author's Address Jerome Durand GIP RENATER 151 Bd de l'Hopital Paris 75013 France Phone: +33 1 53 94 20 30 EMail: Jerome.Durand@renater.fr Durand Expires December 1, 2004 [Page 14] Internet-Draft IPv6 multicast address assignment with DHCPv6June 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 Durand Expires December 1, 2004 [Page 15] Internet-Draft IPv6 multicast address assignment with DHCPv6June 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. Durand Expires December 1, 2004 [Page 16]