Internet DRAFT - draft-smith-mldv2-link-unicast
draft-smith-mldv2-link-unicast
Internet Engineering Task Force M.R. Smith
Internet-Draft IMOT
Intended status: Standards Track March 29, 2013
Expires: September 30, 2013
MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6
draft-smith-mldv2-link-unicast-00
Abstract
Some multi-access link-layer technologies typically not provide good
IPv6 multicast performance, using link-layer multicasts, when the
volume of multicast traffic is significant. It would be possible to
replicate and then link-layer unicast multicast IPv6 traffic to
interested listeners to overcome these link-layer performance
limitations. This memo describes MLDv2 and IPv6 neighbor discovery
procedures to support link-layer unicast delivery of multicast IPv6
traffic.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 30, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Smith Expires September 30, 2013 [Page 1]
Internet-Draft MLDv2 Procedures for Link-Layer Unicast March 2013
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Unicast Link-Layer Information Determination . . . . . . 3
3.2. Determining When a Multicast Listener Becomes Unreachable 4
4. Operating Models . . . . . . . . . . . . . . . . . . . . . . 5
4.1. All Groups on an Interface . . . . . . . . . . . . . . . 5
4.2. Specific Groups on an Interface . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Change Log [RFC Editor please remove] . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Some multi-access link-layer technologies, such as IEEE 802.11,
typically do not provide good IPv6 multicast performance when the
volume of multicast traffic is significant. Additionally, unicast
performance of the link may also be impacted while significant
multicast traffic is present. To overcome link-layer multicast
performance problems, it could be useful to use packet replication
and link-layer unicasting of the IPv6 multicast traffic when the
node's capacity to do so exceeds the link-layer's multicast capacity
and/or performance. It could also be useful to use unicast
transmission of multicast IPv6 traffic to reduce power consumption on
battery powered devices attached to the link.
This link-layer unicast transmission of IPv6 multicast traffic would
be an alternative option to using link-layer multicast transmission.
Where necessary, such as when the link-layer unicast information for
the destination(s) cannot or cannot easily be determined, link-layer
multicast would continue to be used.
[RFC6085] updates the operation of IPv6 over Ethernet to support
link-layer unicast delivery of IPv6 multicast traffic. This is
possible as the destination link-layer address used for frames
carrying IPv6 multicast packets does not have to be a link-layer
multicast address. This technique could be applied to other multi-
Smith Expires September 30, 2013 [Page 2]
Internet-Draft MLDv2 Procedures for Link-Layer Unicast March 2013
access link-layer technologies that support IPv6, including point-to-
point link-layers, where the outgoing link-layer interface is the
required link-layer information.
[RFC6085] does not specify how the IPv6 multicast traffic sender
learns and maintains link-layer unicast destination information for
multicast IPv6 traffic delivery. This memo proposes these
procedures, using a combination of the functionality of IPv6
Multicast Listener Discovery protocol, version 2 (MLDv2) [RFC3810]
and IPv6 Neighbor Discovery [RFC4861]. MLDv2 is necessary as it
supports tracking of individual listeners.
These procedures are primarily applicable to multicast routers.
Hosts may also use these procedures if they are willing to act as a
passive observer of the operation of MLDv2 on the link, and perform
link-layer unicast replication of IPv6 multicast traffic for groups
for which they are sources.
1.1. Requirements Language
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. Requirements
To support unicast link-layer delivery of multicast traffic, in
addition to the existing MLDv2 procedures, the following will need to
be achieved:
o determination of the link-layer information of the multicast
listeners for which unicast link-layer delivery will be used,
o determination of when an individual multicast listener becomes
unreachable, so that delivery of multicast traffic using unicast
link-layer delivery to that listener can cease.
3. Procedures
3.1. Unicast Link-Layer Information Determination
MLDv2 listeners express their interest in receiving traffic destined
to one or more groups by issuing one or more Multicast Listener
Reports.
The source address used for a Multicast Listener Report must either
be the unspecified address (::) or a valid link-local address
[RFC3810].
Smith Expires September 30, 2013 [Page 3]
Internet-Draft MLDv2 Procedures for Link-Layer Unicast March 2013
The unspecified address is used when a valid link-local address has
not been acquired, and is used during IPv6 Neighbor Discovery
Duplicate Address Detection (DAD) [RFC4861]. These Reports are to be
discarded by multicast routers, as their purpose is to inform MLDv2
snooping switches of group membership for groups used during DAD. In
the context of this memo, they do not provide the information
necessary to determine the unicast link-layer information for a
multicast listener.
A link-local address is used as the source address for all other
Multicast Listener Reports. [RFC3810] specifies that Multicast
Listener Reports without valid link-local addresses must be silently
discarded, and that a valid link-local address is one that the router
has determined to belong to the link on which the Report was received
on. This requirement implies that for the Multicast Listener Report
to be accepted, the link-local source address must be already be
present in the multicast router's neighbor cache, and the link-layer
address resolved for link-layers that require it. Alternatively, it
implies that the Report should trigger neighbor presence discovery
for the Report's link-local source address. Note that in this latter
case it is not clear whether the Report should be stored until
neighbor presence discovery is complete and then processed or
discarded, or immediately discarded after neighbor presence discovery
is started. It may be useful to store the Multicast Listener Report
for processing after neighbor presence discovery is complete, however
it would be an optimisation, as Multicast Listener Reports are not
inherently reliable, and therefore will be retransmitted.
If the Multicast Listener Report link-local source address has been
determined to be valid using neighbor discovery, the link-layer
information necessary for link-layer unicast delivery of IPv6
multicast has also been determined. Multicast traffic towards this
listener can now be delivered using unicast link-layer transmission.
3.2. Determining When a Multicast Listener Becomes Unreachable
IPv6 Neighbor Unreachability Discovery (NUD) [RFC4861] actively
tracks the reachability of the unicast neighbors, or more
specifically the unicast IPv6 addresses(es) of the neighbors, that
traffic is being sent to.
MLDv2 supports per-host tracking of multicast listener status on an
interface. Hosts will be individually identified using the link-
local addresses they use as their Multicast Listener Report source
addresses.
If NUD detects that the link-local address of a multicast listener
has become unreachable, link-layer unicast transmission of multicast
Smith Expires September 30, 2013 [Page 4]
Internet-Draft MLDv2 Procedures for Link-Layer Unicast March 2013
IPv6 traffic should cease. This should occur as soon as possible, as
some link-layer technologies will resort to flooding traffic to all
link nodes if a unicast destination becomes unknown.
NUD's detection of the disappearance of the neighbor should be
considered the equivalent of receiving a Multicast Listener Report
from the link-local address owner, leaving all joined groups.
4. Operating Models
For a particular multicast interface on a router (or host), there are
two possible modes of operation for link-layer unicast transmission
of multicast traffic:
o all groups on the interface,
o specific groups on the interface.
4.1. All Groups on an Interface
In this mode of operation, all multicast groups available on the
interface are candidates for the use of link-layer unicast
transmission of multicast traffic. When possible, link-layer unicast
of multicast traffic should be used.
This mode of operation might be most useful when the hosts on the
link are or are likely to be battery powered. This would ensure that
the hosts are only receiving link-layer multicast traffic, perhaps
for groups they are not interested in, only when it is not possible
to use link-layer unicasts. This should improve the hosts' battery
life.
4.2. Specific Groups on an Interface
Alternatively, link-layer unicast transmission of multicast traffic
is only used for specific multicast groups. These groups will need
to be specified via some mechanism that is outside of the scope of
this memo. Examples of these mechanisms might be a list of groups
configured by a system operator, or via an automated and distributed
configuration protocol, that nominates specific multicast groups for
link-layer unicast transmission.
An example scenario might be one where low volume multicast traffic,
such as IPv6 neighbor discovery traffic, continues to be sent using
link-layer multicasts. High volume multicast traffic, carrying
video, is link-layer unicast to the subset of hosts that are
interested in it.
Smith Expires September 30, 2013 [Page 5]
Internet-Draft MLDv2 Procedures for Link-Layer Unicast March 2013
5. Acknowledgements
Review and comments were provided by YOUR NAME HERE!
This memo was prepared using the xml2rfc tool.
6. Security Considerations
The procedures described in this memo use a combination of the
existing functionality of MLDv2 and IPv6 Neighbor Discovery.
Consequently, the security considerations include those of both MLDv2
[RFC3810] and IPv6 Neighbor Discovery [RFC4861].
Link-layer multicasts of multicast IPv6 traffic will typically be
sent to all link-layer nodes, unless a technique such as MLD snooping
[RFC4541] is used to more selectively forward link-layer multicasts
to likely interested nodes. It is possible that multicast IPv6
traffic will be sent to nodes that are not interested in it, and for
which it would be beneficial for data confidentially reasons for them
not to receive it.
Link-layer unicast delivery of IPv6 multicast traffic provides an
improvement in data confidentiality for the multicast IPv6 traffic
that is unicast and successfully delivered to its destination. If
the link-layer unicast destination has disappeared, some link-layer
technologies will resort to flooding the unicast traffic to all
nodes. In this case, the data confidentially benefits of link-layer
unicast of multicast IPv6 traffic will have disappeared. Data
confidentiality will have returned to the level provided by
conventional link-layer multicast of multicast IPv6 traffic, when MLD
snooping or similar techniques are not in use.
The level of data confidentiality improvement is dependent on the
operating model of the interface sending the traffic (all groups or
specific groups), and whether it is necessary to resort to link-layer
multicasts when it is not or not easily possible to determine the
required link-layer unicast information. For example, for a
multicast group carrying video traffic, it is likely to be possible
to determine the link-layer unicast information for all interested
listeners, and therefore all multicast video traffic can be link-
layer unicast. Alternatively, if this technique is applied to IPv6
Neighbor Discovery, some functions of neighbor discovery cannot be
performed without link-layer multicasts, meaning that the data
confidentiality improvements will be lower.
7. Change Log [RFC Editor please remove]
draft-smith-mldv2-link-unicast-00, initial version, 2013-03-29
Smith Expires September 30, 2013 [Page 6]
Internet-Draft MLDv2 Procedures for Link-Layer Unicast March 2013
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
"Address Mapping of IPv6 Multicast Packets on Ethernet",
RFC 6085, January 2011.
Author's Address
Mark Smith
In My Own Time
PO BOX 521
HEIDELBERG, VIC 3084
AU
Email: markzzzsmith@yahoo.com.au
Smith Expires September 30, 2013 [Page 7]
