idnits 2.17.1 draft-krishnan-dna-simple-03.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 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 540. 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 (February 25, 2008) is 5898 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) -- Looks like a reference, but probably isn't: 'RFCDHCPv6' on line 328 == 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') Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 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: August 28, 2008 NetStar Networks 6 February 25, 2008 8 Simple procedures for Detecting Network Attachment in IPv6 9 draft-krishnan-dna-simple-03 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 August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 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. Host data structures . . . . . . . . . . . . . . . . . . . 5 58 3.2. Link-Layer Indication . . . . . . . . . . . . . . . . . . 5 59 3.3. Optimistic DAD . . . . . . . . . . . . . . . . . . . . . . 5 60 3.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6 61 3.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 6 62 3.6. Further Host Operations . . . . . . . . . . . . . . . . . 7 63 3.7. Recommended retransmission behavior . . . . . . . . . . . 7 64 4. Router Operations . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Intellectual Property and Copyright Statements . . . . . . . . . . 13 76 1. Requirements notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [1]. 82 2. Introduction 84 Hosts require procedures to simply and reliably identify if they have 85 moved to a different IP network to the one which they have been 86 recently connected. In order to detect change, router and neighbour 87 discovery messages are used to collect reachability and configuration 88 information. This information is used to detect whether the existing 89 router and address prefixes are likely to be present. 91 This document incorporates feedback from host and router operating 92 systems implementors, which seeks to make implementation and adoption 93 of IPv6 change detection procedures simple for general use. 95 The goal of this document is to specify a simple procedure for 96 detecting network attachment (Simple DNA) that has the following 97 characteristics. 99 o Routers do not have to be modified to support this scheme. 101 o Handle only the simplest and most likely use cases. 103 o Work at least as quickly as standard neighbor discovery. 105 o False positives are not acceptable. A host should not conclude 106 that there is no link change when there is one 108 o False negatives are acceptable. A host can conclude that there is 109 a link change when there is none 111 2.1. DNA Roles 113 Detecting Network Attachment is performed by hosts by sending IPv6 114 neighbour discovery and router discovery messages to routers after 115 connecting to a network. 117 It is desirable that routers adopt procedures which allow for fast 118 unicast Router Advertisement (RA) messages. Routers that follow the 119 standard neighbor discovery procedure described in [2] will delay the 120 router advertisement by a random period between 0 and 121 MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 122 of [2]. This delay can be significant and may result in service 123 disruption. Please note that support for fast unicast RAs is not 124 necessary since the simple dna procedure can continue to work using 125 the NS/NA exchange, which will complete earlier than the RA arrives. 127 The host detects that the link-layer may have changed, and then 128 simultaneously probes the network with Router Solicitations (RSs) and 129 Neighbour Solicitations (NSs). The host uses advertisements to 130 determine if the routers it currently has configured are still 131 available. 133 2.2. Applicability 135 There are a series of assumptions about the network environment which 136 underpin these procedures. 138 o The combination of the link layer address and the link local IPv6 139 address of a router is unique across links. 141 o Hosts receive indications when a link-layer comes up. Without 142 this, they would not know when to commence the DNA procedure. 144 If these assumptions do not hold, host change detection systems will 145 not function optimally. In that case, they may occasionally detect 146 change spuriously, or experience some delay in detecting network 147 attachment. The delays so experienced will be no longer than those 148 caused by following the standard neighbor discovery procedure 149 described in [2]. 151 If systems do not meet these assumptions or if systems seek 152 deterministic change detection operations they are directed to follow 153 the complete dna procedure as defined in [6]. 155 3. Host Operations 157 When a host has an existing configuration for IP address prefixes and 158 next hop routing, it may be disconnected from its link-layer, and 159 then subsequently reconnect the link-layer on the same interface. 161 When the link-layer becomes available again, it is important to 162 determine whether the existing addressing and routing configuration 163 are still valid. 165 In order to determine this, the host performs the detecting network 166 attachment procedure. 168 3.1. Host data structures 170 In order to correctly perform the procedure described in this 171 document the host needs to maintain a data structure called the 172 Simple DNA address table (SDAT). Each entry in the SDAT table 173 consists of at least the following parameters 175 o IPv6 address and its related parameters like valid lifetime 177 o Prefix from which the address was formed 179 o Link local IPv6 address of the router that advertised the prefix 181 o Link layer (MAC) address of the router that advertised the prefix 183 o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire 184 the address 186 The steps involved in basic detection of network attachment are: 188 o Link-Layer Indication 190 o Optimistic DAD 192 o Sending RS and NS probes 194 o Response gathering and assessment 196 These steps are described below. 198 3.2. Link-Layer Indication 200 In order to start Detection of network attachment procedures, a host 201 typically requires a link-layer indication that the medium has become 202 available [7]. 204 When the indication is received, the host marks all currently 205 configured (non-tentative) IP addresses to Optimistic state [5]. 207 3.3. Optimistic DAD 209 All Router Solicitations and unicast Neighbour Solicitations sent for 210 DNA purposes while addresses are in optimistic state SHOULD include 211 the Tentative Option [4]. 213 This allows for DAD-safe transmission of unicast response to 214 solicitation, even if the router has no existing Neighbour Cache 215 entry for the solicitor. 217 3.4. Sending RS and NS probes 219 When a host receives a link-layer "up" indication, it SHOULD 220 immediately send both a Router Solicitation and if it retains at 221 least one valid IPv6 address, one or more unicast Neighbor 222 Solicitations. The Router Solicitation is sent to the All-routers 223 multicast address containing one of the host's optimistic unicast 224 source address [2][5]. If the host is in possession of more than one 225 valid IPv6 address, it MUST send only one router solicitation using 226 any one of its valid IPv6 addresses as the source address.. 228 For the purpose of sending neighbor solicitations to previous 229 routers, the host first needs to pick a subset of operable IPv6 230 addresses (candidate set) that it wishes to use. How this subset of 231 addresses is picked is based on host configuration. e.g. The host 232 may select configured addresses from each of zero, one or two 233 previously connected links. If the addresses obtained from a 234 previous router are no longer valid, the host does include these 235 addresses in the candidate set for NS based probing. 237 For each of the addresses in the candidate set, the host looks up the 238 SDAT to find out the link local and MAC addresses of the router that 239 advertised the prefix used to form the address. It then sends an 240 unicast Neighbor Solicitations to each router's link local address it 241 obtained from the lookup on the SDAT. The host SHOULD NOT send 242 unicast Neighbor Solicitations to a test node corresponding to an 243 IPv6 address that is no longer valid. 245 Please note that the Neighbour Solicitations SHOULD be sent in 246 parallel with the Router Solicitations. Since sending NSs is just an 247 optimization, doing the NSs and RSs in parallel ensures that the 248 procedure does not run slower than it would if it only used an RS. 250 Be aware that each unicast solicitation which is not successful may 251 cause packet flooding in bridged networks, if the networks are not 252 properly configured. This is further described in Section 6. Where 253 flooding may cause performance issues within the LAN, host SHOULD 254 limit the number of unicast solicitations. 256 3.5. Response Gathering 258 When a responding Neighbour Advertisement is received from a test 259 node, the host MUST verify that both the IPv6 and link layer (MAC) 260 addresses of the test node match the expected values before utilizing 261 the configuration associated with the detected network (prefixes, MTU 262 etc.). 264 On reception of a Router Advertisement which contains prefixes which 265 intersect with those previously advertised by a known router, the 266 host utilizes the configuration associated with the detected network. 268 When the host receives a router advertisement containing only 269 prefixes which are disjoint from known advertised prefixes, the host 270 MUST determine whether the solicited router advertisement corresponds 271 to any of the routers probed via NS. If it does, then the host 272 SHOULD conclude that the IPv6 addresses corresponding to that router 273 are no longer valid. Since any NS probes to that router will no 274 longer provide useful information, probing of that router SHOULD be 275 aborted. 277 Where the conclusions obtained from the Neighbor Solicitation/ 278 Advertisement from a given router and the RS/RA exchange with the 279 same router differ, the results obtained from the RS/RA will be 280 considered definitive. 282 3.6. Further Host Operations 284 Operations subsequent to detecting network attachment depend upon 285 whether change was detected. 287 After confirming the reachability of the associated router using an 288 NS/NA pair, the host should assess whether it can use the existing 289 configured addresses using Optimistic Duplicate Address Detection 290 [5]. 292 Also, the host SHOULD rejoin any solicited nodes' multicast groups 293 for addresses it continues to use, and select a default router [2]. 295 If the NS based probe with a router did not complete or if the RS 296 based probe on the same router completed with different prefixes than 297 the ones in the SDAT the host MUST unconfigure all the existing 298 addresses received from the given router, and MUST begin address 299 configuration techniques, as indicated in the received Router 300 Advertisement [2] [8] . 302 3.7. Recommended retransmission behavior 304 In situations where Neighbor Solicitation probes and Router 305 Solicitation probes are used on the same link, it is possible that 306 the NS probe will complete successfully, and then the RS probe will 307 complete later with a different result. If this happens, the 308 implementation SHOULD abandon the results obtained from the NS probe 309 of the router that responded to the RS and the implementation SHOULD 310 behave as if the NS probe did not successfully complete. If the 311 confirmed address was assigned manually, the implementation SHOULD 312 NOT unconfigure the manually assigned address and SHOULD log an error 313 about the mismatching prefix. 315 Where the NS probe does not complete successfully, it usually implies 316 that the host is not attached to the network whose configuration is 317 being tested. In such circumstances, there is typically little value 318 in aggressively retransmitting unicast neighbor solicitations that do 319 not elicit a response. 321 Where unicast Neighbor Solicitations and Router Solicitations are 322 sent in parallel, one strategy is to forsake retransmission of 323 Neighbor Solicitations and to allow retransmission only of Router 324 Solicitations or DHCPv6. In order to reduce competition between 325 unicast Neighbor Solicitations and Router Solicitations and DHCPv6 326 retransmissions, a DNAv6 implementation that retransmits may utilize 327 the retransmission strategy described in the DHCPv6 specification 328 [RFCDHCPv6], scheduling DNAv6 retransmissions between Router 329 Solicitation or DHCPv6 retransmissions. 331 If a response is received to any unicast Neighbor Solicitation, 332 Router Solicitation or DHCPv6 message, pending retransmissions MUST 333 be canceled. A Simple DNA implementation SHOULD NOT retransmit a 334 Neighbor Solicitation more than twice. To provide damping in the 335 case of spurious Link Up indications, the host SHOULD NOT perform the 336 the Simple DNA procedure more than once a second. 338 4. Router Operations 340 Hosts checking their network attachment are unsure of their address 341 status, and may be using Tentative link-layer addressing information 342 in their router or neighbour solicitations. 344 A router which desires to support hosts' DNA operations MUST process 345 Tentative Options from unicast source addressed Router and Neighbour 346 Solicitations, as described in [4] . 348 5. Constants 350 These constants are described as in [6]. 352 UNICAST_RA_INTERVAL 354 Definition: The interval corresponding to the maximum average 355 rate of Router Solicitations that the router is prepared to 356 service with unicast responses. This is the interval at which 357 the token bucket controlling the unicast responses is 358 replenished. 360 Value: 50 milliseconds 362 MAX_UNICAST_RA_BURST 364 Definition: The maximum size burst of Router Solicitations that 365 the router is prepared to service with unicast responses. This 366 is the maximum number of tokens allowed in the token bucket 367 controlling the unicast responses. 369 Value: 20 371 SEND_NA_GRACE_TIME 373 Definition: An optional period to wait after Neighbour 374 Solicitation before adopting a non-SEND RA's link change 375 information. 377 Value: 40 milliseconds 379 6. Open Issues 381 This section documents issues that are still outstanding within the 382 document, and the simple DNA solution in general. 384 Rate limitation for solicitations. 386 Hosts MAY implement hysteresis mechanisms to pace solicitations 387 where necessary to prevent damage to a particular medium. 388 Implementors should be aware that when such hysteresis is 389 triggered, Detecting Network Attachment may be slowed, which may 390 affect application traffic. 392 7. IANA Considerations 394 There are no changes to IANA registries required in this document 396 8. Security Considerations 398 When providing fast responses to router solicitations, it is possible 399 to cause collisions with other signaling packets on contention based 400 media. This can cause repeated packet loss or delay when multiple 401 routers are present on the link. 403 As such the fast router advertisement system is NOT RECOMMENDED in 404 this form for media which are susceptible to collision loss. Such 405 environments may be better served using the procedures defined in 406 [6]. 408 A host may receive Router Advertisements from non SEND devices, after 409 receiving a link-layer indications. While it is necessary to assess 410 quickly whether a host has moved to another network, it is important 411 that the host's current secured SEND [3] router information is not 412 replaced by an attacker which spoofs an RA and purports to change the 413 link. 415 As such, the host SHOULD send a Neighbour Solicitation to the 416 existing SEND router upon link-up indication as described above in 417 Section 3.2. The host SHOULD then ensure that unsecured router 418 information does not cause deletion of existing SEND state, within 419 MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to 420 respond. 422 The host MAY delay SEND_NA_GRACE_TIME after transmission before 423 adopting a new default router, if it is operating on a network where 424 there is significant threat of RA spoofing. 426 Even if SEND signatures on RAs are used, it may not be immediately 427 clear if the router is authorized to make such advertisements. As 428 such, a host SHOULD NOT treat such devices as secure until and unless 429 authorization delegation discovery is successful. 431 It is easy for hosts soliciting without SEND to deplete a SEND 432 router's fast advertisement token buckets, and consume additional 433 bandwidth. As such, a router MAY choose to preserve a portion of 434 their token bucket to serve solicitations with SEND signatures. 436 9. Acknowledgments 438 This document is the product of a discussion between the authors had 439 with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at 440 IETF 69. The authors would like to thank them for clearly detailing 441 the requirements of the solution and the goals it needed to meet and 442 for helping to explore the solution space. The authors would like to 443 thank the authors and editors of the complete DNA specification for 444 detailing the overall problem space and solutions. The authors would 445 like to thank Jari Arkko for driving the evolution of a simple and 446 probabilistic DNA solution. The authors would like to thank Bernard 447 Aboba, Thomas Narten, Sathya Narayan and Frederic Rossi for 448 performing reviews on the document and providing valuable comments to 449 drive the document forward. 451 10. References 453 10.1. Normative References 455 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 456 Levels", BCP 14, RFC 2119, March 1997. 458 [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 459 for IP Version 6 (IPv6)", RFC 4861, December 1998. 461 [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 462 Neighbor Discovery (SEND)", RFC 3971, March 2005. 464 [4] Daley, G., Nordmark, E., and N. Moore, "Tentative Options for 465 IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 (work in 466 progress), July 2007. 468 [5] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 469 RFC RFC4429, April 2006. 471 [6] Narayanan, S., "Detecting Network Attachment in IPv6 Networks 472 (DNAv6)", draft-ietf-dna-protocol (work in progress), June 2007. 474 10.2. Informative References 476 [7] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., and A. 477 Yegin, "Link-Layer Event Notifications for Detecting Network 478 Attachments", RFC 4957, August 2007. 480 [8] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address 481 Autoconfiguration", RFC 4862, September 2007. 483 Authors' Addresses 485 Suresh Krishnan 486 Ericsson 487 8400 Decarie Blvd. 488 Town of Mount Royal, QC 489 Canada 491 Phone: +1 514 345 7900 x42871 492 Email: suresh.krishnan@ericsson.com 493 Greg Daley 494 NetStar Networks 495 Level 9/636 St Kilda Rd 496 Melbourne, Victoria 3004 497 Australia 499 Phone: +61 405 494849 500 Email: gdaley@netstarnetworks.com 502 Full Copyright Statement 504 Copyright (C) The IETF Trust (2008). 506 This document is subject to the rights, licenses and restrictions 507 contained in BCP 78, and except as set forth therein, the authors 508 retain all their rights. 510 This document and the information contained herein are provided on an 511 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 512 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 513 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 514 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 515 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 516 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 518 Intellectual Property 520 The IETF takes no position regarding the validity or scope of any 521 Intellectual Property Rights or other rights that might be claimed to 522 pertain to the implementation or use of the technology described in 523 this document or the extent to which any license under such rights 524 might or might not be available; nor does it represent that it has 525 made any independent effort to identify any such rights. Information 526 on the procedures with respect to rights in RFC documents can be 527 found in BCP 78 and BCP 79. 529 Copies of IPR disclosures made to the IETF Secretariat and any 530 assurances of licenses to be made available, or the result of an 531 attempt made to obtain a general license or permission for the use of 532 such proprietary rights by implementers or users of this 533 specification can be obtained from the IETF on-line IPR repository at 534 http://www.ietf.org/ipr. 536 The IETF invites any interested party to bring to its attention any 537 copyrights, patents or patent applications, or other proprietary 538 rights that may cover technology that may be required to implement 539 this standard. Please address the information to the IETF at 540 ietf-ipr@ietf.org. 542 Acknowledgment 544 Funding for the RFC Editor function is provided by the IETF 545 Administrative Support Activity (IASA).