idnits 2.17.1 draft-ietf-dna-simple-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 674. 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 (October 3, 2008) is 5656 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: 'RFCDHCPv6' is mentioned on line 363, but not defined == 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') Summary: 2 errors (**), 0 flaws (~~), 4 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: April 6, 2009 October 3, 2008 8 Simple procedures for Detecting Network Attachment in IPv6 9 draft-ietf-dna-simple-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 6, 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. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.4. Working Assumptions . . . . . . . . . . . . . . . . . . . 4 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 5 57 4.2. Steps involved in detecting link change . . . . . . . . . 6 58 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 6 59 4.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6 60 4.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 7 61 4.6. Further Host Operations . . . . . . . . . . . . . . . . . 8 62 4.7. Recommended retransmission behavior . . . . . . . . . . . 8 63 5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 9 64 6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 10 65 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . . . . 16 76 1. Requirements notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Introduction 84 Hosts require procedures to simply and reliably identify if they have 85 moved to a different IP network to the one which they have been 86 recently connected. In order to detect change, router and neighbour 87 discovery messages are used to collect reachability and configuration 88 information. This information is used to detect whether the existing 89 router and address prefixes are likely to be present. 91 This document incorporates feedback from host and router operating 92 systems implementors, which seeks to make implementation and adoption 93 of IPv6 change detection procedures simple for general use. 95 2.1. Goals 97 The goal of this document is to specify a simple procedure for 98 detecting network attachment (Simple DNA) that has the following 99 characteristics. 101 o Routers do not have to be modified to support this scheme. 103 o Handle only the simplest and most likely use cases. 105 o Work at least as quickly as standard neighbor discovery. 107 o False positives are not acceptable. A host should not conclude 108 that there is no link change when there is one. 110 o False negatives are acceptable. A host can conclude that there is 111 a link change when there is none. 113 2.2. Applicability 115 The Simple DNA protocol is provides substantial benefits in some 116 scenarios and does not provide any benefit at all in certain other 117 scenarios. This is intentional as Simple DNA was designed for 118 simplicity rather than completeness. In particular, the Simple DNA 119 protocol provides maximum benefits when a host moves between a small 120 set of known links. When a host moves to a completely new link that 121 is previously unknown, the performance of the Simple DNA protocol 122 will be identical to that using standard neighbor discovery 123 procedures [RFC4861]. 125 2.3. DNA Roles 127 Detecting Network Attachment is performed by hosts by sending IPv6 128 neighbour discovery and router discovery messages to routers after 129 connecting to a network. 131 It is desirable that routers adopt procedures which allow for fast 132 unicast Router Advertisement (RA) messages. Routers that follow the 133 standard neighbor discovery procedure described in [RFC4861] will 134 delay the router advertisement by a random period between 0 and 135 MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 136 of [RFC4861]. This delay can be significant and may result in 137 service disruption. Please note that support for fast unicast RAs is 138 not necessary since the simple dna procedure can continue to work 139 using the NS/NA exchange, which will complete earlier than the RA 140 arrives. 142 The host detects that the link-layer may have changed, and then 143 simultaneously probes the network with Router Solicitations (RSs) and 144 Neighbour Solicitations (NSs). The host uses advertisements to 145 determine if the routers it currently has configured are still 146 available. 148 2.4. Working Assumptions 150 There are a series of assumptions about the network environment which 151 underpin these procedures. 153 o The combination of the link layer address and the link local IPv6 154 address of a router is unique across links. 156 o Hosts receive indications when a link-layer comes up. Without 157 this, they would not know when to commence the DNA procedure. 159 If these assumptions do not hold, host change detection systems will 160 not function optimally. In that case, they may occasionally detect 161 change spuriously, or experience some delay in detecting network 162 attachment. The delays so experienced will be no longer than those 163 caused by following the standard neighbor discovery procedure 164 described in [RFC4861]. 166 If systems do not meet these assumptions or if systems seek 167 deterministic change detection operations they are directed to follow 168 the complete dna procedure as defined in [I-D.ietf-dna-protocol]. 170 3. Terminology 172 +---------------------+---------------------------------------------+ 173 | Term | Definition | 174 +---------------------+---------------------------------------------+ 175 | Valid IPv6 address | An IPv6 address configured on the node that | 176 | | has a valid lifetime greater than zero. | 177 | | | 178 | Operable IPv6 | An IPv6 address configured on the node that | 179 | address | can be used safely on the current link. | 180 +---------------------+---------------------------------------------+ 182 Table 1: Simple DNA Terminology 184 4. Host Operations 186 When a host has an existing configuration for IP address prefixes and 187 next hop routing, it may be disconnected from its link-layer, and 188 then subsequently reconnect the link-layer on the same interface. 190 When the link-layer becomes available again, it is important to 191 determine whether the existing addressing and routing configuration 192 are still valid. 194 In order to determine this, the host performs the detecting network 195 attachment procedure. 197 4.1. Host data structures 199 In order to correctly perform the procedure described in this 200 document the host needs to maintain a data structure called the 201 Simple DNA address table (SDAT). This data structure is maintained 202 by the host on a per interface basis. Each entry in the SDAT table 203 consists of at least the following parameters. 205 o IPv6 address and its related parameters like valid lifetime. 207 o Prefix from which the address was formed. 209 o Link-local IPv6 address of the router that advertised the prefix. 211 o Link layer (MAC) address of the router that advertised the prefix. 213 o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire 214 the address. 216 4.2. Steps involved in detecting link change 218 The steps involved in basic detection of network attachment are: 220 o Link-Layer Indication 222 o Sending RS and NS probes 224 o Response gathering and assessment 226 These steps are described below. 228 4.3. Link-Layer Indication 230 In order to start Detection of network attachment procedures, a host 231 typically requires a link-layer indication that the medium has become 232 available [RFC4957]. 234 After the indication is received, the host considers all currently 235 configured (non-tentative) IP addresses to as deprecated until the 236 change detection process completes. It SHOULD also set all Neighbor 237 Cache entries for the routers on its Default Router List to STALE. 238 This is done to speed up the acquisition of a new default router when 239 link change has occurred. 241 4.4. Sending RS and NS probes 243 When a host receives a link-layer "up" indication, it SHOULD 244 immediately send both a Router Solicitation and if it retains at 245 least one valid IPv6 address, one or more unicast Neighbor 246 Solicitations. The Router Solicitation is sent to the All-routers 247 multicast address using a link-local address as the source address 248 [RFC4861]. Even if the host is in possession of more than one valid 249 IPv6 address, it MUST send only one router solicitation using a valid 250 link-local address as the source address. 252 For the purpose of sending neighbor solicitations to previous 253 routers, the host first needs to pick a subset of operable IPv6 254 addresses (candidate set) that it wishes to use. How this subset of 255 addresses is picked is based on host configuration. e.g. The host 256 may select configured addresses from each of zero, one or two 257 previously connected links. If the addresses obtained from a 258 previous router are no longer valid, the host does not include these 259 addresses in the candidate set for NS based probing. 261 For each of the addresses in the candidate set, the host looks up the 262 SDAT to find out the link-local and MAC addresses of the router that 263 advertised the prefix used to form the address. It then sends an 264 unicast Neighbor Solicitations to each router's link-local address it 265 obtained from the lookup on the SDAT. The host SHOULD NOT send 266 unicast Neighbor Solicitations to a test node corresponding to an 267 IPv6 address that is no longer valid. 269 Please note that the Neighbour Solicitations SHOULD be sent in 270 parallel with the Router Solicitations. Since sending NSs is just an 271 optimization, doing the NSs and RSs in parallel ensures that the 272 procedure does not run slower than it would if it only used an RS. 274 Be aware that each unicast solicitation which is not successful may 275 cause packet flooding in bridged networks, if the networks are not 276 properly configured. This is further described in Section 8. Where 277 flooding may cause performance issues within the LAN, host SHOULD 278 limit the number of unicast solicitations. 280 4.5. Response Gathering 282 When a responding Neighbour Advertisement is received from a test 283 node, the host MUST verify that both the IPv6 and link layer (MAC) 284 addresses of the test node match the expected values before utilizing 285 the configuration associated with the detected network (prefixes, MTU 286 etc.). 288 On reception of a Router Advertisement which contains prefixes which 289 intersect with those previously advertised by a known router, the 290 host utilizes the configuration associated with the detected network. 292 When the host receives a router advertisement containing only 293 prefixes which are disjoint from known advertised prefixes, the host 294 MUST determine whether the solicited router advertisement corresponds 295 to any of the routers probed via NS. If it does, then the host 296 SHOULD conclude that the IPv6 addresses corresponding to that router 297 are no longer valid. Since any NS probes to that router will no 298 longer provide useful information, further probing of that router 299 SHOULD be aborted. 301 Where the conclusions obtained from the Neighbor Solicitation/ 302 Advertisement from a given router and the RS/RA exchange with the 303 same router differ, the results obtained from the RS/RA will be 304 considered definitive. 306 When the host receives a Router Advertisement in reply to the Router 307 Solicitation it sent, the host SHOULD look for a Neighbor Cache entry 308 for the sending router and SHOULD mark that router's Neighbor Cache 309 Entry as REACHABLE if one was found. The host SHOULD add a new 310 Neighbor Cache Entry in the REACHABLE state for the sending router if 311 one does not currently exist. 313 4.6. Further Host Operations 315 Operations subsequent to detecting network attachment depend upon 316 whether change was detected. 318 After confirming the reachability of the associated router using an 319 NS/NA pair, the host performs the following steps. 321 o The host SHOULD rejoin any solicited nodes' multicast groups for 322 addresses it continues to use. 324 o The host SHOULD select a default router as described in [RFC4861]. 326 If the host has determined that there has been no link change, it 327 SHOULD NOT perform duplicate address detection on the addresses that 328 have been confirmed to be operable. 330 If the NS based probe with a router did not complete or if the RS 331 based probe on the same router completed with different prefixes than 332 the ones in the SDAT the host MUST unconfigure all the existing 333 addresses received from the given router, and MUST begin address 334 configuration techniques, as indicated in the received Router 335 Advertisement [RFC4861][RFC4862]. 337 4.7. Recommended retransmission behavior 339 In situations where Neighbor Solicitation probes and Router 340 Solicitation probes are used on the same link, it is possible that 341 the NS probe will complete successfully, and then the RS probe will 342 complete later with a different result. If this happens, the 343 implementation SHOULD abandon the results obtained from the NS probe 344 of the router that responded to the RS and the implementation SHOULD 345 behave as if the NS probe did not successfully complete. If the 346 confirmed address was assigned manually, the implementation SHOULD 347 NOT unconfigure the manually assigned address and SHOULD log an error 348 about the mismatching prefix. 350 Where the NS probe does not complete successfully, it usually implies 351 that the host is not attached to the network whose configuration is 352 being tested. In such circumstances, there is typically little value 353 in aggressively retransmitting unicast neighbor solicitations that do 354 not elicit a response. 356 Where unicast Neighbor Solicitations and Router Solicitations are 357 sent in parallel, one strategy is to forsake retransmission of 358 Neighbor Solicitations and to allow retransmission only of Router 359 Solicitations or DHCPv6. In order to reduce competition between 360 unicast Neighbor Solicitations and Router Solicitations and DHCPv6 361 retransmissions, a DNAv6 implementation that retransmits may utilize 362 the retransmission strategy described in the DHCPv6 specification 363 [RFCDHCPv6], scheduling DNAv6 retransmissions between Router 364 Solicitation or DHCPv6 retransmissions. 366 If a response is received to any unicast Neighbor Solicitation, 367 Router Solicitation or DHCPv6 message, pending retransmissions MUST 368 be canceled. A Simple DNA implementation SHOULD NOT retransmit a 369 Neighbor Solicitation more than twice. To provide damping in the 370 case of spurious Link Up indications, the host SHOULD NOT perform the 371 Simple DNA procedure more than once a second. 373 5. Router Operations 375 Hosts checking their network attachment are unsure of their address 376 status, and may be using Tentative link-layer addressing information 377 in their router or neighbour solicitations. 379 A router which desires to support hosts' DNA operations MUST process 380 Tentative Options from unicast source addressed Router and Neighbour 381 Solicitations, as described in [I-D.ietf-dna-tentative]. 383 6. Pseudocode for Simple DNA 385 /* Link up indication received on INTERFACE */ 386 /* Start Simple DNA process */ 388 /* Mark All Addresses as deprecated */ 389 Configured_Address_List=Get_Address_List(INTERFACE); 390 foreach Configured_Address in Configured_Address_List 391 { 392 if (Get_Address_State(Configured_Address)!=AS_TENTATIVE) 393 { 394 Set_Address_State(Configured_Address,AS_DEPRECATED); 395 } 396 } 398 /* Mark all routers' NC entries as STALE to speed up */ 399 /* acquisition of new router if link change has occurred */ 400 foreach Router_Address in DEFAULT_ROUTER_LIST 401 { 402 NCEntry=Get_Neighbor_Cache_Entry(Router_Address); 403 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE); 404 } 406 /* Thread A : Send Router Solicitation */ 407 RS_Target_Address=FF02::2; 408 RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 409 Send_Router_Solicitation(RS_Source_Address,RS_Target_Address); 411 /* Thread B : Send Neighbor Solicitation(s) */ 412 Previously_Known_Router_List=Get_Router_List_from_SDAT(); 413 NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); 415 foreach Router_Address in Previously_Known_Router_List 416 { 417 if (Get_Any_Valid_Address_from_SDAT(Router_Address)) 418 { 419 Send_Neighbor_Solicitation(NS_Source_Address,Router_Address); 420 } 421 } 423 /* Thread C : Response collection */ 425 /* Received Router Advertisement processing */ 426 /* Only for RAs received as response to DNA RSs */ 428 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 429 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 430 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 431 foreach SDAT_Entry in SDAT_Entry_List 432 { 433 if (Exists_PIO(RECEIVED_MESSAGE,Get_Prefix(SDAT_Entry))) 434 { 435 /* Address is operable. Configure on Interface */ 436 /* Rejoin solicited-node multicast group for address */ 437 } 438 else 439 { 440 /* If address is configured on interface, remove it */ 441 /* This could be because of a NA arriving before RA */ 442 } 443 } 445 /* Mark router as reachable */ 446 NCEntry=Get_Neighbor_Cache_Entry(L3_Source); 447 if (NCEntry is not NULL) 448 { 449 Set_Neighbor_Cache_Entry_State(NCEntry,NCS_REACHABLE); 450 } 451 else 452 { 453 Create_Neighbor_Cache_Entry(L3_Source,NCS_REACHABLE); 454 } 456 /* Ignore further NAs from this router */ 457 Add_Router_to_NA_Ignore_List(L3_Source); 459 /* Received Neighbor Advertisement processing */ 460 /* Only for NAs received as response to DNA NSs */ 462 L3_Source=Get_L3_Source(RECEIVED_MESSAGE); 463 L2_Source=Get_L2_Source(RECEIVED_MESSAGE); 465 if (Is_Router_on_NA_Ignore_List(L3_Source)) { 466 /* Ignore message and wait for next message */ 467 continue; 468 } 470 SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); 472 foreach SDAT_Entry in SDAT_Entry_List 473 { 474 /* Address is operable. Configure on Interface */ 475 } 477 Figure 1: Pseudocode for Simple DNA 479 7. Constants 481 These constants are described as in [I-D.ietf-dna-protocol]. 483 UNICAST_RA_INTERVAL 485 Definition: The interval corresponding to the maximum average 486 rate of Router Solicitations that the router is prepared to 487 service with unicast responses. This is the interval at which 488 the token bucket controlling the unicast responses is 489 replenished. 491 Value: 50 milliseconds 493 MAX_UNICAST_RA_BURST 495 Definition: The maximum size burst of Router Solicitations that 496 the router is prepared to service with unicast responses. This 497 is the maximum number of tokens allowed in the token bucket 498 controlling the unicast responses. 500 Value: 20 502 SEND_NA_GRACE_TIME 504 Definition: An optional period to wait after Neighbour 505 Solicitation before adopting a non-SEND RA's link change 506 information. 508 Value: 40 milliseconds 510 8. Open Issues 512 This section documents issues that are still outstanding within the 513 document, and the simple DNA solution in general. 515 Rate limitation for solicitations. 517 Hosts MAY implement hysteresis mechanisms to pace solicitations 518 where necessary to prevent damage to a particular medium. 519 Implementors should be aware that when such hysteresis is 520 triggered, Detecting Network Attachment may be slowed, which may 521 affect application traffic. 523 9. IANA Considerations 525 There are no changes to IANA registries required in this document. 527 10. Security Considerations 529 When providing fast responses to router solicitations, it is possible 530 to cause collisions with other signaling packets on contention based 531 media. This can cause repeated packet loss or delay when multiple 532 routers are present on the link. 534 As such the fast router advertisement system is NOT RECOMMENDED in 535 this form for media which are susceptible to collision loss. Such 536 environments may be better served using the procedures defined in 537 [I-D.ietf-dna-protocol]. 539 A host may receive Router Advertisements from non SEND devices, after 540 receiving a link-layer indications. While it is necessary to assess 541 quickly whether a host has moved to another network, it is important 542 that the host's current secured SEND [RFC3971] router information is 543 not replaced by an attacker which spoofs an RA and purports to change 544 the link. 546 As such, the host SHOULD send a Neighbour Solicitation to the 547 existing SEND router upon link-up indication as described above in 548 Section 4.3. The host SHOULD then ensure that unsecured router 549 information does not cause deletion of existing SEND state, within 550 MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to 551 respond. 553 The host MAY delay SEND_NA_GRACE_TIME after transmission before 554 adopting a new default router, if it is operating on a network where 555 there is significant threat of RA spoofing. 557 Even if SEND signatures on RAs are used, it may not be immediately 558 clear if the router is authorized to make such advertisements. As 559 such, a host SHOULD NOT treat such devices as secure until and unless 560 authorization delegation discovery is successful. 562 It is easy for hosts soliciting without SEND to deplete a SEND 563 router's fast advertisement token buckets, and consume additional 564 bandwidth. As such, a router MAY choose to preserve a portion of 565 their token bucket to serve solicitations with SEND signatures. 567 11. Acknowledgments 569 This document is the product of a discussion between the authors had 570 with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at 571 IETF 69. The authors would like to thank them for clearly detailing 572 the requirements of the solution and the goals it needed to meet and 573 for helping to explore the solution space. The authors would like to 574 thank the authors and editors of the complete DNA specification for 575 detailing the overall problem space and solutions. The authors would 576 like to thank Jari Arkko for driving the evolution of a simple and 577 probabilistic DNA solution. The authors would like to thank Bernard 578 Aboba, Thomas Narten, Sathya Narayan, Julien Laganier, Domagoj 579 Premec, Jin Hyeock-Choi, Alfred Hoenes and Frederic Rossi for 580 performing reviews on the document and providing valuable comments to 581 drive the document forward. 583 12. References 585 12.1. Normative References 587 [I-D.ietf-dna-tentative] 588 Daley, G., Nordmark, E., and N. Moore, "Tentative Options 589 for IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 590 (work in progress), July 2007. 592 [I-D.ietf-dna-protocol] 593 Narayanan, S., "Detecting Network Attachment in IPv6 594 Networks (DNAv6)", draft-ietf-dna-protocol (work in 595 progress), June 2007. 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 601 Neighbor Discovery (SEND)", RFC 3971, March 2005. 603 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 604 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 605 September 2007. 607 12.2. Informative References 609 [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., 610 and A. Yegin, "Link-Layer Event Notifications for 611 Detecting Network Attachments", RFC 4957, August 2007. 613 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 614 Address Autoconfiguration", RFC 4862, September 2007. 616 Authors' Addresses 618 Suresh Krishnan 619 Ericsson 620 8400 Decarie Blvd. 621 Town of Mount Royal, QC 622 Canada 624 Phone: +1 514 345 7900 x42871 625 Email: suresh.krishnan@ericsson.com 627 Greg Daley 628 NetStar Networks 629 Level 9/636 St Kilda Rd 630 Melbourne, Victoria 3004 631 Australia 633 Phone: +61 405 494849 634 Email: gdaley@netstarnetworks.com 636 Full Copyright Statement 638 Copyright (C) The IETF Trust (2008). 640 This document is subject to the rights, licenses and restrictions 641 contained in BCP 78, and except as set forth therein, the authors 642 retain all their rights. 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 647 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 648 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 649 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Intellectual Property 654 The IETF takes no position regarding the validity or scope of any 655 Intellectual Property Rights or other rights that might be claimed to 656 pertain to the implementation or use of the technology described in 657 this document or the extent to which any license under such rights 658 might or might not be available; nor does it represent that it has 659 made any independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents can be 661 found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an 665 attempt made to obtain a general license or permission for the use of 666 such proprietary rights by implementers or users of this 667 specification can be obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary 672 rights that may cover technology that may be required to implement 673 this standard. Please address the information to the IETF at 674 ietf-ipr@ietf.org.