idnits 2.17.1 draft-ietf-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 668. ** 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 110: '... MUST delay a response to a Router S...' RFC 2119 keyword, line 452: '... 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 (June 21, 2006) is 6512 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: '15' is defined on line 591, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 594, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 598, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 602, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 606, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 610, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 614, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 4135 (ref. '2') == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-00 == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-03 == Outdated reference: A later version (-04) exists of draft-ietf-dna-tentative-00 == Outdated reference: A later version (-03) exists of draft-haddad-mipshop-optisend-01 Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 7 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: December 23, 2006 DongYun. Shin 5 Samsung Electronics 6 W. Haddad 7 Ericsson Research 8 June 21, 2006 10 Fast Router Discovery with L2 support 11 draft-ietf-dna-frd-01.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 December 23, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 For efficient Detecting Network Attachment (DNA), a host should 45 quickly receive a Router Advertisement (RA) message upon a new link- 46 layer connection. This draft presents a quick RA acquisition scheme 47 with the support of a link-layer entity, Point of Attachment (PoA). 48 Upon a new network attachment, the PoA may either trigger an Access 49 Router (AR) to immediately send an unicast RA, "RA Triggering" or 50 send such an RA for itself, "RA Proxying". We may put "RA 51 Triggering" or "RA Proxying" functionality on a PoA to get the 52 optimized result without IPv6 standard change. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. RA Triggering . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. RA Proxying . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. RA Triggering . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. RA Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1. RA Caching . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.1.1. Manual Configuration . . . . . . . . . . . . . . . . . 9 65 5.1.2. Scanning . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.1.3. Media Independent Command Service (MICS) . . . . . . . 9 67 5.2. RA Delivery . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.2.1. 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.2.2. 802.16 . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 Intellectual Property and Copyright Statements . . . . . . . . . . 20 79 1. Introduction 81 Upon establishing a new link-layer connection, a host should check 82 for link change to determine whether its IP configuration is still 83 valid. If the host is attached to a different link, it also needs to 84 acquire the IP configuration for the new link [2]. 86 Detecting Network Attachment (DNA) is the process by which a host 87 collects the appropriate information and detects the identity of its 88 currently attached link to ascertain the validity of its IP 89 configuration. [2]. 91 A Router Advertisement (RA) message is necessary when the host has 92 moved to a different link, so the number of messages needed for DNA 93 can be minimized if the RA also can properly represent the link 94 identity. Moreover to quickly check for link change, the host has to 95 receive the RA without delay. 97 DNA solution should be able to 1) correctly check for link change 98 with a single RA message and 2) quickly get a suitable RA, i.e. the 99 RA, such as 'RA with LinkID' or 'CompleteRA' in [4], which can 100 properly indicate the link identity. This draft presents only the 101 second component, quick RA acquisition. But the proposed method can 102 work with any link identification scheme based on unsolicited RA, 103 such as 'CPL' in [3], 'LinkID prefix' or 'CompleteRA' in [4]. 105 There are several hindrances for sufficiently quick RA acquisition. 106 First, Neighbor Discovery protocol [1] limits routers to a minimum 107 interval of 3 seconds between sending multicast RA messages. Second, 108 a host should delay a random amount of time before initial 109 transmission of a Router Solicitation (RS) message. Third, a router 110 MUST delay a response to a Router Solicitation by a random amount of 111 time too. 113 In cellular environments, it may not be cost-effective to broadcast 114 the RA over wireless link. For DNA purposes, it's generally 115 preferable to deliver the RA to the destination in unicast. 117 Point of Attachment (PoA) is the link endpoint of the link [7], such 118 as 802.11 Access Point (AP) or 802.16 Base Station (BS). We propose 119 a scheme which uses the link-layer entity, PoA, in such a way that an 120 RA is delivered to the host in unicast just after L2 connection is 121 established without any random delay. 123 When a host makes a new link-layer connection with a PoA, the PoA 124 detects the new attachment. So at this moment, the PoA may either 125 trigger an Access Router (AR) to immediately send a suitable RA or 126 send such an RA for itself. For the latter case, the PoA needs to 127 cache a suitable RA. 129 For example, if AR and PoA are in the same box, whenever a new host 130 is attached, the PoA module can deliver Link Up event notification to 131 the AR module so that the AR module can immediately fire an RA. Or, 132 if AR and PoA are separated, PoA can cache a suitable RA and deliver 133 it to a new host upon network attachment. 135 In this draft, we design a scheme for a PoA to trigger an RA, "RA 136 Triggering" and another one for a PoA to proxy an RA, "RA Proxying". 137 In RA Proxying, we present a way to cache a suitable RA and send the 138 RA in unicast without any delay. 140 IEEE 802.21 (Media Independent Handover) standard develops a 141 specification [13] that provides link layer intelligence and other 142 related network information to upper layers to optimize handovers 143 between heterogeneous media. 145 Utilizing the services defined in 802.21 Media Independent Handover 146 (MIH) standard, we can put 'RA Triggering' or 'RA Proxying' 147 functionality on a PoA to get the optimized result for quick RA 148 acquisition without IPv6 standard change. 150 2. Terminology 152 Access Router (AR) 154 - An Access Network Router residing on the edge of an Access 155 Network and offers IP connectivity to hosts. 157 Point of Attachment (PoA) 159 - The link endpoint on the link, such as 802.11 Access Point (AP) 160 or 802.16 Base Station (BS), where a host may be connected. 162 Link Up 164 - An event provided by the link layer that signifies a state 165 change associated with the interface becoming capable of 166 communicating data frames. 168 Media Independent Handover Fuction (MIHF) 170 - The MIH Function provides asynchronous and synchronous services 171 through well defined SAPs for lower layers and upper layers. 172 The services provided include the Media Independent Event 173 Service (MIES), the Media Independent Command Service (MICS), 174 and the Media Independent Information Service (MIIS). 176 Media Independent Handover (MIH) Protocol 178 - The Media Independent Handover protocol defines frame formats 179 for exchanging messages between peer MIH Function entities. 180 These messages are based on the primitives which are part of 181 MIES, MICS and MIIS. The MIHF Protocol allows peer MIH 182 Function entities to interact with each other. 184 3. Proposal Overview 186 When a host establishes a link-layer connection, in the process, a 187 link-layer entity, Point of Attachment (PoA), can detect the new 188 attachment and get the necessary information to deliver an unicast L2 189 frame to the host, such as 802.11 MAC address or 802.16 Connection 190 Identifier (CID) [11]. 192 The PoA may forward the link-layer information to an Access Router 193 (AR) and trigger the AR to immediately send in unicast a suitable RA. 195 Alternatively, the PoA itself may cache such an RA beforehand and 196 deliver the cached RA to the host in unicast as soon as the link- 197 layer connection is established. 199 In this draft, we refer the first scheme "RA Triggering" and the 200 second "RA Proxying". 202 3.1. RA Triggering 204 In case PoA and AR are in the same box, when a new host is attached, 205 the link-layer (PoA module) can deliver Link UP event notification 206 [5] to the IP layer (AR module) to generate a suitable RA and 207 immediately send the RA (in an unicast L2 frame with the host's MAC 208 address). 210 In case PoA and AR are separated, upon a new network attachment, the 211 PoA may deliver the Link Up event notification to the remote AR with 212 the information necessary to deliver an unicast RA. Upon receiving 213 this notification, the AR can send a suitable RA in unicast without 214 delay. 216 There are two ways for such a remote Link Up event notification. We 217 may use the Media Independent Event Service (MIES) defined in IEEE 218 802.21 [13] or RS with Tentative Option [6]. 220 3.2. RA Proxying 222 RA Proxying consists of "RA Caching" and "RA Delivery". RA Caching 223 is to get a suitable RA and store it. RA Delivery is to immediately 224 send the cached RA to a new host in unicast 226 There are several ways to cache the RA in a PoA. An administrator 227 may manually cache the RA in the PoA or use an RA scanning scheme. 228 An Access Router (AR) periodically multicasts a suitable RA, which 229 goes through the PoA. So the PoA may scan incoming L2 frames and 230 cache a suitable RA. The PoA can scan L2 frames either continuously 231 or periodically to update the cached RA. Alternatively, PoA and AR 232 may use a special information service, such as the Media Independent 233 Command Service (MICS) defined in IEEE 802.21 [13] in such a way that 234 the AR can forward the PoA the information necessary to generate a 235 suitable RA and permit it to proxy the RA. 237 For RA Delivery, PoA may put the cached RA into an unicast L2 frame 238 with the host's MAC address (or CID for 802.16) and deliver it to the 239 host in unicast immediately after link-layer connection is 240 established. 242 4. RA Triggering 244 In case PoA and AR are in the same box, when a new host is attached, 245 Link Up event notification with the information necessary to deliver 246 an unicast RA, such as the host's MAC address, can be propagated 247 upwards from the link-layer (PoA module) to the IP layer (AR module) 248 within a local stack. Then the IP layer (AR module) can immediately 249 send a suitable RA in an unicast L2 frame with the new host's MAC 250 address. 252 In case PoA and AR are separated, we may use 802.21 Media Independent 253 Event Service (MIES) [13] to enable a PoA to trigger a remote AR to 254 fire an immediate RA in unicast. 256 Media Independent Event Service (MIES) refers to the events sent from 257 the lower layers to the higher layers. Events can also be sent from 258 a local MIH entity to a peer MIH entity. Events may carry useful 259 information. For example, Link Up event can carry a new host's MAC 260 address. 262 When a new host is attached to a PoA, the PoA may use Link Up event 263 and MIH Protocol to notify a remote AR the new attachment with the 264 information necessary to deliver an unicast RA, such as the host's 265 MAC address. Then the AR can immediately send a suitable RA in an 266 unicast L2 frame with the new host's MAC address. 268 In some specific cases, an AR can be informed of a new attachment of 269 a host even without PoA notification. 271 For example, in WiMAX network [14], while establishing a new link- 272 layer connection, a host performs authentication procedure and 273 notifies its presence to an AR. So even without explicit 274 notification from PoA, the AR can perceive that a new host is 275 attached and send a suitable RA upon completing registration. 277 5. RA Proxying 279 RA Proxying is used only when AR and PoA are separated. If they are 280 in the same box, we recommend to use RA Triggering instead. 282 5.1. RA Caching 284 We present 3 different ways to store a suitable RA in a PoA. 286 5.1.1. Manual Configuration 288 In the simplest way, an administrator can manually configure in PoA a 289 suitable RA, such as an RA with the LinkID prefix or a CompleteRA 290 defined in [4]. In many cases, AR and PoA are under the same 291 administration and usually Router Advertisement (RA) message doesn't 292 change so often. 294 5.1.2. Scanning 296 A PoA may scan incoming L2 frames for a suitable RA and store it. 298 First it scans L2 frame header to see whether it is a multicast 299 frame. If not, the PoA sends that frame down link and scans the next 300 L2 frame. If so, the PoA looks IP header to check whether it 301 contains a suitable RA. If an incoming L2 frame doesn't contain a 302 suitable RA, the PoA sends that frame down link and scans a next L2 303 frame. When the PoA finds a suitable RA, it stores it and sends a 304 copy down link. 306 A PoA can scan continuously, updating an old RA with a new RA. 307 Alternatively, if it costs too much for the PoA to scan every 308 incoming L2 frame, we can control the scanning rate. For example, we 309 can set timer and execute scanning every T seconds. Or we can make 310 the PoA to be able to send a Router Solicitation (RS) message. 311 Periodically the PoA sends an RS and an AR will reply a suitable RA 312 and the PoA caches it. It is noted that the PoA doesn't need to have 313 IP address because it can use unspecified address as its source 314 address. 316 To help RA Caching, we may make a recommendation that, whenever an AR 317 changes its RA information, the AR advertises the new information 318 several times, so that a PoA can properly update its cached RA. 320 5.1.3. Media Independent Command Service (MICS) 322 We may use 802.21 Media Independent Command Service (MICS) and Media 323 Independent Handover (MIH) Protocol [13] to enable an AR to send a 324 suitable RA to a PoA and delegate the PoA to proxy the RA. 326 Media Independent Command Service (MICS) refers to the commands sent 327 from the higher layers to the lower layers. Commands can also be 328 sent from a local MIH entity to a peer MIH entity. These commands 329 may carry the upper layer information to the lower layers on local 330 device entity or remote entity, and thus control the behavior of 331 lower layers. For example, a new AR may send its IP address to old 332 PoA with a Remote MIH Command, "MIH Network Address Information". 334 In a similar way, it is possible to define a new Remote MIH Command, 335 "MIH Router Advertisement Information" in 802.21 in such a way that 336 1) a PoA can use the command and MIP Protocol to request a suitable 337 RA from an AR and permission to proxy the RA and 2) the AR can use 338 the command and MIH Protocol to send a suitable RA to the PoA and 339 delegate the PoA to deliver the RA to a new host upon network 340 attachment. Further work is needed because this entails a change in 341 802.21 standard. 343 5.2. RA Delivery 345 We present a way to immediately deliver an RA in unicast upon network 346 attachement for 802.11 and 802.16 respectively. The procedures 347 described in here can be extended to apply to other wireless 348 technologies such as 3GPP and 3GPP.2. 350 5.2.1. 802.11 352 In 802.11 Wireless LAN technology, when a new host arrives at an 353 AP(Access Point), it should associate with the AP. The host sends an 354 Association Request Message with its MAC address. Then the AP sends 355 an Association Response Message to grant association. 357 As soon as association is made, the AP sends a cached RA to the host 358 in an unicast 802.11 frame with the MAC address from the Association 359 Request message. The host receives the unicast RA just after 360 association is made, which is the earliest possible time in current 361 standard. 363 5.2.2. 802.16 365 IEEE 802.16 spec [11], [12] is rather different from Ethernet or 366 802.11 and work is still on-going about how to run IPv6 over 802.16. 367 So we give a rough sketch of RA delivery over 802.16 and mention that 368 further work is needed. 370 The 802.16 MAC is connection-oriented. All services, including 371 inherently connectionless services, are mapped to a connection. 373 Connections are referenced with 16-bit Connection Identifiers (CIDs). 375 Each 802.16 host has a standard 48-bit MAC address, but this serves 376 mainly as an equipment identifier and a 802.16 frame carries only a 377 CID. 379 Upon entering the network, the host is assigned three management 380 connections, the basic connection and the primary management 381 connection and the secondary management connection. 383 The secondary management connection is used for the transfer of 384 standards-based management messages such as Dynamic Host 385 Configuration Protocol (DHCP). It is not decided yet but Neighbor 386 Discovery messages, such as RS, RA, NS (Neighbor Solicitation) and NA 387 (Neighbor Advertisement) may be delivered with this connection. If 388 that's not allowed, a separate transport connection, such as Initial 389 Service Flow (ISF) defined in WiMAX forum [14], can be created for 390 Neighbor Discovery messages. 392 To establish a link layer connection, an 802.16 host performs Ranging 393 to acquire the correct timing offset and power adjustment. The host 394 sends the RNG-REQ message and the 802.16 Base Station (BS) replies 395 RNG-RSP message to provide Basic and Primary Management CIDs for the 396 host. 398 Afterwards the host performs Registration, which is the process by 399 which the host is allowed entry into the network and receives its 400 Secondary Management CID. 402 After Registration is completed, the 802.16 BS may send a cached RA 403 to the host with the Secondary CID. The RA will be delivered in 404 unicast 802.16 frame and the host will receive it with minimum 405 latency. 407 We point out that it's not clear yet whether the Secondary CID can be 408 used for the RA message transfer. In case Secondary CID can't be 409 used, the BS can create a transport connection such as ISF with an 410 associate CID. Afterwards the BS can send a cached RA in unicast 411 802.16 frame with the transport CID. 413 6. IANA Considerations 415 No new message formats or services are defined in this document. 417 7. Security Considerations 419 Because DNA is based on Neighbor Discovery, its trust models and 420 threats are similar to the ones presented in RFC 3756 [9]. Nodes 421 connected over wireless interfaces may be particularly susceptible to 422 jamming, monitoring and packet insertion attacks. 424 Note that a DNA scheme should not result in excessive signaling. An 425 attacker can make a bogus association with an PoA to trigger an 426 additional RA. This may result in amplification attack and consumes 427 wireless bandwidth. However a PoA performs FRD procedure to generate 428 an RA message only when a new host is attached to itself. Usually 429 there is an upper bound for the number of hosts (wireless stations) 430 that a PoA can support at a moment. So the number of RA messages 431 from FRD procedure is also limited by this upper bound. 433 The threats specific to DNA are that an attacker might fool a node to 434 detect attachment to a different link when it is in fact still 435 attached to the same link, and conversely, the attacker might fool a 436 node to not detect attachment to a new link. 438 In case PoA and AR are in the same box, FRD doesn't bring forth any 439 additional DNA specific security problem, because all procedures are 440 executed within a local stack. In case PoA and AR are separated, FRD 441 can be performed in secure manner only if there is a secure path 442 between PoA and AR. For example, Media Independent Handover (MIH) 443 services can be made available at L2 through secure port. 445 The lack of secure path between the PoA and AR does not introduce any 446 additional security attack when using FRD. Currently any node in a 447 link can cache an RA and retransmit it to mislead a host to false 448 decision. But an attacker may poison a PoA's cache with a bogus RA 449 to save itself from having to advertise the false information for 450 itself. Use of [8] to secure Neighbor Discovery are important in 451 achieving reliable detection of network attachment. DNA schemes 452 SHOULD incorporate the solutions developed in IETF SEND WG if 453 available, where assessment indicates such procedures are required. 455 In the presence of SEND, RA Caching may raise security concerns, 456 since the PoA can be considered a man in the middle. Especially, it 457 may be difficult for RA Caching with Scanning (Sec 5.1.2) to work 458 with SEND. If a router sends an RA with a SEND Timestamp option, it 459 puts upper bound on how long the RA remains valid after the router 460 advertises it. So if a PoA caches the RA too long, it will become 461 invalid and a host will discard it. However take notice that even in 462 this case, the host will not make a false DNA decision. 464 We may resolve this issue by including a unique 64 bit number called 465 an Ownership Proof (OP) in an RA. The 64 bit number, OP, is the hash 466 of a nonce and proves to a host that the RA was indeed generated by 467 the router which is listed as the source of the RA. The router must 468 keep a table associating each OP to the nonce, which was used to 469 generate it. When an RA carrying an OP option is received, a host 470 may ignore the SEND Timestamp option if it falls outside the 471 allowable window. 473 With OP, DNA procedure is as below. A PoA caches a suitable RA 474 message with an OP. When a new host makes an attachment, the PoA 475 sends it immediately the cached RA message with an OP. With this 476 cached RA message, the host may perform DNA regardless of its SEND 477 Timestamp and at the same time send an RS message with the OP option. 478 Upon receiving the RS message, the access router may send an RA 479 message immediately because it is solicited in unicast. When the AR 480 responds with a solicited RA it includes the nonce used to generate 481 the OP. Upon receiving the RA message, the host may check if the 482 hash of this nonce matches the OP received in the initial cached RA 483 to verify it. If not, the host stops the DNA procedure with the RA 484 and restarts it with a new RA. 486 In addition to the OP procedure, a sort of combination of the RA 487 triggering and proxying mechanisms may be used, in order to provide a 488 secure FRD procedure without requiring any involvement from the host 489 side. Furthermore, the PoA would better avoid scanning each L2 490 frame, and consequently, limit the need to refresh its cache memory 491 with a new RA message as much as possible. These requirements are 492 fullfilled by having the AR generating one different one way hash 493 chain (OWHC) [10] for each PoA. In this case, each PoA needs to 494 store at the beginning one RA message, i.e., the one which carries 495 the tip of the corresponding OWHC. After that, each time the PoA 496 forwards the cached RA message to the MN, it sends an RS message, 497 which includes the MN's MAC address in Tentative Option [6] and the 498 OWHC value to the AR. At this point, the PoA should start scanning 499 incoming L2 frame from the AR for a short period of time to capture 500 the AR reply. Upon receiving the RS message from the PoA, the AR 501 should send back immediately an RA message in unicast (by using the 502 MN's MAC address), which discloses the correct value from the 503 corresponding OWHC. The AR should also send another multicast RA 504 message (with the same disclosed value from its OWHC) to be cached by 505 the PoA for future use. In such scenario, the PoA should stop 506 scanning L2 frames immediately after receiving a multicast RA 507 message. 509 The combination of RA triggering and proxying described above allows 510 the PoA to keep the RA message, which carries the last disclosed 511 value of the corresponding OWHC. It also allows the MN to perform 512 DNA with the cached RA message, autoconfigure, if needed, a new IPv6 513 address and quickly pursue its ongoing session(s). In fact, the RA 514 triggering and proxying combination allows the MN to get a fresh RA 515 message from the AR and validate the cached RA message almost in 516 parallel with the attachment procedure. At the same time, the 517 suggested procedure eliminates the need for the PoA to refresh its 518 cache memory except when a cached RA message is sent to a MN. 520 8. Acknowledgment 522 We gratefully acknowledge the generous assistance we received from 523 Xiaoyu Liu, YounHee Han and James Kempf for notifying us the 524 usability of 802.21 standard and clarifying the MIH Spec to us. We 525 show our special gratitude to HeeJin Jang, Subba Reddy and Surekha 526 Biruduraju for implementing and testing FRD scheme to provide 527 enlightening insights. The authors wish to express our appreciation 528 to Syam Madanapalli and Wable Ranjitsingh for valuable feedback. 529 Thanks to Suresh Krishnan, Greg Daley, Brett Pentland, Nick Moore and 530 YongGeun Hong for their contributions to this draft. 532 9. References 534 9.1. Normative References 536 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 537 for IP Version 6 (IPv6)", RFC 2461, December 1998. 539 [2] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 540 in IPv6", RFC 4135, August 2005. 542 9.2. Informative References 544 [3] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix 545 list based approach", draft-ietf-dna-cpl-02 (work in progress), 546 January 2006. 548 [4] Kempf, J., "Detecting Network Attachment in IPv6 Networks 549 (DNAv6)", draft-ietf-dna-protocol-00 (work in progress), 550 February 2006. 552 [5] Yegin, A., "Link-layer Event Notifications for Detecting 553 Network Attachments", draft-ietf-dna-link-information-03 (work 554 in progress), October 2005. 556 [6] Daley, G., "Tentative Options for Link-Layer Addresses in IPv6 557 Neighbour Discovery", draft-ietf-dna-tentative-00 (work in 558 progress), February 2006. 560 [7] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network 561 Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 563 [8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 564 Neighbor Discovery (SEND)", RFC 3971, March 2005. 566 [9] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 567 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 569 [10] Haddad, W., "Secure Neighbor Discovery (SEND) Optimization and 570 Adaptation for Mobility: The OptiSEND Protocol", 571 draft-haddad-mipshop-optisend-01 (work in progress), 572 March 2006. 574 [11] IEEE Std 802.16-2004, "IEEE Standard for Local and 575 metropolitan area networks, Part 16: Air Interface for 576 Fixed Broadband Wireless Access Systems", October 2004. 578 [12] IEEE802.16e-2005, "IEEE Standard for Local and metropolitan 579 area networks, Amendment for Physical and Medium Access 580 Control Layers for Combined Fixed and Mobile Operation in 581 Licensed Bands", 2005. 583 [13] IEEE 802.21 Working Document (Draft Standard), 584 "IEEE P802.21/D01.00: Draft IEEE Standard for Local and 585 Metropolitan Area Networks: Media Independent Handover 586 Services," July, 2005 588 [14] WiMAX Forum Network Working Group (NWG), 589 http://www.wimaxforum.org 591 [15] Choi, J. and E. Nordmark, "DNA solution framework", 592 draft-ietf-dna-soln-frame-00 (work in progress), April 2005. 594 [16] Pentland, B., "An Overview of Approaches to Detecting Network 595 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 596 progress), February 2005. 598 [17] Narayanan, S., "Detecting Network Attachment in IPv6 Networks 599 (DNAv6)", draft-pentland-dna-protocol-01 (work in progress), 600 July 2005. 602 [18] Madanapalli, S. and J. Choi, "DNA Solution: Link Identifier 603 based approach", draft-jinchoi-dna-protocol2-01 (work in 604 progress), July 2005. 606 [19] Nordmark, E., "MIPv6: from hindsight to foresight?", 607 draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress), 608 November 2001. 610 [20] Daley, G. and J. Choi, "Movement Detection Optimization in 611 Mobile IPv6", draft-daley-mobileip-movedetect-01 (work in 612 progress), May 2003. 614 [21] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router 615 Advertisement", draft-mkhalil-ipv6-fastra-05 (work in 616 progress), July 2004. 618 Authors' Addresses 620 JinHyeock Choi 621 Samsung AIT 622 Networking Technology Lab 623 P.O.Box 111 Suwon 440-600 624 KOREA 626 Phone: +82 31 280 9233 627 Email: jinchoe@samsung.com 629 DongYun Shin 630 Samsung Electronics 631 Device Solution Group 632 P.O.Box 111 Suwon 440-600 633 KOREA 635 Phone: +82 2 2191 4868 636 Email: yun7521@samsung.com 638 Wassim Haddad 639 Ericsson Research 640 Torshamnsgatan 23 641 SE-164 80 Stockholm 642 Sweden 644 Email: Wassim.Haddad@ericsson.com 646 Intellectual Property Statement 648 The IETF takes no position regarding the validity or scope of any 649 Intellectual Property Rights or other rights that might be claimed to 650 pertain to the implementation or use of the technology described in 651 this document or the extent to which any license under such rights 652 might or might not be available; nor does it represent that it has 653 made any independent effort to identify any such rights. Information 654 on the procedures with respect to rights in RFC documents can be 655 found in BCP 78 and BCP 79. 657 Copies of IPR disclosures made to the IETF Secretariat and any 658 assurances of licenses to be made available, or the result of an 659 attempt made to obtain a general license or permission for the use of 660 such proprietary rights by implementers or users of this 661 specification can be obtained from the IETF on-line IPR repository at 662 http://www.ietf.org/ipr. 664 The IETF invites any interested party to bring to its attention any 665 copyrights, patents or patent applications, or other proprietary 666 rights that may cover technology that may be required to implement 667 this standard. Please address the information to the IETF at 668 ietf-ipr@ietf.org. 670 Disclaimer of Validity 672 This document and the information contained herein are provided on an 673 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 674 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 675 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 676 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 677 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 678 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 680 Copyright Statement 682 Copyright (C) The Internet Society (2006). This document is subject 683 to the rights, licenses and restrictions contained in BCP 78, and 684 except as set forth therein, the authors retain all their rights. 686 Acknowledgment 688 Funding for the RFC Editor function is currently provided by the 689 Internet Society.