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]