idnits 2.17.1 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 523. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 539), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2005) is 7007 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 453, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 456, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2970 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2771 (ref. '3') ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '4') ** Obsolete normative reference: RFC 3315 (ref. '8') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3513 (ref. '9') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3633 (ref. '10') (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Durand 3 Internet-Draft GIP RENATER 4 Expires: August 19, 2005 February 18, 2005 6 IPv6 multicast address assignment with DHCPv6 7 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 19, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document proposes a simple solution to solve IPv6 multicast 40 address assignment problem using the DHCPv6 protocol. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1 IPv6 multicast deployment status . . . . . . . . . . . . . 3 46 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.3 SSM: no solution needed . . . . . . . . . . . . . . . . . 3 48 1.4 Session announcement considerations . . . . . . . . . . . 4 49 2. State of the art for address assignment . . . . . . . . . . . 4 50 3. Assignment with DHCPv6 . . . . . . . . . . . . . . . . . . . . 4 51 3.1 New DHCPv6 options . . . . . . . . . . . . . . . . . . . . 4 52 3.1.1 IA_MA option for IPv6 Multicast Addresses . . . . . . 4 53 3.1.2 Scope Option for IPv6 multicast address . . . . . . . 6 54 3.2 Address timers . . . . . . . . . . . . . . . . . . . . . . 6 55 3.3 Assignment of a multicast prefix . . . . . . . . . . . . . 7 56 3.4 Client and server behavior . . . . . . . . . . . . . . . . 7 57 4. Group-ID consideration . . . . . . . . . . . . . . . . . . . . 8 58 5. Deployment scenarios - Case studies . . . . . . . . . . . . . 8 59 5.1 Scenario 1: Site deployment . . . . . . . . . . . . . . . 8 60 5.2 Scenario 2: Campus deployment . . . . . . . . . . . . . . 9 61 5.3 Scenario 3: ISP deployment . . . . . . . . . . . . . . . . 9 62 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 63 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 64 8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 9. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 10 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 10.1 Normative references . . . . . . . . . . . . . . . . . . . . 10 68 10.2 Informative references . . . . . . . . . . . . . . . . . . . 11 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 70 Intellectual Property and Copyright Statements . . . . . . . . 13 72 1. Introduction 74 Embedded-RP [11] is the only available solution for IPv6 interdomain 75 ASM. Embedded-RP requires an IPv6 multicast address assignment 76 mechanism, as multicast addresses mapping to the RP cannot be guessed 77 and manually built by users. This is depicted in section 2.1.2 of the 78 IETF working group document draft-ietf-mboned-addrarch [13]. 80 This document proposes a simple solution to assign IPv6 multicast 81 addresses or prefixes using the DHCPv6 protocol [8]. 83 1.1 IPv6 multicast deployment status 85 The document draft-jdurand-ipv6-multicast-ra [14] recalls the 86 following: 88 "The deployment of IPv6 multicast is expanding. Some networks have 89 already put the service in production. Some gateways have been 90 deployed, making it possible to have interoperability between IPv4 91 and IPv6 multicast. Some sites have even stopped IPv4 multicast, due 92 to its complexity (due to NAT and MSDP for example) and only rely on 93 IPv6 multicast, using the deployed gateways for interoperability with 94 IPv4. 96 As of this writing, most sessions are created manually from 97 unicast-prefix based address space [6], or use SDR to form a 98 semi-random address. Nevertheless these addresses cannot fit with 99 embedded-RP [11] which is the only existing solution for IPv6 100 interdomain ASM. 102 Some people argue that SSM solves the problem but there is nowadays a 103 demand from customers to be capable to have multicast sessions (both 104 IPv4 and IPv6) with multiple sources (e.g., conferencing) and it is 105 not clear how to achieve this with SSM. While "multiple-source SSM" 106 could potentially be done with the aid of SIP or RTP, this does not 107 exist yet, and a simple solution for ASM is needed." 109 1.2 Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [1]. 115 1.3 SSM: no solution needed 117 In the SSM model, as the channel is defined by the tuple (source 118 address , group address), a collision can only occur if a host would 119 like to be a sender for 2 different groups having the same address. 121 Therefore, it is sufficient for a sender to choose different 122 addresses for different channels, this is a decision local to the 123 host. This document only considers the ASM model which is a bit more 124 complex. 126 1.4 Session announcement considerations 128 This document does not address the session announcement problem. It 129 only answers the question of large scale address assignemnt of IPv6 130 multicast addresses. Announcement of the sessions can still be done 131 using web pages, emails, directories, SAP, etc. 133 2. State of the art for address assignment 135 MADCAP [2] solves, or could solve, the multicast address assignment 136 problem for both IPv4 and IPv6. However, MADCAP is a fork of DHCP, it 137 has only a couple of implementations which have not been widely 138 deployed. We assume that a mechanism that would be a simple extension 139 to a more widely available mechanism (DHCPv6) could be more deployed. 141 This proposal and draft-jdurand-ipv6-multicast-ra [14] simplify the 142 assignment architecture since the unicast and multicast address 143 assignment mechanisms become the same. We consider at this stage only 144 IPv6 multicast since most of the key elements used are already 145 defined, and interaction with IPv4 multicast is ensured. If felt 146 needed by the community, this proposal could be extended to IPv4. 148 3. Assignment with DHCPv6 150 3.1 New DHCPv6 options 152 This section introduces new options for IPv6 multicast address 153 assignment with DHCPv6. 155 3.1.1 IA_MA option for IPv6 Multicast Addresses 157 RFC 3315 [8] defines the following options for Identity Associations 158 (IA): 160 o IA_NA option for Non temporary Addresses 162 o IA_TA option for Temporary Addresses 164 This document introduces a third option: the IA_MA option for IPv6 165 Multicast Addresses. This option is used to carry an IA_MA, the 166 parameters associated with the IA_MA, and the addresses associated 167 with the IA_MA. The format of the IA_MA option is: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | option-code | option-len | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | IAID (4octets) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | 177 . IA_MA-options . 178 . . 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 option-code: OPTION_IA_MA (TBD) 183 option-len: 4 + length of IA_MA-options field 185 IAID: The unique identifier for this IA_MA; the IAID must be unique 186 among the identifiers for all of this client's IA_MAs. The number 187 space for IA_MA IAIDs is separate from the number space for IA_NA 188 and IA_TA IAIDs 190 IA_MA-Options: Options associated with this IA_MA 192 The IA_MA-options field encapsulates those options that are specific 193 to this IA_MA. For example, all of the IA Address Options carrying 194 the multicast addresses associated with this IA_MA are in the 195 IA_MA-options field. 197 Each IA_MA carries one "set" of multicast addresses; that is, at most 198 one address per session created by the client requiring an address. 200 An IA_MA option may only appear in the options area of a DHCP 201 message. A DHCP message may contain multiple IA_MA options. The 202 status of any operations involving this IA_MA is indicated in a 203 Status Code option in the IA_MA-options field. 205 Note that an IA has no explicit "lifetime" or "lease length" of its 206 own. When the valid lifetimes of all of the addresses in an IA_MA 207 have expired, the IA can be considered as having expired. 209 An IA_MA option does not include values for T1 and T2 (see RFC 3315 210 [8]). A client MAY request that the lifetimes of multicast addresses 211 be extended by including the addresses in a IA_MA option sent in a 212 Renew or Rebind message to a server. For example, a client would 213 request an extension on the lifetime of a multicast address to allow 214 an application to continue a multicast session. 216 The client obtains new multicast addresses by sending an IA_MA option 217 with a new IAID to a server. The server will generate new multicast 218 addresses and return them to the client. In case the clients needs to 219 extend the multicast session, it sends a Renew message to the server 220 with the IA_MA and addresses in parameters. 222 3.1.2 Scope Option for IPv6 multicast address 224 The scope option for IPv6 multicast addresses is used by the clients 225 to request multicast addresses with a certain scope. It is included 226 in the IA address option IAaddr-options field defined in section 22.5 227 of RFC 3315 [8]. A user can attach more than one scope option for 228 IPv6 multicast address to an IA address option if the client does not 229 know exactely the scope it wants to request but has a set of adequate 230 scope values. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | OPTION_SCOPE | option-len | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | scope | res | 238 +-+-+-+-+-------+ 240 option-code: OPTION_SCOPE (TBD) 242 option-len: 1 244 scope: The scope value for the requested IPv6 multicast address, 245 according to values defined in RFC 3513 [9] 247 res: This field is reserved for future use. The 4 bits of this field 248 MUST be set to 0, and MUST be ignored on receipt 250 3.2 Address timers 252 NOTE: There have been some discussions about using some options for 253 the timers. This is let to next releases of the document as this 254 release really focuses on why an assignment based on DHCPv6 has an 255 interest. 257 The IA address option defined in RFC 3315 [8] contains the following 258 32 bits fields: 260 o preferred-lifetime: The preferred lifetime for the IPv6 address in 261 the option, expressed in units of seconds 263 o valid-lifetime: The valid lifetime for the IPv6 address in the 264 option, expressed in units of seconds 266 We suggest to use these fields, usually defined for unicast 267 addresses, for IPv6 multicast addresses, with the definition written 268 above. 270 The maximum value for these lifetimes is 2^32 seconds or 49710 days 271 equivalent to 136 years. Therefore a host that wants to be assigned 272 an address for a 2 days session occuring in 30 days can request an 273 address with a preferred lifetime value of 32 days. According to the 274 IPv6 multicast addressing space available, servers should allow this 275 type of requests, or at least should permit a certain number of 276 long-term assignment per host. The address is directly assigned by 277 the DHCP server when the request is received. We suggest here not 278 using the parameters minDesiredStartTime and maxDesiredStartTime 279 specified in RFC 2771 [3] which bring too much complexity for the 280 assignment and don't really make sense for IPv6 where many addresses 281 are available. 283 3.3 Assignment of a multicast prefix 285 The assignment of a multicast prefix can be needed in the following 286 scenarios: 288 o An ISP needs to assign a block of IPv6 multicast address to an 289 enterprise, assigning IPv6 multicast addresses to its hosts. This 290 scenario will most likely occur when DHCPv6 prefix delegation [10] 291 is already used to assign unicast prefixes to the enterprise. 293 o Also it is most likely that the multicast applications will not 294 support at the beginning the API to request for an IPv6 multicast 295 address via DHCPv6. Then, on startup, or when connected to a new 296 network, a host could ask for an IPv6 multicast prefix. 297 Applications could then choose locally multicast addresses in the 298 prefix assigned to the host. 300 To fulfill this need, the prefix delegation mechanism described in 301 RFC 3633 [10] is needed also for multicast prefixes. The actual 302 specifications of the IPv6 prefix Options for DHCPv6 do not need to 303 be changed to support multicast prefix delegations. The only thing to 304 keep in mind is that multicast prefix delegation can also occur 305 between a router and a host to fulfill the second requirement 306 mentioned above. 308 3.4 Client and server behavior 310 The procedures to request an IPv6 multicast address is more or less 311 the same than the ones described in RFC 3315 [8] to request a 312 temporary IPv6 address. The differences are following: 314 o The client uses IA-type IA_MA described above to ask for IPv6 315 multicast addresses. 317 o The client SHOULD use the Scope Option in solicit and request 318 messages to tell the server the scope wanted for the IPv6 319 multicast address requested. It can include more than one Scope 320 Option for IPv6 multicast address per addresses requested in case 321 the client does not know exactly the scope it wants to request but 322 has a set of adequate scope values. 324 o The client SHOULD specify the lifetimes for every address it wants 325 to be assigned in solicit, request, renew and rebind messages. 327 o The server MUST assign addresses only if it can assign an address 328 matching one of the scope requested. In case the server can't 329 assign an address with the requested scopes, it must include the 330 Status Code Option NoAddrsAvail in the advertise and reply 331 messages and should include a status message with the scopes that 332 can be assigned by the server and their description. 334 o If no scope option is specified by the client, the server can 335 assign a multicast address with any scope. It can be a default 336 scope value configured by the DHCP server administrator. 338 4. Group-ID consideration 340 RFC 3307 [7] defines guidelines for the choice of IPv6 multicast 341 group identifier (the last 32 bits of the IPv6 multicast address). It 342 specifies that for dynamic IPv6 multicast address allocation, the 343 group-ID MUST be in the range 0x80000000 to 0xFFFFFFF. 345 5. Deployment scenarios - Case studies 347 This section gives examples of DHCPv6 deployments for IPv6 multicast 348 address assignment. 350 5.1 Scenario 1: Site deployment 352 Consider a site having configured a DHCPv6 server and having one RP 353 for a site-local scope (scope 5). In this simple scenario, the DHCPv6 354 server can assign the complete set of addresses with a site-local 355 scope. 357 We have the same scenario if the site configures one RP for global 358 scope with embedded-RP technology. The DHCPv6 server of the site can 359 assign the complete set of addresses derived from the RP's address 360 (see Embedded-RP [11]). 362 5.2 Scenario 2: Campus deployment 364 Consider a campus having configured one DHCPv6 server for the entire 365 site, and having several labs (in different subnets) having each a 366 multicast scope for their own usage. Every lab might have for example 367 a scope admin-local (scope 4), and the campus may have the scope 368 site-local (scope 5). The problem of the DHCPv6 server is to assign 369 appropriate addresses to each of the labs. 371 The server can retrieve information about the location of the client 372 according to the explanation given in section 11 of RFC 3315 [8]. The 373 server can determine this way in which lab the client is and assign 374 adequate addresses. This way a server can assign the same address 375 twice to different clients in different labs. 377 5.3 Scenario 3: ISP deployment 379 Consider an ISP providing a global RP service to its customers. The 380 ISP decided to use embedded-RP technology for this RP. Every 381 customers having configured a DHCPv6 server would like to assign IPv6 382 multicast addresses based on the RP of their ISP. The problem is to 383 avoid overlap between addresses assigned by every DHCPv6 servers. 385 In this scenario, the ISP having configured an RP would allocate a 386 range of IPv6 multicast addresses based on its RP to every customer 387 having subscribed for the service (as explained in section 5.2 of 388 Embedded-RP [11]). This allocation could be typically hand-off 389 allocation, as it is done between ISP and big customers (not 390 end-users at home) for unicast or could be done with DHCPv6 prefix 391 delegation as explained in this document. This way, every DHCPv6 392 server is then configured with a different multicast address range, 393 all matching the same RP. This means that ISPs need to allocate IPv6 394 multicast addresses to their customers, as they do today for IPv6 395 unicast. Address allocation architectures are exactly the same. 396 Nevertheless, we can note that any customer could deploy its own 397 embedded-RP rather than using the one of its ISP, which simplifies 398 this scenario. 400 6. Security considerations 402 The security considerations related to the DHCPv6 protocol are 403 discussed in the security considerations section of [8]. 405 7. Acknowledgement 407 The author would like to thank Bernard Tuy, Stig Venaas, Christian 408 Strauf, Pekka Savola and Dave Thaler for their good contributions to 409 this memo. The author would also like to thank Ralph Droms who took 410 time to consider the IPv6 multicast assignment problem and introduced 411 the concept of the identity association for IPv6 multicast addresses. 412 The author would also like to thank all the people having worked on 413 the 6NET Deliverable 3.4.3 [12], which was the initial document that 414 raised the complete problematic of IPv6 multicast address assignment. 416 Pekka Savola, Dave Thaler, Stig Venaas and Bernard Tuy have 417 contributed to better state the problem and mention why the proposal 418 is of interest. 420 8. Discussions 422 Here are the current discussions and questions about this document: 424 o Timers could be specified with a new DHCPv6 option rather than 425 overloading the timers of the address 427 o If the server cannot assign addresses for the required scopes, it 428 could assign an address in any other scope it is configured for. 430 9. Changes from -00 432 o Clarification of the need for the proposal 434 o The multicast address assignment state of the art is now let to 435 ID.draft-ietf-mboned-addrarch [13]. 437 o IPv6 multicast prefix delegation is now supported by this 438 mechanism, from comments received in IETF 60th. 440 10. References 442 10.1 Normative references 444 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 445 Levels", RFC 2119, March 1997. 447 [2] S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic 448 Client Allocation Protocol (MADCAP)", RFC 2970, December 1999. 450 [3] R. Finlayson, "An Abstract API for Multicast Address 451 Allocation", RFC 2771, February 2000. 453 [4] M. Handley, C. Perkins and E. Whelan, "Session Announcement 454 Protocol (SAP)", RFC 2974, October 2000. 456 [5] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", RFC 3180, 457 September 2001. 459 [6] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 Multicast 460 Addresses", RFC 3306, August 2002. 462 [7] B. Haberman, "Allocation Guidelines for IPv6 Multicast 463 Addresses", RFC 3307, August 2002. 465 [8] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. 466 Carney, "Dynamic Host Configuration Protocol for IPv6 467 (DHCPv6)", RFC 3315, July 2003. 469 [9] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) 470 Addressing Architecture", RFC 3513, April 2003. 472 [10] O. Troan, R. Droms, "IPv6 Prefix Options for Dynamic Host 473 Configuration Protocol (DHCP) version 6", RFC 3633, December 474 2003. 476 [11] P. Savola and B. Haberman, "Embedding the Rendezvous Point (RP) 477 Address in an IPv6 Multicast Address", November 2004. 479 10.2 Informative references 481 [12] 6NET project partners, "6NET D3.4.3 - IPv6 multicast address 482 allocation study", May 2003. 484 [13] P. Savola, "Overview of the Internet Multicast Addressing 485 Architecture", November 2004. 487 [14] J. Durand and P. Savola, "RA for IPv6 multicast prefixes", 488 February 2005. 490 Author's Address 492 Jerome Durand 493 GIP RENATER 494 151 Bd de l'Hopital 495 Paris 75013 496 France 498 Phone: +33 1 53 94 20 30 499 EMail: Jerome.Durand@renater.fr 501 Intellectual Property Statement 503 The IETF takes no position regarding the validity or scope of any 504 Intellectual Property Rights or other rights that might be claimed to 505 pertain to the implementation or use of the technology described in 506 this document or the extent to which any license under such rights 507 might or might not be available; nor does it represent that it has 508 made any independent effort to identify any such rights. Information 509 on the IETF's procedures with respect to rights in IETF Documents can 510 be found in BCP 78 and BCP 79. 512 Copies of IPR disclosures made to the IETF Secretariat and any 513 assurances of licenses to be made available, or the result of an 514 attempt made to obtain a general license or permission for the use of 515 such proprietary rights by implementers or users of this 516 specification can be obtained from the IETF on-line IPR repository at 517 http://www.ietf.org/ipr. 519 The IETF invites any interested party to bring to its attention any 520 copyrights, patents or patent applications, or other proprietary 521 rights that may cover technology that may be required to implement 522 this standard. Please address the information to the IETF at 523 ietf-ipr@ietf.org. 525 Disclaimer of Validity 527 This document and the information contained herein are provided on an 528 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 529 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 530 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 531 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 532 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 533 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 535 Copyright Statement 537 Copyright (C) The Internet Society (2005). This document is subject 538 to the rights, licenses and restrictions contained in BCP 78, and 539 except as set forth therein, the authors retain all their rights. 541 Acknowledgment 543 Funding for the RFC Editor function is currently provided by the 544 Internet Society.