idnits 2.17.1 draft-daley-ipv6-mcast-dad-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 193: '... values, it MUST be ignored....' RFC 2119 keyword, line 201: '...new random value MUST be generated eac...' RFC 2119 keyword, line 205: '... This field MUST be set to zero a...' RFC 2119 keyword, line 214: '...st response (Code: 0) MUST also have a...' RFC 2119 keyword, line 253: '... received with any other value MUST be...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2373 (ref. 'ARCH-RFC') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2460 (ref. 'IP6-RFC') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. 'ND-RFC') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. 'SAA-RFC') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. 'ICMP6-RFC') (Obsoleted by RFC 4443) -- Duplicate reference: RFC2710, mentioned in 'MLD-SRC', was also mentioned in 'MLD-RFC'. Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group Greg Daley 3 INTERNET-DRAFT Monash University CTIE 4 Expires: September 2003 Richard Nelson 5 CS Waikato University 6 February 2003 8 Duplicate Address Detection Optimization using 9 IPv6 Multicast Listener Discovery 10 draft-daley-ipv6-mcast-dad-02.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/lid-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This document is an individual submission to the IETF. Comments 33 should be directed to the authors. 35 Definitions of requirements keywords are in accordance with the IETF 36 Best Current Practice - RFC2119 [KEYW-RFC] 38 Abstract 40 This draft describes a possible optimization to Duplicate Address 41 Detection (DAD) which can be used to successfully terminate DAD 42 early, based on the presence of listeners on the link-scope solicited 43 nodes multicast address. 45 Table of Contents 47 Status of this Memo.......................................... 1 48 Abstract..................................................... 1 49 Table of Contents............................................ 1 50 1.0 Introduction............................................. 2 51 1.1 Terminology............................................. 3 52 2.0 Protocol Overview........................................ 4 53 3.0 Message Formats.......................................... 4 54 3.1 Multicast Listener Discovery Report..................... 4 55 3.2 Multicast Listener Discovery Response................... 5 56 4.0 Protocol Operation....................................... 6 57 4.1 Host Operations......................................... 7 58 4.2 Querier Router Operations............................... 8 59 5.0 Robustness Mechanisms.................................... 8 60 5.1 Backoff Mechanism for Responses......................... 9 61 5.2 Multiple Requests for the same Multicast Group.......... 9 62 5.3 Subnets Without Routers................................. 9 63 5.4 Multiple Addresses Mapping to Solicited-Node Multicast.. 9 64 5.5 Exhaustion of Querier Router's Storage.................. 10 65 6.0 Variables and Default values............................. 10 66 6.1 Maximum Report Responses................................ 10 67 7.0 IANA Considerations...................................... 10 68 8.0 Security Considerations.................................. 10 69 8.1 Excessive Requests for Response ........................ 10 70 8.2 Creating Non-Existent Multicast Groups.................. 11 71 8.3 Malicious Responses..................................... 11 72 Normative References......................................... 11 73 Non-Normative References..................................... 12 74 Acknowledgements............................................. 12 75 Authors' Address............................................. 12 76 Appendix..................................................... 12 77 Changes Since Last Revision.................................. 12 79 1.0 Introduction 81 Duplicate Address Detection[SAA-RFC], is used by internet nodes to 82 ensure that devices connecting to a multicast capable network do not 83 configure unicast addresses which are already configured on nodes 84 within that subnet. DAD incurs a delay while the tentative address 85 is being tested. This is undesirable for many nodes, such as mobile 86 nodes. 88 Nodes that have completed DAD, and own an address listen on the link- 89 scope solicited-node multicast address[ARCH-RFC] related to the IPv6 90 address which they have completed DAD on[SAA-RFC]. When a new node 91 attempts to configure an address on the network, it sends a neighbor 92 solicitation message to the same address, and succeeds if no device 93 responds to this message within a timeout period. As part of this 94 process, the new node also listens to the solicited-node multicast 95 address 97 The MLD RFC requires a node to send an MLD report before listening to 98 the solicited-node multicast address[MLD-RFC]. This process requires 99 informing the router on a link about the presence of listeners for 100 the address, so that a multicast-group can be managed. 102 The optimization described in this document allows nodes to ask the 103 router to tell them if they are the first node to enter this 104 multicast group. If they are the first to enter the group then it 105 follows that no-one else is currently performing DAD defence against 106 the required unicast address. 108 This reduces the delay incurred to successfully complete DAD. 110 1.1 Terminology 112 IP - Internet Protocol Version 6 (IPv6)[IP6-RFC]. 114 DAD - Duplicate Address Detection [SAA-RFC] 116 MLD - Multicast Listener Discovery [MLD-RFC] 118 node - a device that implements IPv6. 120 router - a node that forwards IPv6 packets not explicitly 121 addressed to itself. 123 host - any node that is not a router. 125 link - a communication facility or medium over which nodes can 126 communicate at the link layer, i.e., the layer 127 immediately below IPv6. Examples are Ethernets (simple 128 or bridged); PPP links; X.25, Frame Relay, or ATM 129 networks; and internet (or higher) layer "tunnels", 130 such as tunnels over IPv4 or IPv6 itself. 132 neighbors - nodes attached to the same link. 134 address - an IPv6-layer identifier for an interface or a set of 135 interfaces. 137 querier - router on the subnet which actively queries MLD 138 state. 140 2.0 Protocol Overview 142 MLD [MLD-RFC] defines that on entering a Multicast group an 143 unsolicited MLD report is sent by a node. This tells the MLD 144 routers that support is required for the specified group. 146 When attempting Duplicate Address Detection on a tentative address, 147 the node sends an MLD Report-Requesting-Response message. This 148 message serves two purposes. Firstly, it contains a report 149 compatible with the Multicast Listener Discovery Specification, for 150 the purposes of telling the router of the listener's presence. 152 Secondly, the report asks the MLD querier router to respond if the 153 group is previously unknown. Limiting response to the querier router 154 prevents multiple responses and allows for simple rate-limiting 155 operation. 157 If the response is not received, DAD will continue in conformance to 158 the Stateless Address Autoconfiguration RFC [SAA-RFC]. 160 3.0 Message Formats 162 The protocol makes use of one modified and one new message from MLD. 164 3.1 Multicast Listener Discovery Report 166 The modified MLD Report allows nodes to request the Querier Router to 167 respond if the multicast group was empty before the node sent the 168 report. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type | Code | Checksum | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Request ID | Reserved | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 + + 179 | | 180 + Multicast Addr + 181 | | 182 + + 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Fields: 187 Type Multicast Listener Report (decimal 131) 189 Code 0 Response not requested 190 (TBA guess: 1) Response requested 192 If a this field contains any other code 193 values, it MUST be ignored. 195 Checksum Covers the entire MLD message, and those 196 pseudo headers defined by IPv6[IP6-RFC] 197 [ICMP6-RFC]. 199 Request ID A 16-bit random number which is used to 200 identify responses received from the router. 201 A new random value MUST be generated each 202 time a host sends an MLD report which 203 requests response. 205 Reserved This field MUST be set to zero and ignored 206 on reception. 208 Multicast Addr The specific multicast IP address which the 209 message sender is listening to. 211 An MLD Report message with a code value of '1' will be referred to as 212 a Report-Requesting-Response throughout this document. 214 A report which does not request response (Code: 0) MUST also have a 215 Request ID of zero. 217 The existing specification of MLD [MLD-RFC] contains two unused 218 reserved fields (Code, and a 16 bit filed starting at octet 4) in the 219 ICMPv6 Multicast Listener Discovery Report Message. MLD requires 220 current implementations to zero these fields, and ignore their value 221 upon reception. 223 The modification of these two fields will not affect reception and 224 normal processing of a Report-Resquesting-Response by MLD compliant 225 nodes. The message will be treated as if it did not contain the 226 request for response. 228 3.2 Multicast Listener Discovery Response 230 The MLD response packet is sent in response to an MLD Report- 231 Requesting-Response 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type | Code | Checksum | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Request ID | Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 + + 241 | | 242 + Multicast Addr + 243 | | 244 + + 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Fields: 249 Type Multicast Listener Response (TBA) 251 Code (TBA guess: 0) New Multicast Group 253 A message received with any other value MUST be 254 silently discarded 256 Checksum Covers the entire MLD message, and those pseudo 257 headers defined by IPv6[IP6-RFC][ICMP6-RFC]. 259 Request ID The 16-bit field copied from the MLD Report 260 which requested response. 262 Reserved This field MUST be set to zero and ignored on 263 reception. 265 Multicast Addr The Multicast IP address copied from the 266 MLD Report which requested response. 268 If a node receives an MLD Response with a different Request 269 identifier to that which was sent for a particular Multicast Address, 270 it MUST silently discard the packet. 272 4.0 Protocol Operation 274 This section describes the operation of the node performing DAD, and 275 of the Querier Router whose task is to maintain state about multicast 276 groups. 278 4.1 Host Operations 280 When the node joins the multicast group in order to participate in 281 Duplicate Address Detection, it sends an MLD report to the link scope 282 solicited-nodes multicast address. 284 The node's link-local source address may be tentative, especially if 285 this DAD is to find duplicates for that particular address. In this 286 case, a report MAY be sent with an unspecified source address (::), 287 as specified in [MLD-SRC]. 289 This is unlikely to be a problem, since the report will not have a 290 unicast response, and will not cause updating of neighbor state. 292 Only the one MLD report for each solicited node address MAY be a 293 Report-Requesting-Response. A response MUST NOT be requested unless 294 DAD is being performed for an address related to the solicited node 295 multicast address. 297 Any other transmissions of MLD reports for the solicited-node 298 multicast address MUST occur without a request for response. 300 When the node sends a report, it MUST set the report flag, and start 301 a timer, in compliance with the MLD Request For Comments[MLD-RFC]. 303 The report MUST be sent before the Neighbor Solicitation for 304 Duplicate Address Detection is sent. 306 No other timer is kept for the node requesting response, except for 307 the RetransTimer defined for Neighbor Discovery, and used for DAD[ND- 308 RFC][SAA-RFC] DAD. When a node sends an MLD Report-Requesting- 309 Response, it stores the Request ID, and perfoms DAD as normal. DAD 310 continues until one of the three following events occur: 312 * DAD expires (indicating no duplicate found), 314 * A Neighbor Solicitation or Advertisement for the tentative 315 address is received (The address is in use). 317 * An MLD Response with matching Multicast Address field and Request ID 318 is received (indicating that no listeners exist). 320 In all situations, any outstanding request state is removed, and DAD 321 is terminated. 323 In the case that the Node which successfully completes DAD by 324 receiving an MLD Response message subsequently wishes to perform DAD 325 on other addresses which have the same solicited-nodes address, the 326 node MAY configure these addresses successfully without performing 327 DAD, if no other attempts at DAD have been successfully performed by 328 any other nodes using the same solicited nodes address in the 329 intervening period. This is because no other nodes have configured 330 any of these addresses. 332 4.2 Querier Router Operations 334 A Router which wishes to provide responses MUST keep track of MLD 335 messages sent to the Solicited Node multicast address. Details of 336 how status of multicast groups are maintained and monitored is 337 provided in the MLD RFC. 339 If the querier receives a Report-Requesting-Response it and it is in 340 a state able to respond, it should check the packet formatting to 341 ensure that the received packet's destination address is the same as 342 the requested Multicast Address from the MLD Message. If the 343 addresses differ, the packet MUST be silently discarded. 345 If the packet is correctly formatted, it should check whether the 346 group currently exists on the subnet before updating the state of the 347 group. 349 Special care should be taken that the test for existence and 350 modification to the state are done atomically, to ensure that two 351 responses may not be sent for the same group. 353 After the group's state is updated, the querier sends a response if a 354 new group was created. This response is sent with the router's link- 355 local address as source, with the destination being the multicast 356 address from the Report-Requesting-Response. The Multicast Address 357 and Request ID fields are copied from the report message. 359 When an MLD router is started, it will not have full state regarding 360 the Multicast groups which are on a link until reports for all groups 361 have been received. This is achieved through the MLD Querier router 362 sending General Query Messages each [Query Interval]. Full state may 363 be achieved through waiting the MLD [Multicast Listener Interval] 364 [MLD-RFC] and only tracking those groups as present for which a 365 response to a general query was received within the interval. 367 Until full state is achieved, a Querier Router MUST NOT respond to 368 MLD Report-Requesting-Response messages. 370 The router MUST make use of the rate limiting mechanism specified in 371 section 5.1 and the procedures to handle resource depletion specified 372 in section 5.5. 374 5.0 Robustness Mechanisms 376 5.1 Rate Limiting for Responses 378 The MLD Response message SHOULD immediately be sent by the MLD 379 Querier Router in response to an MLD Report-Requesting-Response, 380 unless it has already sent [Maximum Report Responses] within the last 381 [Query Interval]. 383 At each General MLD query, the current number of responses is reset 384 to 0. The default value [Query Interval] is specified in the MLD 385 Request for Comments[MLD-RFC]. 387 If the Maximum Report Responses has been exceeded, a response MUST 388 NOT be sent, and the message must be treated as if it did not request 389 response. 391 5.2 Multiple Requests for the same Multicast Group 393 There may be an occasion where two nodes request a response for the 394 same solicited-node multicast address simultaneously. In this case, 395 the response is sent for the node whose message is first processed by 396 the router. In this case, the response is identified by the Request 397 ID. 399 The second node will complete DAD normally, with the possibility that 400 the first node has received the other's neighbor solicitation prior 401 to the MLD Response and has deconfigured the address. 403 5.3 Subnets Without Routers 405 In the case where no router is present on the subnet, there will be 406 no response from the MLD Querier. DAD will be performed normally. 408 5.4 Multiple Addresses Mapping to Solicited-Node Multicast 410 The solicited-node multicast address is based on the 24 low order 411 bits from the address to be configured and is therefore valid for 412 many different non-conflicting IPv6 addresses. There is some 413 possibility that listeners exist for a multicast group, but are DAD 414 defending another address than the required one. 416 In this case, the multicast group is not new on the link, even though 417 the unicast address is not duplicated. The querier router will not 418 send a response and DAD will complete in conformance to the Stateless 419 Address Autoconfiguration RFC. 421 5.5 Exhaustion of Querier Router's Storage 423 If at any time, the number of multicast groups on a Router's links is 424 such that information may not be stored about new groups, then the 425 router MUST cease sending MLD responses until it is sure that it 426 knows about all groups on a link. This may be achieved by using the 427 mechanism to build initial state defined in section 4.2. 429 Since general multicast routing can be affected by resource 430 depletion, it is recommended that the storage of link-scope solicited 431 node addresses SHOULD be kept separately to non-link scope multicast 432 listener information, with explicit limits on the number of link- 433 scope records handled by the router. 435 6.0 Variables and Default values 437 6.1 Maximum Report Responses 439 The number of report responses which may be sent within an MLD [Query 440 Interval] MUST be configurable by the administrator of the Querier 441 Router. It is suggested that the default value of [Maximum Report 442 Responses] be 250, which is roughly two responses per second of the 443 default [Query Interval]. 445 7.0 IANA Considerations 447 All new Code values for the new MLD Response must appear in an RFC. 448 Such RFCs must either be on the standards-track or must define an 449 IESG-approved experimental protocol. 451 8.0 Security Considerations 453 8.1 Excessive Requests for Response 455 The MLD Querying router may be subject to DoS attacks if it responds 456 quickly to many requests querying a single address, or if it receives 457 responses for many nodes in quick succession. 459 The backoff mechanism described in section 5.1 of this document 460 provides some protection, which is customizable for link conditions. 461 Normal DAD operation applies in this state. 463 8.2 Creating Non-Existent Multicast Groups 465 It is possible for a node to create a large number of non-existent 466 multicast groups on the Querier Router. As defined in section 5.5, 467 the fallback case where there is insufficient storage for storage of 468 the link-scope multicast groups is the normal DAD operation. 470 8.3 Malicious Responses 472 It is possible for a malicious node on the link to send response 473 messages to other nodes on the link, telling them that no listeners 474 are present on an address, when in fact there is already a node with 475 that address. This is equivalent to the current situation in DAD 476 where a malicious node itself configures the addresses. 478 Normative References 480 [KEYW-RFC] S. Bradner. Key words for use in RFCs to Indicate 481 Requirement Levels. Request for Comments (Best Current Practice) 482 2119 (BCP 14), Internet Engineering Task Force, March 1997 484 [ARCH-RFC] R. Hinden and S. Deering. IP Version 6 Addressing 485 Architecture. Request for Comments (Proposed Standard) 2373, 486 Internet Engineering Task Force, July 1998. 488 [IP6-RFC] S. Deering, R.Hinden. Internet Protocol, Version 6 (IPv6) 489 Specification. Request for Comments (Draft Standard) 2460, 490 Internet Engineering Task Force, December 1998. 492 [ND-RFC] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for 493 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, 494 Internet Engineering Task Force, December 1998. 496 [SAA-RFC] S. Thomson, T. Narten. IPv6 Stateless Address 497 Autoconfiguration. Request for Comments (Draft Standard) 2462, 498 Internet Engineering Task Force, December 1998. 500 [ICMP6-RFC] A. Conta, S. Deering. Internet Control Message Protocol 501 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 502 Specification. Request for Comments (Draft Standard) 2463, 503 Internet Engineering Task Force, December 1998. 505 [MLD-RFC] S. Deering, W. Fenner, B. Haberman. Multicast Listener 506 Discovery (MLD) for IPv6. Request for Comments (Proposed 507 Standard) 2710, Internet Engineering Task Force, October 1999. 509 [MLD-SRC] B. Haberman. "Source Address Selection for Multicast 510 Listener Discovery Protocol (RFC 2710)", Internet Draft (work in 511 progress), September 2002. 513 Non-Normative References 515 [MLDv2-ID] R. Vida et al. Multicast Listener Discovery Version 2 516 (MLDv2) for IPv6. Internet Draft (work in progress), June 2002. 518 Acknowledgements 520 Thanks to Brett Pentland for his feedback and protocol review. 522 Authors' Address: 524 greg.daley@eng.monash.edu.au 526 Greg Daley 527 Centre for Telecommunications and Information Engineering 528 Department of Electrical and Computer Systems Engineering 529 Monash University 530 Clayton 3800 531 Victoria 532 Australia 534 richardn@cs.waikato.ac.nz 536 Richard Nelson 537 The Department of Computer Science 538 University of Waikato 539 Hamilton, New Zealand 541 Appendix: 543 Interactions with the MLDv2 draft protocol [MLDv2-ID] are expected to 544 be the same as that found with the current standardized protocol 545 [MLD-RFC]. 547 Changes Since Last Revision: 549 - Added more explicit restart information about building state. 550 - Added information about pre-DAD'ing multiple addresses. 552 This document expires in September 2003.