idnits 2.17.1 draft-ietf-dna-simple-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- No issues found here. 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. -- 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 4, 2010) is 5188 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 150, 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 (==), 3 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 8, 2010 NetStar Networks 6 February 4, 2010 8 Simple procedures for Detecting Network Attachment in IPv6 9 draft-ietf-dna-simple-13 11 Abstract 13 Detecting Network Attachment allows hosts to assess if its existing 14 addressing or routing configuration is valid for a newly connected 15 network. This document provides simple procedures for detecting 16 network attachment in IPv6 hosts, and procedures for routers to 17 support such services. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 8, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. Link Identification model . . . . . . . . . . . . . . . . 4 64 2.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6 69 4.1.1. SDAT Maintenance . . . . . . . . . . . . . . . . . . . 6 70 4.2. Steps involved in detecting link change . . . . . . . . . 7 71 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7 72 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7 73 4.5. Contents of the Neighbor Discovery messages . . . . . . . 9 74 4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 9 75 4.5.2. Router Solicitation messages . . . . . . . . . . . . . 9 76 4.6. DHCPv6 operation . . . . . . . . . . . . . . . . . . . . . 10 77 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 10 78 4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 11 79 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 11 80 4.9. Recommended retransmission behavior . . . . . . . . . . . 12 81 5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13 82 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 90 Appendix A. Issues with confirming manually assigned addresses . 17 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Requirements notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Introduction 101 Hosts require procedures to simply and reliably identify if they have 102 moved to a network to which they had been recently connected. In 103 order to detect change, router and neighbor discovery messages are 104 used to collect reachability and configuration information. This 105 information is used to detect whether the existing router and address 106 prefixes are likely to be present. 108 This document incorporates feedback from host and router operating 109 systems implementors, which seeks to make implementation and adoption 110 of IPv6 change detection procedures simple for general use. 112 2.1. Goals 114 The goal of this document is to specify a simple procedure for 115 detecting network attachment (Simple DNA) that has the following 116 characteristics. 118 o Routers do not have to be modified to support this scheme. 120 o The most common use cases are optimized. 122 o In the worst case, detection latency is equal to that of standard 123 neighbor discovery so that performance is never degraded. 125 o False positives are not acceptable. A host MUST NOT conclude that 126 there is no link change when there is one. 128 o False negatives are acceptable. A host MAY fail to identify a 129 previously visited link correctly and attempt to acquire fresh 130 addressing and configuration information. 132 2.2. Applicability 134 The Simple DNA protocol provides substantial benefits over standard 135 neighbor discovery procedures [RFC4861] in some scenarios and does 136 not provide any benefit at all in certain other scenarios. This is 137 intentional as Simple DNA was designed for simplicity rather than 138 completeness. In particular, the Simple DNA protocol provides 139 maximum benefits when a host moves between a small set of known 140 links. When a host moves to a completely new link that is previously 141 unknown, the performance of the Simple DNA protocol will be identical 142 to that using standard neighbor discovery procedures [RFC4861]. In 143 this case the main benefit of the Simple DNA protocol is to 144 immediately flush out the inoperable addresses and configuration 145 instead of timing them out. The Simple DNA procedure provides 146 support for addresses configured using either IPv6 Stateless Address 147 Autoconfiguration [RFC4862] or DHCPv6 [RFC3315]. It does not support 148 manually configured addresses since they are not widely used and can 149 cause unpredictable results and/or aggressive probing behavior 150 [Appendix A]. 152 2.3. Link Identification model 154 Earlier methods of detecting network attachment, e.g. the procedure 155 defined in [I-D.ietf-dna-protocol], relied on detecting whether the 156 host was still connected to the same link. If the host was attached 157 to the same link, all information related to the link such as the 158 routers, prefixes and configuration parameters was considered to be 159 valid. The Simple DNA protocol follows an alternate approach where 160 it relies on probing each previously known router to determine 161 whether to use information learnt from THAT router. This allows 162 simple DNA to probe routers learnt from multiple earlier attachments 163 to optimize movement between a known set of links. 165 2.4. DNA Overview 167 Detecting Network Attachment is performed by hosts after detecting a 168 link-layer "up" indication. The host simultaneously sends multicast 169 Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs) 170 in order to determine whether previously encountered routers are 171 present on the link. 173 Hosts implementing simple DNA may also send DHCPv6 packets, as 174 described in Section 4.6. Since simple DNA does not modify the 175 DHCPv6 protocol or state machine, the operation of DHCPv6 is 176 unchanged. 178 Routers that follow the standard neighbor discovery procedure 179 described in [RFC4861] will delay the router advertisement by a 180 random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms) 181 as described in Section 6.2.6 of [RFC4861]. Hosts implementing 182 simple DNA can detect the presence of a previously encountered router 183 using unicast Neighbor Solicitations. As a result, where the host 184 with a valid configuration is returning to a previously encountered 185 link, delays in the sending of a Router Advertisement (RA) will not 186 delay configuration as long as NS probing is successful. However in 187 situations where the host is attaching to a link for the first time, 188 or where it does not have a valid IP address on the link, it will be 189 dependent on the receipt of an RA for stateless auto-configuration. 190 In these situations delays in the receipt of an RA can be significant 191 and may result in service disruption. 193 2.5. Working Assumptions 195 There are a series of assumptions about the network environment which 196 underpin these procedures. 198 o The combination of the link layer address and the link local IPv6 199 address of a router is unique across links. 201 o Hosts receive indications when a link-layer comes up. Without 202 this, they would not know when to commence the DNA procedure. 204 If these assumptions do not hold, host change detection systems will 205 not function optimally. In that case, they may occasionally detect 206 change spuriously, or experience some delay in detecting network 207 attachment. The delays so experienced will be no longer than those 208 caused by following the standard neighbor discovery procedure 209 described in [RFC4861]. 211 3. Terminology 213 +---------------------+---------------------------------------------+ 214 | Term | Definition | 215 +---------------------+---------------------------------------------+ 216 | Valid IPv6 address | An IPv6 address configured on the node that | 217 | | has a valid lifetime greater than zero. | 218 | | | 219 | Operable IPv6 | An IPv6 address configured on the node that | 220 | address | can be used safely on the current link. | 221 +---------------------+---------------------------------------------+ 223 Table 1: Simple DNA Terminology 225 4. Host Operations 227 When a host has an existing configuration for IP address prefixes and 228 next hop routing, it may be disconnected from its link-layer, and 229 then subsequently reconnect the link-layer on the same interface. 231 When the link-layer becomes available again, it is important to 232 determine whether the existing addressing and routing configuration 233 are still valid. 235 In order to determine this, the host performs the detecting network 236 attachment procedure. 238 4.1. Host data structures 240 In order to correctly perform the procedure described in this 241 document the host needs to maintain a data structure called the 242 Simple DNA address table (SDAT). The host needs to maintain this 243 data structure for each interface on which it performs Simple DNA. 244 Each entry in the SDAT table consists of at least the following 245 parameters. 247 o IPv6 address and its related parameters like valid lifetime, 248 preferred lifetime etc. 250 o Prefix from which the address was formed. 252 o Link-local IPv6 address(es) of the router(s) that advertised the 253 prefix. 255 o Link-layer (MAC) address(es) of the router(s) that advertised the 256 prefix. 258 o Flag indicating whether the address was obtained using SLAAC or 259 DHCPv6. 261 o DHCP specific information in case DHCPv6 [RFC3315] was used to 262 acquire the address. This information includes DUID, IA_ID, a 263 flag indicating IA_NA/IA_TA, configuration information such as DNS 264 server address, NTP server address etc. 266 4.1.1. SDAT Maintenance 268 The host SHOULD maintain the SDAT table by periodically cleaning out 269 entries whose valid lifetimes have expired. The host MAY also 270 maintain the table by allowing SDAT entries from "n" previously 271 visited links. When the host attaches to a previously unknown link 272 and the SDAT already contains entries from the previous "n" attached 273 links,it will discard all the SDAT entries corrsponding to the least 274 recently attached link. 276 4.2. Steps involved in detecting link change 278 The steps involved in basic detection of network attachment are: 280 o Link-Layer Indication 282 o Sending of neighbor discovery and/or DHCPv6 probes 284 o Response gathering and assessment 286 These steps are described below. 288 4.3. Link-Layer Indication 290 In order to start Detection of network attachment procedures, a host 291 typically requires a link-layer indication that the medium has become 292 available [RFC4957]. 294 After the indication is received, the host considers all currently 295 configured (non-tentative) IP addresses to be deprecated until the 296 change detection process completes. It MUST also set all Neighbor 297 Cache entries for the routers on its Default Router List to STALE. 298 This is done to speed up the acquisition of a new default router when 299 link change has occurred. 301 4.4. Sending Neighbor Discovery probes 303 When a host receives a link-layer "up" indication, it SHOULD 304 immediately send both a Router Solicitation (as specified in as 305 specified in section 6.3.7 of [RFC4861]) and if it retains at least 306 one valid IPv6 address, one or more unicast Neighbor Solicitations. 307 The Router Solicitation is sent to the All-routers multicast address 308 using a link-local address as the source address [RFC4861]. Even if 309 the host is in possession of more than one valid IPv6 address, it 310 MUST send only one router solicitation using a valid link-local 311 address as the source address. 313 For the purpose of sending neighbor solicitations to previous 314 routers, the host first identifies the set of valid IPv6 addresses 315 (candidate set) that it wishes to use. 317 For each of the addresses in the candidate set, the host looks up the 318 SDAT to find out the link-local and MAC addresses of the router(s) 319 that advertised the prefix used to form the address. It then sends 320 an unicast Neighbor Solicitations to each router's link-local address 321 it obtained from the lookup on the SDAT. The host MUST NOT send 322 unicast Neighbor Solicitations to a test node corresponding to an 323 IPv6 address that is no longer valid. 325 Please note that the Neighbor Solicitations SHOULD be sent in 326 parallel with the Router Solicitation. Since sending NSs is just an 327 optimization, doing the NSs and the RS in parallel ensures that the 328 procedure does not run slower than it would if it only used an RS. 330 NOTE: A Simple DNA implementation MUST limit its probing to at most 331 six previously seen routers 333 4.5. Contents of the Neighbor Discovery messages 335 4.5.1. Neighbor Solicitation messages 337 This section describes the contents of the neighbor solicitation 338 probe messages sent during the probing procedure. 340 Source Address: A link-local address assigned to the 341 probing host. 343 Destination Address: The link-local address of the router being 344 probed as learnt from the SDAT. 346 Hop Limit: 255 348 ND Options: 350 Target Address: The link-local address of the router being 351 probed as learnt from the SDAT. 353 Link Layer Header: 355 Destination Address: The link-layer (MAC) address of the router 356 being probed as learnt from the SDAT. 358 The probing node SHOULD include the Source link-layer address option 359 in the probe messages. 361 4.5.2. Router Solicitation messages 363 This section describes the contents of the router solicitation probe 364 message sent during the probing procedure. 366 Source Address: A link-local address assigned to the 367 probing host. 369 Destination Address: The all-routers multicast address. 371 Hop Limit: 255 373 The probing node SHOULD NOT include the Source link-layer address 374 option in the probe messages. 376 4.6. DHCPv6 operation 378 Simple DNA does not require a host to implement DHCPv6, nor does it 379 imply any changes to the DHCPv6 protocol or state machine. Hosts MAY 380 attempt to obtain IPv6 configuration via DHCPv6 in parallel with 381 simple DNA probing. This ensures that the simple DNA procedure will 382 not result in additional delay in the case where reachability tests 383 fail, or where a DHCPv6 exchange completes more quickly than the 384 reachability tests. 386 In situations where both simple DNA and DHCPv6 are used on the same 387 link, it is possible that simple DNA probing will complete 388 successfully, and then DHCPv6 will complete later with a different 389 result. If this happens, the procedure described in Section 4.7.1 390 are utilized. 392 The host attempts to verify its DHCPv6-obtained information in 393 parallel with simple DNA. On receiving a link-layer "up" indication, 394 it will initiate a DHCPv6 exchange when and as specified in [RFC3315] 395 in order to verify whether the addresses and configuration obtained 396 using DHCPv6 are still usable on the link. 398 4.7. Response Gathering 400 When a responding Neighbor Advertisement is received from a test 401 node, the host MUST verify that both the IPv6 and link layer (MAC) 402 addresses of the test node match the expected values before utilizing 403 the configuration associated with the detected network (prefixes, MTU 404 etc.). 406 On reception of a Router Advertisement that contains prefixes that 407 intersect with those previously advertised by a known router, the 408 host utilizes the configuration associated with the detected network. 410 If the host receives a router advertisement from a router containing 411 only prefixes that are disjoint from the prefixes associated with the 412 same router in the SDAT, then the host MUST conclude that the IPv6 413 addresses corresponding to that router are no longer valid. Since 414 any NS probes to that router will no longer provide useful 415 information, further probing of that router MUST be aborted. 416 Furthermore, the host MUST remove all the SDAT entries corresponding 417 to this router. 419 Where the conclusions obtained from the Neighbor Solicitation/ 420 Advertisement from a given router and the RS/RA exchange with the 421 same router differ, the results obtained from the RS/RA will be 422 considered definitive. In case the Neighbor Advertisement was 423 secured using SEND and the Router Advertisement was not, the host 424 MUST wait for SEND_NA_GRACE_TIME to see if a SEND-secured RA is 425 received. If a SEND-secured RA is not received, the conclusions 426 obtained from the NS/NA exchange will be considered definitive. 428 When the host receives a Router Advertisement from a given router, 429 the host MUST look for a Neighbor Cache entry for the sending router 430 and MUST mark that router's Neighbor Cache Entry as REACHABLE if one 431 was found. The host MUST add a new Neighbor Cache Entry in the 432 REACHABLE state for the sending router if one does not currently 433 exist. 435 4.7.1. Conflicting results 437 It is possible that the DHCPv6 exchanges and the neighbor discovery 438 based probes complete with conflicting results. In this case, the 439 host SHOULD use the following rules to determine the final result. 441 o If the DHCPv6 exchange was authenticated, use the result from 442 DHCPv6. 444 o If the DHCPv6 exchange was not authenticated and the neighbor 445 discovery exchange was protected by SEND [RFC3971], use the result 446 from the neighbor discovery probe. 448 o If both the DHCPv6 and neighbor discovery exchanges were not 449 authenticated, use the result from DHCPv6. 451 In situations where Neighbor Solicitation probes and Router 452 Solicitation probes are used on the same link, it is possible that 453 the NS probe will complete successfully, and then the RS probe will 454 complete later with a different result. If this happens, the 455 implementation SHOULD abandon the results obtained from the NS probe 456 of the router that responded to the RS and the implementation SHOULD 457 behave as if the NS probe did not successfully complete. If the 458 confirmed address was assigned manually, the implementation SHOULD 459 NOT unconfigure the manually assigned address and SHOULD log an error 460 about the mismatching prefix. 462 4.8. Further Host Operations 464 Operations subsequent to detecting network attachment depend upon 465 whether change was detected. 467 After confirming the reachability of the associated router using an 468 NS/NA pair, the host performs the following steps. 470 o The host SHOULD rejoin any solicited nodes' multicast groups for 471 addresses it continues to use. 473 o The host SHOULD select a default router as described in Section 474 6.3.6 of [RFC4861]. 476 If the host has determined that there has been no link change, it 477 SHOULD NOT perform duplicate address detection on the addresses that 478 have been confirmed to be operable. 480 If the NS based probe with a router did not complete or if the RS 481 based probe on the same router completed with different prefixes than 482 the ones in the SDAT the host MUST begin address configuration 483 techniques, as indicated in a received Router Advertisement 484 [RFC4861][RFC4862]. 486 4.9. Recommended retransmission behavior 488 Where the NS probe does not complete successfully, it usually implies 489 that the host is not attached to the network whose configuration is 490 being tested. In such circumstances, there is typically little value 491 in aggressively retransmitting unicast neighbor solicitations that do 492 not elicit a response. 494 Where unicast Neighbor Solicitations and Router Solicitations are 495 sent in parallel, one strategy is to forsake retransmission of 496 Neighbor Solicitations and to allow retransmission only of Router 497 Solicitations or DHCPv6. In order to reduce competition between 498 unicast Neighbor Solicitations and Router Solicitations and DHCPv6 499 retransmissions, a DNAv6 implementation that retransmits may utilize 500 the retransmission strategy described in the DHCPv6 specification 501 [RFC3315], scheduling DNAv6 retransmissions between Router 502 Solicitations or DHCPv6 retransmissions. 504 If a response is received to any unicast Neighbor Solicitation, 505 Router Solicitation or DHCPv6 message, pending retransmissions MUST 506 be canceled [RFC3315][RFC3736]. A Simple DNA implementation SHOULD 507 NOT retransmit a Neighbor Solicitation more than twice. To provide 508 damping in the case of spurious Link Up indications, the host SHOULD 509 NOT perform the Simple DNA procedure more than once a second. 511 5. Pseudocode for Simple DNA 513 /* Link up indication received on INTERFACE */ 514 /* Start Simple DNA process */ 516 /* Mark All Addresses as deprecated */ 517 Configured_Address_List=Get_Address_List(INTERFACE); 518 foreach Configured_Address in Configured_Address_List 519 { 520 if (Get_Address_State(Configured_Address)!=AS_TENTATIVE) 521 { 522 Set_Address_State(Configured_Address,AS_DEPRECATED); 523 } 524 } 526 /* Mark all routers' NC entries as STALE to speed up */ 527 /* acquisition of new router if link change has occurred */ 528 foreach Router_Address in DEFAULT_ROUTER_LIST 529 { 530 NCEntry=Get_Neighbor_Cache_Entry(Router_Address); 531 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE); 532 } 534 /* Thread A : Send Router Solicitation */ 535 RS_Target_Address=FF02::2; 536 RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 537 Send_Router_Solicitation(RS_Source_Address,RS_Target_Address); 539 /* Thread B : Send Neighbor Solicitation(s) */ 540 Previously_Known_Router_List=Get_Router_List_from_SDAT(); 541 NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 543 foreach Router_Address in Previously_Known_Router_List 544 { 545 if (Get_Any_Valid_Address_from_SDAT(Router_Address)) 546 { 547 Send_Neighbor_Solicitation(NS_Source_Address,Router_Address); 548 } 549 } 551 /* Thread C : Response collection */ 553 /* Received Router Advertisement processing */ 554 /* Only for RAs received as response to DNA RSs */ 556 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 557 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 558 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 559 foreach SDAT_Entry in SDAT_Entry_List 560 { 561 if (Exists_PIO(RECEIVED_MESSAGE,Get_Prefix(SDAT_Entry))) 562 { 563 /* Address is operable. Configure on Interface */ 564 /* Rejoin solicited-node multicast group for address */ 565 } 566 else 567 { 568 /* If address is configured on interface, remove it */ 569 /* This could be because of a NA arriving before RA */ 570 } 571 } 573 /* Mark router as reachable */ 574 NCEntry=Get_Neighbor_Cache_Entry(L3_Source); 575 if (NCEntry is not NULL) 576 { 577 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_REACHABLE); 578 } 579 else 580 { 581 Create_Neighbor_Cache_Entry(L3_Source,NCS_REACHABLE); 582 } 584 /* Ignore further NAs from this router */ 585 Add_Router_to_NA_Ignore_List(L3_Source); 587 /* Received Neighbor Advertisement processing */ 588 /* Only for NAs received as response to DNA NSs */ 590 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 591 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 593 if (Is_Router_on_NA_Ignore_List(L3_Source)) { 594 /* Ignore message and wait for next message */ 595 continue; 596 } 598 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 600 foreach SDAT_Entry in SDAT_Entry_List 601 { 602 /* Address is operable. Configure on Interface */ 603 } 605 Figure 1: Pseudocode for Simple DNA 607 NOTE: This section does not include any pseudo-code for sending of 608 the DHCPv6 packets since the DHCPv6 exchange is orthogonal to the 609 simple DNA process. 611 6. Constants 613 SEND_NA_GRACE_TIME 615 Definition: An optional period to wait after Neighbor 616 Solicitation before adopting a non-SEND RA's link change 617 information. 619 Value: 40 milliseconds 621 7. Relationship to DNAv4 623 DNAv4 [RFC4436] specifies a set of steps that optimize the (common) 624 case of re-attachment to an IPv4 network that one has been connected 625 to previously by attempting to re-use a previous (but still valid) 626 configuration. This document shares the same goal as DNAv4 (that of 627 minimizing the handover latency in moving between points of 628 attachment) but differs in the steps it performs to achieve this 629 goal. Another difference is that this document also supports 630 stateless autoconfiguration of addresses in addition to addresses 631 configured using DHCPv6. 633 8. IANA Considerations 635 There are no changes to IANA registries required in this document. 637 9. Security Considerations 639 A host may receive Router Advertisements from non-SEND devices, after 640 receiving a link-layer indications. While it is necessary to assess 641 quickly whether a host has moved to another network, it is important 642 that the host's current secured SEND [RFC3971] router information is 643 not replaced by an attacker which spoofs an RA and purports to change 644 the link. 646 As such, the host SHOULD send a Neighbor Solicitation to the existing 647 SEND router upon link-up indication as described above in 648 Section 4.3. The host SHOULD then ensure that unsecured router 649 information does not cause deletion of existing SEND state, within 650 MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to 651 respond. 653 If the current default router is a SEND-secured router, the host 654 SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a 655 new default router. 657 Even if SEND signatures on RAs are used, it may not be immediately 658 clear if the router is authorized to make such advertisements. As 659 such, a host SHOULD NOT treat such devices as secure until and unless 660 authorization delegation discovery is successful. 662 Unless SEND or other form of secure address configuration is used, 663 the DNA procedure does not in itself provide positive, secure 664 authentication of the router(s) on the network, or authentication of 665 the network itself, as e.g. would be provided by mutual 666 authentication at the link layer. Therefore when such assurance is 667 not available, the host MUST NOT make any security-sensitive 668 decisions based on the DNA procedure alone. In particular, it MUST 669 NOT decide that it has moved from an untrusted to a trusted network, 670 and MUST NOT make any security decisions that depend on the 671 determination that such a transition has occurred. 673 10. Acknowledgments 675 This document is the product of a discussion the authors had with 676 Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at IETF 677 69. The authors would like to thank them for clearly detailing the 678 requirements of the solution and the goals it needed to meet and for 679 helping to explore the solution space. The authors would like to 680 thank the authors and editors of the complete DNA specification for 681 detailing the overall problem space and solutions. The authors would 682 like to thank Jari Arkko for driving the evolution of a simple and 683 probabilistic DNA solution. The authors would like to thank Bernard 684 Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier, 685 Domagoj Premec, Jin Hyeock-Choi, Alfred Hoenes, Frederic Rossi, Ralph 686 Droms, Ted Lemon, Erik Nordmark, Lars Eggert, Brian Carpenter and 687 Yaron Sheffer for performing reviews on the document and providing 688 valuable comments to drive the document forward. 690 11. References 692 11.1. Normative References 694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 695 Requirement Levels", BCP 14, RFC 2119, March 1997. 697 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 698 (DHCP) Service for IPv6", RFC 3736, April 2004. 700 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 701 and M. Carney, "Dynamic Host Configuration Protocol for 702 IPv6 (DHCPv6)", RFC 3315, July 2003. 704 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 705 Neighbor Discovery (SEND)", RFC 3971, March 2005. 707 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 708 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 709 September 2007. 711 11.2. Informative References 713 [I-D.ietf-dna-protocol] 714 Narayanan, S., "Detecting Network Attachment in IPv6 715 Networks (DNAv6)", draft-ietf-dna-protocol (work in 716 progress), June 2007. 718 [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., 719 and A. Yegin, "Link-Layer Event Notifications for 720 Detecting Network Attachments", RFC 4957, August 2007. 722 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 723 Address Autoconfiguration", RFC 4862, September 2007. 725 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 726 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 728 Appendix A. Issues with confirming manually assigned addresses 730 Even though DNAv4 [RFC4436] supports verification of manually 731 assigned addresses this feature of DNAv4 has not been widely 732 implemented or used. There are two major issues that come up with 733 confirming manually assigned addresses using Simple DNA. 735 o When DHCPv6 or SLAAC addresses are used for probing, there is no 736 need to aggressively retransmit lost probes. This is because the 737 address configuration falls back to vanilla DHCPv6 or SLAAC and 738 the host will eventually obtain an address. This is not the case 739 with manually assigned addresses. If the probes are lost, the 740 host runs the risk of ending up with no addresses at all. Hence 741 agressive retransmissions are necessary. 743 o Another issue comes up when the host moves between two networks, 744 one where manual addressing is being used (say NET1)and the other 745 where dynamic addressing (stateless autoconfig or DHCPv6) is being 746 used (say NET2). Since the host can obtain a dynamic address in 747 some situations, it will need to send simple DNA probes and may 748 also engage in a DHCPv6 exchange. In a situation where the host 749 moves to NET1 and the NS probes are lost and in addition an RA is 750 not received, the host will not be able to confirm that it 751 attached to NET1, and therefore that it should use the manual 752 configuration for that network. As a result, if DHCPv6 is enabled 753 on NET1, then the host could mistakenly obtain a dynamic address 754 and configuration instead of using the manual configuration. To 755 prevent this problem, simple DNA probing needs to continue even 756 after the DHCPv6 exchange has completed, and DNA probes need to 757 take precedence over DHCPv6, contrary to the advice provided in 758 Section 4.7.1 760 Given these issues, it is NOT RECOMMENDED to use manual addressing 761 with Simple DNA. 763 Authors' Addresses 765 Suresh Krishnan 766 Ericsson 767 8400 Decarie Blvd. 768 Town of Mount Royal, QC 769 Canada 771 Phone: +1 514 345 7900 x42871 772 Email: suresh.krishnan@ericsson.com 774 Greg Daley 775 NetStar Networks 776 Level 9/636 St Kilda Rd 777 Melbourne, Victoria 3004 778 Australia 780 Phone: +61 3 8532 4042 781 Email: gdaley@netstarnetworks.com