From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2472.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc2472.txt (limited to 'doc/rfc/rfc2472.txt') diff --git a/doc/rfc/rfc2472.txt b/doc/rfc/rfc2472.txt new file mode 100644 index 0000000..00d257e --- /dev/null +++ b/doc/rfc/rfc2472.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group D. Haskin +Request for Comments: 2472 E. Allen +Obsoletes: 2023 Bay Networks, Inc. +Category: Standards Track December 1998 + + + IP Version 6 over PPP + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method of + encapsulating Network Layer protocol information over point-to-point + links. PPP also defines an extensible Link Control Protocol, and + proposes a family of Network Control Protocols (NCPs) for + establishing and configuring different network-layer protocols. + + This document defines the method for transmission of IP Version 6 [2] + packets over PPP links as well as the Network Control Protocol (NCP) + for establishing and configuring the IPv6 over PPP. It also specifies + the method of forming IPv6 link-local addresses on PPP links. + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1. Specification of Requirements ..................... 2 + 2. Sending IPv6 Datagrams ................................ 2 + 3. A PPP Network Control Protocol for IPv6 ............... 3 + 4. IPV6CP Configuration Options .......................... 4 + 4.1. Interface-Identifier .............................. 4 + 4.2. IPv6-Compression-Protocol.......................... 9 + 5. Stateless Autoconfiguration and Link-Local Addresses .. 10 + 6 Security Considerations ............................... 11 + 7 Acknowledgments ....................................... 11 + 8 Changes from RFC-2023 ................................. 11 + 9 References ............................................ 12 + 10 Authors' Addresses .................................... 13 + + + +Haskin & Allen Standards Track [Page 1] + +RFC 2472 IP Version 6 over PPP December 1998 + + + 11 Full Copyright Statement .............................. 14 + +1. Introduction + + PPP has three main components: + + 1) A method for encapsulating datagrams over serial links. + + 2) A Link Control Protocol (LCP) for establishing, configuring, and + testing the data-link connection. + + 3) A family of Network Control Protocols (NCPs) for establishing and + configuring different network-layer protocols. + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure and test + the data link. After the link has been established and optional + facilities have been negotiated as needed by the LCP, PPP must send + NCP packets to choose and configure one or more network-layer + protocols. Once each of the chosen network-layer protocols has been + configured, datagrams from each network-layer protocol can be sent + over the link. + + In this document, the NCP for establishing and configuring the IPv6 + over PPP is referred as the IPv6 Control Protocol (IPV6CP). + + The link will remain configured for communications until explicit LCP + or NCP packets close the link down, or until some external event + occurs (power failure at the other end, carrier drop, etc.). + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. + + 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 [7]. + +2. Sending IPv6 Datagrams + + Before any IPv6 packets may be communicated, PPP MUST reach the + Network-Layer Protocol phase, and the IPv6 Control Protocol MUST + reach the Opened state. + + Exactly one IPv6 packet is encapsulated in the Information field of + PPP Data Link Layer frames where the Protocol field indicates type + hex 0057 (Internet Protocol Version 6). + + + +Haskin & Allen Standards Track [Page 2] + +RFC 2472 IP Version 6 over PPP December 1998 + + + The maximum length of an IPv6 packet transmitted over a PPP link is + the same as the maximum length of the Information field of a PPP data + link layer frame. PPP links supporting IPv6 MUST allow the + information field at least as large as the minimum link MTU size + required for IPv6 [2]. + +3. A PPP Network Control Protocol for IPv6 + + The IPv6 Control Protocol (IPV6CP) is responsible for configuring, + enabling, and disabling the IPv6 protocol modules on both ends of the + point-to-point link. IPV6CP uses the same packet exchange mechanism + as the Link Control Protocol (LCP). IPV6CP packets may not be + exchanged until PPP has reached the Network-Layer Protocol phase. + IPV6CP packets received before this phase is reached should be + silently discarded. + + The IPv6 Control Protocol is exactly the same as the Link Control + Protocol [1] with the following exceptions: + + Data Link Layer Protocol Field + + Exactly one IPV6CP packet is encapsulated in the Information + field of PPP Data Link Layer frames where the Protocol field + indicates type hex 8057 (IPv6 Control Protocol). + + Code field + + Only Codes 1 through 7 (Configure-Request, Configure-Ack, + Configure-Nak, Configure-Reject, Terminate-Request, + Terminate-Ack and Code-Reject) are used. Other Codes should + be treated as unrecognized and should result in Code-Rejects. + + Timeouts + + IPV6CP packets may not be exchanged until PPP has reached the + Network-Layer Protocol phase. An implementation should be + prepared to wait for Authentication and Link Quality + Determination to finish before timing out waiting for a + Configure-Ack or other response. It is suggested that an + implementation give up only after user intervention or a + configurable amount of time. + + Configuration Option Types + + IPV6CP has a distinct set of Configuration Options. + + + + + + +Haskin & Allen Standards Track [Page 3] + +RFC 2472 IP Version 6 over PPP December 1998 + + +4. IPV6CP Configuration Options + + IPV6CP Configuration Options allow negotiation of desirable IPv6 + parameters. IPV6CP uses the same Configuration Option format defined + for LCP [1], with a separate set of Options. If a Configuration + Option is not included in a Configure-Request packet, the default + value for that Configuration Option is assumed. + + Up-to-date values of the IPV6CP Option Type field are specified in + the most recent "Assigned Numbers" RFC [4]. Current values are + assigned as follows: + + 1 Interface-Identifier + 2 IPv6-Compression-Protocol + + The only IPV6CP options defined in this document are Interface- + Identifier and IPv6-Compression-Protocol. Any other IPV6CP + configuration options that can be defined over time are to be defined + in separate documents. + +4.1. Interface-Identifier + + Description + + This Configuration Option provides a way to negotiate a unique 64- + bit interface identifier to be used for the address + autoconfiguration [3] at the local end of the link (see section 5). + A Configure-Request MUST contain exactly one instance of the + Interface-Identifier option [1]. The interface identifier MUST be + unique within the PPP link; i.e. upon completion of the + negotiation different Interface-Identifier values are to be + selected for the ends of the PPP link. The interface identifier + MAY also be unique over a broader scope. + + Before this Configuration Option is requested, an implementation + chooses its tentative Interface-Identifier. The non-zero value of + the tentative Interface-Identifier SHOULD be chosen such that the + value is both unique to the link and, if possible, consistently + reproducible across initializations of the IPV6CP finite state + machine (administrative Close and reOpen, reboots, etc). The + rationale for preferring a consistently reproducible unique + interface identifier to a completely random interface identifier is + to provide stability to global scope addresses that can be formed + from the interface identifier. + + Assuming that interface identifier bits are numbered from 0 to 63 + in canonical bit order where the most significant bit is the bit + number 0, the bit number 6 is the "u" bit (universal/local bit + + + +Haskin & Allen Standards Track [Page 4] + +RFC 2472 IP Version 6 over PPP December 1998 + + + in IEEE EUI-64 [5] terminology) which indicates whether or not the + interface identifier is based on a globally unique IEEE identifier + (EUI-48 or EUI-64 [5]) (see the case 1 below). It is set to + one (1) if a globally unique IEEE identifier is used to derive + the interface identifier, and it is set to zero (0) otherwise. + + The following are methods for choosing the tentative Interface + Identifier in the preference order: + + 1) If an IEEE global identifier (EUI-48 or EUI-64) is + available anywhere on the node, it should be used to construct + the tentative Interface-Identifier due to its uniqueness + properties. When extracting an IEEE global identifier from + another device on the node, care should be taken to that the + extracted identifier is presented in canonical ordering [8]. + + The only transformation from an EUI-64 identifier is to invert + the "u" bit (universal/local bit in IEEE EUI-64 terminology). + For example, for a globally unique EUI-64 identifier of the + form: + + most-significant least-significant + bit bit + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+----------------+ + + where "c" are the bits of the assigned company_id, "0" is the + value of the universal/local bit to indicate global scope, "g" + is group/individual bit, and "e" are the bits of the extension + identifier, + + the IPv6 interface identifier would be of the form: + + most-significant least-significant + bit bit + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+----------------+ + + The only change is inverting the value of the universal/local + bit. + + + + + +Haskin & Allen Standards Track [Page 5] + +RFC 2472 IP Version 6 over PPP December 1998 + + + In the case of a EUI-48 identifier, it is first converted to the + EUI-64 format by inserting two bytes, with hexadecimal values of + 0xFF and 0xFE, in the middle of the 48 bit MAC (between the + company_id and extension-identifier portions of the EUI-48 + value). For example, for a globally unique 48 bit EUI-48 + identifier of the form: + + most-significant least-significant + bit bit + |0 1|1 3|3 4| + |0 5|6 1|2 7| + +----------------+----------------+----------------+ + |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+ + + where "c" are the bits of the assigned company_id, "0" is the + value of the universal/local bit to indicate global scope, "g" + is group/individual bit, and "e" are the bits of the extension + identifier, the IPv6 interface identifier would be of the form: + + most-significant least-significant + bit bit + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+----------------+ + + 2) If an IEEE global identifier is not available a different source + of uniqueness should be used. Suggested sources of uniqueness + include link-layer addresses, machine serial numbers, et cetera. + + In this case the "u" bit of the interface identifier MUST be set + to zero (0). + + 3) If a good source of uniqueness cannot be found, it is + recommended that a random number be generated. In this case the + "u" bit of the interface identifier MUST be set to zero (0). + + Good sources [1] of uniqueness or randomness are required for the + Interface-Identifier negotiation to succeed. If neither a unique + number or a random number can be generated it is recommended that a + zero value be used for the Interface-Identifier transmitted in the + Configure-Request. In this case the PPP peer may provide a valid + non-zero Interface-Identifier in its response as described below. + Note that if at least one of the PPP peers is able to generate + separate non-zero numbers for itself and its peer, the identifier + negotiation will succeed. + + + +Haskin & Allen Standards Track [Page 6] + +RFC 2472 IP Version 6 over PPP December 1998 + + + When a Configure-Request is received with the Interface-Identifier + Configuration Option and the receiving peer implements this option, + the received Interface-Identifier is compared with the Interface- + Identifier of the last Configure-Request sent to the peer. + Depending on the result of the comparison an implementation MUST + respond in one of the following ways: + + If the two Interface-Identifiers are different but the received + Interface-Identifier is zero, a Configure-Nak is sent with a non- + zero Interface-Identifier value suggested for use by the remote + peer. Such a suggested Interface-Identifier MUST be different from + the Interface-Identifier of the last Configure-Request sent to the + peer. It is recommended that the value suggested be consistently + reproducible across initializations of the IPV6CP finite state + machine (administrative Close and reOpen, reboots, etc). The "u" + universal/local) bit of the suggested identifier MUST be set to + zero (0) regardless of its source unless the globally unique EUI- + 48/EUI-64 derived identifier is provided for the exclusive use by + the remote peer. + + If the two Interface-Identifiers are different and the received + Interface-Identifier is not zero, the Interface-Identifier MUST be + acknowledged, i.e. a Configure-Ack is sent with the requested + Interface-Identifier, meaning that the responding peer agrees with + the Interface-Identifier requested. + + If the two Interface-Identifiers are equal and are not zero, a + Configure-Nak MUST be sent specifying a different non-zero + Interface-Identifier value suggested for use by the remote peer. + It is recommended that the value suggested be consistently + reproducible across initializations of the IPV6CP finite state + machine (administrative Close and reOpen, reboots, etc). The "u" + universal/local) bit of the suggested identifier MUST be set to + zero (0) regardless of its source unless the globally unique EUI- + 48/EUI-64 derived identifier is provided for the exclusive use by + the remote peer. + + If the two Interface-Identifiers are equal to zero, the Interface- + Identifiers negotiation MUST be terminated by transmitting the + Configure-Reject with the Interface-Identifier value set to zero. + In this case a unique Interface-Identifier can not be negotiated. + + If a Configure-Request is received with the Interface-Identifier + Configuration Option and the receiving peer does not implement this + option, Configure-Rej is sent. + + + + + + +Haskin & Allen Standards Track [Page 7] + +RFC 2472 IP Version 6 over PPP December 1998 + + + A new Configure-Request SHOULD NOT be sent to the peer until normal + processing would cause it to be sent (that is, until a Configure- + Nak is received or the Restart timer runs out). + + A new Configure-Request MUST NOT contain the Interface-Identifier + option if a valid Interface-Identifier Configure-Reject is + received. + + Reception of a Configure-Nak with a suggested Interface-Identifier + different from that of the last Configure-Nak sent to the peer + indicates a unique Interface-Identifier. In this case a new + Configure-Request MUST be sent with the identifier value suggested + in the last Configure-Nak from the peer. But if the received + Interface-Identifier is equal to the one sent in the last + Configure-Nak, a new Interface-Identifier MUST be chosen. In this + case, a new Configure-Request SHOULD be sent with the new tentative + Interface-Identifier. This sequence (transmit Configure-Request, + receive Configure-Request, transmit Configure-Nak, receive + Configure-Nak) might occur a few times, but it is extremely + unlikely to occur repeatedly. More likely, the Interface- + Identifiers chosen at either end will quickly diverge, terminating + the sequence. + + If negotiation of the Interface-Identifier is required, and the + peer did not provide the option in its Configure-Request, the + option SHOULD be appended to a Configure-Nak. The tentative value + of the Interface-Identifier given must be acceptable as the remote + Interface-Identifier; i.e. it should be different from the + identifier value selected for the local end of the PPP link. The + next Configure-Request from the peer may include this option. If + the next Configure-Request does not include this option the peer + MUST NOT send another Configure-Nak with this option included. It + should assume that the peer's implementation does not support this + option. + + By default, an implementation SHOULD attempt to negotiate the + Interface-Identifier for its end of the PPP connection. + + A summary of the Interface-Identifier Configuration Option format is + shown below. The fields are transmitted from left to right. + + + + + + + + + + + +Haskin & Allen Standards Track [Page 8] + +RFC 2472 IP Version 6 over PPP December 1998 + + + 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 | Interface-Identifier (MS Bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Interface-Identifier (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Interface-Identifier (LS Bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 1 + + Length + + 10 + + Interface-Identifier + + The 64-bit Interface-Identifier which is very likely to be unique on + the link or zero if a good source of uniqueness can not be found. + + Default + + If no valid interface identifier can be successfully negotiated, no + default Interface-Identifier value should be assumed. The procedures + for recovering from such a case are unspecified. One approach is to + manually configure the interface identifier of the interface. + +4.2. IPv6-Compression-Protocol + + Description + + This Configuration Option provides a way to negotiate the use of a + specific IPv6 packet compression protocol. The + IPv6-Compression-Protocol Configuration Option is used to indicate the + ability to receive compressed packets. Each end of the link must + separately request this option if bi-directional compression is + desired. By default, compression is not enabled. + + IPv6 compression negotiated with this option is specific to IPv6 + datagrams and is not to be confused with compression resulting from + negotiations via Compression Control Protocol (CCP), which potentially + effect all datagrams. + + A summary of the IPv6-Compression-Protocol Configuration Option format + is shown below. The fields are transmitted from left to right. + + + +Haskin & Allen Standards Track [Page 9] + +RFC 2472 IP Version 6 over PPP December 1998 + + + 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 | IPv6-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 2 + + Length + + >= 4 + + IPv6-Compression-Protocol + + The IPv6-Compression-Protocol field is two octets and indicates + the compression protocol desired. Values for this field are + always the same as the PPP Data Link Layer Protocol field values + for that same compression protocol. + + No IPv6-Compression-Protocol field values are currently assigned. + Specific assignments will be made in documents that define + specific compression algorithms. + + Data + + The Data field is zero or more octets and contains additional + data as determined by the particular compression protocol. + + Default + + No IPv6 compression protocol enabled. + +5. Stateless Autoconfiguration and Link-Local Addresses + + The Interface Identifier of IPv6 unicast addresses [6] of a PPP + interface, SHOULD be negotiated in the IPV6CP phase of the PPP + connection setup (see section 4.1). If no valid Interface Identifier + has been successfully negotiated, procedures for recovering from such + a case are unspecified. One approach is to manually configure the + Interface Identifier of the interface. + + As long as the Interface Identifier is negotiated in the IPV6CP phase + of the PPP connection setup, it is redundant to perform duplicate + address detection as a part of the IPv6 Stateless Autoconfiguration + + + +Haskin & Allen Standards Track [Page 10] + +RFC 2472 IP Version 6 over PPP December 1998 + + + protocol [3]. Therefore it is recommended that for PPP links with + the IPV6CP Interface-Identifier option enabled the default value of + the DupAddrDetectTransmits autoconfiguration variable [3] be zero. + + Link-local addresses of PPP interfaces have the following format: + + | 10 bits | 54 bits | 64 bits | + +----------+------------------------+-----------------------------+ + |1111111010| 0 | Interface Identifier | + +----------+------------------------+-----------------------------+ + + The most significant 10 bits of the address is the Link-Local prefix + FE80::. 54 zero bits pad out the address between the Link-Local + prefix and the Interface Identifier fields. + +6. Security Considerations + + The IPv6 Control Protocol extension to PPP can be used with all + defined PPP authentication and encryption mechanisms. + +7. Acknowledgments + + This document borrows from the Magic-Number LCP option and as such is + partially based on previous work done by the PPP working group. + +8. Changes from RFC-2023 + + The following changes were made from RFC-2023 "IP Version 6 over + PPP": + + - Changed to use "Interface Identifier" instead of the "Interface + Token" term according to the terminology adopted in [6]. + + - Increased the size of Interface Identifier to 64 bits according to + the newly adopted IPv6 addressing architecture [6]. + + - Added methods for selection of an interface identifier that is + consistently reproducible across initializations of the IPV6CP + finite state machine. + + - Added the interface identifier selection methods for generating + globally unique interface identifier from an unique an IEEE global + identifier when it is available anywhere on the node. + + - Changed to send a Configure-Nak instead a Configure-Ack in response + to receiving a Configure-Request with a zero Interface-Identifier + value. + + + + +Haskin & Allen Standards Track [Page 11] + +RFC 2472 IP Version 6 over PPP December 1998 + + + - Replaced the value assignment of the IPv6-Compression-Protocol + field of the IPv6-Compression-Protocol Configuration option with + the text stating that no IPv6-Compression-Protocol field values are + currently assigned and that specific assignments will be made in + documents that define specific compression algorithms. + + - Added new and updated references. + + - Minor text clarifications and improvements. + +9. References + + [1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC + 1661, July 1994. + + [2] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. + + [3] Thomson, S., and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, October 1994. See also: http://www.iana.org/numbers.html + + [5] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) + Registration Authority", + http://standards.ieee.org/db/oui/tutorials/EUI64.html, March + 1997. + + [6] Hinden, R., and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels," BCP 14, RFC 2119, March 1997. + + [8] Narten T., and C. Burton, "A Caution On The Canonical Ordering + Of Link-Layer Addresses", RFC 2469, December 1998. + + + + + + + + + + + + + + +Haskin & Allen Standards Track [Page 12] + +RFC 2472 IP Version 6 over PPP December 1998 + + +10. Authors' Addresses + + Dimitry Haskin + Bay Networks, Inc. + 600 Technology Park + Billerica, MA 01821 + + EMail: dhaskin@baynetworks.com + + + Ed Allen + Bay Networks, Inc. + 600 Technology Park + Billerica, MA 01821 + + EMail: eallen@baynetworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Haskin & Allen Standards Track [Page 13] + +RFC 2472 IP Version 6 over PPP December 1998 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (1998). 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. + + + + + + + + + + + + + + + + + + + + + + + + +Haskin & Allen Standards Track [Page 14] + -- cgit v1.2.3