IPv6 Working Group Greg Daley INTERNET-DRAFT Monash University CTIE Expires: September 2003 Richard Nelson CS Waikato University February 2003 Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery draft-daley-ipv6-mcast-dad-02.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. Daley, Nelson draft-daley-ipv6-mcast-dad-02.txt [Page 1] INTERNET-DRAFT DAD Optimization with MLD February 2003 Table of Contents Status of this Memo.......................................... 1 Abstract..................................................... 1 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............................... 8 5.0 Robustness Mechanisms.................................... 8 5.1 Backoff Mechanism for Responses......................... 9 5.2 Multiple Requests for the same Multicast Group.......... 9 5.3 Subnets Without Routers................................. 9 5.4 Multiple Addresses Mapping to Solicited-Node Multicast.. 9 5.5 Exhaustion of Querier Router's Storage.................. 10 6.0 Variables and Default values............................. 10 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.................. 11 8.3 Malicious Responses..................................... 11 Normative References......................................... 11 Non-Normative References..................................... 12 Acknowledgements............................................. 12 Authors' Address............................................. 12 Appendix..................................................... 12 Changes Since Last Revision.................................. 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 Daley, Nelson draft-daley-ipv6-mcast-dad-02.txt [Page 2] INTERNET-DRAFT DAD Optimization with MLD February 2003 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 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-02.txt [Page 3] INTERNET-DRAFT DAD Optimization with MLD February 2003 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-02.txt [Page 4] INTERNET-DRAFT DAD Optimization with MLD February 2003 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-02.txt [Page 5] INTERNET-DRAFT DAD Optimization with MLD February 2003 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-02.txt [Page 6] INTERNET-DRAFT DAD Optimization with MLD February 2003 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. The node's link-local source address may be tentative, especially if this DAD is to find duplicates for that particular address. In this case, a report MAY be sent with an unspecified source address (::), as specified in [MLD-SRC]. This is unlikely to be a problem, since the report will not have a unicast response, and will not cause updating of neighbor state. Only the one MLD report for each solicited node address MAY be a Report-Requesting-Response. A response MUST NOT be requested unless DAD is being performed for an address related to the solicited node multicast address. 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. In the case that the Node which successfully completes DAD by receiving an MLD Response message subsequently wishes to perform DAD on other addresses which have the same solicited-nodes address, the Daley, Nelson draft-daley-ipv6-mcast-dad-02.txt [Page 7] INTERNET-DRAFT DAD Optimization with MLD February 2003 node MAY configure these addresses successfully without performing DAD, if no other attempts at DAD have been successfully performed by any other nodes using the same solicited nodes address in the intervening period. This is because no other nodes have configured any of these addresses. 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. 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. When an MLD router is started, it will not have full state regarding the Multicast groups which are on a link until reports for all groups have been received. This is achieved through the MLD Querier router sending General Query Messages each [Query Interval]. Full state may be achieved through waiting the MLD [Multicast Listener Interval] [MLD-RFC] and only tracking those groups as present for which a response to a general query was received within the interval. Until full state is achieved, a Querier Router MUST NOT respond to MLD Report-Requesting-Response messages. 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. Daley, Nelson draft-daley-ipv6-mcast-dad-02.txt [Page 8] INTERNET-DRAFT DAD Optimization with MLD February 2003 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 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. Daley, Nelson draft-daley-ipv6-mcast-dad-02.txt [Page 9] INTERNET-DRAFT DAD Optimization with MLD February 2003 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 by using the mechanism to build initial state defined in section 4.2. Since general multicast routing can be affected by resource depletion, 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 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. Daley, Nelson draft-daley-ipv6-mcast-dad-02.txt [Page 10] INTERNET-DRAFT DAD Optimization with MLD February 2003 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 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. [MLD-SRC] B. Haberman. "Source Address Selection for Multicast Listener Discovery Protocol (RFC 2710)", Internet Draft (work in Daley, Nelson draft-daley-ipv6-mcast-dad-02.txt [Page 11] INTERNET-DRAFT DAD Optimization with MLD February 2003 progress), September 2002. 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 Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton 3800 Victoria Australia richardn@cs.waikato.ac.nz Richard Nelson The Department of Computer Science University of Waikato Hamilton, New Zealand 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]. Changes Since Last Revision: - Added more explicit restart information about building state. - Added information about pre-DAD'ing multiple addresses. This document expires in September 2003. Daley, Nelson draft-daley-ipv6-mcast-dad-02.txt [Page 12]