IPv6 multicast address assignment with DHCPv6 Tukiyooo 0 DHCP, DHCPv6, IPv6, Setup IPv6 19:10 <pre>Network Working Group J. Durand Internet-Draft GIP RENATER Expires: August 19, 2005 February 18, 2005 IPv6 multicast address assignment with DHCPv6 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 August 19, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document proposes a simple solution to solve IPv6 multicast address assignment problem using the DHCPv6 protocol. Durand Expires August 19, 2005 [Page 1] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 IPv6 multicast deployment status . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 SSM: no solution needed . . . . . . . . . . . . . . . . . 3 1.4 Session announcement considerations . . . . . . . . . . . 4 2. State of the art for address assignment . . . . . . . . . . . 4 3. Assignment with DHCPv6 . . . . . . . . . . . . . . . . . . . . 4 3.1 New DHCPv6 options . . . . . . . . . . . . . . . . . . . . 4 3.1.1 IA_MA option for IPv6 Multicast Addresses . . . . . . 4 3.1.2 Scope Option for IPv6 multicast address . . . . . . . 6 3.2 Address timers . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Assignment of a multicast prefix . . . . . . . . . . . . . 7 3.4 Client and server behavior . . . . . . . . . . . . . . . . 7 4. Group-ID consideration . . . . . . . . . . . . . . . . . . . . 8 5. Deployment scenarios - Case studies . . . . . . . . . . . . . 8 5.1 Scenario 1: Site deployment . . . . . . . . . . . . . . . 8 5.2 Scenario 2: Campus deployment . . . . . . . . . . . . . . 9 5.3 Scenario 3: ISP deployment . . . . . . . . . . . . . . . . 9 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1 Normative references . . . . . . . . . . . . . . . . . . . . 10 10.2 Informative references . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Durand Expires August 19, 2005 [Page 2] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 1. Introduction Embedded-RP [11] is the only available solution for IPv6 interdomain ASM. Embedded-RP requires an IPv6 multicast address assignment mechanism, as multicast addresses mapping to the RP cannot be guessed and manually built by users. This is depicted in section 2.1.2 of the IETF working group document draft-ietf-mboned-addrarch [13]. This document proposes a simple solution to assign IPv6 multicast addresses or prefixes using the DHCPv6 protocol [8]. 1.1 IPv6 multicast deployment status The document draft-jdurand-ipv6-multicast-ra [14] recalls the following: "The deployment of IPv6 multicast is expanding. Some networks have already put the service in production. Some gateways have been deployed, making it possible to have interoperability between IPv4 and IPv6 multicast. Some sites have even stopped IPv4 multicast, due to its complexity (due to NAT and MSDP for example) and only rely on IPv6 multicast, using the deployed gateways for interoperability with IPv4. As of this writing, most sessions are created manually from unicast-prefix based address space [6], or use SDR to form a semi-random address. Nevertheless these addresses cannot fit with embedded-RP [11] which is the only existing solution for IPv6 interdomain ASM. Some people argue that SSM solves the problem but there is nowadays a demand from customers to be capable to have multicast sessions (both IPv4 and IPv6) with multiple sources (e.g., conferencing) and it is not clear how to achieve this with SSM. While "multiple-source SSM" could potentially be done with the aid of SIP or RTP, this does not exist yet, and a simple solution for ASM is needed." 1.2 Terminology 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]. 1.3 SSM: no solution needed 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. Durand Expires August 19, 2005 [Page 3] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 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. 1.4 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. 2. State of the art for address assignment MADCAP [2] solves, or could solve, the multicast address assignment problem for both IPv4 and IPv6. However, MADCAP is a fork of DHCP, it has only a couple of implementations which have not been widely deployed. We assume that a mechanism that would be a simple extension to a more widely available mechanism (DHCPv6) could be more deployed. This proposal and draft-jdurand-ipv6-multicast-ra [14] simplify the assignment architecture since the unicast and multicast address assignment mechanisms become the same. We consider at this stage only IPv6 multicast since most of the key elements used are already defined, and interaction with IPv4 multicast is ensured. If felt needed by the community, this proposal could be extended to IPv4. 3. Assignment with DHCPv6 3.1 New DHCPv6 options This section introduces new options for IPv6 multicast address assignment with DHCPv6. 3.1.1 IA_MA option for IPv6 Multicast Addresses RFC 3315 [8] 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. This option 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: Durand Expires August 19, 2005 [Page 4] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 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-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . IA_MA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_IA_MA (TBD) 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 (see RFC 3315 [8]). 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 Durand Expires August 19, 2005 [Page 5] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 with a new IAID to a server. The server will generate new multicast addresses and return them to the client. In case the clients needs to extend the multicast session, it sends a Renew message to the server with the IA_MA and addresses in parameters. 3.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 [8]. 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 adequate 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 (TBD) option-len: 1 scope: The scope value for the requested IPv6 multicast address, according to values defined in RFC 3513 [9] res: This field is reserved for future use. The 4 bits of this field MUST be set to 0, and MUST be ignored on receipt 3.2 Address timers NOTE: There have been some discussions about using some options for the timers. This is let to next releases of the document as this release really focuses on why an assignment based on DHCPv6 has an interest. The IA address option defined in RFC 3315 [8] 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 Durand Expires August 19, 2005 [Page 6] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 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 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. 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 [3] which bring too much complexity for the assignment and don't really make sense for IPv6 where many addresses are available. 3.3 Assignment of a multicast prefix The assignment of a multicast prefix can be needed in the following scenarios: o An ISP needs to assign a block of IPv6 multicast address to an enterprise, assigning IPv6 multicast addresses to its hosts. This scenario will most likely occur when DHCPv6 prefix delegation [10] is already used to assign unicast prefixes to the enterprise. o Also it is most likely that the multicast applications will not support at the beginning the API to request for an IPv6 multicast address via DHCPv6. Then, on startup, or when connected to a new network, a host could ask for an IPv6 multicast prefix. Applications could then choose locally multicast addresses in the prefix assigned to the host. To fulfill this need, the prefix delegation mechanism described in RFC 3633 [10] is needed also for multicast prefixes. The actual specifications of the IPv6 prefix Options for DHCPv6 do not need to be changed to support multicast prefix delegations. The only thing to keep in mind is that multicast prefix delegation can also occur between a router and a host to fulfill the second requirement mentioned above. 3.4 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 [8] to request a Durand Expires August 19, 2005 [Page 7] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 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 exactly the scope it wants to request but has a set of adequate 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. 4. Group-ID consideration RFC 3307 [7] 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. 5. Deployment scenarios - Case studies This section gives examples of DHCPv6 deployments for IPv6 multicast address assignment. 5.1 Scenario 1: Site deployment Consider a site having configured 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 configures one RP for global scope with embedded-RP technology. The DHCPv6 server of the site can Durand Expires August 19, 2005 [Page 8] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 assign the complete set of addresses derived from the RP's address (see Embedded-RP [11]). 5.2 Scenario 2: Campus deployment Consider a campus having configured one DHCPv6 server for the entire site, and having several labs (in different subnets) having each a multicast scope for their own usage. Every lab might have for example a scope admin-local (scope 4), and the campus may have the scope site-local (scope 5). The problem of the DHCPv6 server is to assign appropriate addresses to each of the labs. The server can retrieve information about the location of the client according to the explanation given in section 11 of RFC 3315 [8]. 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. 5.3 Scenario 3: ISP deployment 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 configured 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 configured 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 [11]). This allocation could be typically hand-off allocation, as it is done between ISP and big customers (not end-users at home) for unicast or could be done with DHCPv6 prefix delegation as explained in this document. This way, every DHCPv6 server is then 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. Address allocation architectures are exactly the same. Nevertheless, we can note that any customer could deploy its own embedded-RP rather than using the one of its ISP, which simplifies this scenario. 6. Security considerations The security considerations related to the DHCPv6 protocol are discussed in the security considerations section of [8]. Durand Expires August 19, 2005 [Page 9] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 7. Acknowledgement The author would like to thank Bernard Tuy, Stig Venaas, Christian Strauf, Pekka Savola and Dave Thaler 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 [12], which was the initial document that raised the complete problematic of IPv6 multicast address assignment. Pekka Savola, Dave Thaler, Stig Venaas and Bernard Tuy have contributed to better state the problem and mention why the proposal is of interest. 8. Discussions Here are the current discussions and questions about this document: o Timers could be specified with a new DHCPv6 option rather than overloading the timers of the address o If the server cannot assign addresses for the required scopes, it could assign an address in any other scope it is configured for. 9. Changes from -00 o Clarification of the need for the proposal o The multicast address assignment state of the art is now let to ID.draft-ietf-mboned-addrarch [13]. o IPv6 multicast prefix delegation is now supported by this mechanism, from comments received in IETF 60th. 10. References 10.1 Normative references [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2970, December 1999. [3] R. Finlayson, "An Abstract API for Multicast Address Durand Expires August 19, 2005 [Page 10] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 Allocation", RFC 2771, February 2000. [4] M. Handley, C. Perkins and E. Whelan, "Session Announcement Protocol (SAP)", RFC 2974, October 2000. [5] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", RFC 3180, September 2001. [6] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [7] B. Haberman, "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. [8] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [9] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [10] O. Troan, R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [11] P. Savola and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", November 2004. 10.2 Informative references [12] 6NET project partners, "6NET D3.4.3 - IPv6 multicast address allocation study", May 2003. [13] P. Savola, "Overview of the Internet Multicast Addressing Architecture", November 2004. [14] J. Durand and P. Savola, "RA for IPv6 multicast prefixes", February 2005. Durand Expires August 19, 2005 [Page 11] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 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 August 19, 2005 [Page 12] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.</pre> IPv6 multicast address assignment with DHCPv6 Network Working Group J. Durand Internet-Draft GIP RE... Read more »
