idnits 2.17.1 draft-dnadt-dna-discussion-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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1081. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1087. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1103), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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 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 (February 14, 2005) is 7005 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: '1' is defined on line 1004, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1015, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1021, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1025, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '3') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-01) exists of draft-jinchoi-dna-frd-00 == Outdated reference: A later version (-02) exists of draft-daley-ipv6-tsllao-00 == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-00 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNA Working Group B. Pentland 2 Internet-Draft Monash University CTIE 3 Expires: August 15, 2005 February 14, 2005 5 An Overview of Approaches to Detecting Network Attachment in IPv6 6 draft-dnadt-dna-discussion-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 15, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document is a discussion of potential solutions to the problem 40 of rapidly and reliably detecting attachment to a network and 41 determining when host configuration change is required. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Objectives for a Solution to the Problem of DNA . . . . . . . 4 48 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 5. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 6. Determining Whether Link Change Has Occurred . . . . . . . . . 4 51 6.1 Techniques that add information to the RA. . . . . . . . . 5 52 6.1.1 Explicit Link Identifier. . . . . . . . . . . . . . . 5 53 6.1.2 Complete Router Advertisement. . . . . . . . . . . . . 6 54 6.2 Techniques That Ask a Question in the RS. . . . . . . . . 6 55 6.2.1 Requested Landmark. . . . . . . . . . . . . . . . . . 6 56 6.2.2 Priority Landmark. . . . . . . . . . . . . . . . . . . 7 57 6.2.3 Hybrid Landmark. . . . . . . . . . . . . . . . . . . . 7 58 7. Fast Responses to Solicitation . . . . . . . . . . . . . . . . 8 59 7.1 Fast Router Discovery. . . . . . . . . . . . . . . . . . . 8 60 7.2 Simple Fast RA. . . . . . . . . . . . . . . . . . . . . . 8 61 7.3 Deterministic Fast RA. . . . . . . . . . . . . . . . . . . 8 62 7.4 Negotiation-free Deterministic Fast RA. . . . . . . . . . 9 63 7.5 Probabilistic Fast RA. . . . . . . . . . . . . . . . . . . 9 64 8. Dealing with Legacy Routers . . . . . . . . . . . . . . . . . 10 65 9. Putting Things Together . . . . . . . . . . . . . . . . . . . 10 66 9.1 Requested Landmark with Negotiation-free Deterministic 67 Fast RA . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 9.1.1 How the goals are met . . . . . . . . . . . . . . . . 13 69 9.2 CompleteRA with Probabilistic Fast RA . . . . . . . . . . 14 70 9.2.1 How the goals are met . . . . . . . . . . . . . . . . 15 71 9.3 Prefix-based LinkID with Fast Router Discovery . . . . . . 16 72 9.3.1 How the goals are met . . . . . . . . . . . . . . . . 17 73 10. On the Wire Costs . . . . . . . . . . . . . . . . . . . . . 18 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 75 12. Security Considerations . . . . . . . . . . . . . . . . . . 21 76 12.1 General Threats . . . . . . . . . . . . . . . . . . . . . 21 77 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 79 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 80 14.2 Informative References . . . . . . . . . . . . . . . . . . . 22 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23 82 Intellectual Property and Copyright Statements . . . . . . . . 24 84 1. Introduction 86 This document represents, an overview of the discussion of the DNA 87 design team on potential solutions to the problem of rapid and 88 reliable network attachment detection. The design team was comprised 89 of JinHyeock Choi, Tero Kauppinen, James Kempf, Sathya Narayanan, 90 Erik Nordmark, and Brett Pentland. 92 While we were unable to settle on a single solution, a number of 93 different techniques were discussed at length, and this document 94 provides a summary of them, including their advantages and 95 disadvantages. 97 In general, it was felt that fast attachment detection will require 98 some kind of hint from layer two. The link layer event notifications 99 draft [13], provides a discussion of layer two information available 100 from a number of link types. Though it talks about "link-up" and 101 "link-down", only link-up is considered here, for its utility in 102 triggering a router solicitation from a host. 104 In considering DNA, we have discussed how to get to the point where a 105 host knows whether or not its IP configuration is likely to be valid, 106 and has enough information to be able to start reconfiguration if 107 necessary. At the end of "DNA" it either knows that it is connected 108 to the same link as its current configuration implies, or it knows 109 that it's connected to a new link, its IP configuration is invalid, 110 as it has at least one prefix that it can use for Stateless Address 111 Auto-configuration, if appropriate. It might also just use this as a 112 trigger to start DHCP and/or any higher layer authorization/ 113 authentication as required. 115 2. Terminology 117 The following terms are used throughout the document 119 Link - As defined in RFC 2461 [2]. 121 Landmark - Some attribute that may be associated with a 122 specific link such as a prefix or global router 123 address. 125 Link Identifier 126 - A consistent identifier used in some way by all 127 routers on a link to allow hosts to distinguish 128 the link from other links. 130 3. Objectives for a Solution to the Problem of DNA 132 Because detecting network attachment will frequently happen on a 133 network that a host has not seen before, information about that 134 network will be required in order to configure addresses, etc. for 135 future communication. The usual mechanism for obtaining this 136 information is the Router Advertisement. A solicitation will be 137 required in order to take advantage of hints from lower layers and 138 speed up the detection process. It was felt that by crafting the 139 information in the solicitation and advertisement, a single RS/RA 140 exchange should be sufficient for DNA. 142 In order to detect attachment rapidly, RA response should be as fast 143 as possible. To this end, a DNA protocol ideally should not include 144 any timer-induced delays for the first RA in response to an RS, 145 though if a technique is sufficiently superior in other areas, some 146 delay may be acceptable. 148 4. Assumptions 150 - All of the routers on a link can be expected to receive packets 151 sent to the "all-routers" multicast address (ff02::2) with some 152 packet-loss probability < 1. 154 - Hosts with interfaces that can connect to more than one link 155 concurrently are able to distinguish packets from the separate links 156 and thus abstract the link connections as separate virtual 157 interfaces. 159 5. The Problem 161 Given the above objectives, the problem to be solved can then be 162 broken into two parts: 164 1. Crafting the information in the RS/RA exchange to allow accurate 165 determination of whether a link change has occurred, necessitating 166 a change to existing configuration, and including the necessary 167 prefixes, etc. to allow those configuration changes to be made if 168 needed. 170 2. Ensuring that an RA is received as rapidly as possible in 171 response to solicitation. 173 6. Determining Whether Link Change Has Occurred 175 There are a number of ways that the RFC 2461 RS/RA exchange could be 176 modified to allow unambiguous determination of whether configuration 177 change is required with a single exchange. These may be broadly 178 divided into two classes: 180 1. Techniques that add information to the RA to allow hosts to make 181 a correct decision. 183 2. Techniques that add information to the RS to ask a question of 184 routers on the link, getting back an answer in the RA. 186 6.1 Techniques that add information to the RA. 188 6.1.1 Explicit Link Identifier. 190 The routers on a link, by some mechanism, agree on a single 191 identifier for the link that is different from any corresponding 192 identifier used on another link that a host is likely to transition 193 to directly. The identifier would then be included in router 194 advertisements to allow hosts to immediately recognise whether this 195 link is the same as the one they believe themselves to be connected 196 to. 198 Link Identifier techniques have an associated cost of needing a 199 (secure) mechanism for the routers to come to agreement on the value 200 of the link ID and also a means to change it if necessary without 201 confusing the hosts on the link. 203 6.1.1.1 Random Link Identifiers. 205 There are a number of options for the identifier. It could be simply 206 a random number carried in a new advertisement option. This is quite 207 simple, independent of changes to prefixes or routers on a link, but 208 takes some extra bytes per RA and has a non-zero probability of there 209 being multiple links using the same identifier. 211 6.1.1.2 Prefix Based Link Identifiers. 213 A global prefix is another possible candidate for use as a Link 214 Identifier. This would have the advantage of being unique, requires 215 no additional RA bytes if a router is already advertising the prefix 216 and just needs to add a flag to indicate that it is also a link 217 identifier. If it is not possible to find a global prefix that all 218 of the routers on the link are announcing, then some routers will 219 need to include a prefix that is only a link identifier, thus 220 increasing the size of the RA. There also needs to be a mechanism to 221 change the Link Identifier if the chosen prefix ceases to be used on 222 the link. 224 Another way to generate an identifier from prefixes is to collect all 225 of the prefixes active on the link and take some kind of hash over 226 the ordered list of them, or alternatively, just one of them. This 227 would generate an identifier like in Section 6.1.1.1, but with a 228 guarantee of uniqueness. As with other prefix based link 229 identifiers, the prefixes need to be monitored to ensure that they 230 are current. A mechanism is needed to be able to change the 231 identifier in response to changes in the prefixes. Using a hash 232 based on a single prefix would be less vulnerable to changes than one 233 based on all of the prefixes. 235 6.1.2 Complete Router Advertisement. 237 Routers on a link listen for other routers' advertisements and 238 include a complete list of all prefixes in use on the link in RAs 239 they send. The RA would carry a flag to indicate that the RA did 240 indeed include a complete list. 242 Care should be taken to differentiate prefixes that are learnt from 243 those that were originally configured on a router. The prefixes that 244 are only learnt would need to be included in special PIOs so that 245 hosts only use them for identification purposes and not as regular 246 PIOs. The special PIOs could have their own code so that they are 247 unrecognised by hosts that don't implement a new DNA specification. 248 Another alternative would be to use conventional PIOs but with the L, 249 A and R flags not set, and with a new D-flag (DNA) to indicate that 250 the prefix is reflected for DNA purposes. PIOs with the L, A and R 251 flags all cleared have no effect on non-DNA hosts. 253 This technique has the advantages of forming an implicit identifier, 254 is quite simple, requires no changes to solicitations, and makes it 255 easy for a host to generate a complete prefix list for a link, 256 allowing it to deal easily with an RA from a non-DNA router. The 257 main cost is the size of the RAs. If routers on a link have matching 258 sets of prefixes, then this is no cost but if there are differences 259 then some of the RAs will be larger. If the sets are disjoint, then 260 all of the solicited RAs will be larger and there is no implicit 261 upper bound on the increase. 263 6.2 Techniques That Ask a Question in the RS. 265 6.2.1 Requested Landmark. 267 Routers on a link listen for other routers' advertisements and 268 collect the prefixes so that they know all of the active prefixes on 269 the link. Hosts, when soliciting, select a prefix that they have 270 seen previously and include it in the solicitation. Routers 271 responding to the solicitation can then included a yes or no flag (as 272 distinct from no flag at all) that says whether or not the prefix is 273 in use on this link. 275 This technique is again quite simple. The cost is an increase in the 276 size of the RS (with no corresponding increase in the RA) but the 277 increase is known, fairly modest, and fixed. There is, in general, a 278 1:N ratio of RSs to RAs, where N is the number of routers on the 279 link. The result of this is that increases to the RS size are less 280 costly than increases to the RA size. 282 In certain other techniques it is possible to reduce the number of 283 RAs by using multicast to answer multiple solicitations at once. 284 This can only be achieved if delays are added which is something to 285 be avoided if possible for the first response to an RS. Thus the 286 number of RAs is always >= the number of RSs and hence increases to 287 the RA size are still more costly than increases to the RS size. 289 6.2.2 Priority Landmark. 291 Hosts include the address of their default router in solicitations. 292 A fast RA mechanism is used that guarantees that if that router is on 293 the link then it will respond first. If the first response is not 294 from the default router then the host can assume that it has moved to 295 a new link, possibly after checking that the included PIOs support 296 this. 298 This technique has the advantage of confirming bi-directional 299 reachability with the default router when movement has not taken 300 place. The cost is an increase in the RS size and a dependence on a 301 mechanism to ensure that the requested router is always the first to 302 respond. 304 6.2.3 Hybrid Landmark. 306 Routers on a link include at least one PIO in unsolicited 307 advertisements that includes an R-bit, and monitor the R-bit PIOs of 308 other routers on the link. This gives out addresses that can be used 309 as landmarks for the link. Hosts pick a landmark that they have seen 310 most recently and include it in solicitations. Routers responding to 311 this solicitation include flags to indicate whether or not this 312 landmark has been seen on the link. The fast RA mechanism can be 313 designed to allow the router with the requested landmark to respond 314 first. 316 This again has the advantage of confirming bi-directional 317 reachability with the default router when movement has not taken 318 place. It also allows any router to respond and give a definitive 319 answer to the link-change question. The main cost is the increased 320 RS size. 322 This, the two preceding landmark schemes, and Complete RA all require 323 routers to place timers on the gathered prefixes to be sure that old 324 information can be discarded if prefixes are moved to different 325 links. 327 7. Fast Responses to Solicitation 329 Again there are a number of ways that standard procedures could be 330 modified to allow a router advertisement to be received quickly 331 following solicitation. 333 7.1 Fast Router Discovery. 335 draft-jinchoi-dna-frd-00.txt 337 Access Points cache the most recent RA(s) and forward it(them) to a 338 host upon detection of its association. 340 This is very simple and potentially very fast and places no 341 requirements on hosts or routers but is link-specific and raises some 342 security concerns since it is, by definition, a "man in the middle". 344 Where there are multiple routers on a link it needs to be determined 345 which RA(s) will be forwarded, and how to time out old cache entries. 347 7.2 Simple Fast RA. 349 draft-mkhalil-ipv6-fastra-05.txt 351 Select one router on each link to be allowed to respond immediately 352 to solicitations. 354 Again very simple, but requires a mechanism to select the fast 355 router, introduces a single point of failure, and may result 356 unbalanced loading of routers. 358 7.3 Deterministic Fast RA. 360 draft-daley-dna-det-fastra-01.txt 362 Routers on a link negotiate amongst themselves an ordering for 363 responding to solicitations. Responses are made in order at fixed 364 intervals starting from zero delay for the first router. 366 This removes the single point of failure problem and means that 367 losing an RA doesn't slow down the RS/RA exchange much (unless there 368 is only one router). The costs include the necessity for the routers 369 to engage in negotiation to select the ordering and fact that that 370 ordering may result in unbalanced loading of the routers. 372 It would be fairly simple to alter the behaviour to reorder the 373 responses based on some function of the source of the RS to spread 374 load evenly. 376 7.4 Negotiation-free Deterministic Fast RA. 378 Routers on a link listen for advertisements from other routers and 379 form tokens for them from the source addresses. Hosts include a 380 tentative source link layer address option (TSLLAO) [11] in 381 solicitations. When an RS is received by a router, some function of 382 the TSLLAO is XORed with each of the router tokens to create a 383 ranking. One or more of the routers then respond in order with fixed 384 delays starting from zero. 386 The advantage here is that routers just need to listen to RAs to 387 determine an ordering that will vary from solicitation to 388 solicitation, it doesn't have a single point of failure and will 389 result in multiple (if there are multiple routers) RAs quickly. The 390 main cost is the need for the RSs from hosts to include a TSLLAO, but 391 this will be necessary for any technique where sending unicast RAs is 392 required, unless a separate NS/NA exchange is done between the RS and 393 RA. 395 If multicast RAs are to be used, then TSLLAOs are not necessary for 396 the transmission of the RA to the host without an NS/NA exchange. 397 The cost of including a TSLLAO might be removed by determining a base 398 ordering for the routers based on the tokens, and then perturbing 399 that ordering using a function of the time that the RS is received 400 (for example, shifting the ordering by the minute of the reception 401 time, modulo the number of routers). The cost of this is the 402 necessity to synchronize the router's clocks and a small period of 403 ambiguity around the time when the part of the timestamp used changes 404 (e.g. when the clock ticks over from one minute to the next). 406 7.5 Probabilistic Fast RA. 408 Routers on a link listen for advertisements from other probabilistic 409 fast RA routers (as defined by a flag) and count the number of them. 410 Responses to solicitations are scheduled into one of count+1 slots 411 spaced, say, 20 ms apart starting from zero. A slight bias towards 412 the zero slot can be done to improve average response. Maximum and 413 minimum values for the number of slots can be set to limit the 414 effects of unknown or spurious routers. Details of this technique 415 can be found in [10] including claimed intellectual property rights. 417 Again, routers just have to listen to other routers on the link to 418 get the information they need to determine the sending delay. The 419 trust requirements are even lower, having no need for security 420 associations between routers. This is because they are just counting 421 routers, storing minimal information about them, and abnormally high 422 counts are easily ignored. 424 An upper bound is placed on introduced delay, and average delays are 425 quite low, albeit non-zero. Hosts will often, but not always receive 426 an immediate response. 428 8. Dealing with Legacy Routers 430 It is likely that hosts will encounter links that have routers that 431 don't have any enhancements to support DNA. It is important that 432 they are still able make correct decisions quickly about whether link 433 change has occurred. By maintaining a list of all of the prefixes in 434 use on a link, they can then use any prefix in an RA to make a 435 decision. One way to maintain such a list is described in [8]. 437 An unsolicited RA might indicate an added prefix or router, rather 438 than movement, but can be used as a trigger to send an RS to test the 439 link. There is a small chance of an erroneous decision, even after 440 an RS, if a prefix or router is added to a link. An implementation 441 may choose to delay making configuration changes until further 442 confirmation if the cost of an incorrect decision is high. It may 443 wait for further RAs or even re-solicit to achieve that confirmation. 445 The Complete Router Advertisement technique described in Section 446 6.1.2 integrates well with this because a single RA can provide all 447 of the prefixes in use on a link, simplifying the process of 448 gathering them. 450 9. Putting Things Together 452 For a complete solution, a fast RA technique needs to be mated up 453 with a technique for using the RS/RA exchange for identification. 454 The two parts are largely but not completely independent. For 455 example, deterministic fast RA defines a "router to router" message 456 that can be reused to negotiate a link identifier. 458 To evaluate solutions, the way they meet the goals laid out in the 459 DNA goals document [9] should be considered. Quoting from the goals 460 document: 462 G1 DNA schemes should detect the identity of the currently attached 463 link to ascertain the validity of the existing IP configuration. 464 They should recognize and determine whether a link change has 465 occurred and initiate the process of acquiring a new 466 configuration if necessary. 468 G2 DNA schemes should detect the identity of an attached link with 469 minimal latency lest there should be service disruption. 471 G3 In the case where a host has not changed a link, DNA schemes 472 should not falsely assume a link change and an IP configuration 473 change should not occur. 475 G4 DNA schemes should not cause undue signaling on a link. 477 G5 DNA schemes should make use of existing signaling mechanisms 478 where available. 480 G6 DNA schemes should make use of signaling within the link 481 (particularly link-local scope messages), since communication 482 off-link may not be achievable in the case of a link change. 484 G7 DNA schemes should be compatible with security schemes such as 485 Secure Neighbour Discovery [3]. 487 G8 DNA schemes should not introduce new security vulnerabilities. 488 The node supporting DNA schemes should not expose itself or 489 others on a link to additional man-in-the-middle, identity 490 revealing, or denial of service attacks. 492 G9 The nodes, such as routers or hosts, supporting DNA schemes 493 should work appropriately with unmodified nodes, such as routers 494 or hosts, which do not support DNA schemes. 496 G10 Hosts, especially in wireless environments, may perceive routers 497 reachable on different links. DNA schemes should take into 498 consideration the case where a host is attached to more than one 499 link at the same time. 501 9.1 Requested Landmark with Negotiation-free Deterministic Fast RA 503 (How routers collect the information needed to determine RS 504 response order) 505 - Routers send periodic advertisements including a flag that 506 indicates that they are DNA routers. 507 - An interval option (rfc3775) should be included in multicast 508 RAs to facilitate detection of lost routers 509 - If more than one SA is in use then a PIO with the R-bit 510 (rfc3775) should be included. 511 - Routers listen to other routers' advertisements and use them to 512 maintain a list of all active prefixes on the link. 513 - Upper bound needed on list length to prevent memory overflow. 514 - routers collect the source addresses of routers they have 515 received RAs from. 516 - a token equal to a hash of the IID (could be the full SA, but 517 presumably the IID is where the variation is) of the 518 collected addresses is stored for each router, associated 519 with a timer related to the interval option in the received 520 RA. 521 - the IIDs are also stored 522 - R-bit PIOs should be monitored to detect the use of 523 multiple SAs by a single router - only the lowest IID and 524 its token should be stored. 525 - an upper bound is needed on the number of tokens that will be 526 stored (to prevent overflow). 527 - a fallback position is needed in the case of a full list. 529 (How hosts request information from the link) 530 - Hosts solicit including a TSLLAO (for unicast responses), an 8 531 bit counter that is incremented for each RS sent, and an option 532 including the most recently received prefix. 534 (How routers respond to solicitation) 535 - Unicast is used by routers for responding to solicitations, 536 subject to rate control by a token bucket scheme. 537 - Exhaustion of the token bucket results in the use of multicast, 538 subject to the controls of rfc2461. 539 - Routers examine the TSLLAO of incoming RSs, XOR the IID contained 540 with each of the stored tokens (including its own) and compare 541 them to calculate a ranking for themselves. 542 - The top ranked router responds immediately. 543 - Some number of the others follow at fixed intervals. 545 (How hosts interpret RAs received) 546 - The response RAs contain one of two flags indicating whether or 547 not the requested prefix is active on this link, and a copy of 548 the counter in the received RS. 549 - Hosts look at the flags in the received RA to decide on a course 550 of action. 551 - Yes flag set: no action required - maybe NS/NA exchange with 552 current default router at leisure. 553 - No flag set: clear NC, and use one of the prefixes in the RA to 554 form a new address - test with optiDAD, etc. 555 - Both set: not allowed - treat as though none set 556 - None set: invoke CPL logic 557 - CPL logic: (going from memory, may need correcting - more 558 aggressive approach to new prefixes) 559 - hosts try to form a complete list of all prefixes available 560 on a link. 561 - send (possibly multiple) RSs at suitable intervals 562 - RAs received in this time considered to be part of prefix 563 list building 564 - RAs with all prefixes disjoint from current prefix list 565 assumed to be from a new link (maybe test with NS/NA to 566 current default router with short timeout) 567 - Clear NC, form new address, etc., restart CPL building. 569 9.1.1 How the goals are met 571 G1 The answer to the landmark question gives a positive indication 572 of whether link change has occurred, and the RA will contain the 573 information required to reconfigure if necessary. 575 G2 Under normal circumstances, a host that sends an RS should get an 576 RA back from a router in one round trip time plus a small 577 processing delay. If that RA is lost another should arrive after 578 a small delay if there is more than on router on the link. 580 G3 Non-movement situations are correctly detected. 582 G4 A single RS/RA exchange is initiated in response to a hint that a 583 link change may have occurred. Routers build the state they need 584 to respond to RSs simply by listening to the unsolicited RAs of 585 other routers. 587 G5 The RS/RA mechanism is all that is required. A new option is 588 defined for the RS and a pair of new flags is required in RAs. 590 G6 Only link-scope signalling is used. 592 G7 SeND can be used to protect RSs with a specified source address 593 and will protect the new option against tampering. It will also 594 protect the new flags in the RA against tampering. 596 G8 If SeND is not deployed, then a rogue device could cause a host 597 to think its configuration is invalid by sending an RA that 598 answers the RS question incorrectly. A similar effect is already 599 possible, however, by a rogue device sending an RA with valid 600 prefixes with zero lifetimes. 602 G9 The CPL logic allows a graceful fallback position for dealing 603 with non-DNA hosts and routers. 605 G10 This technique is carried out on an interface by interface 606 basis. A host with multiple interfaces can get information about 607 changes to configuration on each interface, but would need a 608 higher level process to decide how the information from the 609 various interfaces relates to each other. 611 9.2 CompleteRA with Probabilistic Fast RA 613 (How routers gather all the routers and prefixes on a link.) 614 - Routers include a "D" flag (DNA) in RAs to indicate that they 615 will participate in probabilistic fast RA. 616 - Routers listen to other routers' advertisements and use them to 617 maintain a list of all active prefixes on the link. 618 - They also keep a count of the number of DNA routers on the 619 link. 620 - An upper bound needed on list lengths to prevent memory 621 overflow. 623 (How routers decide when to respond to an RS) 624 - Upon reception of an RS, an RA is scheduled into one of count+1 625 time slots starting from zero with, say, 20 ms spacing. 626 - count is set to the number of probabilistic routers heard with 627 configurable upper and lower bounds 628 - multicast RAs may be used (subject to the rate limiting 629 restrictions of RFC 2461) and if they are, solicitations that 630 would result in the scheduling of an RA after an already 631 scheduled RA may be ignored 633 (How routers advertise CompleteRA) 634 - CompleteRA is the RA that contains the complete set of all 635 prefixes on the link, including a flag to indicate that the list 636 is indeed complete. 637 - PIOs seen on the link but not originating from the sending 638 router could use a new type code (as distinct from a flag 639 which would be ignored by non-dna hosts). 640 - Routers advertise the CompleteRA upon receiving an RS as 641 indicated above. 642 - If too many prefixes are in use to fit in an RA then the 643 complete flag cannot be set and CPL may be relied on with 644 conventional logic. 646 (How hosts check for link change with CompleteRA.) 647 - A host receiving an RA compares the prefixes in the RA to their 648 own list of current prefixes. 649 - if there is overlap between the prefix lists (they should 650 match exactly) then nothing needs to be done - maybe NS/NA 651 exchange with current default router at leisure. 653 - if they are disjoint, then it is a new link and the NC can be 654 cleared and new addresses formed, etc. 656 (How hosts generate the Complete Prefix List with a single 657 CompleteRA) 658 - Upon receiving a CompleteRA, hosts can generate the Complete 659 Prefix List without further action. 661 (How to interoperate with non-supporting links) 662 - The Complete Prefix List logic is simpler: 663 - similar to above 664 - when building the CPL, if an RA is received with the complete 665 flag set, then those prefixes constitute the CPL and the host 666 can go straight to the state where list is considered built. 667 - In the built state, if a new prefix is received that has a 668 disjoint prefix set, then a new link is implied. 669 - reconfiguration should be commenced, possibly after an 670 attempted NS/NA exchange with default router with a short 671 timeout if the cost for an incorrect decision is high 672 (could just be a new router and prefix on the link). 674 9.2.1 How the goals are met 676 G1 The complete set of prefixes in the RA gives a positive 677 indication of whether link change has occurred, and contains the 678 information required to reconfigure if necessary. 680 G2 The router advertisement is usually transmitted to the host in 681 one round trip time plus a processing delay. Sometimes there 682 will be a slot delay if no routers schedule for slot zero, adding 683 20 ms to the delay. 685 G3 Non-movement situations are correctly detected. 687 G4 A single RS/RA exchange is initiated in response to a hint that a 688 link change may have occurred. Routers build the state they need 689 to respond to RSs simply by listening to the unsolicited RAs of 690 other routers. If a complete RA is received without 691 solicitation, then no solicitation is required; the RA contains 692 enough information. 694 G5 The RS/RA mechanism is all that is required. A new option is 695 defined for the RA to carry learned (but unused) prefixes and new 696 flags are required to indicate completeness and participation in 697 probabilistic fast RA. 699 G6 Only link-scope signalling is used. 701 G7 SeND can be used to protect the RAs. The new option can be 702 protected against tampering but not necessarily that they are 703 authorized to be included in the RA. Since they are only used 704 for link identification, this is no different to the flag 705 protection in the previous section. It will also protect the new 706 flags in the RA against tampering. 708 G8 If SeND is not deployed, then a rogue device could cause a host 709 to think its configuration is invalid by sending an RA with bogus 710 prefixes. A similar effect is already possible, however, by a 711 rogue device sending an RA with valid prefixes with zero 712 lifetimes. 714 G9 The CPL logic allows a graceful fallback position for dealing 715 with non-DNA hosts and routers. 717 G10 This technique is carried out on an interface by interface 718 basis. A host with multiple interfaces can get information about 719 changes to configuration on each interface, but would need a 720 higher level process to decide how the information from the 721 various interfaces relates to each other. 723 9.3 Prefix-based LinkID with Fast Router Discovery 725 -(How to choose a common Prefix LinkID on a link) 726 - Routers listen to other routers' advertisements and use 727 them to maintain a list of all active prefixes on the link. 728 - Upper bound needed on list length to prevent memory overflow. 729 - The routers choose the smallest prefix as the Link Identifier, 730 i.e. Prefix LinkID. 732 (How to advertise the Prefix LinkID in an RA) 733 - The routers advertise the prefix in every RA with PIO including 734 a new "I" (identification) bit to indicate that the prefix is 735 the Link Identifier, i.e. Prefix LinkID. 736 - If the prefix is not explicitly configured on the sending 737 router, the L, A and R flags should be set off, so that 738 the PIO would have no effect on hosts other than link 739 identification. 741 (How hosts use Prefix LinkID) 742 - Hosts keep the Prefix LinkID of the currently attached link. 744 (How to quickly forward Prefix LinkID to hosts with FRD) 745 - Access Points on the network cache an RA with the Prefix LinkID. 747 - When an Access Point detects (through layer two means) that 748 a host has arrived on the link, it immediately forward it a 749 copy of the cached RA. 751 (How a host checks for link change with Prefix LinkID) 752 - The host receiving the RA compares the Prefix LinkID in the RA 753 to its currently stored one. 754 - If they are the same, the host remains at the same link and 755 no further DNA action is required. 756 - If they differ, the host assumes a link change and 757 immediately initiates a new IP configuration. 759 (How to interoperate with non-supporting links) 760 - Prefix LinkID scheme allows a host to detect a link change 761 properly when it moves FROM and TO the link supporting 762 the scheme. Backup mechanism such as CPL is needed 763 only when a host moves between non-supporting links. 765 9.3.1 How the goals are met 767 G1 The reception of the LinkID gives a host a positive indication of 768 whether link change has occurred, and the RA will contain the 769 information required to reconfigure if necessary. 771 G2 The router advertisement is transmitted to the host as soon as 772 the AP detects that it has associated and is able to receive 773 packets on the link. 775 G3 Non-movement situations are correctly detected. 777 G4 Only a single RA is required. 779 G5 Only RAs are required. A new flag is added to PIOs to indicate 780 that a prefix is in fact the Link ID as well. 782 G6 Only link-scope signalling is used. 784 G7 SeND can be used to protect RAs and show authorization for a set 785 of prefixes. For routers with the prefix used as the LinkID 786 explicitly configured, SeND may not show authorization. In this 787 case there will be no evidence that the LinkID is valid. Hosts 788 should only accept RAs that contain another authorized prefix. 789 It will also protect the new flag in the RA against tampering. 791 G8 If SeND is not deployed, then a rogue device could cause a host 792 to think its configuration is invalid by sending an RA with a 793 bogus Link ID. A similar effect is already possible, however, by 794 a rogue device sending an RA with valid prefixes with zero 795 lifetimes. 797 G9 The CPL logic allows a graceful fallback position for dealing 798 with non-DNA hosts and routers. 800 G10 This technique is carried out on an interface by interface 801 basis. A host with multiple interfaces can get information about 802 changes to configuration on each interface, but would need a 803 higher level process to decide how the information from the 804 various interfaces relates to each other. 806 10. On the Wire Costs 808 The number of bytes sent onto the wire (air) is highly dependent on 809 the number of routers on a link and the way in which prefixes are 810 distributed across them. In the very simplest case where there is 811 only one router and it only has a single prefix to advertise, the 812 variation in costs is quite small. Considering only unicast RA 813 examples, the RS/RA would take 160 octets for CompleteRA, or for 814 LinkID where the link identifier is the prefix being advertised. 815 Using the hybrid landmark scheme would take 184 octets. 817 As the topology gets more complex and there are more routers and/or 818 prefixes the number of octets in the exchange increases dramatically. 819 In general, however, the growth is fairly consistent across the 820 combinations of techniques. The exception is combinations including 821 CompleteRA. The re-advertising of prefixes makes the size of its 822 exchanges grow much more quickly if there are non-matching sets of 823 prefixes on routers. For example, a medium case where there are two 824 routers each with one prefix (but not the same one), the prefix-based 825 requested landmark scheme takes 280 octets for the exchange. 826 Complete RA takes 328 octets. In a much worse case of four routers, 827 each with two prefixes and none matching, the two exchanges are 616 828 and 1240 octets respectively. 830 The worst case performance of Complete RA can be improved 831 substantially by defining a new RA option to carry all of the 832 re-advertised 64-bit prefixes at once. This reduces the above case 833 exchange to 824 octets, but it is still unbounded. It needs to be 834 considered how likely such topologies are. 836 The actual sizes of RAs will depend on which options are needed but 837 an example of the sizes is shown in the following table. In this 838 case "typical" options counted are Maximum Transmission Unit (MTU) 839 and Link Layer Address Option (LLAO). 841 +--------------------+--------------------+-----------------------+ 842 | Technique | RS size | RA size | 843 +====================+====================+=======================+ 844 | Random LinkID | 56 octets (basic + | 40 + 48 + p*32 octets | 845 | | 8 for TSLLAO) | (basic + 8 (LLAO) + | 846 | | | 8 (MTU) + 16 (LinkID) | 847 | | | + PIOs) | 848 +--------------------+--------------------+-----------------------+ 849 | Prefix LinkID | 56 octets (basic + | 40 + 48 + p*32 octets | 850 | | 8 for TSLLAO) | as above _OR_ | 851 | | | 40 + 32 + p*32 octets | 852 | | | if one of the prefixes| 853 | | | is the link ID | 854 +--------------------+--------------------+-----------------------+ 855 | CompleteRA | 56 octets (basic + | 40 + 32 + P*32 octets | 856 | | 8 for TSLLAO) | (basic + 8 (LLAO) + 8 | 857 | | | (MTU) + all PIOs) | 858 +--------------------+--------------------+-----------------------+ 859 | CompleteRA with | 56 octets (basic + | 40 + 32 + p*32 + 8 + | 860 | re-advertised | 8 for TSLLAO) | p2*32 (basic + 8 | 861 | prefix option | | (LLAO) + 8 (MTU) + | 862 | | | own PIOs + opt header | 863 | | | learned prefixes | 864 +--------------------+--------------------+-----------------------+ 865 | Requested Landmark | 72 octets (basic + | 40 + 32 + p*32 octets | 866 | | TSLLAO + 16 octet | (basic + 8 (LLAO) + | 867 | | landmark option) | 8 (MTU) + PIOs | 868 +--------------------+--------------------+-----------------------+ 869 | Priority Landmark | 80 octets (basic + | 40 + 32 + p*32 octets | 870 | | TSLLAO + 24 octet | as above | 871 | | landmark option) | | 872 +--------------------+--------------------+-----------------------+ 873 | Hybrid Landmark | 80 octets (basic + | 40 + 32 + p*32 octets | 874 | | TSLLAO + 24 octet | as above | 875 | | landmark option) | | 876 +--------------------+--------------------+-----------------------+ 878 p = number of prefixes router advertises 879 P = total number of prefixes on link 880 p2 = number of prefixes re-advertised in case of CompleteRA 882 Note that unicast RAs have been assumed here necessitating the TSLLAO 883 in the RS if an immediate RA is desired. 885 Note that RA size assumes that flags can be placed in existing RA 886 flag fields - if an option is required the RA will be 8 octets 887 larger. 889 Note also that the CompleteRA and LinkID techniques could have value 890 even without an RS at all. 892 As mentioned above, the number of routers on a link and the 893 distribution of prefixes has a large effect on the number and size of 894 packets sent onto the link. Some examples are shown below. 896 +--------------------+--------------------------------------------+ 897 | Technique |1 Router|2 Router|2 Router|2 Router|4 Router| 898 | |1 prefix|1 prefix|1 prefix|2 prefix|2 prefix| 899 | | | |each |disjoint|disjoint| 900 +====================+========+========+========+========+========+ 901 | Random LinkID |56+120 |56+2*120|56+2*120|56+2*152|56+4*152| 902 | |=176 |=296 |=296 |=360 |=664 | 903 +--------------------+--------+--------+--------+--------+--------+ 904 | Prefix LinkID |56+104 |56+2*104|56+104+ |56+136+ |56+136+ | 905 | |=160 |=264 |120=280 |152=344 |3*152 | 906 | | | | | |=648 | 907 +--------------------+--------+--------+--------+--------+--------+ 908 | CompleteRA |56+104 |56+2*104|56+2*136|56+2*200|56+4*296| 909 | |=160 |=264 |=328 |=456 |=1240 | 910 +--------------------+--------+--------+--------+--------+--------+ 911 | CompleteRA with |56+104 |56+2*104|56+2*120|56+2*160|56+4*192| 912 | re-advertised |=160 |=264 |=296 |=376 |=824 | 913 | prefix option | | | | | | 914 +--------------------+--------+--------+--------+--------+--------+ 915 | Requested Landmark |72+104 |72+2*104|72+2*104|72+2*136|72+4*136| 916 | |=176 |=280 |=280 |=344 |=616 | 917 +--------------------+--------+--------+--------+--------+--------+ 918 | Priority Landmark |80+104 |80+2*104|80+2*104|80+2*136|80+4*136| 919 | |=184 |=288 |=288 |=352 |=624 | 920 +--------------------+--------+--------+--------+--------+--------+ 921 | Hybrid Landmark |80+104 |80+2*104|80+2*104|80+2*136|80+4*136| 922 | |=184 |=288 |=288 |=352 |=624 | 923 +--------------------+--------+--------+--------+--------+--------+ 925 Note this table assumes that for each RS there will be N RAs, where 926 N is the number of routers on the link. It may be possible to 927 multicast any delayed RAs and if a group of RSs arrive very close 928 together, to have one RA answer multiple RSs. 929 If the first RA is not delayed, then #RAs is always >= #RSs and in 930 general, #RAs = N * #RSs. 932 11. IANA Considerations 934 No new options or messages are defined in this document. 936 12. Security Considerations 938 All of the techniques described in this document are modifications to 939 router discovery. SeND [12] has be design for the express purpose of 940 securing neighbour and router discovery exchanges. It follows then 941 that there are two cases to consider: networks with and without SeND. 943 SeND can be used to show that a router is authorised to advertise 944 particular prefixes. This can be used equally well by routers 945 checking the prefixes of other routers as it can by hosts checking 946 the same. In the case of link identifiers SeND may not be able to 947 show that a linkid is correct for a given router but it can protect 948 the packet against tampering. 950 There may be some performance issues introduced by SeND. The first 951 time a host comes to a link there may need to be a packet exchange to 952 get certificates chains. This may be mitigated by allowing 953 certificates to cover larger prefixes, e.g. for a site/organization. 955 Where SeND is not deployed there are many attacks against neighbour/ 956 router discovery already possible and it is just necessary to 957 investigate whether proposed DNA techniques make the network or hosts 958 any more vulnerable than they already are. 960 The main difference between the threat to RFC2461 devices and the 961 threat to devices implementing techniques discussed in this document 962 comes from the desire to speed things up. The goal is to have a 963 single RA able to give enough information to decide if a link change 964 has occurred, and if so, reconfigure addressing, etc., to allow 965 packet exchanges to begin on the new link. A result of this is that 966 if a single carefully crafted packet can cause a host to make the 967 decision that it has changed links, it can then cause that host enter 968 a state where logically all of its existing configuration is invalid. 969 If a host has in fact moved to a new link, then that configuration is 970 invalid. It be prudent, however, to move the configuration to a 971 placeholder in case it is possible to recognise to false 972 advertisement and restore the old configuration. 974 12.1 General Threats 976 1 A bogus router advertises a landmark or identifier that convinces a 977 host that it has moved when it in fact not. 979 2 A bogus router advertises a landmark or identifier that convinces a 980 host that it has not moved when it in fact has. 982 3 A mischievous host may, depending on the mechanisms available in 983 the fast RA scheme employed, be able to cause a flood of RAs to be 984 sent onto the link. Even unicast RAs can cause disruption to all 985 nodes on certain link types, such as those employing CSMA/CA like 986 802.11b. It is probably worth designing in mechanisms to limit the 987 effect of this even when SeND is not employed because of the 988 potential for a multiplicative effect where there are more than one 989 router on the link: 1 RS -> N RAs. 991 13. Acknowledgments 993 Thanks to all members of the design team - JinHyeock Choi, Tero 994 Kauppinen, James Kempf, Sathya Narayanan, and Erik Nordmark - upon 995 whose discussion the text of this document is based, and for their 996 help in shaping the content. 998 Thanks also to Greg Daley for some very useful insight. 1000 14. References 1002 14.1 Normative References 1004 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1005 Levels", BCP 14, RFC 2119, March 1997. 1007 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 1008 IP Version 6 (IPv6)", RFC 2461, December 1998. 1010 14.2 Informative References 1012 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 1013 Autoconfiguration", RFC 2462, December 1998. 1015 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1016 IPv6", RFC 3775, June 2004. 1018 [5] Choi, J., "Fast Router Discovery with RA Caching", 1019 draft-jinchoi-dna-frd-00 (work in progress), July 2004. 1021 [6] Kempf, J., Khalil, M. and B. Pentland, "IPv6 Fast Router 1022 Advertisement", draft-mkhalil-ipv6-fastra-05 (work in 1023 progress), July 2004. 1025 [7] Daley, G., "Deterministic Fast Router Advertisement 1026 Configuration", draft-daley-dna-det-fastra-01 (work in 1027 progress), October 2004. 1029 [8] Choi, J., "DNA with unmodified routers: Prefix list based 1030 approach", draft-jinchoi-dna-cpl-01 (work in progress), October 1031 2004. 1033 [9] Choi, J., "Detecting Network Attachment in IPv6 Goals", 1034 draft-ietf-dna-goals-04 (work in progress), December 2004. 1036 [10] Daley, G., Narayanan, S. and G. Perkins, "A probabilistic 1037 scheme for fast Router Advertisement responses in IPv6", 1038 draft-daley-dna-prob-fastra-00 (work in progress), February 1039 2005. 1041 [11] Daley, G., "Tentative Source Link-Layer Address Options for 1042 IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in 1043 progress), June 2004. 1045 [12] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 1046 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 1047 (work in progress), July 2004. 1049 [13] Yegin, A., "Link-layer Event Notifications for Detecting 1050 Network Attachments", draft-ietf-dna-link-information-00 (work 1051 in progress), September 2004. 1053 Author's Address 1055 Brett Pentland 1056 Centre for Telecommunications and Information Engineering 1057 Department of Electrical and Computer Systems Engineering 1058 Monash University 1059 Clayton, Victoria 3800 1060 Australia 1062 Phone: +61 3 9905 5245 1063 EMail: brett.pentland@eng.monash.edu.au 1065 Intellectual Property Statement 1067 The IETF takes no position regarding the validity or scope of any 1068 Intellectual Property Rights or other rights that might be claimed to 1069 pertain to the implementation or use of the technology described in 1070 this document or the extent to which any license under such rights 1071 might or might not be available; nor does it represent that it has 1072 made any independent effort to identify any such rights. Information 1073 on the procedures with respect to rights in RFC documents can be 1074 found in BCP 78 and BCP 79. 1076 Copies of IPR disclosures made to the IETF Secretariat and any 1077 assurances of licenses to be made available, or the result of an 1078 attempt made to obtain a general license or permission for the use of 1079 such proprietary rights by implementers or users of this 1080 specification can be obtained from the IETF on-line IPR repository at 1081 http://www.ietf.org/ipr. 1083 The IETF invites any interested party to bring to its attention any 1084 copyrights, patents or patent applications, or other proprietary 1085 rights that may cover technology that may be required to implement 1086 this standard. Please address the information to the IETF at 1087 ietf-ipr@ietf.org. 1089 Disclaimer of Validity 1091 This document and the information contained herein are provided on an 1092 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1093 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1094 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1095 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1096 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1097 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1099 Copyright Statement 1101 Copyright (C) The Internet Society (2005). This document is subject 1102 to the rights, licenses and restrictions contained in BCP 78, and 1103 except as set forth therein, the authors retain all their rights. 1105 Acknowledgment 1107 Funding for the RFC Editor function is currently provided by the 1108 Internet Society.