idnits 2.17.00 (12 Aug 2021) /tmp/idnits22336/draft-fu-cxtp-gist-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 460. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 163: '...stream identifier MUST NOT be used for...' RFC 2119 keyword, line 191: '...ession identifier MUST NOT be used for...' RFC 2119 keyword, line 217: '... that neighbor, associations SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 362 has weird spacing: '...-domain conte...' -- 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 (March 6, 2006) is 5919 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 4067 (ref. '1') == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '2') ** Obsolete normative reference: RFC 2960 (ref. '3') (Obsoleted by RFC 4960) == Outdated reference: A later version (-01) exists of draft-ietf-pana-cxtp-00 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft Univ. Goettingen 4 Expires: September 7, 2006 J. Loughney 5 Nokia 6 H. Peters 7 Univ. Goettingen 8 March 6, 2006 10 Context Transfer Using GIST 11 draft-fu-cxtp-gist-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 7, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The CXTP specification uses basic SCTP as transport for CXTP message 45 exchanges between a mobile node's previous and new access routers. 46 It also relies on a pre-established IPsec ESP transport mode tunnel. 47 This document discusses two alternative approaches based on 48 "persistent" associations using either SCTP streams feature or GIST 49 protocol. While both approaches reduce context transfer latency 50 during handovers, GIST also offers more flexible transport and richer 51 security properties. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Use of SCTP multiple streams . . . . . . . . . . . . . . . 4 59 3.2. Use of GIST as alternative transport . . . . . . . . . . . 5 60 3.3. Applicability scenario . . . . . . . . . . . . . . . . . . 5 61 4. Context Transfer NSLP . . . . . . . . . . . . . . . . . . . . 6 62 5. Further Discussions . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. Advantages & disadvantages of GIST transport . . . . . . . 7 64 5.2. Triggers for Context Transfer . . . . . . . . . . . . . . 8 65 5.3. Interworking with NSIS QoS and NAT/FW NSLP protocols . . . 8 66 5.4. GIST MA bootstrapping, maintenance and inter-domain 67 context transfer issues . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Intellectual Property and Copyright Statements . . . . . . . . . . 12 76 1. Introduction 78 The Context Transfer Protocol (CXTP) [1] provides a way to improve 79 performance for mobile nodes moving between networks by transferring 80 state context from the previous access router (pAR) to the new access 81 router (nAR) across an IP based network. For each of these context 82 transfers, a new SCTP association is maintained. This document 83 describes alternative potentials based on "persistent" associations 84 between neighboring ARs to reduce the context transfer handover 85 latency due to individual association setup. Similar to the multi- 86 streaming features in the Stream Control Transmission Protocol 87 (SCTP), the General Internet Signaling Transport (GIST) [2] provides 88 the functionality of multiplexing traffic between two peers into a 89 single association, known as messaging association (MA). This 90 technique allows reuse of an existing (secure) communication channel 91 for context transfer between a pAR and any nAR. In addition, the 92 proposed approach could seamlessly interwork with PANA and NSIS 93 protocols, and minimize the involvement of mobile hosts. Such a 94 communication channel is soft state based, which allows an efficient 95 and secure acquisition of state information for roaming devices as 96 well as flexible selection of underlying transport mechanisms and 97 automatic release of unused resources. 99 2. Terminology 101 Most of the terms used are defined in the CXTP [1], SCTP [3] and GIST 102 [2] specifications. Below is a list of acronyms used in this 103 document. 105 o AR Access Router 106 o pAR previous Access Router 107 o nAR new Access Router 108 o CTAR CXTP Activate Request message 109 o CTAA CXTP Activate Acknowledge message 110 o CTD CXTP Data message 111 o CTReq CXTP Request message 112 o CTDR CXTP Data Reply message 113 o CTC CXTP Cancel message 114 o MA GIST messaging association 115 o MRS GIST message routing state 116 o MRI GIST message routing information 118 3. Design Overview 120 CXTP message exchange can be divided into two groups: MN-AR and AR-AR 121 communication. This document mainly addresses the issue of 122 communications between entities within the network. These entities 123 can be either nodes supporting access control or a PEP (Policy 124 Enforcement Point) function, access routers or any other types of 125 nodes. The context transferred can be anything related to mobile 126 nodes' end-to-end communications, such as AAA, header compression, 127 QoS, Policy, and possibly sub-IP protocols and services such as PPP, 128 as supported by RFC 4067 [1]. 130 An access router will likely be able to know its neighboring access 131 routers' address information (either by static configuration or can 132 learn that information by other means), associations between them can 133 be either established on demand or pre-established depending on the 134 policies. An association is a unidirectional context transfer 135 channel. 137 If a mobile node (MN) requests for context transfer, or an AR 138 predicts an MN is likely to move to another AR, context transfer 139 message exchanges can be made upon the corresponding association. 140 This can be done by either of the following approaches, alternative 141 to the one specified in [1]. 143 3.1. Use of SCTP multiple streams 145 SCTP allows to send several messages over a single association using 146 multiple streams. Each stream is associated with a unique stream 147 identifier at both endpoints. Multiple streams prevent Head of Line 148 Blocking (HLB); if retransmission occurs at one stream, messages of 149 the other streams of the same association are not delayed. 151 During establishment of the SCTP association, the pAR and the nAR 152 will negotiate in the INIT and INIT-ACK phase about the number of 153 streams to use, according to section 5.1.1 of [3]. After the 154 association is initialized, the valid outbound stream identifier 155 range for either endpoint shall be between 0 and min (local number of 156 outbound streams, remote maximum inbound streams) - 1. Once a SCTP 157 association is established, there is no need to perform additional 158 negotiation to use multiple streams. 160 A context identified by a feature profile type (FPT) is assigned an 161 incrementing outbound stream identifier, the context is encoded using 162 CXTP message format and finally sent over a pre-established SCTP 163 association. The same stream identifier MUST NOT be used for 164 concurrent context transfers. The stream identifier is reset when it 165 reaches the range limit. 167 3.2. Use of GIST as alternative transport 169 The GIST protocol being developed by the NSIS working group for 170 general signaling transport is independent on the underlying 171 transport protocol, such as UDP, TCP, TCP over TLS or SCTP. In this 172 section we describe the overall approach on how to reuse GIST for 173 general context transfer between two entities within the network that 174 support forwarding of a mobile node's IP traffic. 176 The CXTP messages exchanged between the entities within the network 177 are encapsulated as a NSIS signaling application running above GIST. 178 This way, features like soft state refreshes and messaging state 179 reuse, transport protocol flexibility and ensured reliable and secure 180 transport will allow CXTP to be applicable in many operational 181 environments. 183 Typically, GIST operates with a path-coupled discovery procedure to 184 determine the signaling nodes. As the target node addressing 185 information here is already known in advance and the peers 186 communicate in an end-to-end fashion, there is no need to perform 187 GIST path-coupled discovery and maintaining GIST message routing 188 state (MRS). 190 In GIST, a 32-bit session identifier is assigned to each context 191 transfer randomly. The same session identifier MUST NOT be used for 192 concurrent context transfers. 194 Note, when SCTP is used for GIST [4], multiple different sessions can 195 be further aggregated over a common GIST session, by using different 196 SCTP streams for each session. This will be useful, for instance, 197 when the sessions are used by different corresponding hosts. 199 3.3. Applicability scenario 201 Figure 1 illustrates an example scenario for CXTP using GIST. The 202 scenario also applies for persistent SCTP associations. Non- 203 established associations are denoted with brackets. Theoretically, 204 an AR can maintain (messaging) associations between itself and any 205 number of its neighboring ARs. Assume there is an MN moving from AR2 206 to AR3, then to AR5 and finally AR6. As there is already an existing 207 association (A3) between AR2 and AR3, AR2 can transfer context of 208 this MN to AR3 through A3 by exchanging CXTP data messages over a 209 specified transport protocol. As there exists no association between 210 AR3 and AR5, a new association will establish A5 on demand when 211 either AR3 or AR5 learns MN's movement or intention to move from AR3 212 to AR5. Note, GIST can negotiate transport protocol and security 213 properties between these ARs, allowing maximal flexibility and 214 applicability. After A4 is established, AR3 can perform CXTP over it 215 as usual. If for some (long) period of time AR2 does not anticipate 216 any need for transferring context to any neighboring AR, nor it 217 receives any CXTP message from that neighbor, associations SHOULD be 218 released, avoiding waste of network resources. 220 +-----+ (A4) +-----+ A7 +-----+ 221 | AR2 |---------------------+ AR4 +---------| AR6 | 222 +-----+ +-----+ +-----+ 223 / \\ | A8 ^^ | 224 A1 / \\ A3 A6| .=========' |(A10) 225 / VV | // | 226 +-----+ A2 +-----+ (A5) +-----+ A9 +-----+ 227 | AR1 +---------+ AR3 +============>| AR5 |---------| AR7 | 228 +-----+ +-----+ +-----+ +-----+ 230 Figure 1: An example scenario for CXTP using GIST 232 4. Context Transfer NSLP 234 A new NSIS signaling application type (NSLP ID TBD), "CXTP NSLP", is 235 defined for exchanging encapsulated CXTP messages (CTD, CTReq, CTDR 236 and CTC) between pAR and nAR and possibly creating GIST MAs. Each 237 CXTP NSLP message contains a common NSLP header (as defined in [2]), 238 followed by one of these 4 types of CXTP messages defined in [1]). 239 For example, the CXTP NSLP CTD message is described in Figure 2: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | NSLP message type = CXTP NSLP | reserved | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |Vers.|Type= CTD|V| Reserved | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 ~ MN's Previous IP Address ~ 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 ~ Previous (New) AR IP Address ~ 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Sequence Number | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | MN Authorization Token | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Requested Context Data Block (if present) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Next Requested Context Data Block (if present) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | ........ | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 2: Encapsulated CXTP CTD message 265 GIST discovery as defined in [2] is modified as follows: 266 o GIST query messages are used to create MAs between known ARs, thus 267 there is no need to include a router alert option; 268 o there is no need to create or maintain MRSs upon receipt of a GIST 269 response or confirm message; 270 o MA-Hello messages are used to keep existing MAs alive, its timer 271 value may be smaller than standard GIST MA lifetime; 272 o GIST error messages are used to report an unknown CXTP NSLP 273 message type (i.e., a new error code needs to be introduced). 275 CXTP messages between MN and pAR and between MN and nAR are specified 276 in CXTP [1] as ICMP messages and not modified here. 278 5. Further Discussions 280 5.1. Advantages & disadvantages of GIST transport 282 Advantages: 283 o "Persistent" associations using a soft state approach reduces 284 session setup latency and requires lower state maintenance cost at 285 access routers. When the association is not used for a long 286 period of time, it will be automatically removed; 288 o GIST offers more flexible and dynamic selection of underlying 289 transport protocol, including richer security properties. For 290 instance, this allows to deploy CXTP using TCP/TLS with SCTP 291 "multiple stream"-like feature; 292 o NSIS-aware networks can easily deploy CXTP NSLP. This naturally 293 offers interworking benefits with other NSLPs, such as QoS NSLP or 294 NAT/Firewall NSLP. 295 Disadvantages: 296 o Several features of GIST are not used, such as peer discovery and 297 message routing over a chain of GIST nodes. Thus, it seems a 298 simplified/light-weight version of GIST may be used instead of a 299 full-fledged GIST. 301 5.2. Triggers for Context Transfer 303 There are many possibilities to trigger Context Transfer using GIST, 304 some of which are listed below: 305 o Using the triggers defined in CXTP [1], such as MN-controlled or 306 network-controlled; 307 o Using some kind of (light-weight) NSIS signaling between the MN 308 and the correspondent node as trigger; 309 o If the mobile node is using NSIS signaling for other purposes 310 (middlebox configuration, QoS signaling), ARs could notice MN 311 attachment by MN's discovery messages; 312 o Upon the completion of authentication, e.g., PANA discovery and 313 handshake in PANA mobility optimization [5]; 314 o Upon a successful transfer of PANA context [6]. 316 These triggers can be categorized to either 1) triggers perceived at 317 the nAR or 2) triggers perceived at the pAR. Upon a trigger of 318 category 1), the nAR needs to send a CT-Req over the GIST MA to the 319 pAR, and the latter in turn responds back with a CTD; then an 320 optional CTDR can be sent from the pAR to the nAR. Upon a trigger of 321 category 2), the pAR simply needs to send a CTD over the GIST MA to 322 the nAR. 324 In either case, if a desired CTD message is not received within a 325 certain period of time (or due to other reasons, e.g., the nAR senses 326 that the MN moves out of its coverage before receiving a CTD), the 327 nAR may issue a CTC to cancel the context transfer using the GIST MA. 329 5.3. Interworking with NSIS QoS and NAT/FW NSLP protocols 331 CXTP, especially its use over GIST, can reduce the overhead for the 332 last hop communication between an MN and its AR. Using CXTP/GIST, 333 the AR states related to MN-CN end-to-end communications are 334 transferred seamlessly, without the need to reestablish from the MN. 336 Figure 3 illustrates an example where QoS NSLP signaling is desired 337 from the MN to the CN. The case of NAT/FW NSLP is similar. Before 338 the handover, QoS NSLP is applied, involving steps 1)-4) and finally 339 reaches CN. Then the MN moves to the nAR, which maintains a (secure) 340 GIST MA with the pAR. Some trigger as described in previous 341 subsection (e.g., either (1) or (1a) or another event) then starts 342 the CXTP/GIST, which results in QoS NSLP state successfully to be 343 transferred from the pAR to the nAR. Once the CXTP/GIST is 344 accomplished, the nAR can then act on behalf on the MN and 345 (re)establish the QoS NSLP state along the path towards the CN using 346 QoS NSLP signaling. 348 +-----+ (2) +-----+ 349 ~| pAR |~~~~~~~| R1 | 350 (1)~ +--*--+ +-----+~ (3) 351 ~ * ~ 352 ~ *(CXTP/GIST) ~+----+ (4) +----+ +----+ 353 +----~-+ * | R3 +-----+ .. +--+ CN | 354 | MN | * (3a)/+----+ +----+ +----+ 355 +------+\ \*/ / 356 (1a)\+--*--+ (2a) +-----+/ 357 | nAR +-------+ R2 | 358 +-----+ +-----+ 360 Figure 3: Interworking with NSIS QoS NSLP 362 5.4. GIST MA bootstrapping, maintenance and inter-domain context 363 transfer issues 365 CXTP/GIST requires maintaining a GIST MA between neighboring ARs. In 366 cases where ARs belonging to different administrative domains do not 367 have a pre-established GIST MA, or an AR is newly added or rebooted, 368 GIST MAs need to be established on demand in a secure fashion. 369 Further versions of this document will discuss this aspect in more 370 detail. 372 6. Security Considerations 374 The security considerations of both [2] and [1] apply. "Persistent" 375 SCTP associations are more vulnerable against blind masquerade 376 attacks against the SCTP Verification Tag. Further security analysis 377 is needed to consider additional security vulnerabilities. 379 7. Acknowledgements 381 Kwok-Ho Chan, Hui Deng, James Kempf, Rajeev Koodli, and Hannes 382 Tschofenig provided valuable comments. 384 8. References 386 8.1. Normative References 388 [1] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context 389 Transfer Protocol (CXTP)", RFC 4067, July 2005. 391 [2] Schulzrinne, H. and R. Hancock, "GIST: General Internet 392 Signaling Transport", draft-ietf-nsis-ntlp-09 (work in 393 progress), February 2006. 395 [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 396 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 397 "Stream Control Transmission Protocol", RFC 2960, October 2000. 399 8.2. Informative References 401 [4] Fu, X., "General Internet Signaling Transport (GIST) over SCTP", 402 draft-fu-nsis-ntlp-sctp-01 (work in progress), February 2006. 404 [5] Forsberg, D., "PANA Mobility Optimizations", 405 draft-ietf-pana-mobopts-01 (work in progress), October 2005. 407 [6] Bournelle, J., "Use of Context Transfer Protocol (CXTP) for 408 PANA", draft-ietf-pana-cxtp-00 (work in progress), October 2005. 410 Authors' Addresses 412 Xiaoming Fu 413 University of Goettingen 414 Institute for Informatics 415 Lotzestr. 16-18 416 Goettingen 37083 417 Germany 419 Email: fu@cs.uni-goettingen.de 421 John Loughney 422 Nokia Research Center 423 Itamerenkatu 11-13 424 Helsinki 00180 425 Finland 427 Email: john.loughney@nokia.com 429 Henning Peters 430 University of Goettingen 431 Institute for Informatics 432 Lotzestr. 16-18 433 Goettingen 37083 434 Germany 436 Email: hpeters@math.uni-goettingen.de 438 Intellectual Property Statement 440 The IETF takes no position regarding the validity or scope of any 441 Intellectual Property Rights or other rights that might be claimed to 442 pertain to the implementation or use of the technology described in 443 this document or the extent to which any license under such rights 444 might or might not be available; nor does it represent that it has 445 made any independent effort to identify any such rights. Information 446 on the procedures with respect to rights in RFC documents can be 447 found in BCP 78 and BCP 79. 449 Copies of IPR disclosures made to the IETF Secretariat and any 450 assurances of licenses to be made available, or the result of an 451 attempt made to obtain a general license or permission for the use of 452 such proprietary rights by implementers or users of this 453 specification can be obtained from the IETF on-line IPR repository at 454 http://www.ietf.org/ipr. 456 The IETF invites any interested party to bring to its attention any 457 copyrights, patents or patent applications, or other proprietary 458 rights that may cover technology that may be required to implement 459 this standard. Please address the information to the IETF at 460 ietf-ipr@ietf.org. 462 Disclaimer of Validity 464 This document and the information contained herein are provided on an 465 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 466 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 467 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 468 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 469 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 470 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 472 Copyright Statement 474 Copyright (C) The Internet Society (2006). This document is subject 475 to the rights, licenses and restrictions contained in BCP 78, and 476 except as set forth therein, the authors retain all their rights. 478 Acknowledgment 480 Funding for the RFC Editor function is currently provided by the 481 Internet Society.