| Internet Engineering Task Force | M.R. Smith |
| Internet-Draft | IMOT |
| Intended status: Standards Track | April 11, 2013 |
| Expires: October 13, 2013 |
MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6
draft-smith-mldv2-link-unicast-00
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.
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 October 13, 2013.
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 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.
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-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.
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].
To support unicast link-layer delivery of multicast traffic, in addition to the existing MLDv2 procedures, the following will need to be achieved:
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].
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.
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 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.
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:
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.
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.
Review and comments were provided by YOUR NAME HERE!
This memo was prepared using the xml2rfc tool.
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.
draft-smith-mldv2-link-unicast-00, initial version, 2013-03-29
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6085] | Gundavelli, S., Townsley, M., Troan, O. and W. Dec, "Address Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085, January 2011. |
| [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. |