idnits 2.17.1 draft-ietf-dna-cpl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1115. ** 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 647: '...ndidate. Thus it MUST NOT perform the...' RFC 2119 keyword, line 781: '... schemes SHOULD incorporate the solu...' 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 (April 21, 2005) is 6944 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) -- Looks like a reference, but probably isn't: 'N' on line 898 == Unused Reference: '3' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1058, 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') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-01 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: October 23, 2005 Erik Nordmark 5 SUN Microsystems 6 April 21, 2005 8 DNA with unmodified routers: Prefix list based approach 9 draft-ietf-dna-cpl-00.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 October 23, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Upon establishing a new link-layer connection, a host determines 43 whether a link change has occurred, that is, whether or not it has 44 moved at layer 3 and therefor needs new IP configuration. This draft 45 presents a way to robustly check for link change without assuming any 46 changes to the routers. We choose to uniquely identify each link by 47 the set of prefixes assigned to it. We propose that, at each 48 attached link, the host generates the complete prefix list, that is, 49 a prefix list containing all the valid prefixes on the link, and when 50 it receives a hint that indicates a possible link change, it detects 51 the identity of the currently attached link by consulting the 52 existing prefix list. This memo describes how to generate the 53 complete prefix list and to robustly detect the link identity even in 54 the presence of packet loss. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Prefix list based approach . . . . . . . . . . . . . . . . . 4 60 2.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. DNA based on the complete prefix list . . . . . . . . . . . 7 64 3.1 Complete prefix list generation . . . . . . . . . . . . . 7 65 3.2 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 8 66 3.3 Link identity detection . . . . . . . . . . . . . . . . . 9 67 3.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 10 68 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 12 69 4.1 Conceptual data structures . . . . . . . . . . . . . . . . 12 70 4.2 Merging Candidate Link objects . . . . . . . . . . . . . . 13 71 4.3 Timer handling and Garbage Collection . . . . . . . . . . 13 72 4.4 Receiving link UP notifications . . . . . . . . . . . . . 14 73 4.5 Receiving valid Router Advertisements . . . . . . . . . . 14 74 4.6 Changing the link in Neighbor Discovery . . . . . . . . . 16 75 5. CPL without a 'link UP' notification . . . . . . . . . . . . 17 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 77 7. Security Considerations . . . . . . . . . . . . . . . . . . 20 78 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 8.1 Example with link UP event notification . . . . . . . . . 21 80 8.2 Example without link UP event notification . . . . . . . . 21 81 9. Performance Analysis . . . . . . . . . . . . . . . . . . . . 23 82 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 26 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 12.1 Normative References . . . . . . . . . . . . . . . . . . 27 86 12.2 Informative References . . . . . . . . . . . . . . . . . 27 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 88 Intellectual Property and Copyright Statements . . . . . . . 29 90 1. Introduction 92 When a host establishes a new link-layer connection, it may or may 93 not have a valid IP configuration, such as the subnet prefixes or the 94 default router addresses, for the link. Though the host has changed 95 its network attachment point (at layer 2), it may still be at the 96 same link (at layer 3). The term 'link' used in this document is as 97 defined in RFC 2461 [1], which is a layer 3 definition. NOTE that 98 that definition is completely different than the definition of the 99 term 'link' in IEEE 802 standards. 101 Thus the host needs to check for a link change, i.e. it needs to 102 verify whether it is attached to the same or a different link as 103 before [4]. The host can keep current IP configuration if and only 104 if it remains at the same link. 106 A host receives the link information from RA (Router Advertisement) 107 messages. However, as described in 2.2. [4], it's difficult for a 108 host to correctly detect the identity of a link with a single RA. 109 None of the information in an RA can indicate a link change properly. 110 Neither router address nor prefixes will do. 112 It may be better to design a new way to represent the identity of a 113 link, and/or add new pieces of information to RA or RS (Router 114 Solicitation) messages. Several new approaches to properly indicate 115 link change have been considered by the design team - see [10]. 117 However, even if some such new scheme is standardized and 118 implemented, hosts would still need to cope with routers which do not 119 (yet) implement such a scheme. Thus it makes sense to write down the 120 rules for how to robustly detect the link identity without assuming 121 any changes to the routers, which is the purpose of this document. 123 2. Prefix list based approach 125 2.1 Approach 127 Currently there is one thing which can represent the identify of a 128 link, 130 'The set of all the valid and global prefixes assigned to a link.' 132 If a host has the complete list of all the assigned prefixes, it can 133 properly determine whether a link change has occurred. If the host 134 receives an RA containing one or more prefixes and none of the 135 prefixes in it matches the previously known prefixes for the link, 136 then it is assumed to be a new link. 138 This works because each and every valid global prefix on a link must 139 not be used on any other link thus the sets of global prefixes on 140 different links must be disjoint. 142 This is the case even as there is renumbering. During graceful 143 renumbering a prefix would gradually have its (preferred and valid) 144 lifetimes decrement, until the valid lifetime reaches zero. Some 145 point after the valid lifetime has reached zero, the prefix may be 146 reassigned to some different link. Even during 'flash' renumbering, 147 when the prefix isn't allowed to gracefully move through the 148 deprecated state [2], independently of DNA, the prefix needs to be 149 advertised with a zero valid lifetime on the old link before it can 150 be reassigned. Thus we can assume that a prefix with a non-zero 151 valid lifetime can at most be assigned to one link at any given time. 153 For the purposes of determining the prefixes, this specification uses 154 both 'on-link' and 'addrconf' prefixes [1], that is, prefixes that 155 have either the 'on-link' flag set, the 'autonomous address- 156 autoconfiguration' flag set, or both flags set. This is a safe 157 approach since both the set of valid on-link and the set of valid 158 addrconf prefixes must be uniquely assigned to one link. 160 While the approach is conceptually simple, the difficulty lies both 161 in ensuring that the host knows the complete prefix list for a single 162 link, and preventing prefixes from possibly different links to be 163 viewed as the prefixes for a single link. This is challenging for 164 several reasons: A single RA is not required to include all prefixes 165 for the link, RAs might be subject to packet loss, new routers and 166 new prefixes (due to renumbering) might appear at any time on a link, 167 and the host might move to a different link at any time. 169 If the prefix list determination is incorrect, there can be two 170 different types of failures. One is detecting a new link when in 171 fact the host remains attached to the same link. The other is 172 failing to detect when the host attaches to a different link. The 173 former failure is undesirable because it might trigger other 174 protocols, such as Mobile IPv6 [5], to do unneeded signaling, thus it 175 is important to minimize this type of failure. The latter type of 176 failure can lead to long outages when the host is not able to 177 communicate at all, thus these failures must be prevented. 179 2.2 Assumptions 181 In this approach, we assume that an interface of a host can not be 182 attached to multiple links at the same time. Though this kind of 183 multiple attachments is allowed in neither Ethernet nor 802.11b, it 184 may be possible in some Cellular System, especially CDMA. 186 This assumption implies that, should the host use a layer 2 187 technology which can be multiply connected, this needs to be 188 represented to the DNA (and layer 3 on the host in general), as 189 separate (virtual) interfaces, so that the DNA module can associate 190 each received RA message with a particular (virtual) interface. 192 We also assume that when a host changes its attachment point, the DNA 193 module will be notified of the event using some form of 'link UP' 194 event notification, and that the DNA module determine which RAs 195 arrived before the event and which arrived after the event. This 196 assumption places some requirements on the host implementation, but 197 does not place any assumptions on the layer 2 protocol. 199 It is possible to have CPL operate in less robust fashion when the 200 implementation does not provide such a 'link UP' event notification. 201 We mention this possibility in Section 5. 203 2.3 Overview 205 Hints are used to tell a host that a link change might have happened. 206 This hint itself doesn't confirm a link change, but can be used to 207 initiate the appropriate procedures [4]. 209 In order to never view two different links as one it is critical that 210 when the host might have attached to a link, there has to be some 211 form of hint. This hint doesn't imply that a movement to a different 212 link has occurred, but instead, in the absence of such a hint there 213 could not have been an attachment to a different link. 215 If the IP stack is notified by the link layer when a new attachment 216 is established (e.g., when associating to a different access point in 217 802.11), this will serve as such a hint. It helps to reduce the risk 218 that the assignment of an additional prefix to a link will be 219 misinterpreted as being attached to a different link. Note that this 220 hint is merely a local notification and does not require any protocol 221 changes. For instance, in many implementations this would be a 222 notification passed from a link-layer device driver to the IP layer. 224 Once a hint is received the host will start to collect a new set of 225 valid prefixes for the possibly different link, and compare them with 226 the valid prefixes known from before the hint. If there is one or 227 more common prefixes it is safe to assume that the host is attached 228 to the same link, in which case the prefixes learned after the hint 229 can be merged with the prefixes learned before the hint. But if the 230 sets of valid prefixes are disjoint, then at some point in time the 231 host will decide that it is attached to a different link. 233 The process of collecting valid prefixes starts when the host is 234 powered on and first attaches to a link. 236 Since each RA message isn't guaranteed to contain all valid prefixes 237 it is a challenge for a host to attain and retain the complete prefix 238 list, especially when packets can be lost on the link. 240 The host has to rely on approximate knowledge of the prefix list 241 using RS/ RA exchanges. Just as specified in [1], when the host 242 attaches to a potentially new link, it sends an RS message to All- 243 Router multicast address, then waits for the solicited RAs. If there 244 was no packet loss, the host would receive the RAs from all the 245 routers on the link in a few seconds thereby knowing all the valid 246 prefixes on the link. Taking into account packet loss, the host may 247 need to perform RS/ RA exchanges multiple times to corroborate the 248 result. 250 When a hint indicating a possible link change happens, if the host is 251 reasonably sure that its prefix list is complete, it can determine 252 whether it is attached to the same link on the reception of just one 253 RA containing one or more valid prefixes. 255 Otherwise, to make matters certain, the host may need at least to 256 wait for more than the first RAs, or additionally, perform multiple 257 RS/ RA exchanges after the hint. The first level of trying harder is 258 to, after the RS transmission, wait for all RAs that would have been 259 triggered by the RS. The second level of trying harder is to send 260 multiple RSs (and waiting for the resulting RAs). 262 All tracking of the prefix lists must take the valid lifetime of the 263 prefixes into account. The prefix list is maintained separately per 264 network interface. 266 3. DNA based on the complete prefix list 268 We choose to identify a link by the set of valid prefixes that are 269 assigned to the link, and we denote this 'the complete prefix list'. 270 Each link has its unique complete prefix list. We also say that the 271 prefix list is complete if all the prefixes on the link belong to it. 273 In case that a host has the complete prefix list, it can properly 274 determine whether it is attached to the same link or not, when it 275 receives a single RA message after a hint that a link change might 276 have occurred. 278 This section presents a procedure to generate the complete prefix 279 list and a way to detect the link identity based on the existing 280 prefix list even in the presence of packet losses. 282 3.1 Complete prefix list generation 284 To efficiently check for link change, a host always maintains the 285 list of all known prefixes on the link. This procedure of attaining 286 and retaining the complete prefix list is initialized when the host 287 is powered on. 289 The host forms the prefix list at any attachment point, that is, this 290 process starts independently of any movement. Though the procedure 291 may take some time, that doesn't matter unless the host moves very 292 fast. A host can generate the complete prefix list with reasonable 293 certainty if it remains attached to a link sufficiently long. It 294 will take approximately 12 seconds, when it actively perform 3 RS/ RA 295 exchanges. If it passively relies on unsolicited RA messages 296 instead, it may take much more time. 298 First the host sends an RS to All-Router multicast address. Assuming 299 there is no packet loss, every router on the link would receive the 300 RS and usually reply with an RA containing all the prefixes that the 301 router advertises. However, RFC 2461 mandates certain delays for the 302 RA transmissions. 304 After an RS transmission, the host waits for all RAs that would have 305 been triggered by the RS. There is an upper limit on the delay of 306 the RAs. MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec) 307 + network propagation delay is the maximum delay between an RS and 308 the resulting RAs [1]. 4 seconds would be a safe number for the host 309 to wait for the resulting RAs. Assuming no packet loss, within 4 310 seconds, the host would receive all the RAs and know all the 311 prefixes. 313 In case of packet loss, things get more complicated. In the above 314 process, there may be a packet loss that results in the generation of 315 the incomplete prefix list, i.e. the prefix list that misses some 316 prefix on the link. To remedy this deficiency, the host may perform 317 multiple RS/ RA exchanges to collect all the assigned prefixes. 319 After one RS/ RA exchange, to corroborate the completeness of the 320 prefix list, the host may send additional RSs and wait for the 321 resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS 322 [1]. The host takes the union of the prefixes from all the RAs to 323 generate the prefix list. The more RS/ RA exchange the host 324 performs, the more probable that the resulting prefix list is 325 complete. Section 9 gives the detailed analysis. 327 To ascertain whether its existing prefix list is complete or not, the 328 host can set its own policy. The host may take into consideration 329 the packet loss rate of the link and the number of RAs it received or 330 should have received from each router while it was attached to the 331 link. Per [1] each router should multicast a RA at least every 1800 332 seconds. Furthermore, [5] defines a Advertisement Interval option, 333 which the host can use to determine how often it should receive RAs. 335 For example, the host may keep track of how RAs it has received from 336 each router on this attachment point, and if this is 3 or more it 337 assumes that the resulting prefix list is complete. But if this is 338 only 1 or 2, the host doesn't assume the completeness of the prefix 339 list. 341 In general, the higher the error rate, the longer time and more RA 342 transmissions from the routers are needed to assure the completeness 343 of the prefix list. 345 3.2 Erroneous Prefix Lists 347 The host may generate either 1) the incomplete prefix list, i.e. the 348 prefix list does not include all the prefixes that are assigned to 349 the link or 2) the superfluous prefix list, i.e. the prefix list that 350 contains some prefix that is not assigned to the link. 352 It is noted that 1) and 2) is not exclusive. The host may generate 353 the prefix list that excludes some prefix on the link but includes 354 the prefix not assigned to the link. 356 Severe packet losses during prefix list generation may cause the 357 incomplete prefix list. Or the host may have undergone a link change 358 before finishing the procedure of the complete prefix list 359 generation. Later we will deal with the case that the host can't be 360 sure of the completeness of the prefix list. 362 Even if the host falsely assumes that the incomplete prefix list is 363 complete, the effect of that assumption is that the host might later 364 think it has moved to a different link when in fact it has not. 366 In case that a link change happens, even if the host has the 367 incomplete prefix list, it will detect a link change. Hence the 368 incomplete prefix list doesn't cause a connection disruption. But it 369 may cause extra signaling messages, for example Binding Update 370 messages in [5]. 372 The superfluous prefix list presents a more serious problem. 374 Without the assumed 'link UP' event notification from the link-layer, 375 the host can't perceive that it has changed its attachment point, 376 i.e. it has torn down an old link-layer connection and established a 377 new one. We further discuss the issues, should this assumption be 378 removed, in Section 5. 380 With the assumed 'link UP' notification, and the assumption of 381 different concurrent layer 2 connections being represented as 382 different (virtual) interfaces to the DNA module (see Section 2.2) 383 the host will never treat RAs from different links as being part of 384 the same link. Hence it can not create a superfluous prefix list. 386 3.3 Link identity detection 388 When a host receives a hint that indicates a possible link change, it 389 initiates DNA procedure to determine whether it still remains at the 390 same link or not. At this time, the complete prefix generation may 391 or may not be finished. 393 First, if the host has finished the complete prefix list generation 394 and can be reasonably sure of its completeness, the receipt of a 395 single RA (with at least one valid prefix) is enough to detect the 396 identify of the currently attached link. 398 Assume that, after the hint, the host receives an RA that contains at 399 least one valid prefix. The host compares the valid prefixes in the 400 RA with those in the existing prefix list. If the RA contains a 401 prefix that is also a member of the existing prefix list, the host is 402 still at the same link. Otherwise, if none of the prefixes in that 403 RA matches the previously known prefixes, it is at a different link. 405 If the host is not sure that the prefix list was complete before the 406 hint reception, then the host needs to take several RAs into account 407 after the hint reception, before it can determine that it has moved 408 to a different link. 410 Suppose that before finishing the prefix list generation, the host 411 receives the hint that indicates a possible link change. Then the 412 host can't assume the completeness of the prefix list. 414 The host can then generate another (complete) prefix list for the 415 (potentially new) link, which compensates for the uncertainty of the 416 old prefix list. After the hint, it performs one or more RS/ RA 417 exchanges additionally to collect all the prefixes on the currently 418 attached link. With the resulting prefixes, the host generates the 419 second prefix list. 421 Then the host compares two prefix lists and if the lists are 422 disjoint, i.e. have no prefix in common, it assumes that a link 423 change has occurred. Note that if during this procedure, the host 424 finds a common valid prefix between even one RA and the old prefix 425 list, it can immediately determine that it has not moved to a 426 different link. 428 For example, assume that the host keeps track of how many RAs it has 429 received from each router while attached to a link. If this is 3 or 430 more, the host assumes that it has seen all the prefixes. Suppose 431 that the host has received only one RA from each router, and then it 432 receives a link UP notification that causes it to initiate the DNA 433 procedure. If the first RA does not have a valid prefix which is 434 common with the old prefixes, then the host needs to wait for 435 additional RAs, and perhaps also send additional RSs and wait for the 436 resulting RAs. In case that the lists are disjoint, the host can 437 assume it has moved. 439 In summary, first a host makes the complete prefix list. When a hint 440 occurs, if the host decides that the prefix list is complete, it will 441 check for link change with just one RA (with a prefix). Otherwise, 442 in case that the host can't be so sure, it will perform additional 443 RS/ RA exchanges to corroborate the decision. 445 3.4 Renumbering 447 When the host is sure that the prefix list is complete, a false 448 movement assumption may happen due to renumbering when a new prefix 449 is introduced in RAs at about the same time as the host handles the 450 'link UP' event. We may solve the renumbering problem with minor 451 modification like below. 453 When a router starts advertising a new prefix, for the time being, 454 every time the router advertises a new prefix in an RA, it includes 455 at least one old prefix in the same RA. The old prefix assures that 456 the host doesn't falsely assume a link change because of a new 457 prefix. After a while, hosts will recognize the new prefix as the 458 one assigned to the current link and update its prefix list. 460 In this way, we may provide a fast and robust solution. If a host 461 can make the complete prefix list with certainty, it can check for 462 link change fast. Otherwise, it can fall back on a slow but robust 463 scheme. It is up to the host to decide which scheme to use. 465 4. Protocol Specification 467 This section provides the actual specification for a host 468 implementing this draft. For generality the specification assumes 469 that the host retains multiple (an unbounded set) of prefix lists 470 until the information times out, while an actual implementation would 471 limit the number of sets maintained. 473 This description assumes that the link layer driver provides a 'link 474 UP' notification when the host might have moved to a different link. 476 4.1 Conceptual data structures 478 This section describes a conceptual model of one possible data 479 structure organization that hosts will maintain for the purposes of 480 DNA. The described organization is provided to facilitate the 481 explanation of how this protocol should behave. This document does 482 not mandate that implementations adhere to this model as long as 483 their external behavior is consistent with that described in this 484 document. 486 The basic conceptual data type for the protocol is the Candidate Link 487 object. This is an object which contains all the information learned 488 from RA messages that are known to belong to a single link. These 489 data structures are maintained separately for each interface. In 490 particular, this includes 492 o The valid prefixes learned from the prefix information options, 493 the A/L bits and their valid and preferred lifetimes. 495 o The default routers and their lifetimes. 497 o Any other option content such as the MTU etc. 499 The lifetimes for the prefixes and default routers in the Candidate 500 Link objects should decrement in real time that is, at any point in 501 time they will be the remaining lifetime. An implementation could 502 handle that by recording the 'expire' time for the information, or by 503 periodically decrementing the remaining lifetime. 505 For each interface, the host maintains a notion of its Current 506 Candidate Link (CCL) object. As we will see below, this might 507 actually be different than the prefix list and default router lists 508 maintained by Neighbor Discovery when the host is in the process of 509 determining whether it has attached to a different link or not. 511 In addition, the host maintains previous Candidate Link objects. It 512 is per interface since there are some security issues when merging 513 across interfaces. 515 The previous Candidate Link objects can be found by knowing at least 516 one prefix that is part of the object. 518 The operations on Candidate Link objects is to create a new one, 519 discard one, and merge two of them together. The issues with merging 520 are discussed in the next section. 522 For each interface, the host maintains the last time a valid RA was 523 received (called time_last_RA_received in this document), which 524 actually ignores RAs without prefix options, and the last time a link 525 UP notification was received from the link layer on the host (called 526 time_last_linkUP_received in this document). Together these two 527 conceptual variables serve to identify when a RA containing disjoint 528 prefixes can't be due to being attached to a new link, because there 529 was no link UP notification. 531 4.2 Merging Candidate Link objects 533 When a host has been collecting information about a potentially 534 different link in its Current Candidate Link object, and it discovers 535 that it is in fact the same link as another Candidate Link object, 536 then it needs to merge the information in the two objects to produce 537 a single new object. Since the CCL contains the most recent 538 information, any information contained in it will override the 539 information in the old Candidate Link, for example the remaining 540 lifetimes for the prefixes. When the two objects contain different 541 pieces of information, for instance different prefixes or default 542 routers, the union of these are used in the resulting merged object. 544 4.3 Timer handling and Garbage Collection 546 As stated above, the lifetimes for the prefixes and default routers 547 in each Candidate Link object must be decremented in real time. When 548 a prefix' valid lifetime has expired, the prefix should be removed 549 from its object. Likewise, when a default router lifetime has 550 expired, it should be removed from its object. When a Candidate Link 551 object contains neither any prefixes nor any default routers, the 552 object, including additional information such as MTU, should be 553 discarded. 555 There is nothing to prevent a host from garbage collecting Candidate 556 Link objects before their expire. However, for performance reason a 557 host must be able to retain at least two of them at any given time. 559 It is recommended to put 90 minute upper limit on how long the 560 objects, other than the CCL, should be retained, to make the protocol 561 more robust against flash renumbering and reassignment. 563 4.4 Receiving link UP notifications 565 When the host receives a link UP notification from its link layer, it 566 sets time_last_linkUP_received to the current time. 568 The host also uses this to trigger sending an RS, subject to the rate 569 limitations in [1]. Since there is no natural limit on how 570 frequently the link UP notifications might be generated, we take the 571 conservative approach that even if the host establishes new link 572 layer connectivity very often, under no circumstances should it send 573 Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL. 574 Thus if it handled the most recent link UP notification less than 4 575 seconds ago, it can not immediately send one when it processes a link 576 UP notification. 578 If the RS does not result in the host receiving at least one RA with 579 at least one valid prefix, then the host can retransmit the RS. It 580 is allowed to multicast up to MAX_RTR_SOLICITATIONS [1] RS messages 581 spaced RTR_SOLICITATION_INTERVAL apart. 583 4.5 Receiving valid Router Advertisements 585 When a host receives a valid RA message (after the validity checks 586 specified in [1]) it performs the following processing in addition to 587 the processing specified in [1] and [2] 589 If the valid RA does not contain any prefix information options, or 590 all the prefixes have a zero valid lifetime, then no further 591 processing is performed. Note that not even the 592 time_last_RA_received is updated. 594 If time_last_RA_received is more recent than 595 time_last_linkUP_received, then the host could not possibly have 596 moved to a different link. Hence the only action needed for DNA is 597 to update the current Candidate Link object with the information in 598 the RA, and set time_last_RA_received to the current time. No 599 further processing is performed. 601 Otherwise, that is if a linkUP indication has been received more 602 recently than time_last_RA_received, we have the case when the host 603 needs to perform comparisons of the prefix sets in its Candidate Link 604 objects and the prefix set in the RA. In this case, 605 time_last_RA_received is always set to the current time. 607 Should the received RA contain at least one valid prefix which is in 608 the prefix list in the CCL, then the host is still attached to the 609 same link, and just needs to update the CCL with any new information 610 in the RA. 612 Otherwise, if the received RA contains one or more prefixes which is 613 part of the prefix list in some retained Candidate Link object, then 614 the host has most likely moved back to that link. In this case the 615 host will retain the content of the CCL for future matching, but 616 switch the CCL to be that matching object. The, now new, CCL should 617 be updated based on the information in the RA. Then the DNA module 618 informs the Neighbor Discovery module to replace the old information 619 with the information in the new CCL as specified in Section 4.6. 621 It is possible that the above comparison will result in matching 622 multiple Candidate Link objects. For example, if the RA contains the 623 prefixes P1 and P2, and there is one Candidate Link object with P1 624 and P3 and other Candidate Link object with P2 and P4. This should 625 not happen during normal operation, but if links have been renumbered 626 or physically separate links have been made into one link (before the 627 lifetimes in the Candidate Link objects expired), then the host could 628 observe this. The most sensible action would be for the host to 629 merge all such matching Candidate Link objects together with the 630 information in the receive RA and make this the new CCL. Doing this 631 merging correctly probably requires that each Candidate Link object 632 contains the time it was last updated by a RA, so that more recent 633 information can override older information. Note that this case is 634 one reason one needs to be concerned about security issues when 635 Candidate Link objects are shared across multiple interfaces. 637 The easy cases of staying on the same link or moving to a previously 638 visited link have been handled above. The harder case is when the 639 first RA after a link UP notification contains prefixes that are new 640 to the host. In this case it isn't obvious whether the host has 641 moved or not, because a new prefix could have been added to the 642 existing link instead of being associated with a different link. In 643 order to distinguish those to cases the host needs to do some extra 644 work. The host handles this by creating a new Candidate Link object 645 which it initializes with the information in the received RA, and 646 makes this object the CCL. However, it does not yet treat this as a 647 new link; it is merely a candidate. Thus it MUST NOT perform the 648 actions in Section 4.6. 650 Then the host waits for more RA messages. At a minimum it waits for 651 4 seconds, that is, it starts a timer and RAs that are received 652 during that time interval are processed as specified above. This 653 processing might result in finding a prefix in common between a 654 Candidate Link object and the CCL, in which case the host knows 655 whether and to which link it has moved. But should the 4 seconds 656 expire without any common prefix, then it will conclude that it has 657 moved to a new link and inform the rest of the host of the movement 658 (Section 4.6.) Note that the arrival of a new link UP notification 659 during the 4 second timer must prevent the timer from firing. In 660 this case the host might yet again have moved so it is necessary to 661 restart the process of inspecting the RAs. 663 Subject to local policy, and perhaps also the host's knowledge of the 664 packet loss characteristics of the interface or type of L2 665 technology, the host can try harder than just waiting for 4 seconds. 666 It is allowed to multicast up to MAX_RTR_SOLICITATIONS [1] RS 667 messages spaced RTR_SOLICITATION_INTERVAL apart. In the most 668 conservative approach this means a 12 second delay until the host 669 will declare that is has moved to a new link. Just as above, this 670 process should be terminated should a new link UP notification arrive 671 during the 12 seconds. 673 4.6 Changing the link in Neighbor Discovery 675 When DNA detects that it has moved to a different link this needs to 676 cause Neighbor Discovery, Address autoconfiguration, and DHCPv6 to 677 take some action. While the full implications are outside of the 678 scope of this document, here is what we know about the impact on 679 Neighbor Discovery. 681 Everything learned from the RAs on the interface should be discarded, 682 such as the default router list and the on-link prefix list. 683 Furthermore, all neighbor cache entries, in particular redirects, 684 need to be discarded. Finally the information in the Current 685 Candidate Link object is used to create a new default router list and 686 on-link prefix list. 688 The list of things are are potentially affected by this movement is 689 fairly extensive, since new Neighbor Discovery options are being 690 created. In addition to what is mentioned above, the list includes: 692 o The MTU option defined in [1]. 694 o The Advertisement Interval option defined in [5]. 696 o The Home Agent Information option defined in [5]. 698 o The Route Information option defined in [11]. 700 5. CPL without a 'link UP' notification 702 If the host implementation does not provide any link-layer event 703 notifications [9], and in particular, a link UP notification, the 704 host needs additional logic to try to decide whether a received RA 705 applies to the "old" link or a "new" link. 707 In this case there is an increased risk that the host get confused, 708 thus it isn't clear whether this should be part of the 709 recommendation, or whether we should just require that hosts which 710 implement this draft have a 'link UP' notification. 712 As the protocol is specified in Section 4, if there is no 'link UP' 713 notification when the host might have moved, the host would collect 714 the prefixes from multiple links into a single Candidate Link object, 715 and would never detect movement. 717 Here is an example. The host begins to collect the prefixes on a 718 link. But before the prefix list generation is completed, without 719 its knowledge, the host moves to a new link. Unaware that now it is 720 at the different link, the host keeps collecting prefixes from the 721 received RAs to generate the prefix list. This results in the prefix 722 list containing prefixes from two different links. If the host uses 723 this prefix list, it fails to detect a link change. 725 A possible way to prevent this situation for implementations without 726 a link UP notification, is to treat the arrival of a RA with a 727 disjoint set of prefixes as a hint, the same way Section 4 treats the 728 link UP notification as a hint, as specified below. 730 The implications of treating such an RA as a hint, is that such an RA 731 would set 'time_last_linkUP_received' to the current time, create a 732 new Candidate Link object with the information extracted from that 733 RA, and then send an RS as specified in Section 4.4. 735 However, there is still a risk for confusion because the host can not 736 tell from the RAs whether they were solicited by the host. (RFC 2461 737 recommends that solicited RAs be multicast.) The danger is 738 examplified by this: 740 1. Assume the host has a CCL with prefixes P1 and P2. 742 2. The host changes link layer attachment, but there is no link UP 743 notification. 745 3. The host receives an RA with a disjoint set of prefixes: prefix 746 P3. This causes the host to form a new Candidate Link object 747 with P3 and send an RS. 749 4. The host again changes link layer attachment, and no link UP 750 notification. 752 5. The host receives one of the periodic multicast RAs on the link, 753 which contains prefix P4. It can not tell whether this RA was in 754 response to the RS it send above. The host ends up adding this 755 to the CCL, which now has P3 and P4, even though those prefixes 756 are assigned to different links. 758 There doesn't appear to be a way to solve this problem without 759 changes to the routers and the Router Advertisement messages. 760 However, the probability of this occurring can be limited by limiting 761 the window of exposure. The simplest approach is for the host to 762 assume that any RA received within 4 seconds after sending a RS was 763 in response to the RS. Basically this relies on the small 764 probability of both moving again in that 4 second interval, and 765 receiving one of the periodic RAs. If the periodic RAs are sent 766 infrequently enough, this might work in practise, but is by no means 767 bullet-proof. 769 6. IANA Considerations 771 No new message formats or services are defined in this document. 773 7. Security Considerations 775 DNA process is intimately related to Neighbor Discovery protocol and 776 its trust model and threats have much in common with the ones 777 presented in RFC 3756 [7]. Nodes connected over wireless interfaces 778 may be particularly susceptible to jamming, monitoring, and packet 779 insertion attacks. Use of [6] to secure Neighbor Discovery are 780 important in achieving reliable detection of network attachment. DNA 781 schemes SHOULD incorporate the solutions developed in IETF SEND WG if 782 available, where assessment indicates such procedures are required. 784 The threats specific to DNA are that an attacker might fool a node to 785 detect attachment to a different link when it is in fact still 786 attached to the same link, and conversely, the attacker might fool a 787 node to not detect attachment to a new link. 789 The first form of attack is not very serious, since at worst it would 790 imply some additional higher-level signaling to register a new 791 (care-of) address. The second form of attack can be more serious, 792 especially if the attacker can prevent a host from detecting a new 793 link. The protocol as specified would require an attacker to be on- 794 link and be authenticated and authorized to send Router 795 Advertisements when Secure Neighbor Discovery [6] is in use. 796 However, even without SEND, an attacker would need to send RAs 797 containing the prefixes to which it wants the host to be unable to 798 detect movement. This can be done for a small number of prefixes, 799 but it isn't possible for the attacker to completely disable DNA for 800 all possible prefixes on other links. 802 8. Examples 804 This section contains some example packet flows showing the operation 805 of prefix based DNA. 807 8.1 Example with link UP event notification 809 Assume the host has seen no link UP notification for a long time and 810 that it has the prefixes P1, P2, and P3 in its prefix list for the 811 interface. 813 The IP layer receives a link UP notification. This hint makes it 814 multicast an RS and start collecting the received prefixes in a new 815 list of prefixes. 817 The host receives an RA containing no prefixes. This has no effect 818 on the algorithm contained in this specification. 820 The host receives an RA containing only the prefix P4. This could be 821 due to being attached to a different link or that there is a new 822 prefix on the existing link which is not announced in RAs together 823 with other prefixes, and a spurious hint. In this example the host 824 decides to wait for another RA before deciding. 826 One second later an RA arrives which contains P1 and P2. As a result 827 the "new" prefix list has P1, P2, and P4 hence is not disjoint from 828 the "old" prefix list with P1, P2, and P3. Thus the host concludes 829 it has not moved to a different link and its prefix list is now P1, 830 P2, P3, and P4. 832 Some time later a new link UP notification is received by the IP 833 layer. Triggers sending a RS. 835 An RA containing P5 and P6 is received by the host. Based on some 836 heuristic (for instance, the number of RAs it received on the old 837 link, or the assumed frequency of prefixes being added to an existing 838 link) this time the host decides that it is on a new link. 840 One second later an RA with prefix P7 is received. Thus the prefix 841 list now contains P5, P6, and P7. 843 8.2 Example without link UP event notification 845 Assume the host has collected the prefixes P1, P2, and P3 in its 846 prefix list for the interface. 848 The host receives an RA containing only prefix P4. The fact that P4 849 is disjoint from the prefix list makes this be treated as a hint. 851 This hint makes the host multicast an RS and start collecting the 852 received prefixes in a new list of prefixes, which is initially set 853 to contain P4. 855 The host receives an RA containing no prefixes. This has no effect 856 on the algorithm contained in this specification. 858 The host receives an RA containing only the prefix P4. This could be 859 due to being attached to a different link or that there is a new 860 prefix on the existing link which is not announced in RAs together 861 with other prefixes. In this example the host decides to wait for 862 another RA before deciding. 864 One second later an RA arrives which contains P1 and P2. As a result 865 the "new" prefix list has P1, P2, and P4 hence is not disjoint from 866 the "old" prefix list with P1, P2, and P3. Thus the host concludes 867 it has not moved to a different link and its prefix list is now P1, 868 P2, P3, and P4. 870 Some time later the host receives an RA containing prefix P7. This 871 is treated as a hint since it is not part of the current set of 872 prefixes. Triggers sending a RS and initializing the new prefix list 873 to P7. 875 An RA containing P5 and P6 is received by the host. This is disjoint 876 with both of the previous prefix lists, thus the host might be 877 attached to a 3rd link after very briefly being attached to the link 878 with prefix P7. The host decides to wait for more RAs. 880 One second later an RA with prefix P7 is received. It still isn't 881 certain whether P5, P6, and P7 are assigned to the same link (and 882 without a link UP notification such uncertainties do exist). 884 A millisecond later an RA with prefixes P6 and P7 is received. Now 885 the host decides that P5,P6, and P7 are assigned to the same link. 887 Four seconds after the RS was sent and no RA containing P1, P2, P3, 888 or P4 has been received the host can conclude with high probability 889 that it is no longer attached to the link which had those prefixes. 891 9. Performance Analysis 893 In this section, we compute the probability that a host fails to 894 generate the complete prefix list due to packet loss, and 895 consequently assumes a link change when the host in fact did not move 896 to a different link. 898 Suppose, in a link, there are N routers, R[1], R[2],...., R[N]. 900 Each R[i] advertises the Router Advertisement RA[i] with the prefix 901 P[i]. 903 It is the worst case that each router advertises the different 904 prefix. It is necessary to receive all the RA[i] to generate the 905 complete prefix list. 907 We assume there is a host, H, and when the host sends a Router 908 Solicitation, let P be the probability that it fails to receive a 909 RA[i] because of a RA loss. For the simplicity, we disregard RS 910 losses. 912 So when the sends a Router Solicitation, the probability that it will 913 receive all RA[i] is (1-P)^N. 915 Let's assume the host performs RS/ RA exchange T times, 1,2,..,T. 917 Let S[k] be the set of all RAs which the host H successfully receives 918 at k-th RS/RA exchange. The probability that R[i] belongs to S[k] is 919 (1-P). 921 Let PL[k] be the set of prefixes which are made from S[k], i.e. the 922 set of P[j] such that RA[j] belongs to S[k]. Obviously, the 923 probability that P[i] belongs to PL[k] is also (1-P). 925 Let PL be the union of all PL[k], from k=1 to k=T. PL is the prefix 926 list made from performing RS/ RA exchange T times. 928 1) The probability of the complete prefix list generation 930 First the probability that P[i] belongs to PL is 1-P^T. The 931 probability that the prefix list PL is complete is (1-P^T)^N. 933 For example, assume the error rate is 1 % and there are 3 routers in 934 a link, then, with 2 RS/ RA exchanges, the probability of generating 935 an accurate Complete Prefix List is roughly 99.97 %. 937 At this point, assume that the host H receives a hint that a link 938 change might have happened and consequently initiates the procedure 939 of checking a link change. 941 2) The false DNA probability if the host checks for link change with 942 one RA. 944 Assume one RA, whether solicited or unsolicited arrives. If the host 945 H makes a decision based solely on the RA and the prefix list, the 946 probability that it falsely assume a link change is P^T. 948 For example, given the error rate is 1%, with 2 RS/ RA exchanges, the 949 probability of false movement detection is 1/ 10000. 951 3) The false DNA probability if the host checks for link change with 952 additional RS/ RA exchanges. 954 Instead of depending on the single RA, the host H performs additional 955 RS/ RA exchange U times, 1,2...U. Then the probability that H falsely 956 assumes a link change is 958 [P^T + P^U - P^(T+U)]^N. 960 For example, given the error rate is 1 % and there are 3 routers in a 961 link, if the host H performs 2 RS/ RA exchanges before the hint and 1 962 RS/ RA exchange after one, the probability of false movement 963 detection is roughly 1/1000000. 965 In the above formula, the result goes to P^(U*N) as T goes infinity. 966 The term P^(U*N) results from the probability that the host receives 967 no RA during U RS/ RA exchange after the hint. To see that it still 968 remains at the same link, a host needs to receive at least one RA. 970 We think it is reasonable to assume that the RS will be retransmitted 971 until at least one RA arrives. If we take a one more assumption that 972 the host receives at least one RA, the probability will be 974 [[P^T + P^U - P(T+U)]^N - P^(U*N)]/ [1- P^(U*N)] 976 The above converges to zero as T approaches infinity. 978 10. Change Log 980 The following changes have been made since draft-jinchoi-dna-cpl-01: 982 o Clarified that only prefixes with a non-zero valid lifetime are 983 considered. 985 o Added some text about renumbering considerations. 987 o Limited the retention of old Candidate Link objects to 90 minutes 988 to avoid problems if there is flash renumbering *and* a prefix is 989 reassigned to a different link in less than 90 minutes. 991 o Explicitly made the assumption that the host implementation has a 992 'link UP' event notification. 994 o Added missing text in section 4.4 about sending a RS when a link 995 UP notification is processed. 997 o Added text in section 4.6 to say that current and future ND 998 options need to be included in the information that is discarded 999 when the host declares that is has moved to a different link. 1001 o Made the Candidate Link objects be per interface, since there are 1002 some security issues when they are shared between interfaces that 1003 might be of different trustworthyness. 1005 o Many editorial clarifications. 1007 11. Open Issues 1009 o Should we worry about implementations without 'link Up' 1010 notifications? The technique in Section 5 is far from bullet- 1011 proof. 1013 o Flash renumbering and immediate reassignment may cause a problem. 1014 Assume a prefix is suddenly removed from one link and immediately 1015 reassigned to an another link. A host in first link may not 1016 perceive the prefix removal and mistakenly assume the prefix is 1017 still valid. If the host moves to the second link and check for 1018 link change with the prefix, it will make a false decision. 1020 o The document currently proposes that hosts send one RS (and 1021 retransmit until at least one RA is received) after a hint, and 1022 afterwards wait for 2 additional unsolicited RAs from each router, 1023 before declaring the prefix list complete. With the default 1024 timers in RFC 2461 this will take a long time (60-90 minutes). 1025 Should we instead recommend that the host send 2 or 3 RSs 1026 initially? If so, how frequently? The additional RSs will 1027 increase the total amount of multicast packets on the link - 1028 perhaps significantly - so there are some tradeoffs involved here. 1030 12. References 1032 12.1 Normative References 1034 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1035 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1037 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 1038 Autoconfiguration", RFC 2462, December 1998. 1040 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1041 Addressing Architecture", RFC 3513, April 2003. 1043 [4] Choi, J., "Detecting Network Attachment in IPv6 Goals", 1044 draft-ietf-dna-goals-04 (work in progress), December 2004. 1046 12.2 Informative References 1048 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1049 IPv6", RFC 3775, June 2004. 1051 [6] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 1052 Nikander, "SEcure Neighbor Discovery (SEND)", 1053 draft-ietf-send-ndopt-06 (work in progress), July 2004. 1055 [7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1056 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 1058 [8] Choi, J. and E. Nordmark, "DNA solution framework", 1059 draft-jinchoi-dna-soln-frame-00 (work in progress), July 2004. 1061 [9] Yegin, A., "Link-layer Event Notifications for Detecting 1062 Network Attachments", draft-ietf-dna-link-information-01 (work 1063 in progress), February 2005. 1065 [10] Pentland, B., "An Overview of Approaches to Detecting Network 1066 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 1067 progress), February 2005. 1069 [11] Draves, R. and D. Thaler, "Default Router Preferences and More- 1070 Specific Routes", draft-ietf-ipv6-router-selection-07 (work in 1071 progress), January 2005. 1073 Authors' Addresses 1075 JinHyeock Choi 1076 Samsung AIT 1077 Communication & N/W Lab 1078 P.O.Box 111 Suwon 440-600 1079 KOREA 1081 Phone: +82 31 280 9233 1082 Email: jinchoe@samsung.com 1084 Erik Nordmark 1085 Sun Microsystems 1086 17 Network Circle 1087 Menlo Park, CA 94043 1088 USA 1090 Phone: +1 650 786 2921 1091 Email: erik.nordmark@sun.com 1093 Intellectual Property Statement 1095 The IETF takes no position regarding the validity or scope of any 1096 Intellectual Property Rights or other rights that might be claimed to 1097 pertain to the implementation or use of the technology described in 1098 this document or the extent to which any license under such rights 1099 might or might not be available; nor does it represent that it has 1100 made any independent effort to identify any such rights. Information 1101 on the procedures with respect to rights in RFC documents can be 1102 found in BCP 78 and BCP 79. 1104 Copies of IPR disclosures made to the IETF Secretariat and any 1105 assurances of licenses to be made available, or the result of an 1106 attempt made to obtain a general license or permission for the use of 1107 such proprietary rights by implementers or users of this 1108 specification can be obtained from the IETF on-line IPR repository at 1109 http://www.ietf.org/ipr. 1111 The IETF invites any interested party to bring to its attention any 1112 copyrights, patents or patent applications, or other proprietary 1113 rights that may cover technology that may be required to implement 1114 this standard. Please address the information to the IETF at 1115 ietf-ipr@ietf.org. 1117 Disclaimer of Validity 1119 This document and the information contained herein are provided on an 1120 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1121 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1122 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1123 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1124 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1125 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1127 Copyright Statement 1129 Copyright (C) The Internet Society (2005). This document is subject 1130 to the rights, licenses and restrictions contained in BCP 78, and 1131 except as set forth therein, the authors retain all their rights. 1133 Acknowledgment 1135 Funding for the RFC Editor function is currently provided by the 1136 Internet Society.