idnits 2.17.1 draft-ietf-dna-frd-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 601. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 102: '... it SHOULD delay the transmission fo...' RFC 2119 keyword, line 104: '... router MUST delay a response to a R...' RFC 2119 keyword, line 416: '... SHOULD incorporate the solutions de...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 13, 2005) is 6760 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 474, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 477, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 488, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 496, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 506, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 525, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 529, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 533, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 541, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '2') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3513 (ref. '3') (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 4135 (ref. '4') == Outdated reference: A later version (-02) exists of draft-ietf-dna-cpl-01 == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-02 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '8') (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-16 Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA WG JH. Choi 3 Internet-Draft Samsung AIT 4 Expires: April 16, 2006 DongYun. Shin 5 Samsung Electronics 6 W. Haddad 7 Ericsson Research 8 October 13, 2005 10 Fast Router Discovery with L2 support 11 draft-ietf-dna-frd-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 16, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 For efficient DNA, a host should quickly receive an RA (Router 45 Advertisement) upon a new link-layer connection. This draft presents 46 a quick RA acquisition scheme with the support of a link-layer 47 entity, PoA (Point of Attachment). Upon a new network attachment, 48 the PoA may either trigger an AR (Access Router) to immediately send 49 an unicast RA, "RA Triggering" or send such an RA for itself, "RA 50 Proxying". We may put "RA Triggering" or "RA Proxying" functionality 51 on a PoA to get the optimized result without IPv6 standard change. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1 RA Triggering . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2 RA Proxying . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. RA Triggering . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. RA Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 5.1 RA Caching . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1.1 Manual Configuration . . . . . . . . . . . . . . . . . 9 64 5.1.2 Scanning . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1.3 MICS (Media Independent Comment Service) . . . . . . . 9 66 5.2 RA Delivery . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.2.1 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.2.2 802.16 . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 15 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 74 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . 19 78 1. Introduction 80 Upon establishing a new link-layer connection, a host should detect 81 the identity of the currently attached link to ascertain the validity 82 of the existing IP configuration. If the host is attached to a 83 different link, it also needs to acquire the IP configuration for the 84 new link [4]. 86 An RA (Router Advertisement) message is necessary when the host has 87 moved to a different link, so the number of messages needed for DNA 88 can be minimized if the RA also can properly represent the link 89 identity. Moreover to quickly check for link change, the host has to 90 receive the RA without delay. 92 DNA solution should be able to 1) check for link change with a single 93 RA message and 2) get the RA with minimum latency [5]. This draft 94 presents only the second component, quick RA acquisition. But the 95 proposed method can work with any link identify detection scheme 96 based on unsolicited RA, such as linkid prefix in [13] or CompleteRA 97 in [12]. 99 There are several hindrances for sufficiently quick RA acquisition. 100 First, Neighbor Discovery protocol [1] limits routers to a minimum 101 interval of 3 seconds between sending multicast RA messages. Second, 102 it SHOULD delay the transmission for a random amount of time before a 103 host sends an initial RS (Router Solicitation) message. Third, a 104 router MUST delay a response to a Router Solicitation by a random 105 time too. 107 In cellular environments, it may not be cost-effective to broadcast 108 the RA over wireless link. For DNA purpose, it's generally 109 preferable to deliver the RA to the destination in unicast. 111 PoA (Point of Attachment) is the link endpoint of the link, such as 112 802.11 AP (Access Point) or 802.16 BS (Base Station). We propose a 113 scheme which uses the link-layer entity, PoA, in such a way that an 114 RA is delivered to the host in unicast just after L2 connection is 115 made without any random delay. 117 When a host makes a new link-layer connection with a PoA, the PoA 118 detects the new attachment. So at this moment, the PoA may either 119 trigger an AR (Access Router) to immediately send a suitable RA or 120 send such an RA for itself. For the latter case, the PoA needs to 121 cache a suitable RA, such as 'RA optimized for DNA' defined in [5] 123 For example, if AR and PoA are in the same box, whenever a new host 124 is attached, PoA module can deliver Link Up event to AR module so 125 that AR module can immediately fire an RA. Or, if AR and PoA are 126 separated, PoA can cache a suitable RA and deliver it to a new host 127 upon network attachment. 129 In this draft, we design a scheme for a PoA to trigger an RA, "RA 130 Triggering" and another one for a PoA to proxy an RA, "RA Proxying". 131 In RA Proxying, we present a way to cache a necessary RA and send the 132 RA in unicast without any delay. 134 IEEE 802.21 (Media Independent Handover) standard develops a 135 specification [21] that provides link layer intelligence and other 136 related network information to upper layers to optimize handovers 137 between heterogeneous media. 139 Utilizing the services defined in 802.21 MIH (Media Independent 140 Handover) standard, we can put 'RA Triggering' or 'RA Proxying' 141 functionality on a PoA to get the optimized result for quick RA 142 acquisition without IPv6 standard change. 144 2. Terminology 146 Access Router (AR) 148 - An Access Network Router residing on the edge of an Access 149 Network and offers IP connectivity to hosts. 151 Point of Attachment (PoA) 153 - The link endpoint on the link, such as 802.11 Access Point (AP) 154 or 802.16 Base Station (BS), where a host may be connected. 156 Link Up 158 - An event provided by the link layer that signifies a state 159 change associated with the interface becoming capable of 160 communicating data frames. 162 Media Independent Handover Fuction (MIHF) 164 - The MIH Function provides asynchronous and synchronous services 165 through well defined SAPs for lower layers and upper layers. 166 The services provided include the Media Independent Event 167 Service (MIES), the Media Independent Command Service (MICS), 168 and the Media Independent Information Service (MIIS). 170 Media Independent Handover (MIH) Protocol 172 - The Media Independent Handover protocol defines frame formats 173 for exchanging messages between peer MIH Function entities. 174 These messages are based on the primitives which are part of 175 MIES, MICS and MIIS. The MIHF Protocol allows peer MIH 176 Function entities to interact with each other. 178 3. Proposal Overview 180 When a host establishes a link-layer connection, in the process, a 181 link-layer entity, PoA (Point of Attachment), can detect the new 182 attachment and get the necessary information to deliver an unicast L2 183 frame to the host, such as 802.11 MAC address or 802.16 CID 184 (Connection Identifier) [19]. 186 The PoA may forward the information to an AR (Access Router) and 187 trigger the AR to immediately send in unicast a suitable RA, such as 188 'RA optimized for DNA' defined in [5]. 190 Or the PoA itself may cache such an RA beforehand and deliver the 191 cached RA to the host in unicast as soon as the link-layer connection 192 is established. 194 In this draft, we refer the first scheme "RA Triggering" and the 195 second "RA Proxying". 197 3.1 RA Triggering 199 In case PoA and AR are in the same box, when a new host is attached, 200 link-layer (PoA module) can deliver Link UP event notification [7] to 201 IP layer (AR module) to generate a suitable RA and immediately send 202 the RA (in an unicast L2 frame with the host's MAC address). 204 In case PoA and AR are separated, upon a new network attachment, the 205 PoA may deliver the AR the Link Up event notification with the 206 information necessary to deliver an unicast RA. Upon receiving this 207 notification, the AR can send a suitable RA in unicast without delay. 209 There are two ways for such a remote Link Up event notification. We 210 may use the MIES (Media Independent Event Service) defined in IEEE 211 802.21 [21] or RS with TSLLAO (Tentative Source Link-Layer Address 212 Option) [14]. 214 3.2 RA Proxying 216 RA Proxying consists of "RA Caching" and "RA Delivery". RA Caching 217 is to get a suitable RA and store it. RA Delivery is to immediately 218 send the cached RA to a new host in unicast 220 There are several ways to cache the RA in a PoA. We may manually 221 cache the RA in the PoA or use the scanning scheme. AR (Access 222 Router)s periodically multicast a suitable RA, which goes through the 223 PoA. So the PoA may scan incoming L2 frames and cache a necessary 224 RA. The PoA can scan L2 frames either continuously or periodically 225 to update the cached RA. Or PoA and AR may use a special information 226 service, such as the MICS (Media Independent Command Service) defined 227 in IEEE 802.21 [21] in such a way that the AR can forward the PoA the 228 information necessary to generate a suitable RA and permit it to 229 porxy the RA. 231 For RA Delivery, PoA may put the cached RA into an unicast L2 frame 232 with the host's MAC address (or CID for 802.16) and deliver it to the 233 host in unicast immediately after link-layer connection is 234 established. 236 4. RA Triggering 238 In case PoA and AR are in the same box, when a new host is attached, 239 Link Up event notification with the information necessary to deliver 240 an unicast RA, such as the host's MAC address, can be propagated 241 upwards from the link-layer (PoA module) to the IP layer (AR module) 242 within a local stack. Then IP layer (AR module) can immediately send 243 a suitable RA in an unicast L2 frame with the new host's MAC address. 245 In case PoA and AR are separated, we may use 802.21 MIES (Media 246 Independent Event Service) [21] to enable a PoA to trigger a remote 247 AR to fire an immediate RA in unicast. 249 MIES (Media Independent Event Service) refers to the events sent from 250 the lower layers to the higher layers. Events can also be sent from 251 a local MIH entity to a peer MIH entity. Events may carry useful 252 information. For example, Link Up event can carry a new host's MAC 253 address. 255 When a new host is attached to a PoA, the PoA may use Link Up event 256 and MIH Protocol to notify a remote AR the new attachment with the 257 information necessary to deliver an unicast RA, such as the host's 258 MAC address. Then the AR can immediately send a suitable RA in an 259 unicast L2 frame with the new host's MAC address. 261 5. RA Proxying 263 RA Proxying is used only when AR and PoA are separated. If they are 264 in the same box, we recommend to use RA Triggering instead. 266 5.1 RA Caching 268 We present 3 different ways to store a suitable RA in PoA. 270 5.1.1 Manual Configuration 272 In the simplest way, we can manually configure in PoA a suitable RA, 273 such as RA with the linkid prefix in [13] or CompleteRA in [12]. In 274 many cases, AR and PoA are under same administration and usually RA 275 (Router Advertisement) message doesn't change so often. 277 5.1.2 Scanning 279 A PoA may scan incoming L2 frame for a suitable RA and store it. 281 First it scans L2 frame header to see whether it is a multicast 282 frame. If not, the PoA sends that frame down link and scans a next 283 L2 frame. If so, the PoA looks IP header to check whether it 284 contains a suitable RA. If incoming L2 frame doesn't contain a 285 suitable RA, the PoA sends that frame down link and scans a next L2 286 frame. When the PoA finds a suitable RA, it stores it and sends a 287 copy down link. 289 A PoA can scan continuously, updating an old RA with a new RA. Or if 290 it costs too much for the PoA to scan every incoming L2 frame, we can 291 control the scanning rate. For example, we can set timer and execute 292 scanning every T seconds. Or we can make the PoA to be able to send 293 RS (Router Solicitation) message. Periodically the PoA sends an RS 294 and an AR will reply a suitable RA and the PoA caches it. It is 295 noted that the PoA doesn't need to have IP address since it can use 296 unspecified address as its source address. 298 To help RA Caching, we may make it a rule that, whenever an AR 299 changes its RA information, the AR advertises the new information 300 several times, so that PoA can properly update its cached RA. 302 5.1.3 MICS (Media Independent Comment Service) 304 We may use 802.21 MICS (Media Independent Comment Service) and MIH 305 (Media Independent Handover) Protocol [21] to enable an AR to send a 306 suitable RA to a PoA and delegate the PoA to proxy the RA. 308 MICS (Media Independent Comment Service) refers to the commands sent 309 from the higher layers to the lower layers. Commands can also be 310 sent from a local MIH entity to a peer MIH entity. These commands 311 may carry the upper layer information to the lower layers on local 312 device entity or at remote entity, and thus control the behavior of 313 lower layers. For example, a new AR may send its IP address to old 314 PoA with a Remote MIH Command, "MIH Network Address Information". 316 In a similar way, we may define a new Remote MIH Command, "MIH Router 317 Advertisement Information" in 802.21 in such a way that 1) a PoA can 318 use the command and MIP Protocol to request a suitable RA from an AR 319 and permission to proxy the RA and 2) the AR can use the command and 320 MIH Protocol to send a suitable RA to the PoA and delegate the PoA to 321 deliver the RA to a new host upon network attachment 323 5.2 RA Delivery 325 We present a way to immediately deliver an RA in unicast upon network 326 attachement for 802.11 and 802.16 respectively. The procedures 327 describes in here can be extended to apply to other wireless 328 technologies such as 3GPP and 3GPP.2. 330 5.2.1 802.11 332 In 802.11 Wireless LAN technology, when a new host arrives at an 333 AP(Access Point), it should associate with the AP. The host sends an 334 Association Request Message with its MAC address. Then the AP sends 335 an Association Response Message to grant association. 337 As soon as association is made, the AP sends a cached RA to the host 338 in an unicast 802.11 frame with the MAC address from the Association 339 Request message. The host receives the unicast RA just after 340 association is made, which is the earliest possible time in current 341 standard. 343 5.2.2 802.16 345 IEEE 802.16 spec [19] is rather different from Ethernet or 802.11 and 346 it's still unclear how to run IPv6 over 802.16. So we give a rough 347 sketch of RA delivery over 802.16 and mention that further 348 clarification is needed. 350 The 802.16 MAC is connection-oriented. All services, including 351 inherently connectionless services, are mapped to a connection. 353 Connections are referenced with 16-bit connection identifiers (CIDs). 354 Each 802.16 host has a standard 48-bit MAC address, but this serves 355 mainly as an equipment identifier, since the primary addresses used 356 during operation are the CIDs. 358 Upon entering the network, the host is assigned three management 359 connections, the basic connection and the primary management 360 connection and the secondary management connection. 362 The secondary management connection is used for the transfer of 363 standards-based management messages such as Dynamic Host 364 Configuration Protocol (DHCP). It is not decided yet but Neighbor 365 Discovery messages, such as RS, RA, NS (Neighbor Solicitation) and NA 366 (Neighbor Advertisement) may be delivered with this connection. 368 To establish a link layer connection, an 802.16 host performs Ranging 369 to acquire the correct timing offset and power adjustment. The host 370 sends the RNG-REQ message and the 802.16 BS (Base Station) replies 371 RNG-RSP message to provide Basic and Primary Management CIDs for the 372 host. 374 Afterwards the host performs Registration, which is the process by 375 which the host is allowed entry into the network and receives its 376 Secondary Management CID. 378 After Registration is completed, the 802.16 BS may send a cached RA 379 to the host with the Secondary CID. The RA will be delivered in 380 unicast 802.16 frame and the host will receive it with minimum 381 latency. 383 We point out that it's not decided yet that the Secondary CID is used 384 for RA message transfer. It's possible for RA to be delivered with a 385 different CID. 387 6. IANA Considerations 389 No new message formats or services are defined in this document. 391 7. Security Considerations 393 Because DNA is based on Neighbor Discovery, its trust models and 394 threats are similar to the ones presented in RFC 3756 [10]. Nodes 395 connected over wireless interfaces may be particularly susceptible to 396 jamming, monitoring and packet insertion attacks. 398 The threats specific to DNA are that an attacker might fool a node to 399 detect attachment to a different link when it is in fact still 400 attached to the same link, and conversely, the attacker might fool a 401 node to not detect attachment to a new link. 403 In case PoA and AR are in the same box, there is no FRD specific 404 security problem, because all procedures are executed within a local 405 stack. In case PoA and AR are separated, FRD can be performed in 406 secure manner, if there is a secure path between PoA and AR. For 407 example, MIH (Media Independent Handover) services can be made 408 available at L2 through secure port. 410 Even when there is no secure path between PoA and AR, FRD doesn't 411 introduce a new security vulnerability. For the worst case, a host 412 may reject the proxyed RA from PoA but will not make a false 413 decision. Currently any node in a link can cache an RA and 414 retransmit it. Use of [9] to secure Neighbor Discovery are important 415 in achieving reliable detection of network attachment. DNA schemes 416 SHOULD incorporate the solutions developed in IETF SEND WG if 417 available, where assessment indicates such procedures are required. 419 In the presence of SEND, RA Caching may raise security concerns, 420 since the PoA can be considered a man in the middle. Especially it 421 may be difficult for RA Caching with Scanning (Sec 5.1.2) to work 422 with SEND. If a router sends an RA with a SEND Timestamp option, it 423 puts upper bound on how long the RA remains valid after the router 424 advertises it. So if a PoA caches the RA too long, it will become 425 invalid and a host will discard it. 427 We may resolve this issue by including a unique 64 bit number called 428 an Ownership Proof (OP) in an RA. The 64 bit number, OP, is the hash 429 of a nonce and proves to a host that the RA was indeed generated by 430 the router which is listed as the source of the RA. The router must 431 keep a table associating each OP to the nonce which was used to 432 generate it. When an RA carrying an OP option is received, a host 433 may ignore the SEND Timestamp option if it falls outside the 434 allowable window. 436 With OP, DNA procedure is as below. A PoA caches a suitable RA with 437 an OP. When a new host makes an attachment, the PoA immediately 438 sends it the cached RA with an OP. With this cached RA, the host may 439 perform DNA regardless of its SEND Timestamp and at the same time 440 send an RS with the OP option. Upon receiving the RS, the router may 441 send an RA immediately because it is solicited in unicast. When the 442 router responds with a solicited RA it includes the nonce used to 443 generate the OP. Upon receiving the RA, the host may check if the 444 hash of this nonce matches the OP received in the initial cached RA 445 to verify it. If not, the host stops the DNA procedure with the RA 446 and restarts it with a new RA. 448 DAN scheme should not result in excessive signaling. A PoA performs 449 FRD procedures to generate an RA message only when a new host is 450 attached to itself. Usually there is an upper bound for the number 451 of hosts (wireless stations) that a PoA can support at a moment. So 452 the number of RA messages from FRD procedure is also limited by this 453 upper bound. 455 8. Acknowledgment 457 We gratefully acknowledge the generous assistance we received from 458 Xiaoyu Liu, YounHee Han and James Kempf for notifying us the 459 usability of 802.21 standard and clarifying the MIH Spec to us. We 460 show our special gratitude to HeeJin Jang, Subba Reddy and Surekha 461 Biruduraju for implementing and testing FRD scheme to provide 462 enlightening insights. The authors wish to express our appreciation 463 to Syam Madanapalli and Wable Ranjitsingh for valuable feedback. 464 Thanks to Suresh Krishnan, Greg Daley, Brett Pentland, Nick Moore and 465 YongGeun Hong for their contributions to this draft. 467 9. References 469 9.1 Normative References 471 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 472 for IP Version 6 (IPv6)", RFC 2461, December 1998. 474 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 475 Autoconfiguration", RFC 2462, December 1998. 477 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 478 Addressing Architecture", RFC 3513, April 2003. 480 [4] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 481 in IPv6", RFC 4135, August 2005. 483 9.2 Informative References 485 [5] Choi, J. and E. Nordmark, "DNA solution framework", 486 draft-ietf-dna-soln-frame-00 (work in progress), April 2005. 488 [6] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix 489 list based approach", draft-ietf-dna-cpl-01 (work in progress), 490 July 2005. 492 [7] Yegin, A., "Link-layer Event Notifications for Detecting 493 Network Attachments", draft-ietf-dna-link-information-02 (work 494 in progress), July 2005. 496 [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 497 IPv6", RFC 3775, June 2004. 499 [9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 500 Nikander, "SEcure Neighbor Discovery (SEND)", 501 draft-ietf-send-ndopt-06 (work in progress), July 2004. 503 [10] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 504 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 506 [11] Pentland, B., "An Overview of Approaches to Detecting Network 507 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 508 progress), February 2005. 510 [12] Narayanan, S., "Detecting Network Attachment in IPv6 Networks 511 (DNAv6)", draft-pentland-dna-protocol-01 (work in progress), 512 July 2005. 514 [13] Madanapalli, S. and J. Choi, "DNA Solution: Link Identifier 515 based approach", draft-jinchoi-dna-protocol2-01 (work in 516 progress), July 2005. 518 [14] Daley, G., "Tentative Source Link-Layer Address Options for 519 IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-02 (work in 520 progress), July 2005. 522 [15] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", 523 draft-ietf-dhc-dna-ipv4-16 (work in progress), September 2005. 525 [16] Nordmark, E., "MIPv6: from hindsight to foresight?", 526 draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress), 527 November 2001. 529 [17] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router 530 Advertisement", draft-mkhalil-ipv6-fastra-05 (work in 531 progress), July 2004. 533 [18] Daley, G. and J. Choi, "Movement Detection Optimization in 534 Mobile IPv6", draft-daley-mobileip-movedetect-01 (work in 535 progress), May 2003. 537 [19] IEEE 802.16-2001, "IEEE Standard for Local and Metropolitan 538 Area Networks - Part 16: Air Interface for Fixed Broadband 539 Wireless Access Systems," Apr. 8, 2002. 541 [20] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment 542 for Physical and Medium Access Control Layers for Combined 543 Fixed and Mobile Operation in Licensed Bands", 544 IEEE 802.16e/D8, May 2005. 546 [21] IEEE 802.21 Working Document (Draft Standard), 547 "IEEE P802.21/D00.01: Draft IEEE Standard for Local and 548 Metropolitan Area Networks: Media Independent Handover 549 Services," July, 2005 551 Authors' Addresses 553 JinHyeock Choi 554 Samsung AIT 555 Communication Lab 556 P.O.Box 111 Suwon 440-600 557 KOREA 559 Phone: +82 31 280 9233 560 Email: jinchoe@samsung.com 561 DongYun Shin 562 Samsung Electronics 563 Device Solution Group 564 P.O.Box 111 Suwon 440-600 565 KOREA 567 Phone: +82 2 2191 4868 568 Email: yun7521@samsung.com 570 Wassim Haddad 571 Ericsson Research 572 8400 Decarie Blvd. 573 Town of Mount Royal, QC 574 Canada 576 Phone: +1 514 345 7900 #2334 577 Email: Wassim.Haddad@ericsson.com 579 Intellectual Property Statement 581 The IETF takes no position regarding the validity or scope of any 582 Intellectual Property Rights or other rights that might be claimed to 583 pertain to the implementation or use of the technology described in 584 this document or the extent to which any license under such rights 585 might or might not be available; nor does it represent that it has 586 made any independent effort to identify any such rights. Information 587 on the procedures with respect to rights in RFC documents can be 588 found in BCP 78 and BCP 79. 590 Copies of IPR disclosures made to the IETF Secretariat and any 591 assurances of licenses to be made available, or the result of an 592 attempt made to obtain a general license or permission for the use of 593 such proprietary rights by implementers or users of this 594 specification can be obtained from the IETF on-line IPR repository at 595 http://www.ietf.org/ipr. 597 The IETF invites any interested party to bring to its attention any 598 copyrights, patents or patent applications, or other proprietary 599 rights that may cover technology that may be required to implement 600 this standard. Please address the information to the IETF at 601 ietf-ipr@ietf.org. 603 The IETF has been notified of intellectual property rights claimed in 604 regard to some or all of the specification contained in this 605 document. For more information consult the online list of claimed 606 rights. 608 Disclaimer of Validity 610 This document and the information contained herein are provided on an 611 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 612 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 613 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 614 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 615 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 616 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 618 Copyright Statement 620 Copyright (C) The Internet Society (2005). This document is subject 621 to the rights, licenses and restrictions contained in BCP 78, and 622 except as set forth therein, the authors retain all their rights. 624 Acknowledgment 626 Funding for the RFC Editor function is currently provided by the 627 Internet Society.