idnits 2.17.1 draft-ietf-dna-simple-06.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 (February 24, 2009) is 5532 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) == 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. 'I-D.ietf-dna-protocol') ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: August 28, 2009 February 24, 2009 8 Simple procedures for Detecting Network Attachment in IPv6 9 draft-ietf-dna-simple-06 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 August 28, 2009. 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 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 Detecting Network Attachment allows hosts to assess if its existing 49 addressing or routing configuration is valid for a newly connected 50 network. 52 This document provides simple procedures for detecting network 53 attachment in IPv6 hosts, and procedures for routers to support such 54 services. 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 62 2.3. Link Identification model . . . . . . . . . . . . . . . . 4 63 2.4. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6 68 4.2. Steps involved in detecting link change . . . . . . . . . 6 69 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 6 70 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 6 71 4.5. Contents of the Neighbor Discovery messages . . . . . . . 8 72 4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8 73 4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8 74 4.6. Sending DHCPv6 probes . . . . . . . . . . . . . . . . . . 8 75 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9 76 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 10 77 4.9. Recommended retransmission behavior . . . . . . . . . . . 10 78 5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. DHCPv6 Router/Server Operations . . . . . . . . . . . . . 12 80 6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 12 81 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 14 83 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 89 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Requirements notation 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Introduction 100 Hosts require procedures to simply and reliably identify if they have 101 moved to a different IP network to the one which they have been 102 recently connected. In order to detect change, router and neighbour 103 discovery messages are used to collect reachability and configuration 104 information. This information is used to detect whether the existing 105 router and address prefixes are likely to be present. 107 This document incorporates feedback from host and router operating 108 systems implementors, which seeks to make implementation and adoption 109 of IPv6 change detection procedures simple for general use. 111 2.1. Goals 113 The goal of this document is to specify a simple procedure for 114 detecting network attachment (Simple DNA) that has the following 115 characteristics. 117 o Routers do not have to be modified to support this scheme. 119 o Handle only the simplest and most likely use cases. 121 o Work at least as quickly as standard neighbor discovery. 123 o False positives are not acceptable. A host should not conclude 124 that there is no link change when there is one. 126 o False negatives are acceptable. A host can conclude that there is 127 a link change when there is none. 129 2.2. Applicability 131 The Simple DNA protocol provides substantial benefits in some 132 scenarios and does not provide any benefit at all in certain other 133 scenarios. This is intentional as Simple DNA was designed for 134 simplicity rather than completeness. In particular, the Simple DNA 135 protocol provides maximum benefits when a host moves between a small 136 set of known links. When a host moves to a completely new link that 137 is previously unknown, the performance of the Simple DNA protocol 138 will be identical to that using standard neighbor discovery 139 procedures [RFC4861]. 141 2.3. Link Identification model 143 Earlier methods of detecting network attachment, e.g. the procedure 144 defined in [I-D.ietf-dna-protocol], relied on detecting whether the 145 host was still connected to the same link. If the host was attached 146 to the same link, all information related to the link such as the 147 routers, prefixes and configuration parameters was considered to be 148 valid. The Simple DNA protocol follows an alternate approach where 149 it relies on probing each previously known router to determine 150 whether to use information learnt from THAT router. This allows 151 simple DNA to probe routers learnt from multiple earlier attachments 152 to optimize movement between a known set of links. 154 2.4. DNA Roles 156 Detecting Network Attachment is performed by hosts by sending IPv6 157 neighbour discovery and router discovery messages to routers after 158 connecting to a network. 160 It is desirable that routers adopt procedures which allow for fast 161 unicast Router Advertisement (RA) messages. Routers that follow the 162 standard neighbor discovery procedure described in [RFC4861] will 163 delay the router advertisement by a random period between 0 and 164 MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 165 of [RFC4861]. This delay can be significant and may result in 166 service disruption. Please note that support for fast unicast RAs is 167 not necessary since the simple dna procedure can continue to work 168 using the NS/NA exchange, which will complete earlier than the RA 169 arrives. 171 The host detects that the link-layer may have changed, and then 172 simultaneously probes the network with Router Solicitations (RSs) and 173 Neighbour Solicitations (NSs). The host uses advertisements to 174 determine if the routers it currently has configured are still 175 available. 177 Additionally, on links with no statelessly configured addresses, the 178 host may make use of DHCPv6 procedures to identify an operable 179 address. 181 2.5. Working Assumptions 183 There are a series of assumptions about the network environment which 184 underpin these procedures. 186 o The combination of the link layer address and the link local IPv6 187 address of a router is unique across links. 189 o Hosts receive indications when a link-layer comes up. Without 190 this, they would not know when to commence the DNA procedure. 192 If these assumptions do not hold, host change detection systems will 193 not function optimally. In that case, they may occasionally detect 194 change spuriously, or experience some delay in detecting network 195 attachment. The delays so experienced will be no longer than those 196 caused by following the standard neighbor discovery procedure 197 described in [RFC4861]. 199 If systems do not meet these assumptions or if systems seek 200 deterministic change detection operations they are directed to follow 201 the complete dna procedure as defined in [I-D.ietf-dna-protocol]. 203 3. Terminology 205 +---------------------+---------------------------------------------+ 206 | Term | Definition | 207 +---------------------+---------------------------------------------+ 208 | Valid IPv6 address | An IPv6 address configured on the node that | 209 | | has a valid lifetime greater than zero. | 210 | | | 211 | Operable IPv6 | An IPv6 address configured on the node that | 212 | address | can be used safely on the current link. | 213 +---------------------+---------------------------------------------+ 215 Table 1: Simple DNA Terminology 217 4. Host Operations 219 When a host has an existing configuration for IP address prefixes and 220 next hop routing, it may be disconnected from its link-layer, and 221 then subsequently reconnect the link-layer on the same interface. 223 When the link-layer becomes available again, it is important to 224 determine whether the existing addressing and routing configuration 225 are still valid. 227 In order to determine this, the host performs the detecting network 228 attachment procedure. 230 4.1. Host data structures 232 In order to correctly perform the procedure described in this 233 document the host needs to maintain a data structure called the 234 Simple DNA address table (SDAT). This data structure is maintained 235 by the host on a per interface basis. Each entry in the SDAT table 236 consists of at least the following parameters. 238 o IPv6 address and its related parameters like valid lifetime. 240 o Prefix from which the address was formed. 242 o Link-local IPv6 address of the router that advertised the prefix. 244 o Link layer (MAC) address of the router that advertised the prefix. 246 o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire 247 the address [RFC3315]. 249 4.2. Steps involved in detecting link change 251 The steps involved in basic detection of network attachment are: 253 o Link-Layer Indication 255 o Sending of neighbour discovery or DHCPv6 probes 257 o Response gathering and assessment 259 These steps are described below. 261 4.3. Link-Layer Indication 263 In order to start Detection of network attachment procedures, a host 264 typically requires a link-layer indication that the medium has become 265 available [RFC4957]. 267 After the indication is received, the host considers all currently 268 configured (non-tentative) IP addresses to as deprecated until the 269 change detection process completes. It SHOULD also set all Neighbor 270 Cache entries for the routers on its Default Router List to STALE. 271 This is done to speed up the acquisition of a new default router when 272 link change has occurred. 274 4.4. Sending Neighbor Discovery probes 276 When a host receives a link-layer "up" indication, it SHOULD 277 immediately send both a Router Solicitation and if it retains at 278 least one valid IPv6 address, one or more unicast Neighbor 279 Solicitations. The Router Solicitation is sent to the All-routers 280 multicast address using a link-local address as the source address 281 [RFC4861]. Even if the host is in possession of more than one valid 282 IPv6 address, it MUST send only one router solicitation using a valid 283 link-local address as the source address. 285 For the purpose of sending neighbor solicitations to previous 286 routers, the host first needs to pick a subset of operable IPv6 287 addresses (candidate set) that it wishes to use. How this subset of 288 addresses is picked is based on host configuration. e.g. The host 289 may select configured addresses from each of zero, one or two 290 previously connected links. If the addresses obtained from a 291 previous router are no longer valid, the host does not include these 292 addresses in the candidate set for NS based probing. 294 For each of the addresses in the candidate set, the host looks up the 295 SDAT to find out the link-local and MAC addresses of the router that 296 advertised the prefix used to form the address. It then sends an 297 unicast Neighbor Solicitations to each router's link-local address it 298 obtained from the lookup on the SDAT. The host SHOULD NOT send 299 unicast Neighbor Solicitations to a test node corresponding to an 300 IPv6 address that is no longer valid. 302 Please note that the Neighbour Solicitations SHOULD be sent in 303 parallel with the Router Solicitations. Since sending NSs is just an 304 optimization, doing the NSs and RSs in parallel ensures that the 305 procedure does not run slower than it would if it only used an RS. 307 Be aware that each unicast solicitation which is not successful may 308 cause packet flooding in bridged networks, if the networks are not 309 properly configured. This is further described in Section 9. Where 310 flooding may cause performance issues within the LAN, host SHOULD 311 limit the number of unicast solicitations. 313 4.5. Contents of the Neighbor Discovery messages 315 4.5.1. Neighbor Solicitation messages 317 This section describes the contents of the neighbor solicitation 318 probe messages sent during the probing procedure. 320 Source Address: A link-local address assigned to the 321 probing host. 323 Destination Address: The link-local address of the router being 324 probed as learnt from the SDAT. 326 Hop Limit: 255 328 ND Options: 330 Target Address: The link-local address of the router being 331 probed as learnt from the SDAT. 333 The probing node SHOULD include a Source link-layer address option in 334 the probe messages. If the node believes that the source address of 335 the NS may not be unique on the newly attached link, it MAY omit the 336 Source link-layer address option in the probe messages. 338 4.5.2. Router Solicitation messages 340 This section describes the contents of the router solicitation probe 341 message sent during the probing procedure. 343 Source Address: A link-local address assigned to the 344 probing host. 346 Destination Address: The all-routers multicast address. 348 Hop Limit: 255 350 The probing node SHOULD NOT include a Source link-layer address 351 option if it has not performed duplicate address detection [RFC4862], 352 for the source address of the NS, on the newly attached link. 354 4.6. Sending DHCPv6 probes 356 Where the host has acquired addresses from DHCPv6 or the host does 357 not have a global prefix, it MAY prefer to use DHCPv6 messages either 358 before or simultanously with Neighbour Discovery probing. 360 In that case, when the host receives a link-layer indication, it 361 sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This 362 message contains an Identity Addociation for either a Temporary 363 Address (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an 364 existing valid address is being tested for operability, this address 365 should be placed in the Identity Association's IAADDR element, and 366 the DUID associated with that address should be copied to the DHCP 367 SOLICIT from the SDAT. 369 In order to quickly acquire a new address in the case that link 370 change has occurred, this SOLICIT message MAY contain the Rapid- 371 Commit option. 373 Where the Rapid-Commit option has not been used, a present DHCP 374 server will respond with an ADVERTISE message. The IP address 375 contained in the Identity Association (IA_TA or IA_NA) will contain 376 an IP Address which is operable for the link. 378 Where Rapid-Commit option has been sent, a DHCPv6 server will respond 379 with REPLY. In addition to being operable, this address is allocated 380 to the host for the lease duration indicated in the Identity 381 Association. 383 4.7. Response Gathering 385 When a responding Neighbour Advertisement is received from a test 386 node, the host MUST verify that both the IPv6 and link layer (MAC) 387 addresses of the test node match the expected values before utilizing 388 the configuration associated with the detected network (prefixes, MTU 389 etc.). 391 On reception of a Router Advertisement or advertising DHCPv6 message 392 (a REPLY or ADVERTISE) which contains prefixes that intersect with 393 those previously advertised by a known router, the host utilizes the 394 configuration associated with the detected network. 396 When the host receives an advertisement containing only prefixes 397 which are disjoint from known advertised prefixes, the host MUST 398 determine whether the solicited advertisement corresponds to any of 399 the routers probed via NS. If it does, then the host SHOULD conclude 400 that the IPv6 addresses corresponding to that router are no longer 401 valid. Since any NS probes to that router will no longer provide 402 useful information, further probing of that router SHOULD be aborted. 404 Where the conclusions obtained from the Neighbor Solicitation/ 405 Advertisement from a given router and the RS/RA exchange with the 406 same router differ, the results obtained from the RS/RA will be 407 considered definitive. 409 When the host receives a Router Advertisement in reply to the Router 410 Solicitation it sent, the host SHOULD look for a Neighbor Cache entry 411 for the sending router and SHOULD mark that router's Neighbor Cache 412 Entry as REACHABLE if one was found. The host SHOULD add a new 413 Neighbor Cache Entry in the REACHABLE state for the sending router if 414 one does not currently exist. 416 4.8. Further Host Operations 418 Operations subsequent to detecting network attachment depend upon 419 whether change was detected. 421 After confirming the reachability of the associated router using an 422 NS/NA pair, the host performs the following steps. 424 o The host SHOULD rejoin any solicited nodes' multicast groups for 425 addresses it continues to use. 427 o The host SHOULD select a default router as described in [RFC4861]. 429 If the host has determined that there has been no link change, it 430 SHOULD NOT perform duplicate address detection on the addresses that 431 have been confirmed to be operable. 433 If the NS based probe with a router did not complete or if the RS 434 based probe on the same router completed with different prefixes than 435 the ones in the SDAT the host MUST unconfigure all the existing 436 addresses received from the given router, and MUST begin address 437 configuration techniques, as indicated in the received Router 438 Advertisement [RFC4861][RFC4862]. 440 4.9. Recommended retransmission behavior 442 In situations where Neighbor Solicitation probes and Router 443 Solicitation probes are used on the same link, it is possible that 444 the NS probe will complete successfully, and then the RS probe will 445 complete later with a different result. If this happens, the 446 implementation SHOULD abandon the results obtained from the NS probe 447 of the router that responded to the RS and the implementation SHOULD 448 behave as if the NS probe did not successfully complete. If the 449 confirmed address was assigned manually, the implementation SHOULD 450 NOT unconfigure the manually assigned address and SHOULD log an error 451 about the mismatching prefix. 453 Where the NS probe does not complete successfully, it usually implies 454 that the host is not attached to the network whose configuration is 455 being tested. In such circumstances, there is typically little value 456 in aggressively retransmitting unicast neighbor solicitations that do 457 not elicit a response. 459 Where unicast Neighbor Solicitations and Router Solicitations are 460 sent in parallel, one strategy is to forsake retransmission of 461 Neighbor Solicitations and to allow retransmission only of Router 462 Solicitations or DHCPv6. In order to reduce competition between 463 unicast Neighbor Solicitations and Router Solicitations and DHCPv6 464 retransmissions, a DNAv6 implementation that retransmits may utilize 465 the retransmission strategy described in the DHCPv6 specification 466 [RFC3315], scheduling DNAv6 retransmissions between Router 467 Solicitation or DHCPv6 retransmissions. 469 If a response is received to any unicast Neighbor Solicitation, 470 Router Solicitation or DHCPv6 message, pending retransmissions MUST 471 be canceled [RFC3315][RFC3736]. A Simple DNA implementation SHOULD 472 NOT retransmit a Neighbor Solicitation more than twice. To provide 473 damping in the case of spurious Link Up indications, the host SHOULD 474 NOT perform the Simple DNA procedure more than once a second. 476 5. Router Operations 478 Hosts checking their network attachment are unsure of their address 479 status, and may be using Tentative link-layer addressing information 480 in their router or neighbour solicitations. 482 A router which desires to support hosts' DNA operations MUST process 483 Tentative Options from unicast source addressed Router and Neighbour 484 Solicitations, as described in [I-D.ietf-dna-tentative]. 486 5.1. DHCPv6 Router/Server Operations 488 DHCPv6 Server operations occur in accordance with the DHCPv6 RFC 489 [RFC3315]. 491 6. Pseudocode for Simple DNA 493 /* Link up indication received on INTERFACE */ 494 /* Start Simple DNA process */ 496 /* Mark All Addresses as deprecated */ 497 Configured_Address_List=Get_Address_List(INTERFACE); 498 foreach Configured_Address in Configured_Address_List 499 { 500 if (Get_Address_State(Configured_Address)!=AS_TENTATIVE) 501 { 502 Set_Address_State(Configured_Address,AS_DEPRECATED); 503 } 504 } 506 /* Mark all routers' NC entries as STALE to speed up */ 507 /* acquisition of new router if link change has occurred */ 508 foreach Router_Address in DEFAULT_ROUTER_LIST 509 { 510 NCEntry=Get_Neighbor_Cache_Entry(Router_Address); 511 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE); 512 } 514 /* Thread A : Send Router Solicitation */ 515 RS_Target_Address=FF02::2; 516 RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 517 Send_Router_Solicitation(RS_Source_Address,RS_Target_Address); 519 /* Thread B : Send Neighbor Solicitation(s) */ 520 Previously_Known_Router_List=Get_Router_List_from_SDAT(); 521 NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 523 foreach Router_Address in Previously_Known_Router_List 524 { 525 if (Get_Any_Valid_Address_from_SDAT(Router_Address)) 526 { 527 Send_Neighbor_Solicitation(NS_Source_Address,Router_Address); 528 } 529 } 531 /* Thread C : Response collection */ 532 /* Received Router Advertisement processing */ 533 /* Only for RAs received as response to DNA RSs */ 535 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 536 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 537 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 539 foreach SDAT_Entry in SDAT_Entry_List 540 { 541 if (Exists_PIO(RECEIVED_MESSAGE,Get_Prefix(SDAT_Entry))) 542 { 543 /* Address is operable. Configure on Interface */ 544 /* Rejoin solicited-node multicast group for address */ 545 } 546 else 547 { 548 /* If address is configured on interface, remove it */ 549 /* This could be because of a NA arriving before RA */ 550 } 551 } 553 /* Mark router as reachable */ 554 NCEntry=Get_Neighbor_Cache_Entry(L3_Source); 555 if (NCEntry is not NULL) 556 { 557 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_REACHABLE); 558 } 559 else 560 { 561 Create_Neighbor_Cache_Entry(L3_Source,NCS_REACHABLE); 562 } 564 /* Ignore further NAs from this router */ 565 Add_Router_to_NA_Ignore_List(L3_Source); 567 /* Received Neighbor Advertisement processing */ 568 /* Only for NAs received as response to DNA NSs */ 570 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 571 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 573 if (Is_Router_on_NA_Ignore_List(L3_Source)) { 574 /* Ignore message and wait for next message */ 575 continue; 576 } 578 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 579 foreach SDAT_Entry in SDAT_Entry_List 580 { 581 /* Address is operable. Configure on Interface */ 582 } 584 Figure 1: Pseudocode for Simple DNA 586 7. Constants 588 These constants are described as in [I-D.ietf-dna-protocol]. 590 UNICAST_RA_INTERVAL 592 Definition: The interval corresponding to the maximum average 593 rate of Router Solicitations that the router is prepared to 594 service with unicast responses. This is the interval at which 595 the token bucket controlling the unicast responses is 596 replenished. 598 Value: 50 milliseconds 600 MAX_UNICAST_RA_BURST 602 Definition: The maximum size burst of Router Solicitations that 603 the router is prepared to service with unicast responses. This 604 is the maximum number of tokens allowed in the token bucket 605 controlling the unicast responses. 607 Value: 20 609 SEND_NA_GRACE_TIME 611 Definition: An optional period to wait after Neighbour 612 Solicitation before adopting a non-SEND RA's link change 613 information. 615 Value: 40 milliseconds 617 8. Relationship to DNAv4 619 DNAv4 [RFC4436] specifies a set of steps that optimize the (common) 620 case of re-attachment to an IPv4 network that one has been connected 621 to previously by attempting to re-use a previous (but still valid) 622 configuration. This document shares the same goal as DNAv4 (that of 623 minimizing the handover latency in moving between points of 624 attachment) but differs in the steps it performs to achieve this 625 goal. Another difference is that this document also supports 626 stateless autoconfiguration of addresses in addition to addresses 627 configured using DHCPv6. 629 9. Open Issues 631 This section documents issues that are still outstanding within the 632 document, and the simple DNA solution in general. 634 Rate limitation for solicitations. 636 Hosts MAY implement hysteresis mechanisms to pace solicitations 637 where necessary to prevent damage to a particular medium. 638 Implementors should be aware that when such hysteresis is 639 triggered, Detecting Network Attachment may be slowed, which may 640 affect application traffic. 642 10. IANA Considerations 644 There are no changes to IANA registries required in this document. 646 11. Security Considerations 648 When providing fast responses to router solicitations, it is possible 649 to cause collisions with other signaling packets on contention based 650 media. This can cause repeated packet loss or delay when multiple 651 routers are present on the link. 653 As such the fast router advertisement system is NOT RECOMMENDED in 654 this form for media which are susceptible to collision loss. Such 655 environments may be better served using the procedures defined in 656 [I-D.ietf-dna-protocol]. 658 A host may receive Router Advertisements from non SEND devices, after 659 receiving a link-layer indications. While it is necessary to assess 660 quickly whether a host has moved to another network, it is important 661 that the host's current secured SEND [RFC3971] router information is 662 not replaced by an attacker which spoofs an RA and purports to change 663 the link. 665 As such, the host SHOULD send a Neighbour Solicitation to the 666 existing SEND router upon link-up indication as described above in 667 Section 4.3. The host SHOULD then ensure that unsecured router 668 information does not cause deletion of existing SEND state, within 669 MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to 670 respond. 672 The host MAY delay SEND_NA_GRACE_TIME after transmission before 673 adopting a new default router, if it is operating on a network where 674 there is significant threat of RA spoofing. 676 Even if SEND signatures on RAs are used, it may not be immediately 677 clear if the router is authorized to make such advertisements. As 678 such, a host SHOULD NOT treat such devices as secure until and unless 679 authorization delegation discovery is successful. 681 It is easy for hosts soliciting without SEND to deplete a SEND 682 router's fast advertisement token buckets, and consume additional 683 bandwidth. As such, a router MAY choose to preserve a portion of 684 their token bucket to serve solicitations with SEND signatures. 686 12. Acknowledgments 688 This document is the product of a discussion between the authors had 689 with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at 690 IETF 69. The authors would like to thank them for clearly detailing 691 the requirements of the solution and the goals it needed to meet and 692 for helping to explore the solution space. The authors would like to 693 thank the authors and editors of the complete DNA specification for 694 detailing the overall problem space and solutions. The authors would 695 like to thank Jari Arkko for driving the evolution of a simple and 696 probabilistic DNA solution. The authors would like to thank Bernard 697 Aboba, Thomas Narten, Sathya Narayan, Julien Laganier, Domagoj 698 Premec, Jin Hyeock-Choi, Alfred Hoenes and Frederic Rossi for 699 performing reviews on the document and providing valuable comments to 700 drive the document forward. 702 13. References 704 13.1. Normative References 706 [I-D.ietf-dna-tentative] 707 Daley, G., Nordmark, E., and N. Moore, "Tentative Options 708 for IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 709 (work in progress), July 2007. 711 [I-D.ietf-dna-protocol] 712 Narayanan, S., "Detecting Network Attachment in IPv6 713 Networks (DNAv6)", draft-ietf-dna-protocol (work in 714 progress), June 2007. 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, March 1997. 719 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 720 and M. Carney, "Dynamic Host Configuration Protocol for 721 IPv6 (DHCPv6)", RFC 3315, July 2003. 723 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 724 (DHCP) Service for IPv6", RFC 3736, April 2004. 726 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 727 Neighbor Discovery (SEND)", RFC 3971, March 2005. 729 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 730 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 731 September 2007. 733 13.2. Informative References 735 [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., 736 and A. Yegin, "Link-Layer Event Notifications for 737 Detecting Network Attachments", RFC 4957, August 2007. 739 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 740 Address Autoconfiguration", RFC 4862, September 2007. 742 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 743 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 745 Authors' Addresses 747 Suresh Krishnan 748 Ericsson 749 8400 Decarie Blvd. 750 Town of Mount Royal, QC 751 Canada 753 Phone: +1 514 345 7900 x42871 754 Email: suresh.krishnan@ericsson.com 755 Greg Daley 756 NetStar Networks 757 Level 9/636 St Kilda Rd 758 Melbourne, Victoria 3004 759 Australia 761 Phone: +61 3 8532 4042 762 Email: gdaley@netstarnetworks.com