Mobile IP Working Group Alan O'Neill INTERNET-DRAFT Flarion Technologies Category: Standards Track June 2004 Mobile IPv4 Home Address Leasetime draft-oneill-mobileip-home-address-leasetime-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires January 9, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract With the introduction of NAIs for identifying Mobile Nodes, RFC 2794 also enabled the Home Agents to be able to assign IP addresses to the Mobile Nodes during the initial registration. Though the concept of NAI-based home address assignment is referenced in both RFC 2794 and RFC 3344, a comprehensive procedure for achieving such a NAI-based home address assignment has not been outlined. More particularly, the lifetime of the assigned address is undefined and the address status when deregistering from the HA, such as when returning to the home network, is also undefined. This document first defines a default address lifetime for RFC3344 MIP entities to resolve this ambiguity. The document then specifies a dynamic home address leasetime, as well as two new MIP extensions and associated procedures to facilitate management of a dynamic home address leasetime between the MN and the HA. A.W.O’Neill Expires - January, 9, 2005 [Page 1] Mobile IPv4 Home Address Leasetime July, 2004 Table of Contents Status of this Memo.................................................1 Abstract............................................................1 Table of Contents...................................................2 1. Problem Statement................................................2 2. Proposed Solution Overview.......................................4 3. Terminology......................................................5 4. Requirements and Scope...........................................5 5. Default and Dynamic Home Address Leasetimes for RFC3344..........6 5.1 Returning Home..................................................6 5.2 MIP Binding Expiry..............................................7 5.3 MIP Binding Deregistration (not at home)........................7 6. MIP based Extensions for Dynamic Home Address Leasetime .........7 6.1 Home Address Lease Request......................................7 6.2 Home Address Lease Grant........................................8 6.3 HALR Protocol Rules.............................................9 6.4 HALG Protocol Rules............................................10 6.5 HA Deregistration Considerations...............................10 7. IANA Considerations.............................................11 7.1 Mobile IP Extension Type and Subtypes..........................11 7.2 Mobile IP Error codes..........................................11 8. Security Considerations.........................................11 9. Backward Compatibility Considerations...........................11 9.1 Legacy Home Agent..............................................11 9.2 Legacy Foreign Agent...........................................12 9.3 Legacy Mobile Node.............................................12 10. Acknowledgements...............................................12 Informative References.............................................12 Authors’ Addresses.................................................12 IPR Statement......................................................13 Copyright Statement................................................13 Disclaimer of Validity.............................................13 Acknowledgement....................................................13 1. Problem Statement With the introduction of NAIs for identifying Mobile Nodes, RFC 2794 also enabled the Home Agents to be able to assign IP addresses to the Mobile Nodes during the initial registration. Though the concept of home address assignment is referenced in both RFC 2794 and RFC 3344, a comprehensive procedure for managing such a home address assignment has not been outlined. More particularly, the lifetime of the assigned address is undefined and the address status when deregistering from the HA, such as when returning to the home network, is also undefined, as described below. An RFC 3344 MN can set the home address field to 0.0.0.0 in a RRQ(0.0.0.0) to request the return of a dynamically assigned home address to the MN within the RRP. The RRP as presently specified does not however contain an address lifetime. The lack of an address A.W.O’Neill Expires - January, 9, 2005 [Page 2] Mobile IPv4 Home Address Leasetime July, 2004 lifetime in the RRP can be interpreted by the MN as either; i) implying an infinite home address lifetime (ie static allocation). ii) implying a lifetime equal to that of the MIP binding such that the address is automatically deallocated on the expiry of that binding whether as a result of lifetime expiry or as a result of an explicit deallocation. iii) implying an undefined lifetime such that no assumption on the lifetime can be made and is to be defined by other mechanism. Therefore MIP nodes from different vendors can, and apparently do, have different views on that lifetime, leading to different and incompatible processing rules. Further, it is apparent that each of these interpretations are in themselves also problematic in specific scenarios such that attempting to simply gain consensus for one of them is inappropriate. One can consider that the existence of the multiple interpretations has arisen out of the different requirements for those specific scenarios. For example, in case (ii), it is clear that when a MN returns to its home network and deregisters from the HA then the home address is lost and can be reallocated by the HA to another node, resulting in disruption to any ongoing sessions of the MN that continue to employ that home address on the home network. This interpretation also fails if a MN wishes to maintain a home address when it deregisters from the HA for efficiency reasons (going to sleep, disconnecting from the access network) or as a result of a binding lifetime expiry following some kind of a failure. This is because by definition the address is deallocated on binding expiry. If the MN never needs to return home and never needs to employ the same address across multiple MIP sessions, and hence during the absence of a MIP binding, then this interpretation is appropriate. In case (i), the address has an infinite lifetime and hence the home address will work when returning home and can be otherwise maintained across multiple MIP sessions and in the absence of a binding, but no specification exists to deallocate that address from the MN and hence efficiently maintain the address block at the HA using MIP mechanisms. The home address is then in fact a static address from the perspective of MIP, and dynamic address allocation is not supported. In case (iii), manual configuration or additional non-MIP protocol mechanisms can define the address lifetime that is associated with the home address that is returned in the RRP. This enables a form of dynamic address allocation to be supported with specific constraints. For example, manual configuration of lifetimes is inefficient for dynamic addressing schemes. It also creates A.W.O’Neill Expires - January, 9, 2005 [Page 3] Mobile IPv4 Home Address Leasetime July, 2004 difficulties when the manually configured address lifetime is less than the MIP binding lifetime because of the resulting protocol ambiguities and/or impact on ongoing communications with that address. The MN could alternatively obtain lifetime information from DHCP following MIP based home address allocation, but then it would seem much more appropriate to obtain both the address and the lifetime via DHCP and then register that new home address via MIP whilst maintaining the address lifetime via DHCP. This is however typically too time-consuming for fast-moving mobile devices. It can be seen therefore that this interpretation might be appropriate for road warrior type applications and for semi-static addresses but is unlikely to be appropriate for dynamic home address allocation for such highly mobile devices. This document first proposes a default interpretation for the ambiguous address lifetime and associated behaviour in RFC3344, that will inevitably only be backwards compatible with a subset of current implementations. This document then specifies additional protocol mechanisms that the Mobile IP entities in RFC3344 should follow in order to facilitate dynamic home address lifetimes for MIP based home address allocation. The approach taken is to ensure that the address lifetime management is tightly coupled to the home address allocation by extending MIP mobility signaling and fully integrating the default and dynamic address leasetimes. 2. Proposed Solution Overview Firstly, the default interpretation for the home address lifetime in RFC3344 style home address allocation, for MIP entities that are compliant with this document, MUST be that the lifetime is equal to the MIP binding lifetime. This choice is fully defined in section 5 and is preferred because the general model for the overall solution is that the address lifetime is provided by MIP signaling and hence is tightly coupled to the address allocation and binding lifetime signalling. Highly mobile devices that employ licensed cellular spectrum are less ameniable to both DHCP and MIP based address lifetime management overheads, and cellular mobile systems typically employ a virtual home network that the mobile node does not visit and hence the default lifetime interpretation is at least fully defined and acceptable for a significant scenario. In addition, road warrior and enterprise scenarios are more amenable to DHCP based home address / lifetime allocation, and to the additional cost of maintaining a non-default dynamic address lifetime due to the less expensive access bandwidth typically employed in enterprise, fixed and WLAN access scenarios. Note that this default interpretation says nothing about MIP entities that are only compliant with RFC3344 and not with this document, which will continue to interpret the ambiguous home address lifetime in multiple ways at the cost of interoperability. However, it should be clear that such RFC3344 entities can be viewed as being compatible with this default interpretation in combination with a configured address leasetime A.W.O’Neill Expires - January, 9, 2005 [Page 4] Mobile IPv4 Home Address Leasetime July, 2004 with a value between zero and infinity. Secondly, a Home Address Leasetime Request (HALR) MIP extension and associated protocol, is defined to enable a MN to request a dynamic home address leasetime for an existing, or to be allocated, home address. The presence of this extension indicates to the FA and the HA that the MN is capable of home address leasetime management. Finally, a Home Address Leasetime Grant (HALG) MIP extension and associated protocol, is defined to enable the HA to communicate a dynamic home address leasetime to the MN in a RRP when the home address lifetime needs to be different to the (default) MIP binding lifetime. The HA can include the HALG in a RRP if the RRQ included a HALR or if the HA has other state or indication that the MN is capable of home address leasetime management. The HALR and HALG extensions and the associated processing rules are defined in section 6. The default address lifetime interpretation and the MIP based HALR / HALG extensions are also applicable to MIP entities that support NAI-Based Home Address Assignment, that is being developed in [NAIaddr]. The implications of this document on that work is included in that document and not further qualified here. 3. Terminology MN Mobile Node as defined in RFC 3344 HA Home Agent as defined in RFC 3344 FA Foreign Agent as defined in RFC 3344 RRQ Mobile IP Registration Request as defined in RFC 3344 RRP Mobile IP Registration Reply as defined in RFC 3344 HoA MN’s Home Address RRQ(0.0.0.0) RFC3344 request for dynamic Home Address allocation RRQ(a.b.c.d) A RRQ containing the current HoA of the MN. RRQ(HALR) A RRQ containing the HALR extension. RRP(HALG) A RRP containing the HALG extension. 4. Requirements and Scope Following are the requirements that the proposed home address leasetime scheme tries to satisfy. - Define a default home address leasetime of zero seconds for RFC3344 MIP entities such that the default address lifetime is equal to the binding lifetime. - Specify the HALR and HALG MIP extensions for optional dynamic home address leasetime agreement. A.W.O’Neill Expires - January, 9, 2005 [Page 5] Mobile IPv4 Home Address Leasetime July, 2004 - Specify the HA/FA/MN behavior for the use of the default and dynamic address leasetimes. - Specifically outline MIP entity behaviour when the MN returns home, for MIP based HoA lifetime management. - A MN that has been assigned the home address and the home address lifetime by means other than dynamic allocation by the HA, is outside the scope of this document. 5. Default and Dynamic Home Address Leasetime for RFC3344 MIP Entities The MIP home address lifetime is defined to be the sum of the remaining MIP binding lifetime and the remaining portion of the home address leasetime. This definition simplifies the state machines at the HA and MN by implicitly ensuring that the binding lifetime can never be greater than the remaining lifetime of the home address. This also removes significant motivation for an attacker to attempt to interfere with the address leasetime parameter within MIP signals because this can never force the MN into releasing a home address for a current binding. The default home address leasetime MUST be zero such that the default home address lifetime is equal to the MIP binding lifetime. When a MN deregisters a MIP binding or that binding otherwise expires, then the MN/FA/HA entities MUST consider that the home address leasetime has expired. The MN MUST then cease employing that home address for its communications. The HA MAY then return the home address to the dynamic home address allocation pool. The MN MAY acquire a dynamic home address leasetime as a result of MIP signaling extensions defined in section 6. The MN and the HA MAY alternatively be configured with a dynamic home address leasetime that extends the home address ownership beyond the current MIP binding lifetime (ie to infinity) but such configuration is outside the scope of this draft. This specification does not mandate an implementation approach for the home address lifetime processing and is only concerned with the observable behaviour. However, as an example, a Home Address Lease Timer may be considered to start when the binding lifetime expires or is explicitly cancelled. The home address is considered de- allocated from the MN when this Lease Timer expires. 5.1 MN Returning Home RFC3344 specifies that the MN deregisters its MIP binding on returning to the home network. This can lead to the MN losing its current home address if the home address lifetime is equal to the A.W.O’Neill Expires - January, 9, 2005 [Page 6] Mobile IPv4 Home Address Leasetime July, 2004 remaining binding lifetime (leasetime=0). In such scenarios, the MN and HA MAY avoid this result by; i) by using MIP protocol mechanisms to manage a dynamic home address leasetime, or ii) by using non-MIP home address management mechanisms which are outside the scope of this draft. It should be noted that a MN that is allowed to return to a home network typically has a close administrative association with the HA for that home network which should ensure consistent home address leasetime management on the MN and the HA. 5.2 MIP Binding Expiry If a MIP binding expires, potentially as a result of a loss of connectivity or a MIP entity failure, then the dynamically allocated home address MUST be released. If a dynamic home address leasetime exists then the home address MUST NOT be released until after the expiry of this leasetime. This can be used to provide an extended period for the MN to try to re-establish the MIP session for the current home address. 5.3 MIP Binding Deregistration (not at home) If a MIP binding is deregistered, and the HA observes correct protocol behaviour, then the HA may perceive an opportunity to reclaim the home address immediately. However, the HA MUST NOT reclaim the home address until the expiry of the dynamic home address leasetime to ensure that the HA and the MN remain synchronised and so that, for example, the user can recover a MIP session for the current home address when that session was mistakenly terminated. 6. MIP based Extensions for Dynamic Home Address Leasetime This section further defines the MIP home address leasetime feature by providing extensions to RFC3344 to facilitate MIP based dynamic home address leasetime management. 6.1 Home Address Leasetime Request Extension This extension is included by the MN to inform the home agent that it is requesting an address leasetime in addition to a binding lifetime. This skippable extension follows the short extension format as defined in [2], where the subtype indicates the specific address management extension. A.W.O’Neill Expires - January, 9, 2005 [Page 7] Mobile IPv4 Home Address Leasetime July, 2004 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leasetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Address Management Extension (skippable) [2] Sub-Type 1 Length 4 Reserved Reserved for future use. MUST be set to 0 on sending and MUST be ignored on reception. Leasetime The time in seconds, in addition to the current binding lifetime, that the MN is requesting as the address leasetime. A value of zero indicates a request to remove the current leasetime. A value of 0xffff indicates an infinite address leasetime. A MN can request a leasetime that is greater than the current leasetime to extend the home address lifetime. 6.2 Home Address Leasetime Grant Extension This extension is included by the HA to inform the MN and FA of the granted address lifetime. This skippable extension follows the short extension format as defined in [2], where the subtype indicates the specific address management extension. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leasetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Address Management Extension (skippable) [2] Sub-Type 2 Length 4 Reserved Reserved for future use. MUST be set to 0 on sending and MUST be ignored on reception. Leasetime The time in seconds, in addition to the current A.W.O’Neill Expires - January, 9, 2005 [Page 8] Mobile IPv4 Home Address Leasetime July, 2004 binding lifetime, that the HA is granting as the address leasetime. A value of zero indicates mandatory removal of the current dynamic leasetime. A value of 0xffff indicates an infinite address leasetime. A HA can grant a leasetime that is greater than the current leasetime but not greater than the requested leasetime in the HALR. 6.3 HALR Protocol Rules The HALR requests a specific dynamic home address leasetime at the HA, and can also be used to communicate (as yet unspecified) flag bits that, for example, can indicate additional MN capabilities or requirements that refine the request for a dynamic home address leasetime. The HALR MUST NOT be included by a MN that is otherwise not capable of managing home address leasetimes as defined by this specification. The HALR MUST always precede the authorization- enabling extension between the MN and the HA. The HALR extension MUST be added by a MN into the RRQ to indicate compliance with this specification to the HA, and to any FA. The MN MAY employ the HALR whether or not the FA or HA are known to support this specification. The FA MAY inspect the requested leasetime but MUST NOT undertake any new MIP processing as a result of that value. A HA that does not support this specification will skip the HALR and not return a HALG to the MN, so indicating its lack of support to the MN. A HA that receives a HALR from a MN indicates that the MN is compliant with this specification. The HALR may be included into a RRQ with home address field equal to 0.0.0.0, indicating according to RFC3344 that the MN does not know its home address, and therefore wishes to obtain its home address from the HA via the RRP. The HALR can be included into a RRQ with home address field equal to a previously allocated address RRQ(a.b.c.d), indicating according to RFC3344, that the MN knows its home address. This enables the MN to request allocation or modification of an address leasetime at any stage of the MIP binding lifecycle, and independent of whether the address was allocated via MIP or other mechanisms. The requested home address leasetime is a requested absolute increment on the current binding lifetime of the MN as determined by the MN and the HA. This means that this leasetime does not need to be refreshed whilst the MN has a non-zero binding lifetime so reducing the MIP signaling load. When the MN has an expired or cancelled binding lifetime then the home address leasetime is incrementally consumed, and therefore needs to be replenished periodically to avoid the home address being released. The default refresh interval is 1/3 of the initial granted leasetime and independent of the remaining dynamic leasetime. A.W.O’Neill Expires - January, 9, 2005 [Page 9] Mobile IPv4 Home Address Leasetime July, 2004 6.4 HALG Protocol Rules The HALG extension MAY be added by a HA into the RRP to enable the HA to grant a dynamic home address leasetime to the MN, and can also be used to communicate (as yet unspecified) flag bits that, for example, can indicate additional HA capabilities or conditions that refine the granted home address leasetime. The granted dynamic address leasetime is for the current home address of a MN that is associated with the RRQ/RRP. The HALG enables the MN to generate a home address lifetime which is the sum of the home address leasetime plus the MIP binding lifetime in the RRP. The dynamic address leasetime grant extensions avoids the need for configured leasetimes on MNs. The HALG MUST NOT be included by a HA if the HA has had no indication from the MN for this MIP session that the MN is complaint with this specification. Such indication is given from a previously received RRQ(HALR). A compliant HA MUST return a RRP(HALG) on receipt of a RRQ(HALR) but MAY reduce the requested leasetime based on local policy information. Specifically, the leasetime MAY be reduced to zero and MAY be different from the contents of any previously returned leasetime. A compliant HA MAY also return a RRP(HALG) on receipt of a RRQ that does not include HALR, provided that a previous RRQ(HALR) has been received from the MN. Specifically, the HA SHOULD return RRP(HALG) in response to a RRQ(lifetime=0) or when sending a RRP(registration revocation). The HA MAY return the HALG whether or not the FA or MN are known to support this specification. The FA MAY inspect the granted leasetime but MUST NOT undertake any new MIP processing as a result of that value. A MN that does not support this specification will skip any HALG delivered as a result of a protocol failure. The HALG does not presently communicate whether the HA supports a real or virtual home network for the home address of the MN. The HALG also does not presently communicate the availability of alternative (i.e. non-MIP based) home address leasetime management techniques to the use of the HALR/HALG extensions. 6.5 HA Deregistration Considerations An RFC3344 MN cancels a MIP binding at a HA by sending a deregistration for the current binding which leads to the removal of the binding entry at the HA, and the associated dynamic MIP signaling state used for replay protection and message sequencing. To enable a MN to be able to maintain a home address after cancellation of the binding entry, it is clear that home address state must be independently maintained at the HA. In addition, to A.W.O’Neill Expires - January, 9, 2005 [Page 10] Mobile IPv4 Home Address Leasetime July, 2004 enable a MN to use MIP signaling to subsequently, and periodically, refresh a home address leasetime after binding cancellation, it is necessary to maintain MIP signaling state after binding cancellation, whilst active home address leasetime state exists. MIP signaling state for a MN HoA may be removed only when the MIP home address lifetime (binding lifetime plus home address leasetime) has expired. A valid implementation option, for example, is to maintain a binding entry that includes unexpired home address leasetime information, but that has an expired binding lifetime. 7. IANA Considerations 7.1 Mobile IP Extension Type and Subtypes This document introduces the following Mobile IP extension type. Name : Address Management Extensions Type Value : TBD Section : 6 This document also introduces two of the following subtypes for the above extension type. Sub-type Name Section -------- ---- ------- 1 Home Address Leasetime Request 6.1 2 Home Address Leasetime Grant 6.2 7.2 Mobile IP Error codes This document introduces no new error codes that can be returned by the FA or HA in a Mobile IP Registration Reply. 8. Security Considerations The above mentioned procedure for home address leasetime management introduces the HALR and HALG extensions which MUST be protected by an authorization-enabling extension [2] between the MN and the HA. Thus, this procedure does not introduce any new security concerns. 9. Backward Compatibility Considerations 9.1 Legacy Home Agent Upon receiving a RRQ(HALR) from a MN following the procedure outlined in this document, the legacy HA SHOULD follow the behavior as per RFC 3344, ignoring the HALR extension which has been defined in the skippable range of extensions. A.W.O’Neill Expires - January, 9, 2005 [Page 11] Mobile IPv4 Home Address Leasetime July, 2004 9.2 Legacy Foreign Agent For the cases where the RRQ(HALR) is sent by the MN with home address field set to 0.0.0.0 or a.b.c.d, the behavior of the legacy FA will be the same as per RFC 3344. For the cases where the RRP(HALG) is sent by the HA, the behavior of the legacy FA will be the same as per RFC 3344. 9.3 Legacy Mobile Node The RRQ behavior of a legacy MN will not be affected, since the new behavior will be applicable only for RRQs which include the HALR so indicating compliance with this specification. The RRP behaviour of a legacy MN is also not affected by the receipt of an unsolicited HALG as it is only used with a MN that has indicated compliance with this specification. It is also a skippable extension and behaviour will progress as per RFC 3344 if incorrectly sent to a non-compliant MN as a result of a bug, and whilst this does mean that the MN and HA can have different views on the lifetime of the home address, it is always assured that the HA has a greater lifetime than the MN. 10. Acknowledgements Many thanks to Naveen Paulkandasamy and Kent Leung of Cisco Systems for review of, and contributions to this document. Informative References [1] P. Calhoun and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [2] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, August 2002. [3] Paulkandasamy & Leung, "NAI-Based Home Address Assignment", draft-paulkandasamy-mobileip-nai-based-home-address-00.txt, March, 2004. Authors’ Addresses Alan O'Neill Flarion Technologies a.oneill@flarion.com A.W.O’Neill Expires - January, 9, 2005 [Page 12] Mobile IPv4 Home Address Leasetime July, 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. A.W.O’Neill Expires - January, 9, 2005 [Page 13]