One document matched: draft-jdurand-ipv6-multicast-ra-00.txt
Network Working Group J. Durand
Internet-Draft GIP RENATER
Expires: August 13, 2005 P. Savola
CSC/FUNET
February 9, 2005
Route Advertisement Option for IPv6 Multicast Prefixes
draft-jdurand-ipv6-multicast-ra-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a way to advertise IPv6 multicast prefix
availability using Neighbor Discovery (RFC2461). This multicast RA
option can be used by routers to announce a set of multicast prefixes
that can be on the link to form new group addresses.
Durand & Savola Expires August 13, 2005 [Page 1]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 No Solution Needed: SSM . . . . . . . . . . . . . . . . . 3
1.2 Out of Scope: Session Announcement/Rendezvous . . . . . . 4
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Other Mechanisms for Address Assignment . . . . . . . . . . 4
3. Multicast Prefix Information Option . . . . . . . . . . . . 4
4. Sending RA with a Multicast Prefix Information Option . . . 6
5. Receiving RA with a Multicast Prefix Information Option . . 6
5.1 Processing the Multicast Prefix Information Option . . . . 6
5.2 Forming an Address from a Multicast Prefix . . . . . . . . 6
6. Multicast DAD . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security considerations . . . . . . . . . . . . . . . . . . 7
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 8
9. Open issues / Discussions . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1 Normative references . . . . . . . . . . . . . . . . . . 8
10.2 Informative references . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
A. An Alternative Prefix Information Encoding . . . . . . . . . 10
A.1 Drawbacks/advantages . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 12
Durand & Savola Expires August 13, 2005 [Page 2]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
1. Introduction
The deployment of IPv6 multicast is rapidly 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 [RFC3306], or use SDR to form a
semi-random address. Nevertheless these addresses cannot fit with
embedded-RP [RFC3956] 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.
Section 2.1.2 of [draft-ietf-mboned-addrarch] highlights the fact
that IPv6 multicast embedded-RP [RFC3956] addresses require an
assignment mechanism, also justifying work on a multicast address
assignment mechanism.
This document defines a multicast prefix information option to be put
in Neighbor Discovery [RFC2461] Router Advertisement messages. This
option can be used by routers to announce a set of multicast prefixes
that can be used on the link. A multicast application can then
choose an address derived from the announced IPv6 multicast prefix to
start an IPv6 multicast session.
1.1 No Solution Needed: SSM
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 is a source in two different multicast sessions,
using the same source and group addresses. Therefore, it is
sufficient for a sender to choose different addresses for different
channels, and this is a decision local to the host. Therefore we
only consider ASM in this document.
Durand & Savola Expires August 13, 2005 [Page 3]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
1.2 Out of Scope: Session Announcement/Rendezvous
This document does not try to describe a solution how the other nodes
find out which group addresses are generated by the host from the
prefix. Session announcement or "rendezvous" can be done e.g., using
web pages, emails, directories, etc.
1.3 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 [RFC2119].
2. Other Mechanisms for Address Assignment
[draft-ietf-mboned-addrarch] presents the different ways to assign
today multicast addresses. It mentions MADCAP [RFC2730] and
[draft-jdurand-assign-addr-ipv6-multicast-dhcpv6] that are
client-server protocols for IP multicast address assignment.
It appears that these solutions can be too complicated in the
situations where 1) MADCAP service infrastructure is not available
and cannot be deployed, or 2) DHCPv6 stateful (multicast) address
assignment is not available and cannot (or there is no desire to) be
deployed. Using a Prefix Information option requires no state in the
network, contrary to DHCPv6 or MADCAP.
Note that for link-scoped multicast address assignment, hosts must
use the specifications described in
[draft-ietf-ipv6-link-scoped-mcast] instead.
3. Multicast Prefix Information Option
NOTE: An alternative encoding, re-using the current Prefix
Information option is presented in Appendix A.
A router can send multicast prefixes on a link, using the multicast
prefix information option in router advertisement options. The
following figure presents the multicast prefix information option:
Durand & Savola Expires August 13, 2005 [Page 4]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Multicast |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: (TBD)
Length: 3
Prefix Length: 8-bit unsigned integer. The number of leading bits in
the Multicast Prefix that are part of the prefix, the rest being
specific to the link. The valid values range from 16 to 128.
Reserved1: 8-bit unused field. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Valid Lifetime: 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) that the prefix
is valid for the purpose of being used by applications for
multicast sessions. A value of all one bits (0xffffffff)
represents infinity.
Prefix: An IPv6 address or a prefix of an IPv6 address. The Prefix
Length field contains the number of valid leading bits in the
prefix. The bits in the prefix after the prefix length are
reserved and MUST be initialized to zero by the sender and ignored
by the receiver. A router SHOULD NOT send a multicast prefix
option for any prefix that is not a multicast prefix (e.g that is
not in FF00::/8) and a host SHOULD ignore such a multicast prefix
option.
Description: The Multicast Prefix Information option provide hosts
with a multicast prefix that can be used on the network. The
Multicast Prefix Information option appears in Router
Advertisement packets and MUST be silently ignored for other
messages.
Durand & Savola Expires August 13, 2005 [Page 5]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
4. Sending RA with a Multicast Prefix Information Option
Multicast prefix information is sent in RA messages. Therefore it
follows the rules described in [RFC2461]. The following rules are
more specific to multicast prefix information option:
o A router includes multicast prefix information option to all the
RAs (whether solicited or unsolicited) if a multicast prefix has
been configured.
o The multicast prefix information option SHOULD NOT be included if
there are no multicast prefixes to advertise.
5. Receiving RA with a Multicast Prefix Information Option
5.1 Processing the Multicast Prefix Information Option
For each Multicast Prefix Information (MPI) option, a host processes
it similar to unicast PI (RFC2461, Section 6.3.4):
o If the prefix is not a multicast prefix (FF00::/8), silently
ignore the MPI option.
o If the prefix is of the interface- or link-local scope (FFYX::/8,
for all values of Y where X is "1" or "2"), silently ignore the
MPI option.
o If the prefix is not already present in the Prefix List, and the
MPI option's Valid Lifetime field is non-zero, create a new entry
for the prefix and initialize its invalidation timer to the Valid
Lifetime value in the MPI option.
o If the prefix is already present in the host's Prefix List as the
result of a previously-received advertisement, reset its
invalidation timer to the Valid Lifetime value in the MPI option.
If the new Lifetime value is zero, time-out the prefix immediately
(see Section 6.3.5 of RFC2461).
o If the MPI option's Valid Lifetime field is zero, and the prefix
is not present in the host's Prefix List, silently ignore the
option.
This memo does not impose the "two hour rule" of RFC2462.
5.2 Forming an Address from a Multicast Prefix
If the Prefix Length field is "96" (i.e., the group-id is 32 bits
Durand & Savola Expires August 13, 2005 [Page 6]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
long), a multicast address may be formed automatically. Otherwise an
automatic addresss generation MUST NOT be used.
When an application wants to start a multicast session, it chooses a
prefix among the the locally stored multicast prefixes. This prefix
is chosen following application needs (desired scope etc.) in an
unspecified manner (e.g., [RFC2771]). Then the application computes
an address derived from the prefix chosen.
This document does not specify the exact algorithm which must be used
to automatically generate the address. However, it MUST be generated
in a random or pseudo-random fashion. The output of the
randomization function is 31 random bits which is appended to the
high-order bit of one to form the group-ID. ([RFC3307] requires that
dynamic assignment group-IDs MUST be in the range 0x80000000 to
0xFFFFFFF.)
6. Multicast DAD
A host can perform a DAD when it has chosen a multicast address to
make sure it is not used on the link at the time being. However,
this does not prevent collisions in the cases when nodes creating
sessions are mobile or have been turned off at the time when DAD is
performed.
DAD would only need to be performed to ensure uniqueness within the
local link, among other hosts which may have auto-generated addresses
from the dynamic group-ID space.
It is highly unlikely that 2 hosts on the same link randomly derive
the same multicast address from the same prefix, and at the moment we
do not specify an algorithm to check the uniqueness.
7. Security considerations
The security considerations related to the Neighbor Discovery
protocol are discussed in [RFC2461]. The security is similar to that
of a unicast prefix from the on-link determination perspective
(RFC2461).
At the moment, there is no "two hour rule" which is used for unicast
address autoconfiguration (RFC2462). This allows anyone on the link
to invalidate a valid prefix by advertising Valid Lifetime of zero.
This can be easily fixed if this deemed to be a threat.
SEND [I-D.ietf-send-ndopt] can be used to sign the messages, but
additional code would be needed to verify that the prefix in MPI
option is part of the prefix the router is certified to advertise.
Durand & Savola Expires August 13, 2005 [Page 7]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
8. Acknowledgement
Stig Venaas provided contributions to the initial draft.
9. Open issues / Discussions
Here are the current discussions and questions about this document:
o New Prefix Information option, or re-use the existing PI, and
existing ND mechanisms?
o Should the MPI have the "two hour rule" of PI for address
configuration?
o Randomization, do we need to specify the exact algorithm?
o Multicast DAD, do we need to define it? Here or elsewhere?
10. References
10.1 Normative references
[I-D.ietf-send-ndopt]
Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)",
Internet-Draft draft-ietf-send-ndopt-06, July 2004.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2461] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC3956] P. Savola and B. Haberman, "Embedding the Rendezvous Point
(RP) Address in an IPv6 Multicast Address", November 2004.
10.2 Informative references
[D343] 6NET project partners, "6NET D3.4.3 - IPv6 multicast
address allocation study", May 2003.
Durand & Savola Expires August 13, 2005 [Page 8]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
[RFC2730] S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", RFC 2970, December
1999.
[RFC2771] R. Finlayson, "An Abstract API for Multicast Address
Allocation", RFC 2771, February 2000.
[RFC3306] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3315] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[draft-ietf-ipv6-link-scoped-mcast]
J-S. Park, M-K. Shin and H-J. Kim, "Link Scoped IPv6
Multicast Addresses", December 2004.
[draft-ietf-mboned-addrarch]
P. Savola, "Overview of the Internet Multicast Addressing
Architecture", November 2004.
[draft-jdurand-assign-addr-ipv6-multicast-dhcpv6]
J. Durand, "IPv6 multicast address assignment with
DHCPv6", January 2005.
Authors' Addresses
Jerome Durand
GIP RENATER
151 Bd de l'Hopital
Paris 75013
France
Phone: +33 1 53 94 20 30
Email: Jerome.Durand@renater.fr
Pekka Savola
CSC/FUNET
Espoo
Finland
Email: psavola@funet.fi
Durand & Savola Expires August 13, 2005 [Page 9]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
Appendix A. An Alternative Prefix Information Encoding
Multicast Prefix can be encoded also as follows, based on RFC2461
section 4.6.2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type, Length, Valid Lifetime, Preferred Lifetime, Reserved1 and
Reserved2 fields are set as specified in RFC2461.
L (onlink) and A (address configuration) flags MUST be set to zero.
This prevents the multicast prefix to be used for address
configuration or onlink determination on non-upgraded hosts which
don't properly parse a multicast address in the prefix field.
Prefix Length indicates the number of bits in the prefix which belong
to the "network" part. The rest can be used for creating new
multicast sessions (with caveats of RFC3307).
Prefix is the multicast prefix.
A.1 Drawbacks/advantages
Advantages of this approach, compared to a separate option, are:
o SEND mechanisms for Prefix Information options work out of the
box.
o Code and specification reuse. Processing of valid/preferred
lifetimes etc. is identical as with unicast prefixes and doesn't
Durand & Savola Expires August 13, 2005 [Page 10]
Internet-Draft RA Option for IPv6 Multicast Prefix February 2005
need to be discussed here.
On the other hand, drawbacks are:
o Many implementations quietly discard multicast prefixes in the PI
option. Some even print a warning message about that. It will be
more difficult to know whether the host supports multicast
prefixes or not.
o Code and specification can be reused between two very similar
options in any case.
o Overloading new semantics on old options results in some amount of
confusion.
o SEND doesn't really work (practically, operationally) in any case,
because someone has to delegate the unicast-prefix based multicast
addresses in certificates, and I doubt anyone is going to do that
any time soon..
Durand & Savola Expires August 13, 2005 [Page 11]
Internet-Draft RA Option for IPv6 Multicast Prefix 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 procedures with respect to rights in RFC 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.
Durand & Savola Expires August 13, 2005 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 11:34:43 |