IPv6 Working Group Greg Daley
INTERNET-DRAFT Richard Nelson
Expires: February 2003 Monash University CTIE
August 2002
Duplicate Address Detection Optimization using
IPv6 Multicast Listener Discovery
draft-daley-ipv6-mcast-dad-00.txt
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Definitions of requirements keywords are in accordance with the IETF
Best Current Practice - RFC2119 [KEYW-RFC]
Abstract
This draft describes a possible optimization to Duplicate Address
Detection (DAD) which can be used to successfully terminate DAD
early, based on the presence of listeners on the link-scope solicited
nodes multicast address.
Table of Contents
Status of this Memo.......................................... 1
Abstract..................................................... 1
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 1]
INTERNET-DRAFT DAD Optimization with MLD August 2002
Table of Contents............................................ 1
1.0 Introduction............................................. 2
1.1 Terminology............................................. 3
2.0 Protocol Overview........................................ 4
3.0 Message Formats.......................................... 4
3.1 Multicast Listener Discovery Report..................... 4
3.2 Multicast Listener Discovery Response................... 5
4.0 Protocol Operation....................................... 6
4.1 Host Operations......................................... 7
4.2 Querier Router Operations............................... 7
5.0 Robustness Mechanisms.................................... 8
5.1 Backoff Mechanism for Responses......................... 8
5.2 Multiple Requests for the same Multicast Group.......... 8
5.3 Subnets Without Routers................................. 9
5.4 Multiple Addresses Mapping to Solicited-Node Multicast.. 9
5.5 Exhaustion of Querier Router's Storage.................. 9
6.0 Variables and Default values............................. 9
6.1 Maximum Report Responses................................ 10
7.0 IANA Considerations...................................... 10
8.0 Security Considerations.................................. 10
8.1 Excessive Requests for Response ........................ 10
8.2 Creating Non-Existent Multicast Groups.................. 10
8.3 Malicious Responses..................................... 10
Normative References......................................... 10
Non-Normative References..................................... 11
Acknowledgements............................................. 11
Authors' Address............................................. 11
Appendix..................................................... 12
1.0 Introduction
Duplicate Address Detection[SAA-RFC], is used by internet nodes to
ensure that devices connecting to a multicast capable network do not
configure unicast addresses which are already configured on nodes
within that subnet. DAD incurs a delay while the tentative address
is being tested. This is undesirable for many nodes, such as mobile
nodes.
Nodes that have completed DAD, and own an address listen on the link-
scope solicited-node multicast address[ARCH-RFC] related to the IPv6
address which they have completed DAD on[SAA-RFC]. When a new node
attempts to configure an address on the network, it sends a neighbor
solicitation message to the same address, and succeeds if no device
responds to this message within a timeout period. As part of this
process, the new node also listens to the solicited-node multicast
address
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 2]
INTERNET-DRAFT DAD Optimization with MLD August 2002
The MLD RFC requires a node to send an MLD report before listening to
the solicited-node multicast address[MLD-RFC]. This process requires
informing the router on a link about the presence of listeners for
the address, so that a multicast-group can be managed.
The optimization described in this document allows nodes to ask the
router to tell them if they are the first node to enter this
multicast group. If they are the first to enter the group then it
follows that no-one else is currently performing DAD defence against
the required unicast address.
This reduces the delay incurred to successfully complete DAD.
1.1 Terminology
IP - Internet Protocol Version 6 (IPv6)[IP6-RFC].
DAD - Duplicate Address Detection [SAA-RFC]
MLD - Multicast Listener Discovery [MLD-RFC]
node - a device that implements IPv6.
router - a node that forwards IPv6 packets not explicitly
addressed to itself.
host - any node that is not a router.
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer
immediately below IPv6. Examples are Ethernets (simple
or bridged); PPP links; X.25, Frame Relay, or ATM
networks; and internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself.
neighbors - nodes attached to the same link.
address - an IPv6-layer identifier for an interface or a set of
interfaces.
querier - router on the subnet which actively queries MLD
state.
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 3]
INTERNET-DRAFT DAD Optimization with MLD August 2002
2.0 Protocol Overview
MLD [MLD-RFC] defines that on entering a Multicast group an
unsolicited MLD report is sent by a node. This tells the MLD
routers that support is required for the specified group.
When attempting Duplicate Address Detection on a tentative address,
the node sends an MLD Report-Requesting-Response message. This
message serves two purposes. Firstly, it contains a report
compatible with the Multicast Listener Discovery Specification, for
the purposes of telling the router of the listener's presence.
Secondly, the report asks the MLD querier router to respond if the
group is previously unknown. Limiting response to the querier router
prevents multiple responses and allows for simple rate-limiting
operation.
If the response is not received, DAD will continue in conformance to
the Stateless Address Autoconfiguration RFC [SAA-RFC].
3.0 Message Formats
The protocol makes use of one modified and one new message from MLD.
3.1 Multicast Listener Discovery Report
The modified MLD Report allows nodes to request the Querier Router to
respond if the multicast group was empty before the node sent the
report.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Addr +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 4]
INTERNET-DRAFT DAD Optimization with MLD August 2002
Fields:
Type Multicast Listener Report (decimal 131)
Code 0 Response not requested
(TBA guess: 1) Response requested
If a this field contains any other code
values, it MUST be ignored.
Checksum Covers the entire MLD message, and those
pseudo headers defined by IPv6[IP6-RFC]
[ICMP6-RFC].
Request ID A 16-bit random number which is used to
identify responses received from the router.
A new random value MUST be generated each
time a host sends an MLD report which
requests response.
Reserved This field MUST be set to zero and ignored
on reception.
Multicast Addr The specific multicast IP address which the
message sender is listening to.
An MLD Report message with a code value of '1' will be referred to as
a Report-Requesting-Response throughout this document.
A report which does not request response (Code: 0) MUST also have a
Request ID of zero.
The existing specification of MLD [MLD-RFC] contains two unused
reserved fields (Code, and a 16 bit filed starting at octet 4) in the
ICMPv6 Multicast Listener Discovery Report Message. MLD requires
current implementations to zero these fields, and ignore their value
upon reception.
The modification of these two fields will not affect reception and
normal processing of a Report-Resquesting-Response by MLD compliant
nodes. The message will be treated as if it did not contain the
request for response.
3.2 Multicast Listener Discovery Response
The MLD response packet is sent in response to an MLD Report-
Requesting-Response
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 5]
INTERNET-DRAFT DAD Optimization with MLD August 2002
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Addr +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type Multicast Listener Response (TBA)
Code (TBA guess: 0) New Multicast Group
A message received with any other value MUST be
silently discarded
Checksum Covers the entire MLD message, and those pseudo
headers defined by IPv6[IP6-RFC][ICMP6-RFC].
Request ID The 16-bit field copied from the MLD Report
which requested response.
Reserved This field MUST be set to zero and ignored on
reception.
Multicast Addr The Multicast IP address copied from the
MLD Report which requested response.
If a node receives an MLD Response with a different Request
identifier to that which was sent for a particular Multicast Address,
it MUST silently discard the packet.
4.0 Protocol Operation
This section describes the operation of the node performing DAD, and
of the Querier Router whose task is to maintain state about multicast
groups.
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 6]
INTERNET-DRAFT DAD Optimization with MLD August 2002
4.1 Host Operations
When the node joins the multicast group in order to participate in
Duplicate Address Detection, it sends an MLD report to the link scope
solicited-nodes multicast address, with a link local source address.
The node's link-local source address may be tentative, especially if
this DAD is to find duplicates for that particular address. This is
unlikely to be a problem, since the address will not have a unicast
response, and will not cause updating of neighbor state.
Only the first MLD report sent by a node when it comes up on a link
MAY be a Report-Requesting-Response. A request for response MUST NOT
be set if the MLD Report is being sent in response to a query.
Any other transmissions of MLD reports for the solicited-node
multicast address MUST occur without a request for response.
When the node sends a report, it MUST set the report flag, and start
a timer, in compliance with the MLD Request For Comments[MLD-RFC].
The report MUST be sent before the Neighbor Solicitation for
Duplicate Address Detection is sent.
No other timer is kept for the node requesting response, except for
the RetransTimer defined for Neighbor Discovery, and used for DAD[ND-
RFC][SAA-RFC] DAD. When a node sends an MLD Report-Requesting-
Response, it stores the Request ID, and perfoms DAD as normal. DAD
continues until one of the three following events occur:
* DAD expires (indicating no duplicate found),
* A Neighbor Solicitation or Advertisement for the tentative
address is received (The address is in use).
* An MLD Response with matching Multicast Address field and Request ID
is received (indicating that no listeners exist).
In all situations, any outstanding request state is removed, and DAD
is terminated.
4.2 Querier Router Operations
A Router which wishes to provide responses MUST keep track of MLD
messages sent to the Solicited Node multicast address. Details of
how status of multicast groups are maintained and monitored is
provided in the MLD RFC.
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 7]
INTERNET-DRAFT DAD Optimization with MLD August 2002
If the querier receives a Report-Requesting-Response it and it is in
a state able to respond, it should check the packet formatting to
ensure that the received packet's destination address is the same as
the requested Multicast Address from the MLD Message. If the
addresses differ, the packet MUST be silently discarded.
If the packet is correctly formatted, it should check whether the
group currently exists on the subnet before updating the state of the
group.
Special care should be taken that the test for existence and
modification to the state are done atomically, to ensure that two
responses may not be sent for the same group.
After the group's state is updated, the querier sends a response if a
new group was created. This response is sent with the router's link-
local address as source, with the destination being the multicast
address from the Report-Requesting-Response. The Multicast Address
and Request ID fields are copied from the report message.
The router MUST make use of the rate limiting mechanism specified in
section 5.1 and the procedures to handle resource depletion specified
in section 5.5.
5.0 Robustness Mechanisms
5.1 Rate Limiting for Responses
The MLD Response message SHOULD immediately be sent by the MLD
Querier Router in response to an MLD Report-Requesting-Response,
unless it has already sent [Maximum Report Responses] within the last
[Query Interval].
At each General MLD query, the current number of responses is reset
to 0. The default value [Query Interval] is specified in the MLD
Request for Comments[MLD-RFC].
If the Maximum Report Responses has been exceeded, a response MUST
NOT be sent, and the message must be treated as if it did not request
response.
5.2 Multiple Requests for the same Multicast Group
There may be an occasion where two nodes request a response for the
same solicited-node multicast address simultaneously. In this case,
the response is sent for the node whose message is first processed by
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 8]
INTERNET-DRAFT DAD Optimization with MLD August 2002
the router. In this case, the response is identified by the Request
ID.
The second node will complete DAD normally, with the possibility that
the first node has received the other's neighbor solicitation prior
to the MLD Response and has deconfigured the address.
5.3 Subnets Without Routers
In the case where no router is present on the subnet, there will be
no response from the MLD Querier. DAD will be performed normally.
5.4 Multiple Addresses Mapping to Solicited-Node Multicast
The solicited-node multicast address is based on the 24 low order
bits from the address to be configured and is therefore valid for
many different non-conflicting IPv6 addresses. There is some
possibility that listeners exist for a multicast group, but are DAD
defending another address than the required one.
In this case, the multicast group is not new on the link, even though
the unicast address is not duplicated. The querier router will not
send a response and DAD will complete in conformance to the Stateless
Address Autoconfiguration RFC.
5.5 Exhaustion of Querier Router's Storage
If at any time, the number of multicast groups on a Router's links is
such that information may not be stored about new groups, then the
router MUST cease sending MLD responses until it is sure that it
knows about all groups on a link.
This may be achieved through waiting the MLD [Multicast Listener
Interval] [MLD-RFC] and only keeping those groups for which a
response was received within the interval.
Since general multicast routing can be affected by this situation, it
is recommended that the storage of link-scope solicited node
addresses SHOULD be kept separately to non-link scope multicast
listener information, with explicit limits on the number of link-
scope records handled by the router.
6.0 Variables and Default values
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 9]
INTERNET-DRAFT DAD Optimization with MLD August 2002
6.1 Maximum Report Responses
The number of report responses which may be sent within an MLD [Query
Interval] MUST be configurable by the administrator of the Querier
Router. It is suggested that the default value of [Maximum Report
Responses] be 250, which is roughly two responses per second of the
default [Query Interval].
7.0 IANA Considerations
All new Code values for the new MLD Response must appear in an RFC.
Such RFCs must either be on the standards-track or must define an
IESG-approved experimental protocol.
8.0 Security Considerations
8.1 Excessive Requests for Response
The MLD Querying router may be subject to DoS attacks if it responds
quickly to many requests querying a single address, or if it receives
responses for many nodes in quick succession.
The backoff mechanism described in section 5.1 of this document
provides some protection, which is customizable for link conditions.
Normal DAD operation applies in this state.
8.2 Creating Non-Existent Multicast Groups
It is possible for a node to create a large number of non-existent
multicast groups on the Querier Router. As defined in section 5.5,
the fallback case where there is insufficient storage for storage of
the link-scope multicast groups is the normal DAD operation.
8.3 Malicious Responses
It is possible for a malicious node on the link to send response
messages to other nodes on the link, telling them that no listeners
are present on an address, when in fact there is already a node with
that address. This is equivalent to the current situation in DAD
where a malicious node itself configures the addresses.
Normative References
[KEYW-RFC] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. Request for Comments (Best Current
Practice) 2119 (BCP 14), Internet Engineering Task
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 10]
INTERNET-DRAFT DAD Optimization with MLD August 2002
Force, March 1997
[ARCH-RFC] R. Hinden and S. Deering. IP Version 6 Addressing
Architecture. Request for Comments (Proposed Standard)
2373, Internet Engineering Task Force, July 1998.
[IP6-RFC] S. Deering, R.Hinden. Internet Protocol, Version 6 (IPv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[ND-RFC] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998.
[SAA-RFC] S. Thomson, T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard)
2462, Internet Engineering Task Force, December 1998.
[ICMP6-RFC] A. Conta, S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification. Request for Comments (Draft Standard)
2463, Internet Engineering Task Force, December 1998.
[MLD-RFC] S. Deering, W. Fenner, B. Haberman. Multicast Listener
Discovery (MLD) for IPv6. Request for Comments
(Proposed Standard) 2710, Internet Engineering Task Force,
October 1999.
Non-Normative References
[MLDv2-ID] R. Vida et al. Multicast Listener Discovery Version 2
(MLDv2) for IPv6. Internet Draft (work in progress),
June 2002.
Acknowledgements
Thanks to Brett Pentland for his feedback and protocol review.
Authors' Address:
greg.daley@eng.monash.edu.au
richard.nelson@eng.monash.edu.au
{Greg Daley|Richard Nelson}
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 11]
INTERNET-DRAFT DAD Optimization with MLD August 2002
Monash University
Clayton 3800
Victoria
Australia
Appendix:
Interactions with the MLDv2 draft protocol [MLDv2-ID] are expected to
be the same as that found with the current standardized protocol
[MLD-RFC].
This document expires in February 2003.
Daley, Nelson draft-daley-ipv6-mcast-dad-00.txt [Page 12]