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.
Subscribe to:
Post Comments (Atom)
Post a Comment