idnits 2.17.1 draft-mccann-mobileip-limiph-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'Bradner96' is mentioned on line 13, but not defined -- Looks like a reference, but probably isn't: '1' on line 53 == Missing Reference: 'Perkins00' is mentioned on line 56, but not defined == Missing Reference: 'Johnson00' is mentioned on line 56, but not defined == Missing Reference: 'Dommety00' is mentioned on line 60, but not defined == Outdated reference: A later version (-03) exists of draft-calhoun-mobileip-proactive-fa-01 -- Possible downref: Normative reference to a draft: ref. 'Kempf00' -- Possible downref: Non-RFC (?) normative reference: ref. 'TIA' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-3gwireless-ext-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-mobileip-3gwireless-ext (ref. 'Xu00') Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Peter J. McCann 3 Internet Draft Tom Hiller 4 Document: draft-mccann-mobileip-limiph-00.txt Lucent Technologies 5 Category: Standards Track August, 2000 7 Low Interruption Mobile IP Handoff 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [Bradner96]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Abstract 30 There are currently a number of proposals for different mechanisms 31 intended to reduce the overhead of IP mobility management. Generally 32 speaking, the goal of these proposals is twofold: first, to reduce 33 the latency or interruption due to handoffs; and second, to reduce 34 the signaling load on the Mobile IP Home Agent (and Correspondent 35 Nodes, for the case of Mobile IPv6). These techniques are meant to 36 improve the performance of real-time applications like voice or 37 video over IP over wireless networks. By minimizing the period of 38 interruption during a handoff from one point of attachment to 39 another, the proposals attempt to minimize packet loss when these 40 events occur. This draft argues that the best solution to this 41 problem is a "transparent" one that requires no changes to the 42 Mobile IP clients in mobile nodes and that gives control over 43 routing functionality to the operator of a wireless network. We 44 review some of the existing proposals and describe in detail a new 45 proposal that can provide for low interruption handoffs in a more 46 transparent manner. 48 2. Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 52 this document are to be interpreted as described in RFC-2119 [1]. 54 3. Introduction 56 The Mobile IP protocol [Perkins00, Johnson00] provides support for 57 wide-area mobility. Invoking the entire Mobile IP protocol 58 including a round-trip to an HA on every mobility event may be too 59 slow for latency-sensitive applications. Both the anchor handoff 60 (ANCH) draft [Dommety00] and the proactive foreign agents (PFA) 61 draft [Kempf00] purport to provide support for fast handoffs in a 62 wireless environment. This draft agrees with the basic philosophy 63 of ANCH that the complexity of a static hierarchy is not necessary 64 for providing fast handoffs. However, it also agrees with PFA that 65 a pro-active approach, based on link-layer handoff information, is 66 better able to meet the stringent requirements of a very fast 67 handoff suitable for voice-over-IP applications. In fact we take 68 this philosophy even further and argue that for many networks, a 69 completely pro-active approach is sufficient to complete a handoff 70 without any assistance from the mobile node's layer-3 software. 71 This approach relies on layer-2 authentication to guarantee that 72 packets are not mis-routed by malicious mobile nodes. 74 4. Network Reference Model 76 We define the term "domain" to mean the region within which a mobile 77 node may acquire and continuously make use of a care-of address 78 (COA). To resolve any ambiguity, we mean the care-of address 79 visible to the HA. We assume that each COA is associated with 80 exactly one FA (for IPv6, we use the term FA to refer to some unique 81 last-hop router) somewhere in the domain. 83 MNs connect to FAs via direct, link-layer connections. Because an 84 FA is directly connected to the link-layer, it may obtain link-layer 85 information such as power measurements that might indicate the 86 necessity of a handoff to a new FA. The FA can also gain assurance 87 of the MN's identity through link-layer authentication, and can 88 authenticate the stream of traffic coming from the MN, including any 89 power measurements or other indications used for handoff. The FA 90 also terminates some layer-2 protocol. This issue is revisited at 91 the end of the draft. 93 Consider a handoff that must take place from FA 1 to FA 2. We refer 94 to FA 1 as the "source FA" and FA 2 as the "target FA." There is no 95 need for the link technology on FA 1 and 2 to be the same. However, 96 the acquisition of a "trigger" to signal that a handoff is necessary 97 may be more difficult when the technologies differ. We assume that 98 any such trigger will be sufficient for FA 1 to derive the identity 99 (IP address) of FA 2. If such a trigger is not available or if the 100 MN decides on its own that a handoff is to take place, then one of 101 the FAs can often still derive the identity (IP address) of the 102 other from link-layer messages. We call the FA that does such a 103 derivation the "initiating FA". If such a derivation is possible 104 then we assume that there also exists a trust relationship and 105 security association between FA 1 and FA 2. This is analogous to 106 the relationships that existing cellular operators maintain between 107 neighboring systems that are capable of handing off to one another. 109 In summary, this draft covers a handoff scenario not addressed by 110 the existing drafts: that of a pro-active, network-controlled, 111 anchor-chained handoff. 113 5. Handoff Operation 115 See Figure 1 for an overview of handoff. A MN connects (1) to FA 1 116 through link-layer establishment. It receives an advertisement, 117 acquires a COA, and sends (2) a registration request to its HA and 118 to any CNs that are capable of receiving them. We assume that some 119 "attendant registration protocol" runs at layer-3 during this 120 process in order to authenticate the MN's layer-3 identity (for IPv4 121 this is Mobile IP itself - we assume that the 'R' bit will always be 122 set in advertisements and that the MN-AAA extension is used). Now, 123 assume that FA 1 gets a link-layer indication (3) that a handoff to 124 FA 2 is required, and begins whatever link-layer procedure is 125 necessary to effect a handoff. 127 ____ 128 | HA | 129 |____| 130 > 131 / 132 /(2) 133 / (4a) 134 ____/_ --------> ______ 135 | | (4b) | | 136 | FA 1 | <-------- | FA 2 | 137 | | (5a) | | 138 |______| <-------- |______| 139 ^ (5b) 140 | --------> 141 |(1) 142 | 144 __| __| 145 | | | | 146 |MN| -------> |MN| 147 |__| (3) |__| 149 Figure 1: Overview of Handoff Operation 151 If FA 1 is the initiating FA, it immediately sends (4a) a Binding 152 Update to FA 2. The Binding Update has the Home Address field set 153 to FA 1's address, and has the Care-of Address field set to FA 2's 154 address. The Binding Update contains link-layer identification 155 information for the MN in a special extension given in Section 7. 156 This enables FA 2 to match up the newly handed-off link-layer 157 connection with the Binding Update. The FA 2 then responds (4b) 158 with a Binding Acknowledge to the source address/port of the Binding 159 Update. Each of these messages is authenticated with the 160 appropriate security association between FA 1 and FA 2. 162 If FA 2 is the initiating FA, then step 4 is skipped, and we proceed 163 directly to step 5. In either case, FA 2 sends (5a) a Registration 164 Request to FA 1. The Request is sent to the address copied from the 165 Home Address field of the Binding Update, if one was received from 166 an initiating FA 1, or from link-layer messages otherwise. The 167 Registration Request has the G and T bits set to 1, and has the Home 168 Address field set to zero. The Home Agent Address field is set to 169 FA 1's address and the Care-of Address field is set to FA 2's 170 address. The Registration Request also contains link-layer 171 identification information for the MN in a special extension. This 172 enables FA 1 to match the request to some existing link-layer 173 connection. The extension also contains a Key field that will be 174 used for GRE packet demultiplexing. The FA 1 then responds (5b) 175 with a Registration Reply. 177 After executing step 5, FA 1 and FA 2 have established a bi- 178 directional tunnel for IP packets. This tunnel uses GRE 179 encapsulation and makes use of the Key field for packet 180 demultiplexing. If packets arrive for the MN's COA at FA 1, they 181 should be forwarded to FA 2 and delivered to the MN. When using FA- 182 located COA FA 1 should strip out the care-of address before 183 forwarding to FA 2. If packets are sent from the MN to FA 2, they 184 should be reverse tunneled to FA 1 and then routed as appropriate, 185 with FA 1 placing its COA on the packets if using FA-located COA. 187 FA 2 MAY send Agent Advertisements (or for IPv6, Router 188 Advertisements) to the MN. If it does so these are inserted into 189 the packet stream and delivered to the MN. Any packets from the MN 190 addressed directly to FA 2 MUST NOT be tunneled to FA 1 but will 191 rather be received and processed by FA 2. This will enable the MN 192 to carry out the attendant registration protocol with FA 2. After 193 successfully registering with the attendant, the MN's packets may be 194 directly routed to the Internet from FA 2 without being reverse 195 tunneled to FA 1, assuming that the MN is using a co-located COA and 196 that there is no problem of ingress filtering when such packets 197 originate from FA 2. When using FA-located COA, or when the MN has 198 requested a reverse tunnel back to its HA, FA 2 must wait for a 199 properly formed registration reply from a home agent before directly 200 routing such packets. We allow that the registration reply may or 201 may not be "piggybacked" on the layer-3 attendant registration 202 protocol so there may or may not be any delay between the 203 occurrences of these two events. 205 Although the MN has now completed its registration with FA 2, there 206 may still be packets in flight towards FA 1. For this reason FA 1 207 should continue to forward any received packets for the MN to FA 2 208 until the agreed Lifetime for the FA 1 to FA 2 tunnel has expired. 209 This Lifetime should be set large enough to allow the MN time to 210 register with FA 2, but not so large that it places an unreasonable 211 burden on FA 1 and FA 2 to maintain the unused state information. 212 The proper Lifetime is a parameter that should be chosen by the 213 network operator(s) depending on their particular network 214 characteristics. 216 6. Reducing Signaling Traffic 218 Section 5 above provides for a fast handoff between neighboring FAs 219 but, unlike hierarchical schemes, does nothing to reduce the 220 signaling traffic to the HA. It may be the case that FA handoffs do 221 not happen very frequently and that there is therefore no need to 222 address this problem. However, very small FA coverage areas, as 223 well as rapid "ping-pong" motion between FA coverage areas, may lead 224 to a high rate of Registration Requests from MNs which can produce 225 too much load on the air interface, too much load on HAs, or too 226 many lost in-flight packets. We note that even the hierarchical 227 schemes can suffer from these problems for those nodes that are 228 sitting on the boundary between two hierarchical domains. In this 229 section we outline a non-hierarchical approach to addressing this 230 problem. 232 6.1 Anchor Chaining 234 First, note that the requirement that FA 2 send Agent Advertisements 235 was a "MAY" and not a "MUST". We allow that FA 2 may never send an 236 advertisement or may wait for an undetermined amount of time before 237 sending one. By delaying the advertisement, FA 2 can make sure that 238 the MN has been within its coverage area for a certain minimum 239 amount of time before initiating the costly registration process. 240 Because the mobility event can be completely hidden during this time 241 from the MN's Mobile IP client implementation, no over-the-air 242 messages other than the link-layer signaling required for handoff 243 need to be sent until FA 2 decides to send an Agent Advertisement. 244 Note that if FA 2 refrains from sending such advertisements for a 245 long time it must continue to renew the Lifetime of the tunnel to FA 246 1. Also, the MN must continue to receive Advertisements from FA 1 247 so that it may renew its overall Mobile IP registration as needed. 248 For this reason, we require that FA 1 continue to send 249 Advertisements through the tunnel towards FA 2 but allow that FA 2 250 may filter out such Advertisements if it wishes to force the MN to 251 register directly with FA 2. 253 If the MN moves to a new FA, say FA 3, before it has registered with 254 FA 2, then FA 2 will send a Binding Update to FA 3 (assuming FA 2 is 255 the initiating FA). Because FA 2 is maintaining no layer-3 state 256 for the MN, it may optionally include FA 1's address as the Home 257 Address in the Binding Update, if it knows that FA 1 and FA 3 share 258 a direct security association. That way FA 3 can register directly 259 with FA 1, and packets will be tunneled directly between FA 1 and FA 260 3. If no such knowledge exists at FA 2, then it can send the 261 Binding Update as outlined in Section 5, using its own address. 262 This creates a chain of tunnels from FA 1 to FA 2 to FA 3. 264 To prevent such chains from becoming unreasonably long, some FA 265 along the chain should send an Agent Advertisement that is not 266 filtered out by the downstream FAs. Note that any FA along the 267 chain may do so and the time at which each agent decides to send 268 Advertisements may be given by some probability distribution that is 269 chosen to provide optimal performance. When the MN receives such an 270 Advertisement it may detect that it has moved and will then send a 271 Registration Request. This Request will be forwarded backwards to 272 the FA that sent the Advertisement and will be processed by that FA, 273 according to the forwarding rules outlined in Section 5. This 274 allows the MN to register with a "recently visited" FA, even though 275 it may have already moved several hops away. Also note that an 276 Advertisement may be sent to an MN that is directly attached to FA 277 2, then the MN may move away to FA 3, and finally the MN may 278 register with FA 2 even though its current point of attachment is FA 279 3. This allows for the chains to be cut even in the presence of 280 very rapid motion. 282 Steps must be taken to ensure that the MN retains its COA while in 283 such an anchor-chained situation. For an FA-located COA this is 284 straightforward. For an MN-located COA, the MN may continue to 285 interact with any address allocation agent that may exist on FA 1's 286 network, because all packets from the MN are reverse tunneled to FA 287 1 unless they are addressed directly to FA 2. This includes any 288 broadcast or multicast packets. 290 6.2 Ping-Pong Motion 292 Some link-layers are subject to rapid motion of MNs between two FAs. 293 For example, even though link-layer power measurements may indicate 294 to FA 1 that a handoff to FA 2 is necessary, the MN may fail to 295 attach to FA 2 and return almost immediately to FA 1. 297 If a given link-layer is subject to such "ping-pong" behavior, then 298 FA 2 SHOULD set the 'S' bit in the Registration Request sent to FA 299 1. In this case FA 1 continues to forward packets directly to its 300 local coverage area, in addition to forwarding a copy of each packet 301 along the FA 1 to FA 2 tunnel. Also, FA 1 should continue to handle 302 traffic from the MN that arrives directly from the local coverage 303 area. FA 2 may subsequently re-register with FA 1 with the 'S' bit 304 clear, once it has determined that it has a stable and authentic 305 link-layer connection to the MN, or FA 1 may cease to forward 306 packets to its local coverage area once it receives an authentic 307 Registration Request from the MN along the FA 2 to FA 1 tunnel. FA 308 1 may cease to forward packets along the FA 1 to FA 2 tunnel if it 309 has some indication that the MN has returned; in this case it should 310 send a Binding Update to FA 2 with both the Home Address and Care-of 311 Address set to FA 1's address. 313 7. Extension Format 315 The link-layer identification extension follows that given by Xu 316 [Xu00]: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type | Length | Protocol Type | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Key | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Reserved | MN Connection ID | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | MN ID Type | MN ID Length | MN ID | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | MN ID ... 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Type 39 (not-skippable). 334 Length A one-octet field that indicates the length 335 (in bytes) of the extension, NOT including 336 the Type and Length fields. 338 Protocol Type A two-octet field that indicates the type of 339 the protocol to be tunneled between FA 1 and 340 FA 2. It is same as the Protocol Type field 341 in the GRE header. For IP packets (assumed 342 in this draft) this should be set to 0x0800. 344 Key This is a four-octet value assigned by FA 2. 345 It is used in the GRE encapsulation between 346 FA 1 and FA 2 to indicate to which MN the 347 traffic belongs. 349 Reserved A two-octet field. It is not used and is 350 set to zero. 352 MN Connection ID A two-octet field that is used to 353 differentiate the multiple sessions from the 354 same Mobile Node. It is locally unique to a 355 Mobile Node. 357 MN ID Type A two octet field that indicates the type of 358 the following Mobile Node ID value. 360 Type value 1 will be reserved for 361 International Mobile Station Identity (IMSI) 362 encoded in ASCII format. For detailed 363 description of the IMSI, see IS-95 [TIA]. 365 MN ID Length This is a one octet field and it indicates 366 the length (in bytes) of the following 367 Mobile Node ID field. For IMSI MN ID encoded 368 in ASCII format, the length field value 369 ranges from 10 to 15 bytes. 371 MN ID This is the Mobile Node ID, which is 372 globally unique. It is used to uniquely 373 identify a Mobile Node. 375 For Type 1 MN ID, the most significant digit 376 of IMSI will be coded in ASCII and stored as 377 the most significant byte of the MN ID. 379 8. Stateful Link Layers 381 The level of interruption depends heavily on the time for the data 382 link to re-initialize when handing off from FA 1 to FA 2. For 383 wireless architectures that involve significant link negotiations, 384 such as LCP and NCP of PPP, the level of interruption for voice over 385 IP is not acceptable. An approach outside the scope of this draft 386 is to replace the layer-3 tunnels with layer-2 tunnels so that 387 movement of the mobile allows the data link layer to the previous 388 foreign agent to be maintained while the mobile performs MIP 389 registration. This change is possible because of the degree of 390 transparency offered by our architecture. When this approach is 391 taken it will not be possible for downstream FAs to "filter out" 392 Agent Advertisements from upstream FAs, but the new registration 393 with FA 2 will be carried out on a separate link-layer connection, 394 enabling the MN to close the old connection once handoff is 395 complete. 397 9. Security Considerations 399 This draft assumes that the MN is authenticated at the link layer. 400 Furthermore, the link must be secure; otherwise, untrusted mobile 401 nodes may be able to inject or intercept packets to a given FA. 403 If the target FA 2 is unable to authenticate the MN at the link 404 layer, then it SHOULD set the 'S' bit in the Registration Request to 405 FA 1. Then FA 1 will duplicate received packets, sending one copy 406 to FA 2 and another copy directly to its local coverage area. FA 1 407 may cease such duplication upon receipt of an authentic Registration 408 Request from the MN along the FA 2 to FA 1 tunnel. 410 10. References 412 [Bradner96]Scott Bradner., "The Internet Standards Process -- 413 Revision 3", BCP 9, RFC 2026, October 1996. 415 [Bradner97]Scott Bradner. "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [Dommety00]Gopal Dommety and Tao Ye. "Local and Indirect 419 Registration for Anchoring Handoffs", Internet Draft 420 draft-dommety-mobileip-anchor-handoff-01.txt, July 2000. 421 Work In Progress. 423 [Johnson00]David Johnson and Charles Perkins. "Mobility Support in 424 IPv6", Internet Draft draft-ietf-mobileip-ipv6-12.txt, 425 April 2000. Work In Progress. 427 [Kempf00] James Kempf, Pat Calhoun, and Chandana Pairla. "Foreign 428 Agent Assisted Handoffs", Internet Draft draft-calhoun- 429 mobileip-proactive-fa-01.txt, June 2000. Work In 430 Progress. 432 [Perkins00]Charles Perkins, editor. "IP Mobility Support for Mobile 433 IPv4, revised", Internet Draft draft-ietf-mobileip- 434 rfc2002-bis-02.txt, July 2000. Work In Progress. 436 [TIA] TIA/EIA IS-95 B. 438 [Xu00] Yingchun Xu et al. "Mobile IP Based Micro Mobility 439 Management Protocol in the Third Generation wireless 440 Network", Internet Draft draft-ietf-mobileip-3gwireless- 441 ext-04.txt, June 2000. Work In Progress. 443 11. Authors' Addresses 445 Peter J. McCann 446 Lucent Technologies 447 Rm 2Z-305 448 263 Shuman Blvd 449 Naperville, IL 60566-7050 450 USA 452 Phone: +1 630 713 9359 453 FAX: +1 630 713 4982 454 EMail: mccap@lucent.com 456 Tom Hiller 457 Lucent Technologies 458 Rm 2F-218 459 263 Shuman Blvd 460 Naperville, IL 60566-7050 461 USA 463 Phone: +1 630 979 7673 464 FAX: +1 630 979 7673 465 EMail: tom.hiller@lucent.com 467 Intellectual Property Statement 469 The IETF is hereby notified of intellectual property rights claimed 470 in regard to some or all of the specification contained in this 471 document. A letter setting forth Lucent Technologies' policy with 472 respect to licensing such intellectual property is on file with the 473 IETF Secretariat. 475 The IETF takes no position regarding the validity or scope of any 476 intellectual property or other rights that might be claimed to 477 pertain to the implementation or use of the technology described in 478 this document or the extent to which any license under such rights 479 might or might not be available; neither does it represent that it 480 has made any effort to identify any such rights. Information on the 481 IETF's procedures with respect to rights in standards-track and 482 standards-related documentation can be found in BCP-11. Copies of 483 claims of rights made available for publication and any assurances 484 of licenses to be made available, or the result of an attempt made 485 to obtain a general license or permission for the use of such 486 proprietary rights by implementers or users of this specification 487 can be obtained from the IETF Secretariat. 489 The IETF invites any interested party to bring to its attention any 490 copyrights, patents or patent applications, or other proprietary 491 rights that may cover technology that may be required to practice 492 this standard. Please address the information to the IETF Executive 493 Director. 495 Full Copyright Statement 497 "Copyright (C) The Internet Society (2000). All Rights Reserved. 498 This document and translations of it may be copied and furnished to 499 others, and derivative works that comment on or otherwise explain it 500 or assist in its implementation may be prepared, copied, published 501 and distributed, in whole or in part, without restriction of any 502 kind, provided that the above copyright notice and this paragraph 503 are included on all such copies and derivative works. However, this 504 document itself may not be modified in any way, such as by removing 505 the copyright notice or references to the Internet Society or other 506 Internet organizations, except as needed for the purpose of 507 developing Internet standards in which case the procedures for 508 copyrights defined in the Internet Standards process must be 509 followed, or as required to translate it into languages other than 510 English. 512 The limited permissions granted above are perpetual and will not be 513 revoked by the Internet Society or its successors or assigns. 515 This document and the information contained herein is provided on an 516 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 517 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 518 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 519 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 520 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 522 McCann, Hiller Standards Track - Expires 02/01 12