idnits 2.17.1 draft-krishnan-dna-simple-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (November 7, 2007) is 6012 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) == Outdated reference: A later version (-04) exists of draft-ietf-dna-tentative-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-dna-protocol (ref. '6') == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-03 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track G. Daley 5 Expires: May 10, 2008 NetStar Networks 6 November 7, 2007 8 Simple procedures for Detecting Network Attachment in IPv6 9 draft-krishnan-dna-simple-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Detecting Network Attachment allows hosts to assess if its existing 43 addressing or routing configuration is valid for a newly connected 44 network. 46 This document provides simple procedures for detecting network 47 attachment in IPv6 hosts, and procedures for routers to support such 48 services. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Link-Layer Indication . . . . . . . . . . . . . . . . . . 5 58 3.2. Optimistic DAD . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Router Solicitation . . . . . . . . . . . . . . . . . . . 5 60 3.4. Neighbour Solicitation . . . . . . . . . . . . . . . . . . 5 61 3.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 6 62 3.6. Further Host Operations . . . . . . . . . . . . . . . . . 7 63 3.6.1. Actions upon return to a link . . . . . . . . . . . . 7 64 3.6.2. Actions upon arrival at a new link . . . . . . . . . . 7 65 4. Router Operations . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Tentative Option Processing . . . . . . . . . . . . . . . 7 67 4.2. Fast Unicast Response to Router Solicitation . . . . . . . 8 68 4.2.1. Fast Router Advertisement Transmission . . . . . . . . 8 69 4.3. Additional Router Procedures . . . . . . . . . . . . . . . 8 70 5. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Remaining Issues . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 Intellectual Property and Copyright Statements . . . . . . . . . . 13 81 1. Requirements notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [1]. 87 2. Introduction 89 Hosts require procedures to simply and reliably identify if they have 90 moved to a different IP network to the one which they have been 91 recently connected. In order to detect change, router and neighbour 92 discovery messages are used to collect reachability and configuration 93 information. This information is used to detect whether the existing 94 router and address prefixes are likely to be present. 96 This document incorporates feedback from host and router operating 97 systems implementors, which seeks to make implementation and adoption 98 of IPv6 change detection procedures simple for general use. 100 The feedback received mentioned that the complete dna protocol, as it 101 exists, is too complex to implement. As a reaction, some OS vendors 102 started shipping their own version of DNAv6 (it is pretty much a 103 version of DNAv4 adapted to IPv6). The implementers who brought up 104 the complexity concerns, identified the following issues with the 105 complete dna proposal as the main obstacles to deployment 107 o Router changes are NECESSARY 109 o Handling of corner cases adds complexity to most likely use cases 111 o Some of the DNA Goals are not really necessary/useful 113 2.1. DNA Roles 115 Detecting Network Attachment is performed by hosts by sending IPv6 116 neighbour discovery and router discovery messages to routers after 117 connecting to a network. 119 Routers adopt procedures which allow for fast unicast Router 120 Advertisement (RA) messages. Routers that follow the standard 121 neighbor discovery procedure described in [2] will delay the router 122 advertisement by a random period between 0 and MAX_RA_DELAY_TIME 123 (defined to be 500ms) as described in Section 6.2.6 of [2]. This 124 delay can be significant and may result in service disruption. 126 The host detects that the link-layer may have changed, and then 127 probes the network with Router Solicitations (RSs) and Neighbour 128 Solicitations (NSs). The host uses advertisements to determine if 129 the routers it currently has configured are still available. 131 2.2. Applicability 133 There are a series of assumptions about the network environment which 134 underpin these procedures. 136 o All the prefixes advertised on the link need to fit into a single 137 RA. This implies that the number of prefixes on the link needs to 138 be limited. e.g. 15 prefixes per link. If all the prefixes on the 139 link do not fit into a single RA, the prefixes that are left out 140 of the first RA will be advertised in another RA. A host 141 receiving such an RA from another router on the link will 142 incorrectly assume that it has changed links. 144 o All routers on the link advertise the same subnet prefixes. 146 o The number of advertising routers on the link needs to be limited 147 to the number defined in MAX_ROUTERS_FOR_SIMPLE_DNA. 149 o Hosts receive indications when a link-layer comes up. Without 150 this, they would not know when to commence the DNA procedure. 152 If these assumptions do not hold, host change detection systems will 153 not function optimally. In that case, they may occasionally detect 154 change spuriously, or experience some delay in detecting network 155 attachment. The delays so experienced will be no longer than those 156 caused by following the standard neighbor discovery procedure 157 described in [2]. 159 If systems do not meet these assumptions or if systems seek 160 deterministic change detection operations they are directed to follow 161 the complete dna procedure as defined in [6]. 163 3. Host Operations 165 When a host has an existing configuration for IP address prefixes and 166 next hop routing, it may be disconnected from its link-layer, and 167 then subsequently reconnect the link-layer on the same interface. 169 When the link-layer becomes available again, it is important to 170 determine whether the existing addressing and routing configuration 171 are still valid. 173 In order to determine this, the host undertakes detecting network 174 attachment. 176 The steps involved in basic detection of network attachment are: 178 o Link-Layer Indication 180 o Optimistic DAD 182 o Router Solicitation 184 o Neighbour Solicitations to prior router(s) 186 o Response gathering and assessment 188 These steps are described below. 190 3.1. Link-Layer Indication 192 In order to start Detection of network attachment procedures, a host 193 typically requires a link-layer indication that the medium has become 194 available [7]. 196 When the indication is received, the host marks all currently 197 configured (non-tentative) IP addresses to Optimistic state [5]. 199 3.2. Optimistic DAD 201 All Router Solicitations and unicast Neighbour Solicitations sent for 202 DNA purposes while addresses are in optimistic state SHOULD include 203 the Tentative Option [4]. 205 This allows for DAD-safe transmission of unicast response to 206 solicitation, even if the router has no existing Neighbour Cache 207 entry for the solicitor. 209 3.3. Router Solicitation 211 The primary mechanism used to detect network attachment in IPv6 is 212 router solicitation and advertisement. When a host receives a link- 213 layer indication, it SHOULD immediately send a Router Solicitation to 214 the All-routers address containing one of the host's optimistic 215 unicast source address [2][5]. 217 3.4. Neighbour Solicitation 219 The host will have configuration for addresses configured from 220 prefixes advertised on one or more routers. 222 In order to gain a quick confirmation that a host has returned to one 223 of the links associated with these existing prefixes, the host can 224 send Neighbour Solicitations. 226 The host may select one of its configured next hop routers from each 227 of zero, one or two previously connected links, and send a unicast 228 Neighbour Solicitation to each of these [2][5]. If the addresses 229 obtained from a previous router are no longer valid, the host SHOULD 230 NOT send a Neighbour Solicitation to that router. 232 Please note that the Neighbour Solicitations SHOULD be sent in 233 parallel with the Router Solicitations. Since sending NSs is just an 234 optimization, doing the NSs and RSs in parallel ensures that the 235 procedure does not run slower than it would if it only used an RS. 237 Be aware that each unicast solicitation which is not successful may 238 cause packet flooding in bridged networks, if the networks are not 239 properly configured. This is further described in Section 6. Where 240 flooding may cause performance issues within the LAN, host SHOULD 241 limit the number of unicast solicitations. 243 3.5. Response Gathering 245 The Simple IPv6 DNA assessment on the host relies upon tying 246 advertised prefixes to the advertising routers. Reception of an 247 advertisement from a router which is known to advertise a prefix can 248 be used to indicate that the node has reconnected to a link it was 249 previously connected to. 251 Where a responding Neighbour Advertisement is received from a 252 previously configured router, the host MUST verify if the hardware 253 address of the router matches the one that was previously known. If 254 it does, the host can decide that it hasn't changed networks, and MAY 255 continue to use the link configuration information (prefixes, MTU 256 etc.) with high probability. 258 Reception of a Router Advertisement which contains prefixes which 259 intersect with those previously advertised by a known router 260 indicates that the host has returned to that link with high 261 likelihood.In this case the host can decide that it hasn't changed 262 networks, and MAY continue to use the existing prefixes with high 263 probability. 265 Additionally, where a host receives a solicited router advertisement 266 after sending an RS for the purpose of detecting network attachment, 267 and this prefix contains only prefixes which are disjoint from known 268 advertised prefixes, the host SHOULD conclude with high probability 269 that it has moved to a different link. 271 3.6. Further Host Operations 273 Operations subsequent to detecting network attachment depend upon 274 whether change was detected. 276 3.6.1. Actions upon return to a link 278 Upon arrival at a previously visited link, the host should assess 279 whether it can use the existing configured addresses using Optimistic 280 Duplicate Address Detection [5]. 282 Also, the host SHOULD rejoin any solicited nodes' multicast groups 283 for addresses it continues to use, and select a default router [2]. 285 3.6.2. Actions upon arrival at a new link 287 Upon arrival on a new link, the host should unconfigure its existing 288 addresses and routers, and begin address configuration techniques, as 289 indicated in the received Router Advertisement [2][8]. 291 The host SHOULD keep information about prefixes advertised by routers 292 from the prior link, for the purposes of subsequent change detection 293 operations. 295 4. Router Operations 297 Routers wishing to support host change detection need to provide them 298 with quick responses to queries. Basic support for DNA for IPv6 299 requires two basic operations. 301 These procedures allow for a host to receive immediate response to a 302 router solicitation, and may simplify a host's internal change 303 detection operations. 305 The simple IPv6 DNA router components are: 307 1. Tentative Option processing 309 2. Fast Unicast Response to Solicitation with Token Buckets 311 These are described in the following sections. 313 4.1. Tentative Option Processing 315 Hosts checking their network attachment are unsure of their address 316 status, and may be using Tentative link-layer addressing information 317 in their router or neighbour solicitations. 319 A router which desires to support hosts' DNA operations MUST process 320 Tentative Options from unicast source addressed Router and Neighbour 321 Solicitations, as described in [4] . 323 4.2. Fast Unicast Response to Router Solicitation 325 In order to provide fast response to router solicitation the router 326 removes the random delay before sending a unicast response to a 327 Router Solicitation. 329 4.2.1. Fast Router Advertisement Transmission 331 To control the rate at which Router Advertisements are sent, the 332 router maintains a token bucket per-interface, whereby fast RAs are 333 only transmitted when a token is available [6]. 335 The bucket receives a token every UNICAST_RA_INTERVAL, unless the 336 bucket already contains MAX_UNICAST_RA_BURST tokens. 338 When the router receives a Router Solicitation containing a unicast 339 source address it SHOULD send a unicast router advertisement to the 340 solicitor's address without delay if there are remaining tokens in 341 the bucket. Each such transmission consumes one token. 343 When there are no remaining tokens, the router SHOULD send a 344 solicited Router Advertisement, as described in RFC 4861 [2]. 346 4.3. Additional Router Procedures 348 As described, the system used here may not be applicable to all 349 environments. Therefore the fast response advertisement mechanisms 350 for simple IPv6 DNA MUST be configurable. When disabled the host 351 would revert to existing IPv6 Neighbour discovery behaviour [2]. 353 5. Constants 355 These constants are described as in [6]. 357 UNICAST_RA_INTERVAL 359 Definition: The interval corresponding to the maximum average 360 rate of Router Solicitations that the router is prepared to 361 service with unicast responses. This is the interval at which 362 the token bucket controlling the unicast responses is 363 replenished. 365 Value: 50 milliseconds 367 MAX_UNICAST_RA_BURST 369 Definition: The maximum size burst of Router Solicitations that 370 the router is prepared to service with unicast responses. This 371 is the maximum number of tokens allowed in the token bucket 372 controlling the unicast responses. 374 Value: 20 376 SEND_NA_GRACE_TIME 378 Definition: An optional period to wait after Neighbour 379 Solicitation before adopting a non-SEND RA's link change 380 information. 382 Value: 40 milliseconds 384 6. Remaining Issues 386 These issues are still outstanding within the document, and the 387 simple DNA solution in general. 389 Identification of Fast advertising Simple DNA routers to other 390 routers. 392 Other protocols attempt to desynchronize Router Advertisements 393 while still allowing fast RA response [6]. 395 In an environment where it is safe to use Simple DNA, it may 396 not be necessary to worry about sending RAs at the same time as 397 other routers. 399 In the case where this specification's Fast Advertisements 400 cause problems due to contention with more sophisticated RA 401 delivery schemes, it SHOULD be turned off as described in 402 Section 4.3. 404 Rate limitation for solicitations. 406 In some circumstances, the rate of transmissions for 407 solicitations may need to be restricted or limited. This 408 depends highly upon the movement pattern and quality of link- 409 layer indications. Hysteresis mechanisms which slow or prevent 410 solicitation operations may be necessary to prevent damage to 411 the local network environment. 413 Particularly, transmission of unicast solicitations may cause 414 packet flooding across a bridged network if received on a 415 network where the link-layer unicast destination is unknown. 416 This shouldn't cause wireless link utilization, where base 417 stations maintain state about attached subscribers. 419 Hosts MAY implement hysteresis mechanisms to pace solicitations 420 where necessary to prevent damage to a particular medium. 421 Implementors should be aware that when such hysteresis is 422 triggered, Detecting Network Attachment may be slowed, which 423 may affect application traffic. 425 7. IANA Considerations 427 There are no changes to IANA registries required in this document 429 8. Security Considerations 431 When providing fast responses to router solicitations, it is possible 432 to cause collisions with other signaling packets on contention based 433 media. This can cause repeated packet loss or delay when multiple 434 routers are present on the link. 436 As such the fast router advertisement system is NOT RECOMMENDED in 437 this form for media which are susceptible to collision loss. Such 438 environments may be better served using the procedures defined in 439 [6]. 441 A host may receive Router Advertisements from non SEND devices, after 442 receiving a link-layer indications. While it is necessary to assess 443 quickly whether a host has moved to another network, it is important 444 that the host's current secured SEND [3] router information is not 445 replaced by an attacker which spoofs an RA and purports to change the 446 link. 448 As such, the host SHOULD send a Neighbour Solicitation to the 449 existing SEND router upon link-up indication as described above in 450 Section 3.1. The host SHOULD then ensure that unsecured router 451 information does not cause deletion of existing SEND state, within 452 MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to 453 respond. 455 The host MAY delay SEND_NA_GRACE_TIME after transmission before 456 adopting a new default router, if it is operating on a network where 457 there is significant threat of RA spoofing. 459 Even if SEND signatures on RAs are used, it may not be immediately 460 clear if the router is authorized to make such advertisements. As 461 such, a host SHOULD NOT treat such devices as secure until and unless 462 authorization delegation discovery is successful. 464 It is easy for hosts soliciting without SEND to deplete a SEND 465 router's fast advertisement token buckets, and consume additional 466 bandwidth. As such, a router MAY choose to preserve a portion of 467 their token bucket to serve solicitations with SEND signatures. 469 9. Acknowledgments 471 This document is the product of a discussion between the authors had 472 with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at 473 IETF 69. The authors would like to thank them for clearly detailing 474 the requirements of the solution and the goals it needed to meet and 475 for helping to explore the solution space. The authors would like to 476 thank the authors and editors of the complete DNA specification for 477 detailing the overall problem space and solutions. The authors would 478 like to thank Jari Arkko for driving the evolution of a simple and 479 probabilistic DNA solution. The authors would like to thank Bernard 480 Aboba, Thomas Narten, Sathya Narayan and Frederic Rossi for 481 performing reviews on the document and providing valuable comments to 482 drive the document forward. 484 10. References 486 10.1. Normative References 488 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 489 Levels", BCP 14, RFC 2119, March 1997. 491 [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 492 for IP Version 6 (IPv6)", RFC 4861, December 1998. 494 [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 495 Neighbor Discovery (SEND)", RFC 3971, March 2005. 497 [4] Daley, G., Nordmark, E., and N. Moore, "Tentative Options for 498 IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 (work in 499 progress), July 2007. 501 [5] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 502 RFC RFC4429, April 2006. 504 [6] Narayanan, S., "Detecting Network Attachment in IPv6 Networks 505 (DNAv6)", draft-ietf-dna-protocol (work in progress), June 2007. 507 10.2. Informative References 509 [7] Yegin, A., "Link-layer Event Notifications for Detecting Network 510 Attachments", draft-ietf-dna-link-information-03 (work in 511 progress), October 2005. 513 [8] Thomson, S. and T. Narten, "IPv6 Stateless Address 514 Autoconfiguration", RFC 4862, December 1998. 516 Authors' Addresses 518 Suresh Krishnan 519 Ericsson 520 8400 Decarie Blvd. 521 Town of Mount Royal, QC 522 Canada 524 Phone: +1 514 345 7900 x42871 525 Email: suresh.krishnan@ericsson.com 527 Greg Daley 528 NetStar Networks 529 Level 9/636 St Kilda Rd 530 Melbourne, Victoria 3004 531 Australia 533 Phone: +61 405 494849 534 Email: gdaley@netstarnetworks.com 536 Full Copyright Statement 538 Copyright (C) The IETF Trust (2007). 540 This document is subject to the rights, licenses and restrictions 541 contained in BCP 78, and except as set forth therein, the authors 542 retain all their rights. 544 This document and the information contained herein are provided on an 545 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 546 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 547 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 548 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 549 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Intellectual Property 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at 574 ietf-ipr@ietf.org. 576 Acknowledgment 578 Funding for the RFC Editor function is provided by the IETF 579 Administrative Support Activity (IASA).