idnits 2.17.1 draft-ietf-dna-simple-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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. (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- 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 (October 26, 2009) is 5296 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Appendix A' is mentioned on line 143, but not defined ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 Updates: 4861 (if approved) G. Daley 5 Intended status: Standards Track NetStar Networks 6 Expires: April 29, 2010 October 26, 2009 8 Simple procedures for Detecting Network Attachment in IPv6 9 draft-ietf-dna-simple-10 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 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 to 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/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 29, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Detecting Network Attachment allows hosts to assess if its existing 48 addressing or routing configuration is valid for a newly connected 49 network. 51 This document provides simple procedures for detecting network 52 attachment in IPv6 hosts, and procedures for routers to support such 53 services. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Link Identification model . . . . . . . . . . . . . . . . 4 62 2.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6 67 4.2. Steps involved in detecting link change . . . . . . . . . 6 68 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7 69 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7 70 4.5. Contents of the Neighbor Discovery messages . . . . . . . 8 71 4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8 72 4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8 73 4.6. DHCPv6 operation . . . . . . . . . . . . . . . . . . . . . 9 74 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 10 75 4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 11 76 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 11 77 4.9. Recommended retransmission behavior . . . . . . . . . . . 12 78 5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13 79 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 87 Appendix A. Issues with confirming manually assigned addresses . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 Hosts require procedures to simply and reliably identify if they have 99 moved to a different IP network than the one to which they have been 100 recently connected. In order to detect change, router and neighbor 101 discovery messages are used to collect reachability and configuration 102 information. This information is used to detect whether the existing 103 router and address prefixes are likely to be present. 105 This document incorporates feedback from host and router operating 106 systems implementors, which seeks to make implementation and adoption 107 of IPv6 change detection procedures simple for general use. 109 2.1. Goals 111 The goal of this document is to specify a simple procedure for 112 detecting network attachment (Simple DNA) that has the following 113 characteristics. 115 o Routers do not have to be modified to support this scheme. 117 o The most common use cases are optimized. 119 o In the worst case, detection latency is equal to that of standard 120 neighbor discovery so that performance is never degraded. 122 o False positives are not acceptable. A host should not conclude 123 that there is no link change when there is one. 125 o False negatives are acceptable. A host can conclude that there is 126 a link change when there is none. 128 2.2. Applicability 130 The Simple DNA protocol provides substantial benefits in some 131 scenarios and does not provide any benefit at all in certain other 132 scenarios. This is intentional as Simple DNA was designed for 133 simplicity rather than completeness. In particular, the Simple DNA 134 protocol provides maximum benefits when a host moves between a small 135 set of known links. When a host moves to a completely new link that 136 is previously unknown, the performance of the Simple DNA protocol 137 will be identical to that using standard neighbor discovery 138 procedures [RFC4861]. The Simple DNA procedure provides support for 139 addresses configured using either IPv6 Stateless Address 140 Autoconfiguration [RFC4862] or DHCPv6 [RFC3315]. It does not support 141 manually configured addresses since they are not widely used and can 142 cause unpredictable results and/or aggressive probing behavior 143 [Appendix A]. 145 2.3. Link Identification model 147 Earlier methods of detecting network attachment, e.g. the procedure 148 defined in [I-D.ietf-dna-protocol], relied on detecting whether the 149 host was still connected to the same link. If the host was attached 150 to the same link, all information related to the link such as the 151 routers, prefixes and configuration parameters was considered to be 152 valid. The Simple DNA protocol follows an alternate approach where 153 it relies on probing each previously known router to determine 154 whether to use information learnt from THAT router. This allows 155 simple DNA to probe routers learnt from multiple earlier attachments 156 to optimize movement between a known set of links. 158 2.4. DNA Overview 160 Detecting Network Attachment is performed by hosts after detecting a 161 link-layer "up" indication. The host simultaneously sends multicast 162 Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs) 163 in order to determine whether previously encountered routers are 164 present on the link. 166 Hosts implementing simple DNA may also send DHCPv6 packets, as 167 described in Section 4.6. Since simple DNA does not modify the 168 DHCPv6 protocol or state machine, the operation of DHCPv6 is 169 unchanged. 171 Routers that follow the standard neighbor discovery procedure 172 described in [RFC4861] will delay the router advertisement by a 173 random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms) 174 as described in Section 6.2.6 of [RFC4861]. Hosts implementing 175 simple DNA can detect the presence of a previously encountered router 176 using unicast Neighbor Solicitations. As a result, where the host 177 with a valid configuration is returning to a previously encountered 178 link, delays in the sending of a Router Advertisement (RA) will not 179 delay configuration as long as NS probing is successful. However in 180 situations where the host is attaching to a link for the first time, 181 or where it does not have a valid IP address on the link, it will be 182 dependent on the receipt of an RA for stateless auto-configuration. 183 In these situations delays in the receipt of an RA can be significant 184 and may result in service disruption. 186 As a result, in addition to implementing simple DNA, it is desirable 187 that routers adopt procedures which allow for fast unicast Router 188 Advertisement (RA) messages. 190 2.5. Working Assumptions 192 There are a series of assumptions about the network environment which 193 underpin these procedures. 195 o The combination of the link layer address and the link local IPv6 196 address of a router is unique across links. 198 o Hosts receive indications when a link-layer comes up. Without 199 this, they would not know when to commence the DNA procedure. 201 If these assumptions do not hold, host change detection systems will 202 not function optimally. In that case, they may occasionally detect 203 change spuriously, or experience some delay in detecting network 204 attachment. The delays so experienced will be no longer than those 205 caused by following the standard neighbor discovery procedure 206 described in [RFC4861]. 208 3. Terminology 210 +---------------------+---------------------------------------------+ 211 | Term | Definition | 212 +---------------------+---------------------------------------------+ 213 | Valid IPv6 address | An IPv6 address configured on the node that | 214 | | has a valid lifetime greater than zero. | 215 | | | 216 | Operable IPv6 | An IPv6 address configured on the node that | 217 | address | can be used safely on the current link. | 218 +---------------------+---------------------------------------------+ 220 Table 1: Simple DNA Terminology 222 4. Host Operations 224 When a host has an existing configuration for IP address prefixes and 225 next hop routing, it may be disconnected from its link-layer, and 226 then subsequently reconnect the link-layer on the same interface. 228 When the link-layer becomes available again, it is important to 229 determine whether the existing addressing and routing configuration 230 are still valid. 232 In order to determine this, the host performs the detecting network 233 attachment procedure. 235 4.1. Host data structures 237 In order to correctly perform the procedure described in this 238 document the host needs to maintain a data structure called the 239 Simple DNA address table (SDAT). This data structure is maintained 240 by the host on a per interface basis. Each entry in the SDAT table 241 consists of at least the following parameters. 243 o IPv6 address and its related parameters like valid lifetime. 245 o Prefix from which the address was formed. 247 o Link-local IPv6 address of the router that advertised the prefix. 249 o Link-layer (MAC) address of the router that advertised the prefix. 251 o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire 252 the address [RFC3315]. 254 4.2. Steps involved in detecting link change 256 The steps involved in basic detection of network attachment are: 258 o Link-Layer Indication 260 o Sending of neighbor discovery or DHCPv6 probes 262 o Response gathering and assessment 264 These steps are described below. 266 4.3. Link-Layer Indication 268 In order to start Detection of network attachment procedures, a host 269 typically requires a link-layer indication that the medium has become 270 available [RFC4957]. 272 After the indication is received, the host considers all currently 273 configured (non-tentative) IP addresses to be deprecated until the 274 change detection process completes. It SHOULD also set all Neighbor 275 Cache entries for the routers on its Default Router List to STALE. 276 This is done to speed up the acquisition of a new default router when 277 link change has occurred. 279 4.4. Sending Neighbor Discovery probes 281 When a host receives a link-layer "up" indication, it SHOULD 282 immediately send both a Router Solicitation and if it retains at 283 least one valid IPv6 address, one or more unicast Neighbor 284 Solicitations. The Router Solicitation is sent to the All-routers 285 multicast address using a link-local address as the source address 286 [RFC4861]. Even if the host is in possession of more than one valid 287 IPv6 address, it MUST send only one router solicitation using a valid 288 link-local address as the source address. 290 For the purpose of sending neighbor solicitations to previous 291 routers, the host first identifies the set of operable IPv6 addresses 292 (candidate set) that it wishes to use. If the addresses obtained 293 from a previous router are no longer valid, the host does not include 294 these addresses in the candidate set for NS based probing. 296 For each of the addresses in the candidate set, the host looks up the 297 SDAT to find out the link-local and MAC addresses of the router that 298 advertised the prefix used to form the address. It then sends an 299 unicast Neighbor Solicitations to each router's link-local address it 300 obtained from the lookup on the SDAT. The host SHOULD NOT send 301 unicast Neighbor Solicitations to a test node corresponding to an 302 IPv6 address that is no longer valid. 304 Please note that the Neighbor Solicitations SHOULD be sent in 305 parallel with the Router Solicitations. Since sending NSs is just an 306 optimization, doing the NSs and RSs in parallel ensures that the 307 procedure does not run slower than it would if it only used an RS. 309 4.5. Contents of the Neighbor Discovery messages 311 4.5.1. Neighbor Solicitation messages 313 This section describes the contents of the neighbor solicitation 314 probe messages sent during the probing procedure. 316 Source Address: A link-local address assigned to the 317 probing host. 319 Destination Address: The link-local address of the router being 320 probed as learnt from the SDAT. 322 Hop Limit: 255 324 ND Options: 326 Target Address: The link-local address of the router being 327 probed as learnt from the SDAT. 329 Link Layer Header: 331 Destination Address: The link-layer (MAC) address of the router 332 being probed as learnt from the SDAT. 334 The probing node SHOULD include a Source link-layer address option in 335 the probe messages if the address was obtained using DHCPv6 and the 336 lease has not expired. Otherwise the probing node SHOULD NOT include 337 the Source link-layer address option in the probe messages. 339 4.5.2. Router Solicitation messages 341 This section describes the contents of the router solicitation probe 342 message sent during the probing procedure. 344 Source Address: A link-local address assigned to the 345 probing host. 347 Destination Address: The all-routers multicast address. 349 Hop Limit: 255 351 The probing node SHOULD NOT include the Source link-layer address 352 option in the probe messages. 354 4.6. DHCPv6 operation 356 Simple DNA does not require a host to implement DHCPv6, nor does it 357 imply any changes to the DHCPv6 protocol or state machine. Hosts MAY 358 attempt to obtain IPv6 configuration via DHCPv6 in parallel with 359 simple DNA probing. This ensures that the simple DNA procedure will 360 not result in additional delay in the case where reachability tests 361 fail, or where a DHCPv6 exchange completes more quickly than the 362 reachability tests. 364 In situations where both simple DNA and DHCPv6 are used on the same 365 link, it is possible that simple DNA probing will complete 366 successfully, and then DHCPv6 will complete later with a different 367 result. If this happens, the procedure described in Section 4.7.1 368 are utilized. 370 Where the host attempts to obtain IPv6 configuration in parallel with 371 simple DNA, on receiving a link-layer "up" indication, it sends a 372 DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This message 373 contains an Identity Association for either a Temporary Address 374 (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an 375 existing valid address is being tested for operability, this address 376 should be placed in the Identity Association's IAADDR element, and 377 the DUID associated with that address should be copied to the DHCP 378 SOLICIT from the SDAT. 380 In order to quickly acquire a new address in the case that link 381 change has occurred, this SOLICIT message MAY contain the Rapid- 382 Commit option. 384 Where the Rapid-Commit option has not been used, a present DHCP 385 server will respond with an ADVERTISE message. The IP address 386 contained in the Identity Association (IA_TA or IA_NA) will contain 387 an IP Address which is operable for the link. 389 Where Rapid-Commit option has been sent, a DHCPv6 server will respond 390 with REPLY. In addition to being operable, this address is allocated 391 to the host for the lease duration indicated in the Identity 392 Association. 394 Where the host has acquired addresses from DHCPv6 or the host does 395 not have a global prefix, it MAY prefer to use DHCPv6 probe messages 396 in parallel with the Neighbor Discovery probing. The DHCPv6 probing 397 procedures described in this document do not imply any changes to the 398 DHCPv6 protocol or state machine. 400 In that case, when the host receives a link-layer indication, it 401 sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This 402 message contains an Identity Association for either a Temporary 403 Address (IA_TA) or Non-Temporary Address (IA_NA) . Where an existing 404 valid address is being tested for operability, this address should be 405 placed in the Identity Association's IAADDR element, and the DUID 406 associated with that address should be copied to the DHCP SOLICIT 407 from the SDAT. 409 In order to quickly acquire a new address in the case that link 410 change has occurred, this SOLICIT message MAY contain the Rapid- 411 Commit option. 413 Where the Rapid-Commit option has not been used, a present DHCP 414 server will respond with an ADVERTISE message. The IP address 415 contained in the Identity Association (IA_TA or IA_NA) will contain 416 an IP Address which is operable for the link. 418 Where Rapid-Commit option has been sent, a DHCPv6 server will respond 419 with REPLY. In addition to being operable, this address is allocated 420 to the host for the lease duration indicated in the Identity 421 Association. 423 4.7. Response Gathering 425 When a responding Neighbor Advertisement is received from a test 426 node, the host MUST verify that both the IPv6 and link layer (MAC) 427 addresses of the test node match the expected values before utilizing 428 the configuration associated with the detected network (prefixes, MTU 429 etc.). 431 On reception of a Router Advertisement or advertising DHCPv6 message 432 (a REPLY or ADVERTISE) which contains prefixes that intersect with 433 those previously advertised by a known router, the host utilizes the 434 configuration associated with the detected network. 436 When the host receives an advertisement containing only prefixes 437 which are disjoint from known advertised prefixes, the host MUST 438 determine whether the solicited advertisement corresponds to any of 439 the routers probed via NS. If it does, then the host SHOULD conclude 440 that the IPv6 addresses corresponding to that router are no longer 441 valid. Since any NS probes to that router will no longer provide 442 useful information, further probing of that router SHOULD be aborted. 444 Where the conclusions obtained from the Neighbor Solicitation/ 445 Advertisement from a given router and the RS/RA exchange with the 446 same router differ, the results obtained from the RS/RA will be 447 considered definitive. 449 When the host receives a Router Advertisement in reply to the Router 450 Solicitation it sent, the host SHOULD look for a Neighbor Cache entry 451 for the sending router and SHOULD mark that router's Neighbor Cache 452 Entry as REACHABLE if one was found. The host SHOULD add a new 453 Neighbor Cache Entry in the REACHABLE state for the sending router if 454 one does not currently exist. 456 4.7.1. Conflicting results 458 It is possible that the DHCPv6 exchanges and the neighbor discovery 459 based probes complete with conflicting results. In this case, the 460 host SHOULD use the following rules to determine the final result. 462 o If the DHCPv6 exchange was authenticated, use the result from 463 DHCPv6. 465 o If the DHCPv6 exchange was not authenticated and the neighbor 466 discovery exchange was protected by SEND [RFC3971], use the result 467 from the neighbor discovery probe. 469 o If both the DHCPv6 and neighbor discovery exchanges were not 470 authenticated, use the result from DHCPv6. 472 In situations where Neighbor Solicitation probes and Router 473 Solicitation probes are used on the same link, it is possible that 474 the NS probe will complete successfully, and then the RS probe will 475 complete later with a different result. If this happens, the 476 implementation SHOULD abandon the results obtained from the NS probe 477 of the router that responded to the RS and the implementation SHOULD 478 behave as if the NS probe did not successfully complete. If the 479 confirmed address was assigned manually, the implementation SHOULD 480 NOT unconfigure the manually assigned address and SHOULD log an error 481 about the mismatching prefix. 483 4.8. Further Host Operations 485 Operations subsequent to detecting network attachment depend upon 486 whether change was detected. 488 After confirming the reachability of the associated router using an 489 NS/NA pair, the host performs the following steps. 491 o The host SHOULD rejoin any solicited nodes' multicast groups for 492 addresses it continues to use. 494 o The host SHOULD select a default router as described in [RFC4861]. 496 If the host has determined that there has been no link change, it 497 SHOULD NOT perform duplicate address detection on the addresses that 498 have been confirmed to be operable. 500 If the NS based probe with a router did not complete or if the RS 501 based probe on the same router completed with different prefixes than 502 the ones in the SDAT the host MUST unconfigure all the existing 503 addresses received from the given router, and MUST begin address 504 configuration techniques, as indicated in the received Router 505 Advertisement [RFC4861][RFC4862]. 507 4.9. Recommended retransmission behavior 509 Where the NS probe does not complete successfully, it usually implies 510 that the host is not attached to the network whose configuration is 511 being tested. In such circumstances, there is typically little value 512 in aggressively retransmitting unicast neighbor solicitations that do 513 not elicit a response. 515 Where unicast Neighbor Solicitations and Router Solicitations are 516 sent in parallel, one strategy is to forsake retransmission of 517 Neighbor Solicitations and to allow retransmission only of Router 518 Solicitations or DHCPv6. In order to reduce competition between 519 unicast Neighbor Solicitations and Router Solicitations and DHCPv6 520 retransmissions, a DNAv6 implementation that retransmits may utilize 521 the retransmission strategy described in the DHCPv6 specification 522 [RFC3315], scheduling DNAv6 retransmissions between Router 523 Solicitation or DHCPv6 retransmissions. 525 If a response is received to any unicast Neighbor Solicitation, 526 Router Solicitation or DHCPv6 message, pending retransmissions MUST 527 be canceled [RFC3315][RFC3736]. A Simple DNA implementation SHOULD 528 NOT retransmit a Neighbor Solicitation more than twice. To provide 529 damping in the case of spurious Link Up indications, the host SHOULD 530 NOT perform the Simple DNA procedure more than once a second. 532 5. Pseudocode for Simple DNA 534 /* Link up indication received on INTERFACE */ 535 /* Start Simple DNA process */ 537 /* Mark All Addresses as deprecated */ 538 Configured_Address_List=Get_Address_List(INTERFACE); 539 foreach Configured_Address in Configured_Address_List 540 { 541 if (Get_Address_State(Configured_Address)!=AS_TENTATIVE) 542 { 543 Set_Address_State(Configured_Address,AS_DEPRECATED); 544 } 545 } 547 /* Mark all routers' NC entries as STALE to speed up */ 548 /* acquisition of new router if link change has occurred */ 549 foreach Router_Address in DEFAULT_ROUTER_LIST 550 { 551 NCEntry=Get_Neighbor_Cache_Entry(Router_Address); 552 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE); 553 } 555 /* Thread A : Send Router Solicitation */ 556 RS_Target_Address=FF02::2; 557 RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 558 Send_Router_Solicitation(RS_Source_Address,RS_Target_Address); 560 /* Thread B : Send Neighbor Solicitation(s) */ 561 Previously_Known_Router_List=Get_Router_List_from_SDAT(); 562 NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 564 foreach Router_Address in Previously_Known_Router_List 565 { 566 if (Get_Any_Valid_Address_from_SDAT(Router_Address)) 567 { 568 Send_Neighbor_Solicitation(NS_Source_Address,Router_Address); 569 } 570 } 572 /* Thread C : Response collection */ 574 /* Received Router Advertisement processing */ 575 /* Only for RAs received as response to DNA RSs */ 577 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 578 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 579 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 580 foreach SDAT_Entry in SDAT_Entry_List 581 { 582 if (Exists_PIO(RECEIVED_MESSAGE,Get_Prefix(SDAT_Entry))) 583 { 584 /* Address is operable. Configure on Interface */ 585 /* Rejoin solicited-node multicast group for address */ 586 } 587 else 588 { 589 /* If address is configured on interface, remove it */ 590 /* This could be because of a NA arriving before RA */ 591 } 592 } 594 /* Mark router as reachable */ 595 NCEntry=Get_Neighbor_Cache_Entry(L3_Source); 596 if (NCEntry is not NULL) 597 { 598 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_REACHABLE); 599 } 600 else 601 { 602 Create_Neighbor_Cache_Entry(L3_Source,NCS_REACHABLE); 603 } 605 /* Ignore further NAs from this router */ 606 Add_Router_to_NA_Ignore_List(L3_Source); 608 /* Received Neighbor Advertisement processing */ 609 /* Only for NAs received as response to DNA NSs */ 611 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 612 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 614 if (Is_Router_on_NA_Ignore_List(L3_Source)) { 615 /* Ignore message and wait for next message */ 616 continue; 617 } 619 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 621 foreach SDAT_Entry in SDAT_Entry_List 622 { 623 /* Address is operable. Configure on Interface */ 624 } 626 Figure 1: Pseudocode for Simple DNA 628 NOTE: This section does not include any pseudo-code for sending of 629 the DHCPv6 packets since the DHCPv6 exchange is orthogonal to the 630 simple DNA process. 632 6. Constants 634 SEND_NA_GRACE_TIME 636 Definition: An optional period to wait after Neighbor 637 Solicitation before adopting a non-SEND RA's link change 638 information. 640 Value: 40 milliseconds 642 7. Relationship to DNAv4 644 DNAv4 [RFC4436] specifies a set of steps that optimize the (common) 645 case of re-attachment to an IPv4 network that one has been connected 646 to previously by attempting to re-use a previous (but still valid) 647 configuration. This document shares the same goal as DNAv4 (that of 648 minimizing the handover latency in moving between points of 649 attachment) but differs in the steps it performs to achieve this 650 goal. Another difference is that this document also supports 651 stateless autoconfiguration of addresses in addition to addresses 652 configured using DHCPv6. 654 8. IANA Considerations 656 There are no changes to IANA registries required in this document. 658 9. Security Considerations 660 A host may receive Router Advertisements from non-SEND devices, after 661 receiving a link-layer indications. While it is necessary to assess 662 quickly whether a host has moved to another network, it is important 663 that the host's current secured SEND [RFC3971] router information is 664 not replaced by an attacker which spoofs an RA and purports to change 665 the link. 667 As such, the host SHOULD send a Neighbor Solicitation to the existing 668 SEND router upon link-up indication as described above in 669 Section 4.3. The host SHOULD then ensure that unsecured router 670 information does not cause deletion of existing SEND state, within 671 MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to 672 respond. 674 If the current default router is a SEND-secured router, the host 675 SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a 676 new default router. 678 Even if SEND signatures on RAs are used, it may not be immediately 679 clear if the router is authorized to make such advertisements. As 680 such, a host SHOULD NOT treat such devices as secure until and unless 681 authorization delegation discovery is successful. 683 10. Acknowledgments 685 This document is the product of a discussion the authors had with 686 Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at IETF 687 69. The authors would like to thank them for clearly detailing the 688 requirements of the solution and the goals it needed to meet and for 689 helping to explore the solution space. The authors would like to 690 thank the authors and editors of the complete DNA specification for 691 detailing the overall problem space and solutions. The authors would 692 like to thank Jari Arkko for driving the evolution of a simple and 693 probabilistic DNA solution. The authors would like to thank Bernard 694 Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier, 695 Domagoj Premec, Jin Hyeock-Choi, Alfred Hoenes and Frederic Rossi for 696 performing reviews on the document and providing valuable comments to 697 drive the document forward. 699 11. References 701 11.1. Normative References 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, March 1997. 706 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 707 (DHCP) Service for IPv6", RFC 3736, April 2004. 709 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 710 and M. Carney, "Dynamic Host Configuration Protocol for 711 IPv6 (DHCPv6)", RFC 3315, July 2003. 713 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 714 Neighbor Discovery (SEND)", RFC 3971, March 2005. 716 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 717 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 718 September 2007. 720 11.2. Informative References 722 [I-D.ietf-dna-protocol] 723 Narayanan, S., "Detecting Network Attachment in IPv6 724 Networks (DNAv6)", draft-ietf-dna-protocol (work in 725 progress), June 2007. 727 [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., 728 and A. Yegin, "Link-Layer Event Notifications for 729 Detecting Network Attachments", RFC 4957, August 2007. 731 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 732 Address Autoconfiguration", RFC 4862, September 2007. 734 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 735 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 737 Appendix A. Issues with confirming manually assigned addresses 739 Even though DNAv4 [RFC4436] supports verification of manually 740 assigned addresses this feature of DNAv4 has not been widely 741 implemented or used. There are two major issues that come up with 742 confirming manually assigned addresses using Simple DNA. 744 o When DHCPv6 or SLAAC addresses are used for probing, there is no 745 need to aggressively retransmit lost probes. This is because the 746 address configuration falls back to vanilla DHCPv6 or SLAAC and 747 the host will eventually obtain an address. This is not the case 748 with manually assigned addresses. If the probes are lost, the 749 host runs the risk of ending up with no addresses at all. Hence 750 agressive retransmissions are necessary. 752 o Another issue comes up when the host moves between two networks, 753 one where manual addressing is being used (say NET1)and the other 754 where dynamic addressing (stateless autoconfig or DHCPv6) is being 755 used (say NET2). Since the host can obtain a dynamic address in 756 some situations, it will need to send simple DNA probes and may 757 also engage in a DHCPv6 exchange. In a situation where the host 758 moves to NET1 and the NS probes are lost and in addition an RA is 759 not received, the host will not be able to confirm that it 760 attached to NET1, and therefore that it should use the manual 761 configuration for that network. As a result, if DHCPv6 is enabled 762 on NET1, then the host could mistakenly obtain a dynamic address 763 and configuration instead of using the manual configuration. To 764 prevent this problem, simple DNA probing needs to continue even 765 after the DHCPv6 exchange has completed, and DNA probes need to 766 take precedence over DHCPv6, contrary to the advice provided in 767 Section 4.7.1 769 Given these issues, it is NOT RECOMMENDED to use manual addressing 770 with Simple DNA. 772 Authors' Addresses 774 Suresh Krishnan 775 Ericsson 776 8400 Decarie Blvd. 777 Town of Mount Royal, QC 778 Canada 780 Phone: +1 514 345 7900 x42871 781 Email: suresh.krishnan@ericsson.com 783 Greg Daley 784 NetStar Networks 785 Level 9/636 St Kilda Rd 786 Melbourne, Victoria 3004 787 Australia 789 Phone: +61 3 8532 4042 790 Email: gdaley@netstarnetworks.com