idnits 2.17.1 draft-jinchoi-dna-frd-01.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 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 560. ** 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 100: '... it SHOULD delay the transmission fo...' RFC 2119 keyword, line 102: '... router MUST delay a response to a R...' RFC 2119 keyword, line 414: '... 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 (July 18, 2005) is 6857 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 443, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 446, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 457, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 465, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 475, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 490, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 493, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 497, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 501, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 509, 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 draft: draft-ietf-dna-goals (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-01 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '8') (Obsoleted by RFC 6275) == Outdated reference: A later version (-01) exists of draft-pentland-dna-protocol-00 == Outdated reference: A later version (-01) exists of draft-jinchoi-dna-protocol2-00 == Outdated reference: A later version (-02) exists of draft-daley-ipv6-tsllao-01 == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-13 Summary: 8 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA WG JinHyeock Choi 3 Internet-Draft Samsung AIT 4 Expires: January 19, 2006 DongYun Shin 5 Samsung Electronics 6 July 18, 2005 8 Fast Router Discovery with L2 support 9 draft-jinchoi-dna-frd-01.txt 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 January 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 For efficient DNA, a host should quickly receive an RA upon a new 43 link-layer connection. This draft presents a quick RA acquisition 44 scheme with the support of a link-layer entity, PoA (Point of 45 Attachment). Upon a new network attachment, the PoA may either 46 trigger an AR (Access Router) to immediately send an unicast RA, "RA 47 Triggering" or send such an RA for itself, "RA Proxying". We may put 48 "RA Triggering" or "RA Proxying" functionality on a PoA to get the 49 optimized result without IPv6 standard change. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1 RA Triggering . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2 RA Proxying . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. RA Triggering . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5. RA Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.1 RA Caching . . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.1.1 Manual Configuration . . . . . . . . . . . . . . . . . 9 62 5.1.2 Scanning . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1.3 MICS (Media Independent Comment Service) . . . . . . . 9 64 5.2 RA Delivery . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.2.1 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.2.2 802.16 . . . . . . . . . . . . . . . . . . . . . . . . 10 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 14 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 9.1 Normative References . . . . . . . . . . . . . . . . . . . 15 72 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 74 Intellectual Property and Copyright Statements . . . . . . . . 18 76 1. Introduction 78 Upon establishing a new link-layer connection, a host should detect 79 the identity of the currently attached link to ascertain the validity 80 of the existing IP configuration. If the host is attached to a 81 different link, it also needs to acquire the IP configuration for the 82 new link [4]. 84 An RA (Router Advertisement) message is necessary when the host has 85 moved to a different link, so the number of messages needed for DNA 86 can be minimized if the RA also can properly represent the link 87 identity. Moreover to quickly check for link change, the host has to 88 receive the RA without delay. 90 DNA solution should be able to 1) check for link change with a single 91 RA message and 2) get the RA with minimum latency [5]. This draft 92 presents only the second component, quick RA acquisition. But the 93 proposed method can work with any link identify detection scheme 94 based on unsolicited RA, such as linkid prefix in [13] or CompleteRA 95 in [12]. 97 There are several hindrances for sufficiently quick RA acquisition. 98 First, Neighbor Discovery protocol [1] limits routers to a minimum 99 interval of 3 seconds between sending multicast RA messages. Second, 100 it SHOULD delay the transmission for a random amount of time before a 101 host sends an initial RS (Router Solicitation) message. Third, a 102 router MUST delay a response to a Router Solicitation by a random 103 time too. 105 In cellular environments, it may not be cost-effective to broadcast 106 the RA over wireless link. For DNA purpose, it's generally 107 preferable to deliver the RA to the destination in unicast. 109 PoA (Point of Attachment) is the link endpoint of the link, such as 110 802.11 AP (Access Point) or 802.16 BS (Base Station). We propose a 111 scheme which uses the link-layer entity, PoA, in such a way that an 112 RA is delivered to the host in unicast just after L2 connection is 113 made without any random delay. 115 When a host makes a new link-layer connection with a PoA, the PoA 116 detects the new attachment. So at this moment, the PoA may either 117 trigger an AR (Access Router) to immediately send a suitable RA or 118 send such an RA for itself. For the latter case, the PoA needs to 119 cache a suitable RA, such as 'RA optimized for DNA' defined in [5] 121 For example, if AR and PoA are in the same box, whenever a new host 122 is attached, PoA module can deliver Link Up event to AR module so 123 that AR module can immediately fire an RA. Or, if AR and PoA are 124 separated, PoA can cache a suitable RA and deliver it to a new host 125 upon network attachment. 127 In this draft, we design a scheme for a PoA to trigger an RA, "RA 128 Triggering" and another one for a PoA to proxy an RA, "RA Proxying". 129 In RA Proxying, we present a way to cache a necessary RA and send the 130 RA in unicast without any delay. 132 IEEE 802.21 (Media Independent Handover) standard develops a 133 specification [21] that provides link layer intelligence and other 134 related network information to upper layers to optimize handovers 135 between heterogeneous media. 137 Utilizing the services defined in 802.21 MIH (Media Independent 138 Handover) standard, we can put 'RA Triggering' or 'RA Proxying' 139 functionality on a PoA to get the optimized result for quick RA 140 acquisition without IPv6 standard change. 142 2. Terminology 144 Access Router (AR) 146 - An Access Network Router residing on the edge of an Access 147 Network and offers IP connectivity to hosts. 149 Point of Attachment (PoA) 151 - The link endpoint on the link, such as 802.11 Access Point (AP) 152 or 802.16 Base Station (BS), where a host may be connected. 154 Link Up 156 - An event provided by the link layer that signifies a state 157 change associated with the interface becoming capable of 158 communicating data frames. 160 Media Independent Handover Fuction (MIHF) 162 - The MIH Function provides asynchronous and synchronous services 163 through well defined SAPs for lower layers and upper layers. 164 The services provided include the Media Independent Event 165 Service (MIES), the Media Independent Command Service (MICS), 166 and the Media Independent Information Service (MIIS). 168 Media Independent Handover (MIH) Protocol 170 - The Media Independent Handover protocol defines frame formats 171 for exchanging messages between peer MIH Function entities. 172 These messages are based on the primitives which are part of 173 MIES, MICS and MIIS. The MIHF Protocol allows peer MIH 174 Function entities to interact with each other. 176 3. Proposal Overview 178 When a host establishes a link-layer connection, in the process, a 179 link-layer entity, PoA (Point of Attachment), can detect the new 180 attachment and get the necessary information to deliver an unicast L2 181 frame to the host, such as 802.11 MAC address or 802.16 CID 182 (Connection Identifier) [19]. 184 The PoA may forward the information to an AR (Access Router) and 185 trigger the AR to immediately send in unicast a suitable RA, such as 186 'RA optimized for DNA' defined in [5]. 188 Or the PoA itself may cache such an RA beforehand and deliver the 189 cached RA to the host in unicast as soon as the link-layer connection 190 is established. 192 In this draft, we refer the first scheme "RA Triggering" and the 193 second "RA Proxying". 195 3.1 RA Triggering 197 In case PoA and AR are in the same box, when a new host is attached, 198 link-layer (PoA module) can deliver Link UP event notification [7] to 199 IP layer (AR module) to generate a suitable RA and immediately send 200 the RA (in an unicast L2 frame with the host's MAC address). 202 In case PoA and AR are separated, upon a new network attachment, the 203 PoA may deliver the AR the Link Up event notification with the 204 information necessary to deliver an unicast RA. Upon receiving this 205 notification, the AR can send a suitable RA in unicast without delay. 207 There are two ways for such a remote Link Up event notification. We 208 may use the MIES (Media Independent Event Service) defined in IEEE 209 802.21 [21] or RS with TSLLAO (Tentative Source Link-Layer Address 210 Option) [14]. 212 3.2 RA Proxying 214 RA Proxying consists of "RA Caching" and "RA Delivery". RA Caching 215 is to get a suitable RA and store it. RA Delivery is to immediately 216 send the cached RA to a new host in unicast 218 There are several ways to cache the RA in a PoA. We may manually 219 cache the RA in the PoA or use the scanning scheme. AR (Access 220 Router)s periodically multicast a suitable RA, which goes through the 221 PoA. So the PoA may scan incoming L2 frames and cache a necessary 222 RA. The PoA can scan L2 frames either continuously or periodically 223 to update the cached RA. Or PoA and AR may use a special information 224 service, such as the MICS (Media Independent Command Service) defined 225 in IEEE 802.21 [21] in such a way that the AR can forward the PoA the 226 information necessary to generate a suitable RA and permit it to 227 porxy the RA. 229 For RA Delivery, PoA may put the cached RA into an unicast L2 frame 230 with the host's MAC address (or CID for 802.16) and deliver it to the 231 host in unicast immediately after link-layer connection is 232 established. 234 4. RA Triggering 236 In case PoA and AR are in the same box, when a new host is attached, 237 Link Up event notification with the information necessary to deliver 238 an unicast RA, such as the host's MAC address, can be propagated 239 upwards from the link-layer (PoA module) to the IP layer (AR module) 240 within a local stack. Then IP layer (AR module) can immediately send 241 a suitable RA in an unicast L2 frame with the new host's MAC address. 243 In case PoA and AR are separated, we may use 802.21 MIES (Media 244 Independent Event Service) [21] to enable a PoA to trigger a remote 245 AR to fire an immediate RA in unicast. 247 MIES (Media Independent Event Service) refers to the events sent from 248 the lower layers to the higher layers. Events can also be sent from 249 a local MIH entity to a peer MIH entity. Events may carry useful 250 information. For example, Link Up event can carry a new host's MAC 251 address. 253 When a new host is attached to a PoA, the PoA may use Link Up event 254 and MIH Protocol to notify a remote AR the new attachment with the 255 information necessary to deliver an unicast RA, such as the host's 256 MAC address. Then the AR can immediately send a suitable RA in an 257 unicast L2 frame with the new host's MAC address. 259 5. RA Proxying 261 RA Proxying is used only when AR and PoA are separated. If they are 262 in the same box, we recommend to use RA Triggering instead. 264 5.1 RA Caching 266 We present 3 different ways to store a suitable RA in PoA. 268 5.1.1 Manual Configuration 270 In the simplest way, we can manually configure in PoA a suitable RA, 271 such as RA with the linkid prefix in [13] or CompleteRA in [12]. In 272 many cases, AR and PoA are under same administration and usually RA 273 (Router Advertisement) message doesn't change so often. 275 5.1.2 Scanning 277 A PoA may scan incoming L2 frame for a suitable RA and store it. 279 First it scans L2 frame header to see whether it is a multicast 280 frame. If not, the PoA sends that frame down link and scans a next 281 L2 frame. If so, the PoA looks IP header to check whether it 282 contains a suitable RA. If incoming L2 frame doesn't contain a 283 suitable RA, the PoA sends that frame down link and scans a next L2 284 frame. When the PoA finds a suitable RA, it stores it and sends a 285 copy down link. 287 A PoA can scan continuously, updating an old RA with a new RA. Or if 288 it costs too much for the PoA to scan every incoming L2 frame, we can 289 control the scanning rate. For example, we can set timer and execute 290 scanning every T seconds. Or we can make the PoA to be able to send 291 RS (Router Solicitation) message. Periodically the PoA sends an RS 292 and an AR will reply a suitable RA and the PoA caches it. It is 293 noted that the PoA doesn't need to have IP address since it can use 294 unspecified address as its source address. 296 To help RA Caching, we may make it a rule that, whenever an AR 297 changes its RA information, the AR advertises the new information 298 several times, so that PoA can properly update its cached RA. 300 5.1.3 MICS (Media Independent Comment Service) 302 We may use 802.21 MICS (Media Independent Comment Service) and MIH 303 (Media Independent Handover) Protocol [21] to enable an AR to send a 304 suitable RA to a PoA and delegate the PoA to proxy the RA. 306 MICS (Media Independent Comment Service) refers to the commands sent 307 from the higher layers to the lower layers. Commands can also be 308 sent from a local MIH entity to a peer MIH entity. These commands 309 may carry the upper layer information to the lower layers on local 310 device entity or at remote entity, and thus control the behavior of 311 lower layers. For example, a new AR may send its IP address to old 312 PoA with a Remote MIH Command, "MIH Network Address Information". 314 In a similar way, we may define a new Remote MIH Command, "MIH Router 315 Advertisement Information" in 802.21 in such a way that 1) a PoA can 316 use the command and MIP Protocol to request a suitable RA from an AR 317 and permission to proxy the RA and 2) the AR can use the command and 318 MIH Protocol to send a suitable RA to the PoA and delegate the PoA to 319 deliver the RA to a new host upon network attachment 321 5.2 RA Delivery 323 We present a way to immediately deliver an RA in unicast upon network 324 attachement for 802.11 and 802.16 respectively. The procedures 325 describes in here can be extended to apply to other wireless 326 technologies such as 3GPP and 3GPP.2. 328 5.2.1 802.11 330 In 802.11 Wireless LAN technology, when a new host arrives at an 331 AP(Access Point), it should associate with the AP. The host sends an 332 Association Request Message with its MAC address. Then the AP sends 333 an Association Response Message to grant association. 335 As soon as association is made, the AP sends a cached RA to the host 336 in an unicast 802.11 frame with the MAC address from the Association 337 Request message. The host receives the unicast RA just after 338 association is made, which is the earliest possible time in current 339 standard. 341 5.2.2 802.16 343 IEEE 802.16 spec [19] is rather different from Ethernet or 802.11 and 344 it's still unclear how to run IPv6 over 802.16. So we give a rough 345 sketch of RA delivery over 802.16 and mention that further 346 clarification is needed. 348 The 802.16 MAC is connection-oriented. All services, including 349 inherently connectionless services, are mapped to a connection. 351 Connections are referenced with 16-bit connection identifiers (CIDs). 352 Each 802.16 host has a standard 48-bit MAC address, but this serves 353 mainly as an equipment identifier, since the primary addresses used 354 during operation are the CIDs. 356 Upon entering the network, the host is assigned three management 357 connections, the basic connection and the primary management 358 connection and the secondary management connection. 360 The secondary management connection is used for the transfer of 361 standards-based management messages such as Dynamic Host 362 Configuration Protocol (DHCP). It is not decided yet but Neighbor 363 Discovery messages, such as RS, RA, NS (Neighbor Solicitation) and NA 364 (Neighbor Advertisement) may be delivered with this connection. 366 To establish a link layer connection, an 802.16 host performs Ranging 367 to acquire the correct timing offset and power adjustment. The host 368 sends the RNG-REQ message and the 802.16 BS (Base Station) replies 369 RNG-RSP message to provide Basic and Primary Management CIDs for the 370 host. 372 Afterwards the host performs Registration, which is the process by 373 which the host is allowed entry into the network and receives its 374 Secondary Management CID. 376 After Registration is completed, the 802.16 BS may send a cached RA 377 to the host with the Secondary CID. The RA will be delivered in 378 unicast 802.16 frame and the host will receive it with minimum 379 latency. 381 We point out that it's not decided yet that the Secondary CID is used 382 for RA message transfer. It's possible for RA to be delivered with a 383 different CID. 385 6. IANA Considerations 387 No new message formats or services are defined in this document. 389 7. Security Considerations 391 Because DNA is based on Neighbor Discovery, its trust models and 392 threats are similar to the ones presented in RFC 3756 [10]. Nodes 393 connected over wireless interfaces may be particularly susceptible to 394 jamming, monitoring and packet insertion attacks. 396 The threats specific to DNA are that an attacker might fool a node to 397 detect attachment to a different link when it is in fact still 398 attached to the same link, and conversely, the attacker might fool a 399 node to not detect attachment to a new link. 401 In case PoA and AR are in the same box, there is no FRD specific 402 security problem, because all procedures are executed within a local 403 stack. In case PoA and AR are separated, FRD can be performed in 404 secure manner, if there is a secure path between PoA and AR. For 405 example, MIH (Media Independent Handover) services can be made 406 available at L2 through secure port. 408 Even when there is no secure path between PoA and AR, FRD doesn't 409 introduce a new security vulnerability. For the worst case, a host 410 may reject the proxyed RA from PoA but will not make a false 411 decision. Currently any node in a link can cache an RA and 412 retransmit it. Use of [9] to secure Neighbor Discovery are important 413 in achieving reliable detection of network attachment. DNA schemes 414 SHOULD incorporate the solutions developed in IETF SEND WG if 415 available, where assessment indicates such procedures are required. 417 DAN scheme should not result in excessive signaling. A PoA performs 418 FRD procedures to generate an RA message only when a new host is 419 attached to itself. Usually there is an upper bound for the number 420 of hosts (wireless stations) that a PoA can support at a moment. So 421 the number of RA messages from FRD procedure is also limited by this 422 upper bound. 424 8. Acknowledgment 426 We gratefully acknowledge the generous assistance we received from 427 Xiaoyu Liu, YounHee Han and James Kempf for notifying us the 428 usability of 802.21 standard and clarifying the MIH Spec to us. We 429 show our special gratitude to HeeJin Jang, Subba Reddy and Surekha 430 Biruduraju for implementing and testing FRD scheme to provide 431 enlightening insights. The authors wish to express our appreciation 432 to Syam Madanapalli and Wable Ranjitsingh for valuable feedback. 433 Thanks to Greg Daley, Brett Pentland, Nick Moore and YongGeun Hong 434 for their contributions to this draft. 436 9. References 438 9.1 Normative References 440 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 441 for IP Version 6 (IPv6)", RFC 2461, December 1998. 443 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 444 Autoconfiguration", RFC 2462, December 1998. 446 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 447 Addressing Architecture", RFC 3513, April 2003. 449 [4] Choi, J., "Goals of Detecting Network Attachment in IPv6", 450 draft-ietf-dna-goals-04 (work in progress), December 2004. 452 9.2 Informative References 454 [5] Choi, J. and E. Nordmark, "DNA solution framework", 455 draft-ietf-dna-soln-frame-00 (work in progress), April 2005. 457 [6] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix 458 list based approach", draft-ietf-dna-cpl-01 (work in progress), 459 July 2005. 461 [7] Yegin, A., "Link-layer Event Notifications for Detecting 462 Network Attachments", draft-ietf-dna-link-information-01 (work 463 in progress), February 2005. 465 [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 466 IPv6", RFC 3775, June 2004. 468 [9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 469 Nikander, "SEcure Neighbor Discovery (SEND)", 470 draft-ietf-send-ndopt-06 (work in progress), July 2004. 472 [10] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 473 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 475 [11] Pentland, B., "An Overview of Approaches to Detecting Network 476 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 477 progress), February 2005. 479 [12] Narayanan, S., "Detecting Network Attachment in IPv6 Networks 480 (DNAv6)", draft-pentland-dna-protocol-00 (work in progress), 481 May 2005. 483 [13] Choi, J., "DNA Solution: Link Identifier based approach", 484 draft-jinchoi-dna-protocol2-00 (work in progress), May 2005. 486 [14] Daley, G., "Tentative Source Link-Layer Address Options for 487 IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-01 (work in 488 progress), February 2005. 490 [15] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", 491 draft-ietf-dhc-dna-ipv4-13 (work in progress), June 2005. 493 [16] Nordmark, E., "MIPv6: from hindsight to foresight?", 494 draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress), 495 November 2001. 497 [17] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router 498 Advertisement", draft-mkhalil-ipv6-fastra-05 (work in 499 progress), July 2004. 501 [18] Daley, G. and J. Choi, "Movement Detection Optimization in 502 Mobile IPv6", draft-daley-mobileip-movedetect-01 (work in 503 progress), May 2003. 505 [19] IEEE 802.16-2001, "IEEE Standard for Local and Metropolitan 506 Area Networks - Part 16: Air Interface for Fixed Broadband 507 Wireless Access Systems," Apr. 8, 2002. 509 [20] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment 510 for Physical and Medium Access Control Layers for Combined 511 Fixed and Mobile Operation in Licensed Bands", 512 IEEE 802.16e/D8, May 2005. 514 [21] IEEE 802.21 Working Document (Draft Standard), 515 "IEEE P802.21/D00.01: Draft IEEE Standard for Local and 516 Metropolitan Area Networks: Media Independent Handover 517 Services," July, 2005. 519 Authors' Addresses 521 JinHyeock Choi 522 Samsung AIT 523 Communication & N/W Lab 524 P.O.Box 111 Suwon 440-600 525 KOREA 527 Phone: +82 31 280 9233 528 Email: jinchoe@samsung.com 529 DongYun Shin 530 Samsung Electronics 531 Device Solution Group 532 P.O.Box 111 Suwon 440-600 533 KOREA 535 Phone: +82 2 2191 4868 536 Email: yun7521@samsung.com 538 Intellectual Property Statement 540 The IETF takes no position regarding the validity or scope of any 541 Intellectual Property Rights or other rights that might be claimed to 542 pertain to the implementation or use of the technology described in 543 this document or the extent to which any license under such rights 544 might or might not be available; nor does it represent that it has 545 made any independent effort to identify any such rights. Information 546 on the procedures with respect to rights in RFC documents can be 547 found in BCP 78 and BCP 79. 549 Copies of IPR disclosures made to the IETF Secretariat and any 550 assurances of licenses to be made available, or the result of an 551 attempt made to obtain a general license or permission for the use of 552 such proprietary rights by implementers or users of this 553 specification can be obtained from the IETF on-line IPR repository at 554 http://www.ietf.org/ipr. 556 The IETF invites any interested party to bring to its attention any 557 copyrights, patents or patent applications, or other proprietary 558 rights that may cover technology that may be required to implement 559 this standard. Please address the information to the IETF at 560 ietf-ipr@ietf.org. 562 Disclaimer of Validity 564 This document and the information contained herein are provided on an 565 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 566 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 567 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 568 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 569 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 570 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 572 Copyright Statement 574 Copyright (C) The Internet Society (2005). This document is subject 575 to the rights, licenses and restrictions contained in BCP 78, and 576 except as set forth therein, the authors retain all their rights. 578 Acknowledgment 580 Funding for the RFC Editor function is currently provided by the 581 Internet Society.