A. Azcorra Internet Draft Univ. Carlos III Document: draft-azcorra-ipv64-03.txt de Madrid Expires: June 4, 2002 December 5, 2001 Internet Protocol, Version 64 (IPv64) Specification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document specifies an IPv6 protocol extension that allows IPv6 packets to be backward compatible with IPv4. An IPv6 packet encapsulated in IPv4 in this way (called IPv64) would be processed as native IPv6 by IPv6 routers, and at the same time, in case there is an IPv4-only router in the path, it will be processed as IPv4. Consequently, it is possible to have native end-to-end IPv6 communication, with IPv6 processing at IPv6 routers, through a path that contains some IPv4-only routers. Protocol conversion from/to IPv6 to/from IPv64 is made at edge routers, and therefore the advantages of IPv64 are achieved with standard native IPv6 hosts A. Azcorra Informational - Expires June 4, 2002 1 INTERNET DRAFT IPv64 Specification December 5, 2001 Table of Contents 1. Changes from previous version of the draft......................3 2. Introduction....................................................3 3. IPv64 Packet Format.............................................4 4. IPv6 Extension Headers in IPv64 packets.........................6 5. Identification of IPv64 packets at IPv64 nodes..................6 6. Processing IPv64 packets at IPv6 dual-stack nodes...............7 7. Processing IPv64 packets at IPv64 nodes.........................7 8. IPv64 Protocol Translation......................................8 9. Firewalls and other protocol functions..........................9 10. Conclusions....................................................9 11. Acknowledgements...............................................9 12. APPENDIX: Sending IPv64 packets to IPv4-only destinations.....10 A. Azcorra Informational - Expires June 4, 2002 2 INTERNET DRAFT IPv64 Specification December 5, 2001 1. Changes from previous version of the draft Standard IPv6 and IPv4 headers are used, without proposing modifications on them. Protocol conversion from/to IPv6 to/from IPv64 is made at edge routers, and therefore the advantages of IPv64 are achieved with standard native IPv6 hosts. A prototype of IPv64 router has been developed over lynux to experiment with possible implementation problems, and current experience show satisfactory behavior. 2. Introduction The intention of this document is to provide a complementary transition mechanism to facilitate the migration from IPv4 to IPv6. This additional transition mechanism would allow that IPv6 be backward compatible with IPv4. Being backward compatible means that IPv6 packets encapsulated in IPv4 will be processed as IPv6 by IPv6 routers (and not according to the encapsulating IPv4 header), while IPv4 routers will process them as IPv4 (according to the encapsulating IPv4 header). To distinguish in the remaining text of this document between plain IPv4-tunneled IPv6 packets and IPv4-encapsulated IPv6 packets that will be processed as IPv6 by IPv6 routers, the former will just be called tunneled IPv6 packets, while the latter will be called "IPv64" packets. IPv4 packets that do not carry an IPv6 packet will just be called IPv4 packets. The approach described in this document has the advantage that it allows the communication between two IPv6 hosts with packets being processed as IPv6 packets at IPv6 routers, and being processed as IPv4 at IPv4-only routers. Therefore, it is possible to use routing based on an IPv6 destination address (including all new types), use IPv6 source routing, and use hop-by-hop extension headers at in- transit IPv6 routers, while in-transit IPv4-only routers will still route the packet correctly. Current transition approaches work well to interconnect IPv6 islands through IPv4 clouds. The IPv64 approach offers advantages for the coming situation in which there will be an infrastructure composed of highly interconnected IPv4 and IPv6 user and transit networks. To achieve the aforementioned functionalities it is required that IPv6 routers recognize IPv64 packets, distinguishing them from other IPv4 packets, in order to process them as IPv6 packets. A. Azcorra Informational - Expires June 4, 2002 3 INTERNET DRAFT IPv64 Specification December 5, 2001 2.1 Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3. IPv64 Packet Format The format of an IPv64 packet is the same as an IPv6 packet encapsulated in IPv4, with the specific utilization of the IPv4 fields described in the following subsections. 3.1 IPv4 Total Length This IPv4 field contains the total length of the IPv4 packet. This field will be unchanged by IPv64 routers unless there is a modification of the size of the enclosed IPv6 packet (e.g. because of modifications of extension headers). 3.2 Bit 16 of the third word of IPv4 header Bit number 16 of the third word of the IPv4 header (i.e. bit number 48, beginning with bit 0, of the header) will be called "IPv64 packet". This bit MUST be set to 1 to identify that this packet is an IPv64 packet, and not a regular tunneled IPv6 packet. Regular tunneled IPv6 packets will be processed as IPv4 at IPv64 routers. 3.3 IPv4 Fragmentation Control Fields These rules apply to IPv4 fields Identification, Do not Fragment (DF), More Fragments (MF), and Fragment Offset. IPv4 in-transit or source fragmentation of IPv64 packets is undesirable because the second and subsequent fragments would not contain the IPv6 headers. As IPv6 headers are not present, IPv64 routers in the path will only be able to process IPv64 fragments as IPv4 packets, thus loosing all of the network IPv6 functionality. Therefore, IPv4 fragmentation is not allowed. The IPv4 DF bit MUST be set to one. The source node MUST provide an appropriate mechanism to use an IPv4 packet size that MUST be below the minimum IPv4 MTU in the path to each destination, in order to avoid that the IPv64 packet be discarded. A straightforward mechanism, although somehow inefficient in transmission overhead, is to always use 576 octets as MTU. Other more efficient mechanisms remain for further study. In case the upper layer at the source desires to send a packet size above the path MTU (e.g. to send a large UDP datagram), IPv6 fragmentation will be used. A. Azcorra Informational - Expires June 4, 2002 4 INTERNET DRAFT IPv64 Specification December 5, 2001 As a consequence of the above discussion, IPv4 fields MF and Fragment Offset MUST always be set to zero. 3.4 IPv4 Time To Live This IPv4 field will only be processed by IPv4-only routers. IPv64 capable routers MUST NOT modify this field. IPv64 capable routers MUST modify the Hop Limit field in the enclosed IPv6 header. This fact should be taken into account by the source node when selecting the appropriate value for both fields (TTL and Hop Limit). This aspect remains for further study, because an alternative design would be that IPv64 routers decrement both the TTL sub-field and the Hop Limit fields. However, this approach has the disadvantage to require a modification of the contents of the IPv4 header at all IPv64 routers, instead of just forwarding it unchanged whenever possible. 3.5 IPv4 Header Checksum In case an IPv64 capable router modifies a field in the IPv4 header, then the checksum will have to be recalculated. Examples of cases in which an IPv64 capable router has to modify a field in the IPv4 header are the modification of a hop-by-hop extension header (that implies a modification in the IPv4 Total Length field), or the remarking of the IPv4 TOS field at a Differentiated Services IPv64 edge router. 3.6 IPv4 Source and Destination addresses These fields MUST contain a sufficiently close IPv4 source and destination addresses of the IPv64 packet. A sufficiently close address means that it is not required that the IPv4 packet be addressed to the final destination, but rather to a place beyond which it will be processed only by IPv64 capable routers. For example, it is possible to have a domain with a border router that only has one public IPv4 address in its interface, while there are many IPv6 hosts and IPv64 routers internally. In this case the IPv4 address used by any host sending packets to any host within that domain will be the one of the border router, so the packets are correctly routed from anywhere in the Internet to the border router. Beyond the border router the IPv4 address will be ignored, as all routers are IPv64, and packets will be routed based only on the IPv6 destination address field. The destination address field in the IPv4 header and the IPv6 header need not correspond to the same system and interface, but they must be consistent, as described above. The same applies for the IPv4 and IPv6 source address fields. A. Azcorra Informational - Expires June 4, 2002 5 INTERNET DRAFT IPv64 Specification December 5, 2001 4. IPv6 Extension Headers in IPv64 packets IPv6 extension headers are allowed in IPv64 packets. The extension headers are located, as in regular IPv6 packets, following the IPv6 header, and with the same structure and semantics. 5. Identification of IPv64 packets at IPv64 nodes When an IPv64 router receives an IPv4 packet with value 4 in the Internet Version field, it will need to know whether it is a native IPv4 packet (including in this category pure tunneled IPv6 packets) or an IPv64 packet, in order to decode and process it correctly. The proposal for this function is that the currently unused bit in the IPv4 header (that has been called "IPv64 Packet" field in this document) be set to 1 in IPv64 packets. The IP specification in RFC 791 indicates that even thought this bit is unused, it must be set to 0. Therefore, IPv4 nodes sending IPv4 packets would set this bit to 0, while IPv64 packets would have it set to 1. IPv64 routers or destination nodes would use the value of this bit to distinguish between incoming IPv4 packets and IPv64 packets. This proposal is built on the assumption that all IPv4 implementations comply with RFC 791, setting bit 16 of the third word of the header to zero at the source, and ignoring its value when processing the packet at routers and the destination node. As this might not be the case, and the number of non-compliant implementations could be relevant, several alternative procedures have been considered. These procedures are described in the following sub-sections. 5.1 Using the reserved IPv4 option number IPv64 packets sent as IPv4 compatible packets (see the APPENDIX) would have the specific option number (decimal 15 as stated above) reserved for this purpose. Therefore, IPv6 nodes could use this fact to detect IPv64 packets. Notice that this only applies to IPv64 packets sent in IPv4 compatible way. Consequently, either, a) ALL IPv64 packets are sent in IPv4 compatible format, or, b) another procedure is used to detect IPv64 packets sent in non-IPv4 compatible format. Alternative a) would extend the already mentioned disadvantages of the IPv4 compatible format to all IPv64 packets: processing in the slow path and restrictions on the use of the flow-label field. Alternative b) is feasible (see the next sub-section), but would require more instructions to implement the procedure of detecting formats. This procedure has to be applied to each and every packet, and is therefore somehow undesirable to increase its computational complexity. A. Azcorra Informational - Expires June 4, 2002 6 INTERNET DRAFT IPv64 Specification December 5, 2001 5.2 IPv4 Protocol field The content of the IPv4 Protocol field could be used to detect IPv64 packets sent in regular format (i.e. those that are not in IPv4- compatible format): when a packet that does not have option number 15 set has the reserved value (e.g. 101) for IPv64 packets in the IPv4 Protocol field, then it is an IPv64 packet. 5.3 IPv4 DSCP value in the TOS Field The six-bit DSCP value in the IPv4 header could be assigned a reserved value to identify IPv64 packets. The disadvantage is that in this case Differentiated Services could not be used for IPv64 packets, as all of them would carry the specific DSCP value. 5.4 ECN bits in the Differentiated Services Field One of the two bits in the Differentiated Services Field that have been proposed to be used for ECN (see RFC 3022) could be used for this function. The obvious disadvantage is that in this case they could not be used for ECN. 6. Processing IPv64 packets at IPv6 dual-stack nodes Plain IPv6 nodes will treat IPv64 packets as IPv4 packets, as they can not distinguish IPv64 packets from IPv4 packets. A plain IPv6 end system that receives an IPv64 packet will pass all data after the IPv4 header to the corresponding upper layer protocol entity identified in the Protocol field of the IPv4 header. 7. Processing IPv64 packets at IPv64 nodes An IPv64 source node needs to know, in addition to the IPv6 address of the final destination, a sufficiently close IPv4 address. These values are reasonably static and independent of the network topological changes. An IPv64 router receiving an IPv64 packet will first have to identify it as such (see the corresponding section in this document). Once it has identified the packet as IPv64, then it will process the packet as a native IPv6 packet, ignoring the fields of the IPv4 header, with the exception of the TOS field, whose value is used instead of the one from Traffic Class field (IPv4 remarking is acceptable). Once the packet has been processed as an IPv6 packet, and the outgoing IPv6 packet has been constructed, the outgoing IPv4 header will be constructed. The outgoing IPv4 basic header (i.e. without the options field) will be the same as the incoming one, with the following exceptions: * Total Length: it will be recalculated if the length of the IPv6 enclosed packet has been modified (e.g. routing header). A. Azcorra Informational - Expires June 4, 2002 7 INTERNET DRAFT IPv64 Specification December 5, 2001 * Type Of Service: it will be modified in case this is an edge router and remarking of the DSCP field is needed. In this case, the value of the outgoing DSCP field will be set according to the Differentiated Services specification. * IPv4 addresses: only modified if NAT is being performed. The combined usage of IPv64 and IPv4 NAT is currently for further study. * Checksum: it will be recalculated if the incoming IPv4 header has been modified. Therefore, at an IPv64 router the fields of the IPv4 header in the incoming IPv64 packet are used only to: 1. Identify the packet as an IPv64 packet and not a plain IPv4 packet. 2. The Traffic Class value in the incoming IPv6 header has to be ignored, and its value be taken from the TOS octet of the IPv4 header. Notice that an IPv4 edge router performing remarking would only remark the DSCP in the IPv4 TOS field. 3. Generate the appropriate IPv4 header in the outgoing IPv64 packet. In the case of direct delivery of the IPv64 packet to its IPv6 destination, the address resolution function MUST be performed first using the IPv6 destination address. 8. IPv64 Protocol Translation Producing IPv64 packets would require that IPv6 end-system implementations be modified according to the specification performed in this document. This has the obvious disadvantage of requiring the modification of the already designed IPv6 systems, and its deployment. To avoid this problem, a protocol translation procedure has been designed to allow current native IPv6 systems to interoperate with IPv64. This procedure would be provided at the router with a direct delivery capacity to the IPv6 end-system. This is a current restriction that might be relaxed in the future. An IPv64 router with IPv6 hosts connected to one of its interfaces can be configured to perform protocol translation at that interface. This means that the router will convert incoming IPv6 packets from that interface to IPv64 packets and IPv64 packets directed to a host on that interface will be converted to native IPv6. Protocol translation from IPv6 to IPv64 requires that the local router be capable of determining the sufficiently close IP addresses associated to both the IPv6 source and destination. For this purpose, the following complementary (not alternative) procedures will be used: A. Azcorra Informational - Expires June 4, 2002 8 INTERNET DRAFT IPv64 Specification December 5, 2001 1. Configured Table: this is suitable for the source address, but it will not serve in the general case for the destination address. 2. Learnt table: the system will maintain a cached table of associations that it learns by inspecting IPv64 packets that are received by it. 3. IPv6 addresses with either IPv4 format or 2002Hex prefix: these addresses allow direct calculation of the associated IPv4 address. 4. DNS look up: This subject remain for further study. 5. Cached table: the system will maintain a cached table of previously resolved associations that have been performed for IPv6 to IPv64 packet conversion. Protocol conversion must be made guaranteeing the requirement already described that IPv4 fragmentation of IPv64 packets MUST NOT take place. This implies that the IPv6 MTU being used by the native IPv6 hosts MUST be, at most, 20 octets smaller than the actual IPv4 MTU of the path. This subject remains for further study. 9. Firewalls and other protocol functions The impact of Firewalls, NAT, ICMP diagnostics, ECN, path MTU discovery and other functions in relation to IPv64 remains for further study. 10. Conclusions The IPv64 transition mechanism described in this document is compatible with other transitions mechanisms based on NAT and on different tunneling approaches, and might be used in conjunction with them. IPv64 requires modifications in the procedures of IPv6 implementations in order to recognize and process IPv64 packets as IPv6, instead of forwarding them as IPv4. However, these changes need not be global, and might be deployed at some IPv6 routers without affecting the functionality of the network. As more IPv6 routers incorporate these functions, then more IPv64 packets will be processed as IPv6 instead of as IPv4, smoothly migrating the network functionality to IPv6. Current transition approaches work well to interconnect IPv6 islands through IPv4 clouds. The IPv64 approach offers advantages for the coming situation in which there will be an infrastructure composed of highly interconnected IPv4 and IPv6 user and transit networks. 11. Acknowledgements This work has used valuable comments received from Tony Hain, Brian E. Carpenter, Svend Moeller Nielsen, and Alberto Garcia-Martinez. A. Azcorra Informational - Expires June 4, 2002 9 INTERNET DRAFT IPv64 Specification December 5, 2001 12. APPENDIX: Sending IPv64 packets to IPv4-only destinations This feature remains for further study. What follows is the current state of the design. This is not a basic feature of IPv64, and its removal does not affect the basic advantages of IPv64 as a transition mechanism. The objective of this feature is to allow that an IPv4-only destination node receives, and correctly processes, an IPv64 packet even without any specific IPv6 software installed. This would allow the advantages of IPv6 in-transit processing (IPv6 destination address being assigned to the IPv4-only node, routing extension header and hop-by-hop extension headers, etc) while sending packets to an IPv4-only host. The basic idea is to encode the IPv6 header of IPv64 packets as IPv4 options of the encapsulating IPv4 packet. To achieve this feature, a number of changes are required on the usage of some fields that have been described in the previous sections. This refinement of the IPv64 format will be called "IPv4-compatible" format. This feature is built on the assumption that IPv4 implementations (router or host) that detect an unrecognized option number will ignore the option and process the packet normally, instead of discarding the packet. The main disadvantage of using the IPv4-compatible format is that it requires to use the IPv4 options field, which on some IPv4 routers would imply processing the packet on the slow path. Another disadvantage is that higher four bits of the Flow Label field can not be used. Notice that the following changes in field usage would only be required when sending an IPv64 packet to an IPv4-only destination node, and the usage would be as described up to now when the destination is an IPv6-capable node. 12.1 IPv4 Internet Header Length Field The IPv4 IHL field of IPv64 packets MUST be set to 15 decimal so as to consider the IPv6 header as included into the Options part of the IPv4 header. 12.2 IPv6 Traffic Class Field The value of this field is combined with the value in the IPv6 Internet Protocol Field and the value in the IPv6 Flow Label Field in order to resemble the first two octets in the IPv4 Options field. Therefore, its value MUST be set to 11110001 binary. A. Azcorra Informational - Expires June 4, 2002 10 INTERNET DRAFT IPv64 Specification December 5, 2001 This usage does not prevent the utilization of Differentiated Services, because when processing any IPv64 packet at an IPv6 router the value contained in the IPv4 TOS field MUST be used as the value to apply the correct PHB to this packet. In case the router is an edge router and remarking is needed, then the corresponding value MUST be coded in the TOS field of the IPv4 header of the outgoing IPv64 packet, but MUST NOT be coded in the IPv6 Traffic Class Field. 12.3 IPv6 Flow Label Field The highest order four bits of the IPv6 Flow Label Field MUST be set to binary 0100. The remaining bits of the IPv6 Flow Label Field may be set to any value that the source node decides. 12.4 Resulting IPv4 Options Field The above values result in the following coding for the IPv4 Option Type and Option Length: Type Length +--------+--------+ |01101111|00010100| +--------+--------+ Type: Copied flag: 0 (fragments must not carry the option) Option class: 11 (Reserved for future use) Option number: 01111 (15 decimal) Length: 0101000 (40 decimal) The selection of the option class (Reserved) is a side effect of the coding of the Internet Protocol Version Field (value 0110 binary). The selection of the option number 15 decimal has been done taking into account that the high-order bit has to be zero (the last bit in the Internet Version Field), and therefore it is not possible to select a currently unassigned number. The Assigned Numbers RFC states that value 15 is reserved for VerSteeg. In case it is not possible to use instead value 15 for this feature, it would be needed to vacate other option number below 15. If this is not considered possible, the only other solution would be to code an odd value (e.g. 7 decimal) in the Internet Protocol Version Field, which does not seem a very desirable solution. The remaining 38 octets in the IPv4 options field consist of the IPv4 option data, and their value depends on the actual value of the IPv6 header, without further restrictions. A. Azcorra Informational - Expires June 4, 2002 11 INTERNET DRAFT IPv64 Specification December 5, 2001 12.5 IPv4 Protocol Field This field must carry the protocol identifier of the actual upper layer protocol data unit contained in the IPv6 packet payload, instead of a specific value to identify the enclosed IPv6 packet. 12.6 IPv4 Fragmentation fields In-transit IPv4 fragmentation is not permitted because it would not copy the IPv6 header, neither the IPv6 extension headers, to the fragments following the first one. For this reason, the DF bit MUST be set to 1. As IPv6 fragmentation may not be used in this case (the destination node is IPv4-only), IPv4 fragmentation will be needed when it is desired to send a payload that implies a datagram size above the path MTU. Then, source-node IPv4 fragmentation MUST be used, and therefore the values of the IPv4 fragmentation fields (Identification, MF and Offset) should be coded by the source node according to the fragmentation specification of IPv4 in RFC 791, taking into account the following aspect. IPv6 extension headers present in one, or more, of the fragments will be removed before the packet arrives to its final destination. Therefore their length MUST NOT be taken into account when calculating the value of the IPv4 Fragment Offset field in each fragment. This is, the values coded in the Fragment Offset field of the fragments MUST be calculated as in the standard RFC 791 way, taking into account only the IPv6 data payload, ignoring the existence of IPv6 extension header octets, in case they are present. 12.7 IPv6 Extension Headers End-to-end IPv6 extension headers can not be used because the destination is an IPv4-only node. IPv6 routing and hop-by-hop extension headers can be used as long as it is guaranteed that they will be removed by in-transit IPv6 routers, and will not arrive to the destination node. For routing headers, the IPv6 router MUST take into account the IPv4 header in the incoming IPv64 packet in order to generate a correct IPv4 header for the outgoing IPv64 packet. 12.8 IPv4 Options As the maximum variable part of the IPv4 header is used to carry the IPv6 header, then no IPv4 options may be used in IPv64 packets sent in IPv4-compatible format. A. Azcorra Informational - Expires June 4, 2002 12 INTERNET DRAFT IPv64 Specification December 5, 2001 12.9 Address Resolution Notice that the address resolution function is performed first using the IPv6 destination address. This allows that an IPv4-only host with only a private IPv4 address receives IPv64 packets addressed to a public IPv6 address assigned to it, as long as an IPv6-capable router is attached to its same subnetwork. A. Azcorra Informational - Expires June 4, 2002 13 INTERNET DRAFT IPv64 Specification December 5, 2001 References [RFC-2460] Deering, S., et. al., "Internet Protocol Version 6 Specification", RFC 2460, December 1998. [RFC-2474] Nichols, K., et. al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC-2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP",RFC 2481, January 1999. A. Azcorra Informational - Expires June 4, 2002 14 INTERNET DRAFT IPv64 Specification December 5, 2001 Author's Addresses Arturo Azcorra Universidad Carlos 3 de Madrid Av. Universidad 30 28911 Leganes (Madrid) SPAIN Email: azcorra@it.uc3m.es Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. A. Azcorra Informational - Expires June 4, 2002 15