idnits 2.17.1 draft-pentland-mobileip-linkid-02.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 576. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 592), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 19, 2004) is 7221 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) == Missing Reference: 'DETFASTRA-00' is mentioned on line 221, but not defined == Unused Reference: 'RFC-2119' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC-2462' is defined on line 440, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. 'FASTRA-04' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRD-00' ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Possible downref: Non-RFC (?) normative reference: ref. 'SEND-05' -- Duplicate reference: RFC3775, mentioned in 'RFC-3756', was also mentioned in 'RFC-3775'. -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'RFC-3756') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA Working Group Brett Pentland 3 INTERNET-DRAFT Greg Daley 4 Expires: January 20, 2005 Monash University CTIE 5 JinHyeock Choi 6 Samsung AIT 7 July 19, 2004 9 Router Advertisement Link Identification 10 for Mobile IPv6 Movement Detection 11 draft-pentland-mobileip-linkid-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 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 January 20, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document defines a mechanism by which Access Routers on a link 45 may automatically assign a consistent identifier to this link to aid 46 in Movement Detection. This assists Movement Detection by allowing a 47 Mobile Node to rapidly determine whether it has moved to a new link 48 upon reception of a Router Advertisement containing this identifier. 50 Table of Contents 52 Abstract...................................................... 2 53 Table of Contents............................................. 2 54 1. Introduction............................................... 2 55 2. Link Identifiers for Movement Detection.................... 3 56 3. Link ID Message Format..................................... 4 57 4. Host Operations............................................ 4 58 4.1. Processing LinkIDs.................................... 4 59 4.2. Interoperation with Existing RAs...................... 5 60 5. Access Router Operations................................... 5 61 5.1. Discovering the Link ID............................... 5 62 5.2. Generating the Link ID................................ 6 63 5.3. Link ID Change Management............................. 6 64 5.3.1. Initiating Change................................ 6 65 5.3.2. Responding to Change............................. 7 66 5.4. Advertising the Link ID............................... 7 67 6. Applicability Statement.................................... 8 68 7. IANA Considerations........................................ 8 69 8. Security Considerations.................................... 8 70 8.1. Hosts................................................. 8 71 8.2. Access Routers........................................ 9 72 Normative References.......................................... 10 73 Informative References........................................ 10 74 Acknowledgements.............................................. 11 75 Authors' Addresses............................................ 11 76 Appendix : Alternative to Random Identifiers.................. 12 78 1. Introduction 80 Movement detection is the task of determining if an IPv6 node has 81 moved to a new network. This detection is important since in the 82 case that the device has moved, addresses it has configured will be 83 invalid and additional configuration must be undertaken to establish 84 or maintain upper layer connectivity. 86 Movement detection is accomplished by determining that the current 87 router is unreachable, checking the validity of configured addresses 88 and finding that a new router is available on the network. Most 89 previous efforts at movement detection have aimed at speeding up 90 discovery of new routers with Router Advertisements(RAs) 91 [FASTRA-04][FRD-00] and discounted the requirement for determining 92 current router reachability[RFC-3775][MDO-01]. 94 In IPv6 multiple routers are allowed on a link, and these routers do 95 not have to advertise overlapping prefixes[RFC-2461]. Therefore, 96 reception of an RA from a new router does not imply movement. For 97 reliable movement detection, nodes can check the reachability of the 98 current router. Determination that the current router is unreachable 99 is typically a slow process[RFC-2461], but provides safeguards which 100 allow nodes to be sure that movement has occurred. 102 Link Identifiers (LinkIDs) are numeric values automatically 103 configured on a link, which are extremely unlikely to conflict with 104 an identifier on an adjacent link. Earlier work by Erik Nordmark 105 described a form of Link Identifier in [HINDSIGHT-00]. This document 106 describes a technique for automatically establishing a consistent 107 Link Identifier for the set of routers on a given link. The Link 108 Identifier is randomly generated by one of the routers on a link and 109 all of the other Link Identifier supporting routers on that link 110 agree to use that identifier. 112 Hosts receiving Router Advertisements (RAs) with LinkID options can 113 use the LinkID value to identify the link that they are attached to. 114 This may aid movement detection by allowing hosts to determine when 115 the link changes. A change to the LinkID implies to the host that 116 currently configured router is unreachable. 118 Terminology 120 Access - A Router that has interfaces on a link which 121 Router Mobile Nodes may communicate with directly. 123 LinkID - An identifier, consistent across the routers on 124 a given link, that can be used by Mobile Nodes as 125 an indication of link changes. 127 2. Link Identifiers for Movement Detection 129 All routers supporting the Link Identifier Option advertise it in 130 each of their Router Advertisements. Advertised Link Identifiers are 131 consistent within any one link. 133 Hosts store the Link Identifier internally, for comparison with 134 subsequently received Router Advertisements. 136 Upon receiving an RA with a LinkID that differs from the host's 137 currently recorded value of LinkID, the host has a strong indication 138 that it has moved to a new network and that its current default 139 router is unreachable. 141 This information may be used to initiate further stateful or 142 stateless autoconfiguration procedures, or appropriate mobility 143 signalling by the host. 145 When a host receives an RA from a previously unseen router, which 146 contains the same LinkID as its default, this means the host is on 147 the same link, but does not guarantee reachability for the current 148 default router. Other mechanisms can be used in order to check 149 bidirectional reachability with the default router, as described in 150 [RFC-3775]. 152 3. Link ID Message Format 154 0 1 2 3 155 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Type | Length | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 159 | LinkID | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Fields: 164 Type TBA (suggest 203) 166 Length 1 168 LinkID 48-bit unsigned integer. Link identifier. 169 Generated randomly. 171 4. Host Operations 173 Link Identifiers assist in the determination of whether 174 advertisements received from different routers are from the same 175 link. This is possible because multiple routers on a link will share 176 the same LinkID. 178 4.1. Processing LinkIDs 180 Hosts monitor the current link's identity using LinkID. They 181 maintain a system variable, CurrentLinkID, that is equal to the value 182 of the most recently received LinkID option. 184 If the received LinkID in an RA differs from the value of 185 CurrentLinkID it is likely that this RA represents movement to a new 186 link. 188 There may be circumstances where it is desirable for a link's LinkID 189 to change so a node that has just detected a changing LinkID should 190 compare the prefix information options (PIO) in the RA to its current 191 list of valid prefixes. If there are no matches, the host should 192 assume that it is on a new link. The host should then mark its 193 current default router as unreachable and commence router discovery. 195 4.2. Interoperation with existing RAs 197 If a host receives an RA with no LinkID and no prefixes that match 198 its current CoA, it cannot use this technique to infer anything about 199 point of network attachment. The host SHOULD proceed to confirm bi- 200 directional reachability or otherwise with its current default 201 router. 203 If a host starts receiving Link Identifiers and the LinkID is not 204 currently set, it MUST set CurrentLinkID to the received value and 205 SHOULD test its current router for reachability to detect movement. 207 5. Access Router Operations 209 When undertaking LinkID advertisement, an Access Router needs to 210 ensure that it is in agreement with other Routers sending the same 211 option. To do this ARs maintain two variables for each interface 212 where LinkID is being used: CurrentLinkID and ProspectiveLinkID. The 213 following sections describe mechanisms to discover, generate and 214 advertise a LinkID. 216 5.1. Discovering the Link ID 218 Upon bringing up an interface, an AR will be unaware of any LinkID in 219 use on the link. In order to determine if a LinkID is in use on a 220 link, it sends out Router-to-Router (RtR) Status Request messages as 221 defined in [DETFASTRA-00]. A LinkID option is placed in the Status 222 Request message and the value of LinkID in that option MUST be set to 223 zero. 225 After an initial random delay of zero to MAX_RTR_STATUS_DELAY 226 milliseconds, the AR sends out MAX_RTR_STATUS_REQS Status Requests 227 separated by RTR_STATUS_REQ_INTERVAL seconds and listens for Status 228 messages in response. If one or more non-zero LinkIDs has been 229 received at RetransTimer milliseconds after the last Status Request, 230 then CurrentLinkID is set to the greatest value received (using 231 modulo 2^48-1 arithmetic). 233 If no non-zero LinkIDs have been received, then the AR should attempt 234 to generate one as described in section 5.2. 236 5.2. Generating the Link ID 238 If, at the end of procedure described in 5.1 no non-zero LinkIDs have 239 been received, the AR should generate a LinkID itself. The AR 240 generates a random 48-bit integer with due care to its randomness 241 [RFC-1750], and assigns it to ProspectiveLinkID. 243 The AR then attempts to propagate this to any other routers on the 244 link. After an initial random delay of zero to MAX_RTR_STATUS_DELAY 245 milliseconds, it transmits MAX_RTR_STATUS_REQS RtR Status messages on 246 the All-Routers multicast address, separated by 247 RTR_STATUS_REQ_INTERVAL seconds. 249 This period of LinkID propagation ends at RetransTimer seconds after 250 the last RtR Status message is sent. If the end is reached without 251 receiving any non-zero LinkIDs that do not match the LinkID being 252 transmitted, CurrentLinkID is set equal to ProspectiveLinkID and is 253 used for transmission in Router Advertisements. 255 If, during the propagation period, a non-zero LinkID is received that 256 does not match the generated value, the two are compared and the 257 greater, using modulo 2^48-1 arithmetic, assigned to 258 ProspectiveLinkID, and is used in future transmissions. If no change 259 takes place, operation continues as before, otherwise counters are 260 reset and the propagation period begins afresh. 262 At the end of the period, CurrentLinkID is set equal to 263 ProspectiveLinkID. 265 5.3. Link ID Change Management 267 During normal operation, there should be no reason to change the 268 LinkID being used on a link, but it should be possible for the LinkID 269 to be changed at an administrator's request. 271 5.3.1. Initiating Change 273 At any time an AR may initiate LinkID change. It does so by first 274 sending out MAX_RTR_STATUS_REQS multicast RAs, separated by 275 MIN_DELAY_BETWEEN_RAS with the old LinkID and at least one valid PIO. 276 The first should be delayed if necessary to respect 277 MIN_DELAY_BETWEEN_RAS from any previous multicast RA. It should also 278 be delayed by a small random interval if LinkID change is being 279 triggered by something that could allow synchronization between 280 multiple routers. Any solicited RAs sent during this time should 281 also use the old LinkID and have at least one valid PIO. 283 During this process, the AR generates a new non-zero LinkID, multiple 284 times if necessary to ensure that it is greater than CurrentLinkID 285 (using modulo 2^48-1 arithmetic) and assigns it to ProspectiveLinkID. 286 It then propagates ProspectiveLinkID to the other routers on the link 287 using the mechanism described in section 5.2. 289 The AR then simply starts using the new LinkID. It should transmit 290 MAX_RTR_STATUS_REQS multicast RAs, separated by MIN_DELAY_BETWEEN_RAS 291 with the new LinkID and with a PIO that matches one sent with the old 292 LinkID. 294 5.3.2. Responding to Change 296 If an AR receives an RtR Status message with a LinkID option that is 297 greater than its value of CurrentLinkID (modulo 2^48-1), it sets 298 ProspectiveLinkID to this new value. 300 The AR should wait MAX_RTR_STATUS_REQS * RTR_STATUS_REQ_INTERVAL 301 seconds for the LinkID propagation period to finish, monitoring RtR 302 Status messages for any changes to the LinkID, updating 303 ProspectiveLinkID as appropriate. At the end of this period the AR 304 should send out MAX_RTR_STATUS_REQS multicast RAs, separated by 305 MIN_DELAY_BETWEEN_RAS with the old LinkID and at least one valid PIO. 307 The AR can then set CurrentLinkID to ProspectiveLinkID and transmit 308 MAX_RTR_STATUS_REQS multicast RAs, separated by MIN_DELAY_BETWEEN_RAS 309 with the LinkID set to CurrentLinkID and with a PIO that matches one 310 sent with the old LinkID. 312 5.4. Advertising the Link ID 314 Advertisement of Link Identifier Options in RAs MUST be configurable 315 on a per-interface basis. 317 When configured to send LinkID options in RAs for a given interface, 318 an AR MUST monitor Router Status messages on that link and be 319 prepared to change its advertised LinkID for that interface as 320 described in section 5.2.1. 322 During the initial period of discovering the LinkID (section 5.1), an 323 AR SHOULD NOT include LinkID options in RAs. This is to avoid 324 excessive changing of the advertised LinkID when machines start up 325 simultaneously after, say, a power failure. 327 Once the LinkID has been determined, an AR SHOULD advertise the 328 LinkID in every RA it sends from an interface where the use of LinkID 329 is enabled. This encourages consistently fast movement detection for 330 mobile nodes arriving on a network. 332 The LinkID advertised is always CurrentLinkID. 334 One side benefit of requiring LinkID options in RAs on supporting 335 Routers, is that using LinkIDs may remove the necessity to advertise 336 PIOs in all unsolicited RAs. Upon receiving a LinkID that indicates a 337 change of link, a host is then able to solicit the router for new 338 addressing information. This may be an important overhead saving in 339 the case that the router is advertising RAs at the highest rates 340 allowed in [RFC-3775]. 342 6. Applicability Statement 344 Advertisement of Link Identifiers is only really applicable to 345 networks where all of the routers on a link can see each other. 346 Environments with routers that are linked to one another by wireless 347 connections that may come and go SHOULD NOT be using this approach. 349 Using LinkIDs to infer unreachability may also be inappropriate for 350 hosts using technologies where it is possible to receive packets at 351 layer three on a single interface from two separate links 352 simultaneously. In such a case the host may incorrectly assume that 353 its previous AR is unreachable each time it receives an RA, resulting 354 in "ping-ponging" behaviour. 356 7. IANA Considerations 358 Allocation by the IANA of an ICMPv6 ND Option Type for the Link 359 Identifier Option is requested. Suggested value: 203. 361 8. Security Considerations 363 8.1. Hosts 365 This document describes a mechanism by which reception of an RA is 366 used by nodes to de-configure the current default router (and 367 associated on-link addresses associated with this router). 368 Additionally, in many environments, movement detection is used as an 369 instigator for configuration signaling. 371 This allows trivial denial-of-service or elicitation of configuration 372 packets by an unauthorized LinkID advertiser, if hosts listen to 373 unverified RAs. Therefore, it is imperative that Router 374 Advertisements are verified using a robust authentication scheme, 375 before nodes take action based on received LinkID 376 information[RFC-3756]. A candidate scheme which may provide such 377 authentication (under development at the time of writing) is SEND 378 (Secure Neighbour Discovery)[SEND-05]. 380 Current proposals would allow a host to verify a router by validation 381 of a chain of trust. This trust chain describes the relationship of 382 the router with an authority on the Internet, with whom the host has 383 some relationship (presumably through its own trust chain). In 384 [SEND-05], this information is elicited through sending the potential 385 router a Delegation Chain Solicitation. 387 The response Delegation Chain Advertisement (DCA) has similar 388 properties to solicited Router Advertisement in [RFC-2461]. In 389 particular, there may be some delay before the advertisement arrives 390 (around 0-500ms, or longer for multicast DCA). Until this 391 advertisement arrives and is processed, it is unsafe to believe that 392 the router is valid, or that the LinkID provided by the RA implies 393 that movement has occurred (and existing addresses or routers are 394 invalid). 396 Therefore, all statements regarding reachability of a router assume 397 that a DCA has been received and verified before a host uses the 398 LinkID for movement confirmation. This may cause significant 399 overhead to movement detection times, even in the case that the 400 initial router advertisement is received quickly. 402 It is worth noting that hosts can be made to consume computation 403 resources in verification of delegation chains, as well as on-link 404 bandwidth through solicitation and acceptance of delegation 405 chains(DCS/DCA). Particularly, if a bogus router advertises a LinkID 406 in a multicast RA, any node which is using LinkIDs for movement 407 detection may solicit for DCA. This may lead to multicast bombing 408 similar to that described in [MDO-01], unless random delays are 409 undertaken before solicitation. Alternatively, such random delays 410 may be unnecessary if additional information, such as a link-layer 411 trigger, is available. 413 8.2. Access Routers 415 The process of establishing a common LinkID is also vulnerable to 416 attack if unverified RtR messages are processed. Upon reception of a 417 LinkID in a Router Status message, the configuring router needs to 418 establish the authority of the router which advertised the 419 identifier. 421 Since the number of routers on a link may be small, it is possible 422 that routers be preconfigured with SAs or shared keys (from which 423 negotiations for SAs may be started) with their peer routers. The 424 aim of this specification was to provide a mechanism which allows 425 LinkID configuration without any such shared state. If there is no 426 a-priori knowledge of peer routers, any router which wishes to verify 427 a Router Status message may do so using the same procedure described 428 for hosts (DCS/DCA). 430 Normative References 432 [RFC-2119] S. Bradner. Key words for use in RFCs to Indicate 433 Requirement Levels. Request for Comments (Best Current Practice) 434 2119 (BCP 14), Internet Engineering Task Force, March 1997 436 [RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for 437 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, 438 Internet Engineering Task Force, December 1998. 440 [RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address 441 Autoconfiguration. Request for Comments (Draft Standard) 2462, 442 Internet Engineering Task Force, December 1998. 444 [FASTRA-04] M. Khalil, J. Kempf, B. Pentland. IPv6 Fast Router 445 Advertisement (FastRA), Internet Draft (work in progress), 446 September 2003. 448 [FRD-00] JinHyeock Choi, DongYun Shin. Fast Router Discovery with RA 449 Caching in AP. Internet Draft (work in progress), Feb 2003. 451 [RFC-3775] D. Johnson, C. Perkins, J. Arkko. Mobility Support in 452 IPv6. Request for Comments (Proposed Standard) 3775, June 2004. 454 [SEND-05] J. Arkko et al. "SEcure Neighbor Discovery (SEND)", 455 Internet draft (work in progress), April 2004. 457 Informative References 459 [RFC-3756] P. Nikander (ed), J. Kempf, E. Nordmark. "IPv6 Neighbor 460 Discovery Trust Models and Threats", Request for Comments 461 (Informational) 3775, May 2004. 463 [MDO-01] G. Daley, JinHyeock Choi. "Movement Detection Optimization 464 in Mobile IPv6", Internet Draft (work in progress), May 2003. 466 [RFC-1750] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness 467 Recommendations for Security", RFC1750 (Informational), Dec 1994 469 [HINDSIGHT-00] E. Nordmark. "MIPv6: from hindsight to foresight?", 470 Expired Internet Draft, Nov 2001, Available at: 471 http://www.watersprings.org/pub/id/draft-nordmark-mobileip- 472 mipv6-hindsight-00.txt 474 Acknowledgements 476 Much of this work is based upon an idea which Erik Nordmark had 477 regarding being able to unambiguously identify a link for MIPv6 478 movement detection [HINDSIGHT-00]. 480 This work has been supported by the Australian Telecommunications CRC 481 and Samsung. 483 Authors' Addresses: 485 Brett Pentland 486 E-mail: brett.pentland@eng.monash.edu.au 487 Phone: +61-3-9905-5245 489 Greg Daley 490 E-mail: greg.daley@eng.monash.edu.au 491 Phone: +61-3-9905-4655 493 Address: 494 Centre for Telecommunications and Information Engineering 495 Department of Electrical and Computer Systems Engineering 496 Monash University 497 Clayton 3800 Victoria 498 Australia 500 JinHyeock Choi 501 E-mail: athene@sait.samsung.co.kr 502 Phone: +82-31-280-9233 504 Address: 505 i-Networking Lab, Samsung AIT (SAIT) 507 Appendix : Alternative to Random Identifiers 509 The purpose of LinkID is to allow a host to quickly determine if an 510 RA it receives is from the same link as its current default router or 511 if it is from a new link, thus requiring the host to perform some 512 configuration tasks. To do this, the LinkID used on a link must be 513 different from the LinkIDs being used on any adjacent networks. This 514 is a far less stringent requirement than being different from every 515 other link in the world. 517 If we have a set of 100 adjacent networks, then using 48-bit random 518 identifiers there is a probability of approximately 2*10^-11 of there 519 being any collisions. Though the Internet is not arranged this way, 520 it is perhaps worth noting that if it were made up of 10,000,000 non- 521 adjacent sets of 100 adjacent networks (ie. we are only concerned 522 with collisions within each 100-network group), then the probability 523 of there being a concerning collision is approximately 2*10-4 524 anywhere in this fictitious network. And even then the problem is 525 handovers that go initially un-noticed, requiring several seconds to 526 be dealt with, and the problem is fixed by an administrator simply 527 telling one of the routers to initiate a LinkID change. 529 If it is considered that this is unacceptable, if may be possible to 530 alter this protocol to use globally unique identifiers. Global 531 address prefixes can only be used on one link at a time and so may be 532 a candidate. Some links may not have global prefixes assigned to 533 them so careful consideration needs to be given to whether local- 534 scope prefixes could be used in certain circumstances. Another 535 alternative may be to use random identifiers on these links. 537 The down side to using address prefixes is that they are generally 64 538 bits long. This means that the LinkID option would not fit into 8 539 bytes, and then next size up is 16 bytes. One of our goals was to 540 keep the size of the identifier down since it is desirable to have it 541 sent in all RAs. On networks supporting mobility, the rate that RAs 542 are sent can be quite high and it would be good to keep the overhead 543 associated with LinkID to a minimum. In fact it was noted in section 544 5.3 that it may be possible to reduce overhead by omitting PIOs 545 altogether in the unsolicited multicast RAs that are used as beacons 546 on such networks. 548 Changes Since Last Revision: 550 Removed concept of ambiguity of LinkID 551 Simplified process of selecting LinkID 552 Added appendix comparing random IDs to globally unique ones 554 Intellectual Property Statement 556 The IETF takes no position regarding the validity or scope of any 557 Intellectual Property Rights or other rights that might be claimed to 558 pertain to the implementation or use of the technology described in 559 this document or the extent to which any license under such rights 560 might or might not be available; nor does it represent that it has 561 made any independent effort to identify any such rights. Information 562 on the procedures with respect to rights in RFC documents can be 563 found in BCP 78 and BCP 79. 565 Copies of IPR disclosures made to the IETF Secretariat and any 566 assurances of licenses to be made available, or the result of an 567 attempt made to obtain a general license or permission for the use of 568 such proprietary rights by implementers or users of this 569 specification can be obtained from the IETF on-line IPR repository at 570 http://www.ietf.org/ipr. 572 The IETF invites any interested party to bring to its attention any 573 copyrights, patents or patent applications, or other proprietary 574 rights that may cover technology that may be required to implement 575 this standard. Please address the information to the IETF at ietf- 576 ipr@ietf.org. 578 Disclaimer of Validity 580 This document and the information contained herein are provided on an 581 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 582 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 583 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 584 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 585 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 586 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Copyright Statement 590 Copyright (C) The Internet Society (2004). This document is subject 591 to the rights, licenses and restrictions contained in BCP 78, and 592 except as set forth therein, the authors retain all their rights. 594 Acknowledgment 596 Funding for the RFC Editor function is currently provided by the 597 Internet Society.