idnits 2.17.1 draft-daley-dna-det-fastra-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1111. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1088. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1101. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1117), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2004) is 7122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 1077, but not defined == Missing Reference: '500' is mentioned on line 1077, but not defined == Unused Reference: '1' is defined on line 982, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2463 (ref. '3') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-05 == Outdated reference: A later version (-05) exists of draft-mkhalil-ipv6-fastra-02 -- Possible downref: Normative reference to a draft: ref. '6' -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '7') (Obsoleted by RFC 4291) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNA Working Group G. Daley 2 Internet-Draft B. Pentland 3 Expires: April 25, 2005 Monash University CTIE 4 E. Nordmark 5 Sun Microsystems 6 October 25, 2004 8 Deterministic Fast Router Advertisement Configuration 9 draft-daley-dna-det-fastra-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 April 25, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 Neighbour Discovery forces routers responding to Router Solicitations 43 to delay a random interval of 0-500 ms in order to prevent contention 44 and bandwidth utilization by multiple responding routers. Routers 45 receiving solicitations may need to quickly send responding Router 46 Advertisements faster than allowed in IPv6 Neighbour Discovery. 48 In order to provide fast router response, Fast Router Advertisements 49 have been proposed, which do not randomly delay. This document 50 describes an automatic arbitration and configuration mechanism to 51 allow hosts to securely agree on the relative ordering and delay of 52 their Fast Router Advertisements. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1 Deterministic Fast Router Advertisement Concepts . . . . . 6 60 3.2 Router-to-Router Status Communication . . . . . . . . . . 7 61 3.3 Deterministic Fast Router Advertisement Options . . . . . 7 62 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.1 Router to Router ICMPv6 message . . . . . . . . . . . . . 8 64 4.2 Deterministic Fast Router Advertisement Option Format . . 10 65 4.2.1 Rank . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.2.2 Fixed Delay . . . . . . . . . . . . . . . . . . . . . 12 67 4.2.3 Separation . . . . . . . . . . . . . . . . . . . . . . 12 68 4.2.4 Relative Preference . . . . . . . . . . . . . . . . . 12 69 5. Sending Router-to-Router messages . . . . . . . . . . . . . . 12 70 5.1 Sending Router-to-Router Status-Requests . . . . . . . . . 12 71 5.2 Sending Router-to-Router Status . . . . . . . . . . . . . 13 72 6. Ranking Calculation . . . . . . . . . . . . . . . . . . . . . 13 73 6.1 Ranking Score Calculation Reasoning . . . . . . . . . . . 14 74 7. Becoming a Fast Router . . . . . . . . . . . . . . . . . . . . 15 75 8. Receiving DetFRAO in ICMPv6 Router-to-Router . . . . . . . . . 15 76 8.1 Receiving Bootstrap Deterministic FastRA Options . . . . . 16 77 8.2 Cleaning up old entries . . . . . . . . . . . . . . . . . 16 78 8.3 Responding to Status-Requests with DetFRAO . . . . . . . . 16 79 9. Sending DetFRAOs in ICMPv6 Router-to-Router . . . . . . . . . 16 80 9.1 Sending RAs on Rank or Delay Change . . . . . . . . . . . 17 81 9.2 Sending Advertisement Intervals . . . . . . . . . . . . . 17 82 10. Sending Fast Router Advertisements . . . . . . . . . . . . . 17 83 10.1 Sending Unicast Fast RAs . . . . . . . . . . . . . . . . . 18 84 10.2 Sending Multicast Fast RAs . . . . . . . . . . . . . . . . 18 85 11. Interaction with Other Routers . . . . . . . . . . . . . . . 18 86 11.1 Presence of Legacy Routers . . . . . . . . . . . . . . . . 18 87 11.2 Ceasing to be a Fast Router . . . . . . . . . . . . . . . 19 88 11.3 Presence of Non Fast Routers . . . . . . . . . . . . . . . 19 89 11.4 Presence of Incompatible Fast Routers . . . . . . . . . . 19 90 12. Configuration Parameters . . . . . . . . . . . . . . . . . . 20 91 13. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 20 92 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 93 15. Security Considerations . . . . . . . . . . . . . . . . . . 21 94 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 95 17. Changes Since Last Revision . . . . . . . . . . . . . . . . 22 96 17.1 draft-daley-dna-det-fastra-00 to -01 . . . . . . . . . . . 22 98 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 18.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 100 18.2 Informative References . . . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 102 A. State Diagram . . . . . . . . . . . . . . . . . . . . . . . . 24 103 Intellectual Property and Copyright Statements . . . . . . . . 26 105 1. Introduction 107 Existing standards require that hosts which respond to Router 108 Solicitations introduce a random delay of 0-500ms before sending a 109 Router Advertisement [2]. 111 The Fast RA draft [6] introduces the concept of a Fast Router 112 Advertisement. Fast Router advertisements provide the capability for 113 a router to avoid performing the random delay before transmission, 114 and send responses without the mean 250ms delay. 116 Additionally, routers may wish to allow a small number of multicast 117 Router Advertisements to configuring devices with similar delays. 118 Extensions to FastRA which support multicast Router Advertisement are 119 considered in this document (possibly to move elsewhere later). 121 Fast Router Advertisement, as specified, only allows one host on a 122 link to be a FastRA router. Unless FastRA specified this limit, 123 responses from more than one FastRA router would result in the same 124 MAC contention which RFC 2461 sought to avoid. 126 Unfortunately, while Fast RA is an effective way of providing fast 127 response, it has no defined automated configuration mechanism to 128 determine which router is the fastest, nor any method to provide 129 router reselection in case a router is no longer able to provide fast 130 responses. This lack of a router reselection mechanism is seen a a 131 clear stumbling block to FastRA's deployment. 133 This document defines a secured mechanism relying on new 134 Router-to-Router ICMPv6 messages to allow routers to make decisions 135 about which router responds fastest, and additionally allows other 136 routers to avoid random delays[5][2]. The new mechanism relies upon 137 SEND-like security to determine trust-relationships between on-link 138 routers, and test the reachability of existing routers. 140 It allows automated reconfiguration in the case that routers join or 141 leave the Fast Router set, and ensures that Fast Routers do not 142 collide with each other by providing negotiated fixed delays between 143 responding advertisements. 145 2. Terminology 147 The following terms are used throughout the document 149 Bootstrapping Router: A router which has not yet determined its rank 150 and delay for Fast Router Advertisement. 152 Deterministic Fast Router Advertisement Option (DetFRAO): An ICMPv6 153 option indicating the Fast Router's participation in this 154 protocol, as well as its rank and delay. This option may appear 155 in Router-to-Router Status-Requests and Status messages. The 156 option's format is defined in Section 4.2. 158 Fast Router: A router participating in this protocol and exchanging 159 Deterministic Fast Router Advertisement Options in 160 Router-to-Router messages. 162 Fast Router Advertisement: A response to a Router Solicitation which 163 is not randomly delayed. Please note that at a particular time, a 164 Fast Advertising Router may advertise with a delay whose mean is 165 slower than that defined by [2]. Even in this case, the response 166 is still called a Fast Router Advertisement (or FastRA). 168 Fast Advertising Router List: A conceptual list where FastRA routers 169 are sorted by a Ranking Score, and delays for various routers 170 calculated. 172 Fastest Advertising Router: The router with Rank=1, which is able to 173 transmit without delay. 175 Fixed Delay: The minimum amount of time which a Fast Advertising 176 Router may delay before sending a Router Advertisement in response 177 to a Router Solicitation. Typically this is the delay used for 178 Router Advertisement transmission. 180 Legacy Router: A router which responds to router solicitations using 181 the algorithm defined in section 6.2.6 of the IPv6 Neighbour 182 Discovery RFC[2]. 184 Multicast Fast Router Advertisement A Fast Router Advertisement sent 185 to the all-nodes multicast address. These advertisements have 186 different parameters for their Token Bucket than a Unicast Fast 187 Router Advertisement. 189 Rank: The position of the router in the advertising order. A router 190 with a better (lower numbered) rank will always send responding 191 advertisements faster than one with a worse rank. 193 Ranking Identifier: An value derived from the identity of the 194 advertising router, used in ranking calculations. 196 Ranking Score: A score calculated from the router's preference and 197 Ranking Identifier. This score is used to order the routers on 198 the link and determine their Rank. 200 Router-to-Router message: A new ICMPv6 message which uses the same 201 options format as IPv6 Neighbour Discovery, but is only used for 202 communication between routers on a local link. It provides a 203 means by which routers can advertise their configuration status 204 and request that other routers do the same. 206 Separation: A period after the transmission of a previous RA that the 207 router must wait. The separation time is defined by the preceding 208 router. 210 Token Bucket A finite sized non-negative resource counter which 211 increases at a set rate while the number of resource tokens in the 212 bucket is not at maximum. When a resource is to be allocated, 213 there must be a non-zero number of resource tokens in the bucket. 214 As the token is allocated the resource counter decrements. 216 Unicast Fast Router Advertisement A Fast Router Advertisement sent to 217 the unicast source address of a Router Solicitation. Unicast Fast 218 RAs can be sent while there are tokens in the Unicast FastRA token 219 bucket as defined in [6]. 221 3. Protocol Operation 223 Routers wishing to provide Fast Router Advertisement need to check if 224 other routers on the link are providing Fast RAs and agree on a 225 relative ordering and delay before response. This negotiation takes 226 place prior to Fast RA operation, when routers are first configured, 227 start or change their preferences. 229 This allows all Fast Routers to send responses to Router 230 Solicitations at the agreed delay, without introducing additional 231 variable delays. Delays and ordering are therefore deterministic, 232 and one responding Fast Advertising Router (the Fastest) will be able 233 to transmit Router Advertisements in response to solicitation with no 234 delay at all. 236 During transition periods where router ordering changes, router 237 advertise their changed configuration to peer routers using ICMPv6 238 Router-to-Router messages, defined in this document. 240 3.1 Deterministic Fast Router Advertisement Concepts 242 To agree on when to send responses, Fast RA routers need to know 243 which routers are Fast Routers, and must agree on their relative 244 order for RS response. In this document, the ordinal position agreed 245 to by a router is its Rank. 247 The lowest number provides the best Rank, and the fastest responding 248 router has a Rank of 1. The ranking algorithm seeks to avoid ties, 249 although from time to time, multiple routers will be seen to have the 250 same Rank. Handling of this condition is specified in Section 6. 252 Upon determining the advertisement order, each router needs to choose 253 a delay exceeding that advertised by its better Ranked routers. To 254 do this it inspects the Separation value advertised by the fastest 255 router, and advertises its own Fixed Delay value based on the number 256 of routers preceding it and the fastest router's Separation. The 257 Fixed Delay is the lowest value used by the router as delay for 258 responding to Router Solicitations. 260 3.2 Router-to-Router Status Communication 262 In order to accomplish Ranking and delay agreement between routers on 263 a link, messages need to be exchanged between FastRA routers. These 264 messages contain information about the router's current configuration 265 status, and indicate that FastRA is in use. This document specifies 266 the Router-to-Router(RtR) ICMPv6 message which allows configuration 267 status to be requested from other routers while advertising the 268 router's own status. 270 In negotiating with other routers on a link, trust of a router's 271 identity and authorization needs to be established, and mechanisms to 272 check these must be devised. The Router-to-Router message is able to 273 use the existing message formats for Secure Neighbour Discovery, and 274 uses the same signatures and keys which are used in Router 275 Solicitations and Advertisements. 277 Existing protocol messages such as Router Solicitation and Router 278 Advertisement were explicitly designed for communication between 279 routers and autoconfiguring hosts. While the options deployed in 280 this document may have worked interoperably in existing Neighbour 281 Discovery messages, existing assumptions about the roles of 282 particular message senders (particularly as defined in Appendix D of 283 [2]) would be violated in doing so. 285 The newly defined Router-to-Router message aims to be compatible with 286 future protocols requiring router negotiation and agreement, and 287 defines an extensible option format in the same manner as IPv6 288 Neighbour Discovery. 290 3.3 Deterministic Fast Router Advertisement Options 292 Deterministic Fast Router Advertisement Options provide the means by 293 which a router's interest in being a Fast Advertising Router is 294 advertised, as well as providing an indication of the router's Rank, 295 Fixed Delay and Separation. 297 These options are sent in Router-to-Router Status-Request messages 298 from routers which wish to learn other routers' Fast RA parameters, 299 and sent in Router-to-Router Status messages responding to these 300 requests. The option may also appear in Router Solicitations and 301 Advertisements when communicating between a router and a host. 303 This draft principally concerns the use and operation of routers 304 configuring FastRA with Deterministic Fast Router Advertisement 305 Options. 307 4. Message Formats 309 This document introduces one new ICMPv6 Message, the Router-to-Router 310 message (RtR). It also defines a new option for this message, The 311 Deterministic FastRA Option (DetFRAO). 313 4.1 Router to Router ICMPv6 message 315 0 1 2 3 316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Code | Checksum | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Reserved | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Options ... 323 +-+-+-+-+-+-+-+-+-+-+-+- 325 Source Address 326 MUST be the link-local address assigned to the 327 interface from which this message is sent. 329 Destination Address 330 Typically the router-to-routers multicast 331 group (TBD Suggest: FF02::12). 333 Hop Limit 255 335 ICMP Fields: 337 Type TBD (Suggest 191) 339 Code 0 - Status Request 340 1 - Status 342 Checksum The ICMPv6 checksum. 344 Reserved This field is unused. It MUST be initialized to 345 zero by the sender and MUST be ignored by the 346 receiver. 348 Valid Options: 350 Advertisement Interval 351 The maximum delay between unsolicited Router 352 Advertisement messages. This option and its use 353 are defined in Mobile IPv6. 355 Deterministic Fast Router Advertisement 356 The configuration status for FastRA, as defined in 358 Section 4.2 359 of this document. 361 CGA An option providing information about the router's 362 cryptographically generated address, as defined in 363 SEND. 365 Nonce This option is provided in Status-Request messages, 366 and copied into Status messages when responding to 367 a particular Status-Request. It is defined in SEND. 369 Timestamp An indication of the time of a Status-Request or 370 Status message, as perceived at the transmitter. 371 This option is aims to reduce the chance of 372 messages being replayed, and is defined in SEND. 374 Signature A digital signature over the message (including the 375 CGA Type Tag, IPv6 Source and Destination addresses 376 and the entire ICMPv6 message without Signature 377 option). This option MUST be the last option in 378 the message, if present, and is defined in SEND. 380 Future versions of this protocol may define new option types. 381 Receivers MUST silently ignore any options they do not recognize 382 and continue processing the message. 384 Mobile IPv6 is defined in [4], SEND is defined in [5]. 386 The Router-to-Router message comes with two different codes. A 387 Status-Request message asks peer routers which understand the message 388 to report back with their configuration for the options contained in 389 the message. A Status message either responds to a Status-Request or 390 periodically updates its peers of the configuration. 392 Sending of Status-Request messages is defined in Section 5.1. 394 Processing of Status-Request messages is performed as described for 395 each received option type (unknown options being ignored). A router 396 MUST respond to a Status-Request message with a Status message, even 397 if it contains no configuration status information. 399 Transmission of Status messages is defined in Section 5.2. 401 SEND options are ignored as regards requests for status by receiving 402 routers. 404 SEND option processing is as detailed in [5] and particularly, all 405 secured Router-to-Router messages MUST contain the Signature and 406 Timestamp options. Status-Request messages act as if they are 407 solicitations for the inclusion of CGA options and Nonce Options. 408 CGA and Nonce Options MUST also be present in Status messages which 409 respond to a Status-Request. Where the Status messages are sent 410 otherwise they SHOULD include the CGA Option regularly to ensure that 411 routers newly arrived on the link are able to verify their message. 413 4.2 Deterministic Fast Router Advertisement Option Format 415 0 1 2 3 416 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type | Length | Rank | Reserved | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Fixed Delay | Separation | Rel Pref | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Fields: 425 Type TBD (Suggest 13) 427 Length The length of the option (including the type and 428 length fields) in units of 8 octets. Routers 429 compliant with this document MUST set the 430 length to 1. If the option is received in a 431 Router-to-Router message with a length greater 432 than one the router MUST NOT read the option's 433 contents, and MUST set the IncompatibleFastRouters 434 flag on the interface until the advertising router 435 disappears or begins advertising with an option 436 length of 1. 438 Rank An integer in the range 0-255 indicating the the 439 ordinal position of the Fast Router. 441 Reserved This field MUST be set to zero and be MUST be 442 ignored by receivers. 444 Fixed Delay The minimum delay used by this router to send 445 Router Advertisements in response to Router 446 Solicitation. 447 (Units: milliseconds) 449 Separation A delay after the current router's Fixed Delay 450 that worse ranked routers wait before transmitting. 451 This is used by other routers when the subject 452 router is fastest. 453 (Units: milliseconds) 455 Rel Pref The Relative Preference of the router seeking to 456 perform Fast Router Advertisement. This is set 457 to the variable FastRARelPref. 459 This option may appear in Router-to-Router, Router Solicitation and 460 Router Advertisement messages. Nodes receiving this option in other 461 messages MUST ignore it, acting as if they didn't understand the 462 option. 464 4.2.1 Rank 466 The Router ranked 1 will be the fastest router, and MUST configure a 467 Fixed Delay of 0. No router may adopt a rank (other than 468 BOOTSTRAP_RANK) until it has undertaken router querying as defined in 469 Section 7. 471 4.2.2 Fixed Delay 473 The router determines its Fixed Delay by counting the number of 474 preceding routers (Rank - 1) and multiplying this by the fastest 475 router's Separation value. 477 The Fastest Router MUST set its Fixed Delay to 0. 479 4.2.3 Separation 481 This value for the Fast Router's Separation from subsequent Fast 482 Routers exceeds the maximum additional delay over Fixed Delay 483 required to transmit a Fast Router Advertisement. 485 This delay MUST allow for computation delays in forming the RA (such 486 as incurred with SEND) [5]. 488 4.2.4 Relative Preference 490 This is an integer number providing the relative preference of the 491 fast router for Rank determination. It is controlled by the variable 492 FastRARelPref which MUST be configurable by the router's 493 administrator. This value is prepended to the 24 bit Rank Identifier 494 in order to provide a Ranking Score, as described in Section 6. 496 A lower value will increase the preference of the router, and will 497 outrank routers configured with the default preference value of 498 DEF_REL_PREF. 500 Changes in a router's FastRA preference MAY be advertised immediately 501 based on its newly calculated Rank, since routers should be checking 502 if the Ranking Identifier associated with a particular router already 503 exists in the Fast Router List, and will move the existing entry to 504 its new location in the Fast Router List. 506 5. Sending Router-to-Router messages 508 Router-to-Router messages indicate the router's current configuration 509 and may request a response from a peer router, with its own 510 configuration status. 512 5.1 Sending Router-to-Router Status-Requests 514 When seeking to learn about other routers' status, a router may send 515 Router-to-Router status Requests to its peers. 517 In doing so the router delays randomly for between 0 and 518 MAX_RTR_STATUS_REQ_DELAY, and then sends up to MAX_RTR_STATUS_REQS 519 requests separated by at least RTR_STATUS_REQ_INTERVAL seconds. 521 These messages are sent to the router-to-routers multicast group, and 522 contain the Nonce, Signature, CGA and Timestamp options (at least) if 523 CGA is used. 525 5.2 Sending Router-to-Router Status 527 Router-to-Router Status messages MAY be sent periodically to other 528 routers to update the peers although the router's own reachability is 529 readily confirmed by periodic unsolicited RA reception. 531 When changes in configuration occur, the router SHOULD send up to 532 MAX_RTR_STATUS_REQS separated by MIN_DELAY_BETWEEN_RTR_STATUS after 533 an initial random delay of between 0 and MAX_RTR_STATUS_DELAY. 535 Responses to Status-Request messages MUST be sent. 537 This responding Status MUST be sent after a random delay of 0 to 538 MAX_RTR_STATUS_DELAY. Additionally, multicast Status Messages MUST 539 NOT be sent more regularly than once every 540 MIN_DELAY_BETWEEN_RTR_STATUS on average. 542 Responding Status messages MAY be sent to the unicast source address 543 of the Status-Request. If MIN_DELAY_BETWEEN_RTR_STATUS has elapsed 544 since the last multicast Status message, the response SHOULD be 545 multicast to the router-to-routers group. 547 When a router's configuration the steady state, it adopts a periodic 548 Router-to-Router Status advertisement interval as specificed by 549 R2RStatusInt. The Advertisements are randomly distributed by their 550 random delay upon advertisement of configuration changes. However, 551 routers SHOULD periodically pause an additional random delay between 552 0 and MAX_RTR_STATUS_DELAY, in order to re-spread Status messages. 554 6. Ranking Calculation 556 When receiving Router-to-Router messages containing the DetFRAO, a 557 router may maintain a list of Fast Routers and determines a relative 558 order amongst them. Changes in the relative order trigger changes in 559 Router Advertisement delays, so calculations for Rank need to be done 560 simply, and reliably on information available in each 561 Router-to-Router message with a Deterministic FastRA option. 563 Every Router-to-Router message is sent from a unicast link-local 564 address uniquely owned (on the link) by the router. Additionally, 565 every DetFRA Option contains a Rel Pref variable, which indicates the 566 configured preference of this router over others. 568 When receiving an Router-to-Router message containing a DetFRAO, the 569 Ranking Score is calculated by appending the Rank Identifier to the 570 Rel Pref value received in the DetFRAO. 572 The Rank Identifier is created by taking the final 24 bits of the 573 router's advertising link-local address and XOR'ing this value with 574 0xffffff. 576 As an example, using 32 bit unsigned integers, Ranking Score 577 computation is as follows: 579 RankID = ((ntohl(ll.s6_addr32[3]) & 0x00ffffff) ^ 0x00ffffff); 580 RScore = RankID | (relpref << 24); 582 A discussion of the reasoning behind this algorithm is provided in 583 Section 6.1. 585 The router with the lowest Ranking Score assumes the Rank: 1, and the 586 next lowest Rank: 2, etc. 588 In the situation where routers share the same Ranking Score and 589 Identifier, comparison of the routers' complete IPv6 link-local 590 address is made, in order to break ties. 592 The Ranking Identifier SHOULD be used to determine if a received 593 router's preference has changed, by checking if the Ranking 594 Identifier (as a lookup for the Source Address of the received 595 message) is already present in the list, and has a different Ranking 596 Score. In this case, the old entry is overridden by a more recent 597 advertisement, and list entries consequently are re-Ranked. 599 Note that during ranking calculation the advertised option's Rank 600 field is not consulted, although it may be checked subsequently. 602 6.1 Ranking Score Calculation Reasoning 604 Selecting the low-order 24 bits of the IPv6 address allows selection 605 of fastest router in the case of interface identifier creation from 606 MAC-48 addresses, without reference to manufacturer's 607 Organizationally Unique Identifier (OUI). Use of the XOR reverses 608 the order of the IPv6 address suffix so that EUI-64 based addresses 609 favour newer routers rather than older ones (unlike in [8] for the 610 case where OUIs are the same), and the relative preference overrides 611 all[7]. 613 Maintaining this structure (RelPref,Suffix) allows routers to check 614 not only the relative ordering of a router in the list on DetFRAO 615 reception, but allows even Router-to-Router messages which do not 616 contain DetFRAOs to update the validity of the Fast Router's existing 617 list entry by matching Rank Identifiers created from the RA's source 618 address (if this is a unique match). 620 7. Becoming a Fast Router 622 When a router wishes to be a Fast Router, it needs to check if anyone 623 else is acting as a Fast Router on this link. The router begins this 624 bootstrap process sending Status-Request messages containing a 625 DetFRAO, as defined in Section 5.1. 627 The Deterministic FastRA option in this case MUST contain the values: 629 Rank = BOOTSTRAP_RANK 630 Fixed Delay= BOOTSTRAP_DELAY 631 Separation = FastRASep 632 Rel Pref = FastRARelPref 634 Receivers will see this option and recognise that the requester is a 635 bootstrapping router. As defined in Section 8.3, the routers MUST 636 send a Status message responding to the request containing the DetFRA 637 option. This informs the requester of their own identity, Rank and 638 delays. 640 While collecting information about other routers, the bootstrapping 641 router MUST send Router-to-Router messages with the DetFRA option. 642 It MUST delay when sending responses to Router Solicitations by 0 to 643 MAX_RA_DELAY_TIME, and ensure that MIN_DELAY_BETWEEN_RAS separates 644 multicast advertisements. 646 After collecting this information, the new Fast Router calculates its 647 Rank and begins advertising as described in Section 9.1. 649 8. Receiving DetFRAO in ICMPv6 Router-to-Router 651 When receiving Router-to-Router messages with the DetFRAO option, the 652 router determines whether the transmitting router has been seen 653 before, and whether the transmitted Rank, Fixed Delay or Separation 654 have changed. If either the router is previously unseen or the 655 ranking or delay parameters have changed, the entry is inserted into 656 the list at the position indicated by the router's Ranking Scores. 658 If the delay or rank of the receiving router have changed, it 659 advertises its changed configuration as indicated in Section 9.1. 661 8.1 Receiving Bootstrap Deterministic FastRA Options 663 Deterministic FastRA routers or bootstrapping routers may receive 664 Router-to-Router messages containing a DetFRAO from a bootstrapping 665 router. 667 Routers SHOULD add such routers into their Fast Router List, in 668 anticipation of the router's arrival as a fully functioning Fast 669 Router. 671 Calculations for the Rank and Fixed delay of the bootstrapping Router 672 MUST NOT be made based on the values in the received Option, but on 673 the Ranking Score generated as described in Section 6. The Fixed 674 Delay calculated for the bootstrap router should be based on the best 675 ranked router's Separation, and the number of preceding routers. 676 Where the best ranked router is the bootstrapping router, this 677 router's Separation is used in Fixed Delay calculations. 679 8.2 Cleaning up old entries 681 If a Fast Router fails to receive multiple expected Router 682 Advertisement packets from a peer router, it SHOULD check if the peer 683 router is dead using either router or neighbour discovery . Such 684 mechanisms may be invoked upon non-reception of advertisements in 685 multiple retransmission intervals as advertised by the peer router, 686 or non-response to previous Router-to-Router Status-Request [4]. 688 If the peer is dead, the local router removes its entry from the 689 list, and re-advertises its own preference and distance as defined in 690 Section 9.1, if any change has occurred. 692 If one of a router's preceding routers reduces their Rank, so that it 693 conflicts with another router in the list, a router MAY send a 694 Router-to-Router Status-Request message containing DetFRAO after a 695 random delay between 0 and MAX_RTR_STATUS_REQ_DELAY, to establish 696 whether routers are still reachable. 698 8.3 Responding to Status-Requests with DetFRAO 700 A router MUST send a Deterministic FastRA option to a router which 701 sends a Router-to-Router Status-Request to it, if the router is 702 trusted. Delays to Status message are described in Section 5.2. 704 9. Sending DetFRAOs in ICMPv6 Router-to-Router 705 9.1 Sending RAs on Rank or Delay Change 707 In the case that a router's Rank, Fixed Delay or Separation change, 708 it MUST transmit a Router-to-Router Status message after a delay of 709 between 0 and MAX_RTR_STATUS_DELAY seconds and then 710 MAX_INITIAL_RTR_STATUS-1 messages each separated by 711 MIN_DELAY_BETWEEN_RTR_STATUS seconds (as described in Section 5.2. 713 If subsequent changes occur within this interval, it extends such 714 that three multicast Router-to-Router Status messages are sent with 715 the new configuration. This allows all peer routers to be updated in 716 a configuration interval of less than 12.5 seconds, if one set of 717 changes occurs. 719 9.2 Sending Advertisement Intervals 721 When a router advertises Deterministic Fast RA Options in 722 Router-to-Router messages, it MAY also indicate the frequency of its 723 periodic Router-to-Router Status messages using Advertisement 724 Interval Options in the message if there is room. 726 This option allows receiving routers to know how often to expect 727 these Router Advertisements, so that they can check that the 728 advertising router is active if expected packets are not received (as 729 in Section 8.2). 731 Routers MAY send DetFRAOs occasionally in their periodic unsolicited 732 Router Advertisements, in order to show hosts their FastRA 733 configuration. 735 10. Sending Fast Router Advertisements 737 Fast Router Advertisements are sent in response to Router 738 Solicitations. Where Deterministic Fast Router Advertisement Options 739 have been exchanged, and the routers know their fixed delays, Router 740 Advertisements are transmitted to the solicitor after delaying for 741 the Fixed Delay. 743 The number of FastRAs which may be sent at any time are determined by 744 trading off the reasonable arrival rate of Router Solicitations, and 745 the bandwidth and delay consumption caused by having all of these 746 packets transmitted successively[6]. 748 Determining good values for these outstanding FastRA bucket sizes is 749 not well described and may require further work. The values defined 750 in this document are approximations thought to be relatively harmless 751 based on other protocol defaults, at the time of writing. 753 10.1 Sending Unicast Fast RAs 755 The same resource DoS protection mechanisms for unicast FastRAs used 756 in the FastRA Draft are used in this document. Particularly, the 757 maximum token bucket size is limited to MaxFastRAs, which defaults to 758 MAXFASTRAS (10) [6]. 760 The FastRA draft places up to MaxFastRAs tokens into the bucket each 761 multicast Router Advertisement interval. 763 In order to provide more flexible replenishment of FastRA resources, 764 a router MAY place unicast FastRA tokens into the bucket at a rate of 765 one every FastRARefreshIval ms, where this defaults to 766 FASTRAREFRESHIVAL. 768 10.2 Sending Multicast Fast RAs 770 Multicast Fast RAs are not supported in the original FastRA draft 771 [6]. It does make sense for routers to provide fast multicast 772 responses to Router Solicitations, where such solicitations do not 773 create sufficient neighbour cache state to allow immediate unicast 774 response. 776 Also, if a router has multiple Unicast FastRAs delayed before 777 transmission, it may be possible to send a multicast FastRA instead 778 at the earliest of the delay times, in order to reduce the number of 779 responses required. 781 Multicast Fast RA transmission is managed separately to unicast 782 transmission, and has a token bucket with a size of MaxMCFastRAs 783 which defaults to MAXMCFASTRAS. 785 Tokens are placed into this bucket at a rate of one every 786 MIN_DELAY_BETWEEN_RAS. 788 11. Interaction with Other Routers 790 Not all routers will understand Deterministic FastRA options or want 791 to be in a Fast Router List. This section describes interactions 792 between Fast Routers and other routers. 794 11.1 Presence of Legacy Routers 796 Deterministic Fast Routers ignore the presence of Legacy Routers when 797 building their Fast Router List. Fast Routers rely upon these 798 routers undertaking random delays according to IPv6 Neighbour 799 Discovery[2]. 801 11.2 Ceasing to be a Fast Router 803 A router which no longer wishes to undertake FastRA may stop making 804 fast responses at any time, but SHOULD delay by a random value 805 between 0 and MAX_RTR_STATUS_DELAY, before sending 806 MAX_INITIAL_RTR_STATUS successive multicast Router-to-Router Status 807 messages. These messages MUST contain the DetFRA option with Rank 808 set to NOT_FAST_RTR_RANK and an advertised Fixed Delay of 809 NOT_FAST_RTR_DELAY. These multicast Router Advertisements SHOULD be 810 sent once every MIN_DELAY_BETWEEN_RTR_STATUS to the router-to-routers 811 group. 813 While a router advertises its Fixed Delay as NOT_FAST_RTR_DELAY, it 814 in fact reverts to the procedures defined in IPv6 Neighbour Discovery 815 [2]. 817 Routers receiving this option in a Router-to-Router message SHOULD 818 remove the router from the Fast Routers List, and recalculate 819 subsequent Ranks and delays of routers remaining in the list. 821 This may lead to peer routers' re-advertisement of new Ranks and 822 delays as described in Section 9.1. 824 11.3 Presence of Non Fast Routers 826 While a router may be able to understand and process DetFRAOs, it may 827 not wish to be a Fast Router. Routers which have completed 828 advertising their leaving of the Fast Routers List fall into this 829 category. 831 These routers SHOULD act like legacy routers, and ignore 832 Deterministic FastRA options as if they didn't understand them. 834 11.4 Presence of Incompatible Fast Routers 836 When routers wishing to undertake FastRA exist on the link but are 837 not trusted for inclusion in the Fast Routers List, two distinct sets 838 of routers may appear. 840 Each set may not trust another, and may instead have its own router 841 at each Rank. In this case, the IncompatibleFastRouters flag SHOULD 842 be set on the interface until the untrusted routers become trusted, 843 or cease being Fast Routers. 845 Each Fast Router which has the IncompatibleFastRouters flag MUST 846 attempt to inform its administrator about the misconfiguration. 848 12. Configuration Parameters 850 The following parameters are defined in this document: 852 FastRARelPref A parameter which controls the 853 ranking of Fast Routers. It sets 854 the advertised Rel Pref field in 855 the DetFRAO. Setting this value lower 856 betters the preference of the router. 858 Minimum: 0 859 Maximum: 255 860 Default: DEF_REL_PREF 862 FastRASep A parameter controlling the delay between 863 scheduling of Fast Router Advertisements 864 on adjacent routers in the Fast Routers 865 List. 866 (Units: milliseconds) 868 Minimum: 1 869 Maximum: 255 870 Default: DEF_SEP 872 MaxFastRAs The maximum bucket size for Unicast 873 FastRAs. 875 Minimum: 0 (not Fast RA) 876 Default: MAXFASTRAS 878 MaxMCFastRAs The maximum bucket size for Multicast 879 FastRAs. 881 Minimum: 0 (no Multicast Fast RA) 882 Default: MAXMCFASTRAS 884 R2RStatusInt The interval between Router-to-Router 885 Status messages while in steady state. 887 Minimum: MIN_DELAY_BETWEEN_RTR_STATUS 888 Default: DEF_DELAY_BETWEEN_RTR_STATUS 890 13. Protocol Constants 891 BOOTSTRAP_DELAY 500ms 892 BOOTSTRAP_RANK 254 893 DEF_SEP 50ms 894 DEF_REL_PREF 127 895 MAXMCFASTRAS 5 896 MAX_INITIAL_RTR_STATUS 3 897 MAX_RTR_STATUS_REQ_DELAY 1000ms 898 MAX_RTR_STATUS_REQS 3 899 MAX_RTR_STATUS_DELAY 500ms 900 MIN_DELAY_BETWEEN_RTR_STATUS 3 seconds 901 DEF_DELAY_BETWEEN_RTR_STATUS 15 seconds 902 NOT_FAST_RTR_DELAY 500ms 903 NOT_FAST_RTR_RANK 255 904 RTR_STATUS_REQ_INTERVAL 4 seconds 905 UCASTFASTRAREFRESHIVAL 400ms 907 14. IANA Considerations 909 The new ICMPv6 message type - Router to Router (with two codes) and a 910 new ICMPv6 'Deterministic Fast Router Advertisement Option' are 911 defined in this document. 913 The Router-to-Router message is suggested to be an Informational 914 ICMPv6 message and is defined in Section 4.1. 916 In order to provide a unique multicast address for routers wishing to 917 participate in router-to-rotuer configuration, it is suggested the 918 IANA supply the following Link-Local Scope multicast address: 920 FF02:0:0:0:0:0:0:12 Router-to-Routers Configuration 922 (DetFRAO) is defined in Section 4.2 of this document. It is 923 suggested that the option number 13 is used for the Type of this 924 option. 926 15. Security Considerations 928 The Router-to-Router message's use of the Neighbour Discovery option 929 format allows SEND options to be used to check the authenticity of 930 the messages sent from the peer router. 932 The authorization of a node to be a router is described by a 933 delegation chain advertised in a succession of Delegation Chain 934 Advertisement messages. When using SEND, routers MUST check that the 935 router from which they receive a DetFRAO is an authorized router from 936 that link, and that the router trusts the delegation service used to 937 sign this authorization [5]. 939 Where the Router-to-Router message is not trusted, but contains a 940 Deterministic FastRA Option, the router MUST NOT include the router 941 in its Fast Router List, but SHOULD set the IncompatibleFastRouters 942 flag on that interface. This will turn attempt to inform the 943 administrator of the configuration problem. 945 Where disjoint sets of routers each undertake FastRA (but don't trust 946 each other), they can choose the same delay timers for sending 947 FastRA. In the worst case this means that every FastRA sent will 948 collide with another RA. Administrative action is currently required 949 to fix this issue, but further work may establish if automated 950 robustness to this issue is desirable. 952 16. Acknowledgments 954 This work is based on and expands the FastRA internet-draft [6]. 956 17. Changes Since Last Revision 958 17.1 draft-daley-dna-det-fastra-00 to -01 960 Force Fastest Router to respond with no delay MUST instead of SHOULD. 962 Allow calculation based on advertised Separation in fastest router 964 Removed section about duplicate list entries. Working from 965 calculated rank only now. 967 Cleaned up references to Router Advertisement and Router-to-Router. 969 Removed Misleading SHOULD from Status-Request response 971 Removed capability to use Advertisement Interval in RA for R2R. 973 Removed entire section about hosts using DETFRAO. 975 Added configuration option for Router-to-Router Status Interval (15s 976 Def). 978 18. References 980 18.1 Normative References 982 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 983 Levels", BCP 14, RFC 2119, March 1997. 985 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 986 IP Version 6 (IPv6)", RFC 2461, December 1998. 988 [3] Conta, A. and S. Deering, "Internet Control Message Protocol 989 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 990 Specification", RFC 2463, December 1998. 992 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 993 IPv6", RFC 3775, June 2004. 995 [5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 996 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 997 (work in progress), April 2004. 999 [6] Kempf, J., Khalil, M. and B. Pentland, "IPv6 Fast Router 1000 Advertisement", draft-mkhalil-ipv6-fastra-02 (work in progress), 1001 October 2002. 1003 18.2 Informative References 1005 [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1006 Addressing Architecture", RFC 3513, April 2003. 1008 [8] "IEEE standard for local and metropolitan area networks - 1009 commmon specifications - Media access control (MAC) Bridges", 1010 ISO/IEC IEEE Std 802.1d, 1998. 1012 Authors' Addresses 1014 Greg Daley 1015 Centre for Telecommunications and Information Engineering 1016 Department of Electrical and Computer Systems Engineering 1017 Monash University 1018 Clayton, Victoria 3800 1019 Australia 1021 Phone: +61 3 9905 4655 1022 EMail: greg.daley@eng.monash.edu.au 1024 Brett Pentland 1025 Centre for Telecommunications and Information Engineering 1026 Department of Electrical and Computer Systems Engineering 1027 Monash University 1028 Clayton, Victoria 3800 1029 Australia 1031 Phone: +61 3 9905 5245 1032 EMail: brett.pentland@eng.monash.edu.au 1033 Erik Nordmark 1034 Sun Microsystems, Inc. 1035 17 Network Circle 1036 Mountain View, CA 1037 USA 1039 Phone: +1 650 786 2921 1040 EMail: erik.nordmark@sun.com 1042 Appendix A. State Diagram 1044 Below is a state diagram for Fast Router Advertisement. 1046 Legend: 1047 ------- 1048 FD : Fixed Delay 1049 TmrSet : Set Timer value(milliseconds) 1050 DetFRAO: Deterministic Fast RA Option 1051 RSResp : Response to Router Solicitation 1052 S : Router-to-Router Status 1053 SR: : Router-to-Router Status-Request 1054 TmrExp : A timer expiry 1055 TmrExp4: Fourth Timer Expiry(resets counter) 1056 TmrExp,SR /-\ /-\ Recv: TmrExp,S /-\ 1057 TmrSet:4K | | | | DetFRAO TmrSet:3K| | 1058 * \V \V \V 1059 /----\ /-----\TmrExp4 /---------\ /-------\ 1060 |Not |-------------->|Boot |------->| Changed |-------->|Adv | 1061 |Fast|TmrSet: |Strap| | RtrSet |Sort List|Change | 1062 \----/[0,1000] \-----/ 7\---------/Calc:FD \-------/ 1063 ^ RSResp ^\ / ^ ^ TmrSet: ^\ \ 1064 | Delay: | | / | | [0,500] | | \ 1065 | [0,500] \-/ / Option| | \-/ \ 1066 | | Change| | RSResp \ 1067 | Pref \ or Add| | Delay: FD | 1068 | TmrExp,RA /-\ Change\ | |List / 1069 \ TmrSet:3K | | \ | |Entry / 1070 Stop \ \V \ | |Timeout / 1071 FastRA\ /------\ /-------------\ / 1072 \------|Adv | | Steady |<------------/ 1073 |Leave |<-------------| State | TmrExp4 1074 \------/Leave List \-------------/ 1075 RSResp ^\ TmrSet:[0,500] ^\ RSResp 1076 Delay: | | | | Delay: FD 1077 [0,500] \-/ \-/ 1079 Intellectual Property Statement 1081 The IETF takes no position regarding the validity or scope of any 1082 Intellectual Property Rights or other rights that might be claimed to 1083 pertain to the implementation or use of the technology described in 1084 this document or the extent to which any license under such rights 1085 might or might not be available; nor does it represent that it has 1086 made any independent effort to identify any such rights. Information 1087 on the procedures with respect to rights in RFC documents can be 1088 found in BCP 78 and BCP 79. 1090 Copies of IPR disclosures made to the IETF Secretariat and any 1091 assurances of licenses to be made available, or the result of an 1092 attempt made to obtain a general license or permission for the use of 1093 such proprietary rights by implementers or users of this 1094 specification can be obtained from the IETF on-line IPR repository at 1095 http://www.ietf.org/ipr. 1097 The IETF invites any interested party to bring to its attention any 1098 copyrights, patents or patent applications, or other proprietary 1099 rights that may cover technology that may be required to implement 1100 this standard. Please address the information to the IETF at 1101 ietf-ipr@ietf.org. 1103 Disclaimer of Validity 1105 This document and the information contained herein are provided on an 1106 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1107 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1108 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1109 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1110 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1111 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1113 Copyright Statement 1115 Copyright (C) The Internet Society (2004). This document is subject 1116 to the rights, licenses and restrictions contained in BCP 78, and 1117 except as set forth therein, the authors retain all their rights. 1119 Acknowledgment 1121 Funding for the RFC Editor function is currently provided by the 1122 Internet Society.