idnits 2.17.1 draft-ietf-dna-simple-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 771. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 777. 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 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 (November 3, 2008) is 5643 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 (==), 9 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: May 7, 2009 November 3, 2008 8 Simple procedures for Detecting Network Attachment in IPv6 9 draft-ietf-dna-simple-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Abstract 38 Detecting Network Attachment allows hosts to assess if its existing 39 addressing or routing configuration is valid for a newly connected 40 network. 42 This document provides simple procedures for detecting network 43 attachment in IPv6 hosts, and procedures for routers to support such 44 services. 46 Table of Contents 48 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 52 2.3. Link Identification model . . . . . . . . . . . . . . . . 4 53 2.4. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 4 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6 58 4.2. Steps involved in detecting link change . . . . . . . . . 6 59 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 6 60 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 6 61 4.5. Contents of the Neighbor Discovery messages . . . . . . . 8 62 4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8 63 4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8 64 4.6. Sending DHCPv6 probes . . . . . . . . . . . . . . . . . . 8 65 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9 66 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 10 67 4.9. Recommended retransmission behavior . . . . . . . . . . . 10 68 5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 11 69 5.1. DHCPv6 Router/Server Operations . . . . . . . . . . . . . 12 70 6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 12 71 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 78 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 Intellectual Property and Copyright Statements . . . . . . . . . . 18 82 1. Requirements notation 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Introduction 90 Hosts require procedures to simply and reliably identify if they have 91 moved to a different IP network to the one which they have been 92 recently connected. In order to detect change, router and neighbour 93 discovery messages are used to collect reachability and configuration 94 information. This information is used to detect whether the existing 95 router and address prefixes are likely to be present. 97 This document incorporates feedback from host and router operating 98 systems implementors, which seeks to make implementation and adoption 99 of IPv6 change detection procedures simple for general use. 101 2.1. Goals 103 The goal of this document is to specify a simple procedure for 104 detecting network attachment (Simple DNA) that has the following 105 characteristics. 107 o Routers do not have to be modified to support this scheme. 109 o Handle only the simplest and most likely use cases. 111 o Work at least as quickly as standard neighbor discovery. 113 o False positives are not acceptable. A host should not conclude 114 that there is no link change when there is one. 116 o False negatives are acceptable. A host can conclude that there is 117 a link change when there is none. 119 2.2. Applicability 121 The Simple DNA protocol provides substantial benefits in some 122 scenarios and does not provide any benefit at all in certain other 123 scenarios. This is intentional as Simple DNA was designed for 124 simplicity rather than completeness. In particular, the Simple DNA 125 protocol provides maximum benefits when a host moves between a small 126 set of known links. When a host moves to a completely new link that 127 is previously unknown, the performance of the Simple DNA protocol 128 will be identical to that using standard neighbor discovery 129 procedures [RFC4861]. 131 2.3. Link Identification model 133 Earlier methods of detecting network attachment, e.g. the procedure 134 defined in [I-D.ietf-dna-protocol], relied on detecting whether the 135 host was still connected to the same link. If the host was attached 136 to the same link, all information related to the link such as the 137 routers, prefixes and configuration parameters was considered to be 138 valid. The Simple DNA protocol follows an alternate approach where 139 it relies on probing each previously known router to determine 140 whether to use information learnt from THAT router. This allows 141 simple DNA to probe routers learnt from multiple earlier attachments 142 to optimize movement between a known set of links. 144 2.4. DNA Roles 146 Detecting Network Attachment is performed by hosts by sending IPv6 147 neighbour discovery and router discovery messages to routers after 148 connecting to a network. 150 It is desirable that routers adopt procedures which allow for fast 151 unicast Router Advertisement (RA) messages. Routers that follow the 152 standard neighbor discovery procedure described in [RFC4861] will 153 delay the router advertisement by a random period between 0 and 154 MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 155 of [RFC4861]. This delay can be significant and may result in 156 service disruption. Please note that support for fast unicast RAs is 157 not necessary since the simple dna procedure can continue to work 158 using the NS/NA exchange, which will complete earlier than the RA 159 arrives. 161 The host detects that the link-layer may have changed, and then 162 simultaneously probes the network with Router Solicitations (RSs) and 163 Neighbour Solicitations (NSs). The host uses advertisements to 164 determine if the routers it currently has configured are still 165 available. 167 Additionally, on links with no statelessly configured addresses, the 168 host may make use of DHCPv6 procedures to identify an operable 169 address. 171 2.5. Working Assumptions 173 There are a series of assumptions about the network environment which 174 underpin these procedures. 176 o The combination of the link layer address and the link local IPv6 177 address of a router is unique across links. 179 o Hosts receive indications when a link-layer comes up. Without 180 this, they would not know when to commence the DNA procedure. 182 If these assumptions do not hold, host change detection systems will 183 not function optimally. In that case, they may occasionally detect 184 change spuriously, or experience some delay in detecting network 185 attachment. The delays so experienced will be no longer than those 186 caused by following the standard neighbor discovery procedure 187 described in [RFC4861]. 189 If systems do not meet these assumptions or if systems seek 190 deterministic change detection operations they are directed to follow 191 the complete dna procedure as defined in [I-D.ietf-dna-protocol]. 193 3. Terminology 195 +---------------------+---------------------------------------------+ 196 | Term | Definition | 197 +---------------------+---------------------------------------------+ 198 | Valid IPv6 address | An IPv6 address configured on the node that | 199 | | has a valid lifetime greater than zero. | 200 | | | 201 | Operable IPv6 | An IPv6 address configured on the node that | 202 | address | can be used safely on the current link. | 203 +---------------------+---------------------------------------------+ 205 Table 1: Simple DNA Terminology 207 4. Host Operations 209 When a host has an existing configuration for IP address prefixes and 210 next hop routing, it may be disconnected from its link-layer, and 211 then subsequently reconnect the link-layer on the same interface. 213 When the link-layer becomes available again, it is important to 214 determine whether the existing addressing and routing configuration 215 are still valid. 217 In order to determine this, the host performs the detecting network 218 attachment procedure. 220 4.1. Host data structures 222 In order to correctly perform the procedure described in this 223 document the host needs to maintain a data structure called the 224 Simple DNA address table (SDAT). This data structure is maintained 225 by the host on a per interface basis. Each entry in the SDAT table 226 consists of at least the following parameters. 228 o IPv6 address and its related parameters like valid lifetime. 230 o Prefix from which the address was formed. 232 o Link-local IPv6 address of the router that advertised the prefix. 234 o Link layer (MAC) address of the router that advertised the prefix. 236 o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire 237 the address [RFC3315]. 239 4.2. Steps involved in detecting link change 241 The steps involved in basic detection of network attachment are: 243 o Link-Layer Indication 245 o Sending of neighbour discovery or DHCPv6 probes 247 o Response gathering and assessment 249 These steps are described below. 251 4.3. Link-Layer Indication 253 In order to start Detection of network attachment procedures, a host 254 typically requires a link-layer indication that the medium has become 255 available [RFC4957]. 257 After the indication is received, the host considers all currently 258 configured (non-tentative) IP addresses to as deprecated until the 259 change detection process completes. It SHOULD also set all Neighbor 260 Cache entries for the routers on its Default Router List to STALE. 261 This is done to speed up the acquisition of a new default router when 262 link change has occurred. 264 4.4. Sending Neighbor Discovery probes 266 When a host receives a link-layer "up" indication, it SHOULD 267 immediately send both a Router Solicitation and if it retains at 268 least one valid IPv6 address, one or more unicast Neighbor 269 Solicitations. The Router Solicitation is sent to the All-routers 270 multicast address using a link-local address as the source address 271 [RFC4861]. Even if the host is in possession of more than one valid 272 IPv6 address, it MUST send only one router solicitation using a valid 273 link-local address as the source address. 275 For the purpose of sending neighbor solicitations to previous 276 routers, the host first needs to pick a subset of operable IPv6 277 addresses (candidate set) that it wishes to use. How this subset of 278 addresses is picked is based on host configuration. e.g. The host 279 may select configured addresses from each of zero, one or two 280 previously connected links. If the addresses obtained from a 281 previous router are no longer valid, the host does not include these 282 addresses in the candidate set for NS based probing. 284 For each of the addresses in the candidate set, the host looks up the 285 SDAT to find out the link-local and MAC addresses of the router that 286 advertised the prefix used to form the address. It then sends an 287 unicast Neighbor Solicitations to each router's link-local address it 288 obtained from the lookup on the SDAT. The host SHOULD NOT send 289 unicast Neighbor Solicitations to a test node corresponding to an 290 IPv6 address that is no longer valid. 292 Please note that the Neighbour Solicitations SHOULD be sent in 293 parallel with the Router Solicitations. Since sending NSs is just an 294 optimization, doing the NSs and RSs in parallel ensures that the 295 procedure does not run slower than it would if it only used an RS. 297 Be aware that each unicast solicitation which is not successful may 298 cause packet flooding in bridged networks, if the networks are not 299 properly configured. This is further described in Section 8. Where 300 flooding may cause performance issues within the LAN, host SHOULD 301 limit the number of unicast solicitations. 303 4.5. Contents of the Neighbor Discovery messages 305 4.5.1. Neighbor Solicitation messages 307 This section describes the contents of the neighbor solicitation 308 probe messages sent during the probing procedure. 310 Source Address: A link-local address assigned to the 311 probing host. 313 Destination Address: The link-local address of the router being 314 probed as learnt from the SDAT. 316 Hop Limit: 255 318 ND Options: 320 Target Address: The link-local address of the router being 321 probed as learnt from the SDAT. 323 The probing node SHOULD NOT include a Source link-layer address 324 option if it has not performed duplicate address detection [RFC4862], 325 for the source address of the NS, on the newly attached link. 327 4.5.2. Router Solicitation messages 329 This section describes the contents of the router solicitation probe 330 message sent during the probing procedure. 332 Source Address: A link-local address assigned to the 333 probing host. 335 Destination Address: The all-routers multicast address. 337 Hop Limit: 255 339 The probing node SHOULD NOT include a Source link-layer address 340 option if it has not performed duplicate address detection [RFC4862], 341 for the source address of the NS, on the newly attached link. 343 4.6. Sending DHCPv6 probes 345 Where the host has acquired addresses from DHCPv6 or the host does 346 not have a global prefix, it MAY prefer to use DHCPv6 messages either 347 before or simultanously with Neighbour Discovery probing. 349 In that case, when the host receives a link-layer indication, it 350 sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This 351 message contains an Identity Addociation for either a Temporary 352 Address (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an 353 existing valid address is being tested for operability, this address 354 should be placed in the Identity Association's IAADDR element, and 355 the DUID associated with that address should be copied to the DHCP 356 SOLICIT from the SDAT. 358 In order to quickly acquire a new address in the case that link 359 change has occurred, this SOLICIT message MAY contain the Rapid- 360 Commit option. 362 Where the Rapid-Commit option has not been used, a present DHCP 363 server will respond with an ADVERTISE message. The IP address 364 contained in the Identity Association (IA_TA or IA_NA) will contain 365 an IP Address which is operable for the link. 367 Where Rapid-Commit option has been sent, a DHCPv6 server will respond 368 with REPLY. In addition to being operable, this address is allocated 369 to the host for the lease duration indicated in the Identity 370 Association. 372 4.7. Response Gathering 374 When a responding Neighbour Advertisement is received from a test 375 node, the host MUST verify that both the IPv6 and link layer (MAC) 376 addresses of the test node match the expected values before utilizing 377 the configuration associated with the detected network (prefixes, MTU 378 etc.). 380 On reception of a Router Advertisement or advertising DHCPv6 message 381 (a REPLY or ADVERTISE) which contains prefixes that intersect with 382 those previously advertised by a known router, the host utilizes the 383 configuration associated with the detected network. 385 When the host receives an advertisement containing only prefixes 386 which are disjoint from known advertised prefixes, the host MUST 387 determine whether the solicited advertisement corresponds to any of 388 the routers probed via NS. If it does, then the host SHOULD conclude 389 that the IPv6 addresses corresponding to that router are no longer 390 valid. Since any NS probes to that router will no longer provide 391 useful information, further probing of that router SHOULD be aborted. 393 Where the conclusions obtained from the Neighbor Solicitation/ 394 Advertisement from a given router and the RS/RA exchange with the 395 same router differ, the results obtained from the RS/RA will be 396 considered definitive. 398 When the host receives a Router Advertisement in reply to the Router 399 Solicitation it sent, the host SHOULD look for a Neighbor Cache entry 400 for the sending router and SHOULD mark that router's Neighbor Cache 401 Entry as REACHABLE if one was found. The host SHOULD add a new 402 Neighbor Cache Entry in the REACHABLE state for the sending router if 403 one does not currently exist. 405 4.8. Further Host Operations 407 Operations subsequent to detecting network attachment depend upon 408 whether change was detected. 410 After confirming the reachability of the associated router using an 411 NS/NA pair, the host performs the following steps. 413 o The host SHOULD rejoin any solicited nodes' multicast groups for 414 addresses it continues to use. 416 o The host SHOULD select a default router as described in [RFC4861]. 418 If the host has determined that there has been no link change, it 419 SHOULD NOT perform duplicate address detection on the addresses that 420 have been confirmed to be operable. 422 If the NS based probe with a router did not complete or if the RS 423 based probe on the same router completed with different prefixes than 424 the ones in the SDAT the host MUST unconfigure all the existing 425 addresses received from the given router, and MUST begin address 426 configuration techniques, as indicated in the received Router 427 Advertisement [RFC4861][RFC4862]. 429 4.9. Recommended retransmission behavior 431 In situations where Neighbor Solicitation probes and Router 432 Solicitation probes are used on the same link, it is possible that 433 the NS probe will complete successfully, and then the RS probe will 434 complete later with a different result. If this happens, the 435 implementation SHOULD abandon the results obtained from the NS probe 436 of the router that responded to the RS and the implementation SHOULD 437 behave as if the NS probe did not successfully complete. If the 438 confirmed address was assigned manually, the implementation SHOULD 439 NOT unconfigure the manually assigned address and SHOULD log an error 440 about the mismatching prefix. 442 Where the NS probe does not complete successfully, it usually implies 443 that the host is not attached to the network whose configuration is 444 being tested. In such circumstances, there is typically little value 445 in aggressively retransmitting unicast neighbor solicitations that do 446 not elicit a response. 448 Where unicast Neighbor Solicitations and Router Solicitations are 449 sent in parallel, one strategy is to forsake retransmission of 450 Neighbor Solicitations and to allow retransmission only of Router 451 Solicitations or DHCPv6. In order to reduce competition between 452 unicast Neighbor Solicitations and Router Solicitations and DHCPv6 453 retransmissions, a DNAv6 implementation that retransmits may utilize 454 the retransmission strategy described in the DHCPv6 specification 455 [RFC3315], scheduling DNAv6 retransmissions between Router 456 Solicitation or DHCPv6 retransmissions. 458 If a response is received to any unicast Neighbor Solicitation, 459 Router Solicitation or DHCPv6 message, pending retransmissions MUST 460 be canceled [RFC3315][RFC3736]. A Simple DNA implementation SHOULD 461 NOT retransmit a Neighbor Solicitation more than twice. To provide 462 damping in the case of spurious Link Up indications, the host SHOULD 463 NOT perform the Simple DNA procedure more than once a second. 465 5. Router Operations 467 Hosts checking their network attachment are unsure of their address 468 status, and may be using Tentative link-layer addressing information 469 in their router or neighbour solicitations. 471 A router which desires to support hosts' DNA operations MUST process 472 Tentative Options from unicast source addressed Router and Neighbour 473 Solicitations, as described in [I-D.ietf-dna-tentative]. 475 5.1. DHCPv6 Router/Server Operations 477 DHCPv6 Server operations occur in accordance with the DHCPv6 RFC 478 [RFC3315]. 480 6. Pseudocode for Simple DNA 482 /* Link up indication received on INTERFACE */ 483 /* Start Simple DNA process */ 485 /* Mark All Addresses as deprecated */ 486 Configured_Address_List=Get_Address_List(INTERFACE); 487 foreach Configured_Address in Configured_Address_List 488 { 489 if (Get_Address_State(Configured_Address)!=AS_TENTATIVE) 490 { 491 Set_Address_State(Configured_Address,AS_DEPRECATED); 492 } 493 } 495 /* Mark all routers' NC entries as STALE to speed up */ 496 /* acquisition of new router if link change has occurred */ 497 foreach Router_Address in DEFAULT_ROUTER_LIST 498 { 499 NCEntry=Get_Neighbor_Cache_Entry(Router_Address); 500 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE); 501 } 503 /* Thread A : Send Router Solicitation */ 504 RS_Target_Address=FF02::2; 505 RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 506 Send_Router_Solicitation(RS_Source_Address,RS_Target_Address); 508 /* Thread B : Send Neighbor Solicitation(s) */ 509 Previously_Known_Router_List=Get_Router_List_from_SDAT(); 510 NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 512 foreach Router_Address in Previously_Known_Router_List 513 { 514 if (Get_Any_Valid_Address_from_SDAT(Router_Address)) 515 { 516 Send_Neighbor_Solicitation(NS_Source_Address,Router_Address); 517 } 518 } 520 /* Thread C : Response collection */ 521 /* Received Router Advertisement processing */ 522 /* Only for RAs received as response to DNA RSs */ 524 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 525 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 526 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 528 foreach SDAT_Entry in SDAT_Entry_List 529 { 530 if (Exists_PIO(RECEIVED_MESSAGE,Get_Prefix(SDAT_Entry))) 531 { 532 /* Address is operable. Configure on Interface */ 533 /* Rejoin solicited-node multicast group for address */ 534 } 535 else 536 { 537 /* If address is configured on interface, remove it */ 538 /* This could be because of a NA arriving before RA */ 539 } 540 } 542 /* Mark router as reachable */ 543 NCEntry=Get_Neighbor_Cache_Entry(L3_Source); 544 if (NCEntry is not NULL) 545 { 546 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_REACHABLE); 547 } 548 else 549 { 550 Create_Neighbor_Cache_Entry(L3_Source,NCS_REACHABLE); 551 } 553 /* Ignore further NAs from this router */ 554 Add_Router_to_NA_Ignore_List(L3_Source); 556 /* Received Neighbor Advertisement processing */ 557 /* Only for NAs received as response to DNA NSs */ 559 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 560 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 562 if (Is_Router_on_NA_Ignore_List(L3_Source)) { 563 /* Ignore message and wait for next message */ 564 continue; 565 } 567 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 568 foreach SDAT_Entry in SDAT_Entry_List 569 { 570 /* Address is operable. Configure on Interface */ 571 } 573 Figure 1: Pseudocode for Simple DNA 575 7. Constants 577 These constants are described as in [I-D.ietf-dna-protocol]. 579 UNICAST_RA_INTERVAL 581 Definition: The interval corresponding to the maximum average 582 rate of Router Solicitations that the router is prepared to 583 service with unicast responses. This is the interval at which 584 the token bucket controlling the unicast responses is 585 replenished. 587 Value: 50 milliseconds 589 MAX_UNICAST_RA_BURST 591 Definition: The maximum size burst of Router Solicitations that 592 the router is prepared to service with unicast responses. This 593 is the maximum number of tokens allowed in the token bucket 594 controlling the unicast responses. 596 Value: 20 598 SEND_NA_GRACE_TIME 600 Definition: An optional period to wait after Neighbour 601 Solicitation before adopting a non-SEND RA's link change 602 information. 604 Value: 40 milliseconds 606 8. Open Issues 608 This section documents issues that are still outstanding within the 609 document, and the simple DNA solution in general. 611 Rate limitation for solicitations. 613 Hosts MAY implement hysteresis mechanisms to pace solicitations 614 where necessary to prevent damage to a particular medium. 615 Implementors should be aware that when such hysteresis is 616 triggered, Detecting Network Attachment may be slowed, which may 617 affect application traffic. 619 9. IANA Considerations 621 There are no changes to IANA registries required in this document. 623 10. Security Considerations 625 When providing fast responses to router solicitations, it is possible 626 to cause collisions with other signaling packets on contention based 627 media. This can cause repeated packet loss or delay when multiple 628 routers are present on the link. 630 As such the fast router advertisement system is NOT RECOMMENDED in 631 this form for media which are susceptible to collision loss. Such 632 environments may be better served using the procedures defined in 633 [I-D.ietf-dna-protocol]. 635 A host may receive Router Advertisements from non SEND devices, after 636 receiving a link-layer indications. While it is necessary to assess 637 quickly whether a host has moved to another network, it is important 638 that the host's current secured SEND [RFC3971] router information is 639 not replaced by an attacker which spoofs an RA and purports to change 640 the link. 642 As such, the host SHOULD send a Neighbour Solicitation to the 643 existing SEND router upon link-up indication as described above in 644 Section 4.3. The host SHOULD then ensure that unsecured router 645 information does not cause deletion of existing SEND state, within 646 MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to 647 respond. 649 The host MAY delay SEND_NA_GRACE_TIME after transmission before 650 adopting a new default router, if it is operating on a network where 651 there is significant threat of RA spoofing. 653 Even if SEND signatures on RAs are used, it may not be immediately 654 clear if the router is authorized to make such advertisements. As 655 such, a host SHOULD NOT treat such devices as secure until and unless 656 authorization delegation discovery is successful. 658 It is easy for hosts soliciting without SEND to deplete a SEND 659 router's fast advertisement token buckets, and consume additional 660 bandwidth. As such, a router MAY choose to preserve a portion of 661 their token bucket to serve solicitations with SEND signatures. 663 11. Acknowledgments 665 This document is the product of a discussion between the authors had 666 with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at 667 IETF 69. The authors would like to thank them for clearly detailing 668 the requirements of the solution and the goals it needed to meet and 669 for helping to explore the solution space. The authors would like to 670 thank the authors and editors of the complete DNA specification for 671 detailing the overall problem space and solutions. The authors would 672 like to thank Jari Arkko for driving the evolution of a simple and 673 probabilistic DNA solution. The authors would like to thank Bernard 674 Aboba, Thomas Narten, Sathya Narayan, Julien Laganier, Domagoj 675 Premec, Jin Hyeock-Choi, Alfred Hoenes and Frederic Rossi for 676 performing reviews on the document and providing valuable comments to 677 drive the document forward. 679 12. References 681 12.1. Normative References 683 [I-D.ietf-dna-tentative] 684 Daley, G., Nordmark, E., and N. Moore, "Tentative Options 685 for IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 686 (work in progress), July 2007. 688 [I-D.ietf-dna-protocol] 689 Narayanan, S., "Detecting Network Attachment in IPv6 690 Networks (DNAv6)", draft-ietf-dna-protocol (work in 691 progress), June 2007. 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, March 1997. 696 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 697 and M. Carney, "Dynamic Host Configuration Protocol for 698 IPv6 (DHCPv6)", RFC 3315, July 2003. 700 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 701 (DHCP) Service for IPv6", RFC 3736, April 2004. 703 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 704 Neighbor Discovery (SEND)", RFC 3971, March 2005. 706 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 707 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 708 September 2007. 710 12.2. Informative References 712 [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., 713 and A. Yegin, "Link-Layer Event Notifications for 714 Detecting Network Attachments", RFC 4957, August 2007. 716 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 717 Address Autoconfiguration", RFC 4862, September 2007. 719 Authors' Addresses 721 Suresh Krishnan 722 Ericsson 723 8400 Decarie Blvd. 724 Town of Mount Royal, QC 725 Canada 727 Phone: +1 514 345 7900 x42871 728 Email: suresh.krishnan@ericsson.com 730 Greg Daley 731 NetStar Networks 732 Level 9/636 St Kilda Rd 733 Melbourne, Victoria 3004 734 Australia 736 Phone: +61 3 8532 4042 737 Email: gdaley@netstarnetworks.com 739 Full Copyright Statement 741 Copyright (C) The IETF Trust (2008). 743 This document is subject to the rights, licenses and restrictions 744 contained in BCP 78, and except as set forth therein, the authors 745 retain all their rights. 747 This document and the information contained herein are provided on an 748 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 749 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 750 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 751 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 752 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 753 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 755 Intellectual Property 757 The IETF takes no position regarding the validity or scope of any 758 Intellectual Property Rights or other rights that might be claimed to 759 pertain to the implementation or use of the technology described in 760 this document or the extent to which any license under such rights 761 might or might not be available; nor does it represent that it has 762 made any independent effort to identify any such rights. Information 763 on the procedures with respect to rights in RFC documents can be 764 found in BCP 78 and BCP 79. 766 Copies of IPR disclosures made to the IETF Secretariat and any 767 assurances of licenses to be made available, or the result of an 768 attempt made to obtain a general license or permission for the use of 769 such proprietary rights by implementers or users of this 770 specification can be obtained from the IETF on-line IPR repository at 771 http://www.ietf.org/ipr. 773 The IETF invites any interested party to bring to its attention any 774 copyrights, patents or patent applications, or other proprietary 775 rights that may cover technology that may be required to implement 776 this standard. Please address the information to the IETF at 777 ietf-ipr@ietf.org.