diff options
Diffstat (limited to 'rfc/rfc3046.txt')
| -rw-r--r-- | rfc/rfc3046.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/rfc/rfc3046.txt b/rfc/rfc3046.txt new file mode 100644 index 0000000..18d7014 --- /dev/null +++ b/rfc/rfc3046.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group M. Patrick +Request for Comments: 3046 Motorola BCS +Category: Standards Track January 2001 + + + DHCP Relay Agent Information Option + +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 (2001). All Rights Reserved. + +Abstract + + Newer high-speed public Internet access technologies call for a + high-speed modem to have a local area network (LAN) attachment to one + or more customer premise hosts. It is advantageous to use the + Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to + assign customer premise host IP addresses in this environment. + However, a number of security and scaling problems arise with such + "public" DHCP use. This document describes a new DHCP option to + address these issues. This option extends the set of DHCP options as + defined in RFC 2132. + + The new option is called the Relay Agent Information option and is + inserted by the DHCP relay agent when forwarding client-originated + DHCP packets to a DHCP server. Servers recognizing the Relay Agent + Information option may use the information to implement IP address or + other parameter assignment policies. The DHCP Server echoes the + option back verbatim to the relay agent in server-to-client replies, + and the relay agent strips the option before forwarding the reply to + the client. + + The "Relay Agent Information" option is organized as a single DHCP + option that contains one or more "sub-options" that convey + information known by the relay agent. The initial sub-options are + defined for a relay agent that is co-located in a public circuit + access unit. These include a "circuit ID" for the incoming circuit, + and a "remote ID" which provides a trusted identifier for the remote + high-speed modem. + + + + +Patrick Standards Track [Page 1] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + +Table of Contents + + 1 Introduction........................................... 2 + 1.1 High-Speed Circuit Switched Data Networks.............. 2 + 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4 + 2.0 Relay Agent Information Option......................... 5 + 2.1 Agent Operation........................................ 6 + 2.1.1 Reforwarded DHCP requests............................ 7 + 2.2 Server Operation....................................... 7 + 3.0 Relay Agent Information Suboptions..................... 8 + 3.1 Agent Circuit ID....................................... 8 + 3.2 Agent Remote ID........................................ 9 + 4.0 Issues Resolved........................................ 9 + 5.0 Security Considerations................................ 10 + 6.0 IANA Considerations.................................... 11 + 7.0 Intellectual Property Notice........................... 12 + 8.0 References............................................. 12 + 9.0 Glossary............................................... 13 + 10.0 Author's Address...................................... 13 + 11.0 Full Copyright Statement ............................. 14 + +1 Introduction + +1.1 High-Speed Circuit Switched Data Networks + + Public Access to the Internet is usually via a circuit switched data + network. Today, this is primarily implemented with dial-up modems + connecting to a Remote Access Server. But higher speed circuit + access networks also include ISDN, ATM, Frame Relay, and Cable Data + Networks. All of these networks can be characterized as a "star" + topology where multiple users connect to a "circuit access unit" via + switched or permanent circuits. + + With dial-up modems, only a single host PC attempts to connect to the + central point. The PPP protocol is widely used to assign IP + addresses to be used by the single host PC. + + The newer high-speed circuit technologies, however, frequently + provide a LAN interface (especially Ethernet) to one or more host + PCs. It is desirable to support centralized assignment of the IP + addresses of host computers connecting on such circuits via DHCP. + The DHCP server can be, but usually is not, co-implemented with the + centralized circuit concentration access device. The DHCP server is + often connected as a separate server on the "Central LAN" to which + the central access device (or devices) attach. + + + + + + +Patrick Standards Track [Page 2] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + + A common physical model for high-speed Internet circuit access is + shown in Figure 1, below. + + +---------------+ | + Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A + LAN | | Access | Lan |- Host B + | | Unit 1 | |- Host C + |-----| |-- | + | |(relay agent) |... ++---------+ | +---------------+ +| DHCP |--| +| Server | | ++---------+ | + | + | +---------------+ ++---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D +| Other | | | Access | Lan +| Servers |--|-----| Unit 2 | +| (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E +| DNS) | | |(relay agent) |... Lan +| | +---------------+ ++---------+ + + Figure 1: DHCP High Speed Circuit Access Model + + Note that in this model, the "modem" connects to a LAN at the user + site, rather than to a single host. Multiple hosts are implemented + at this site. Although it is certainly possible to implement a full + IP router at the user site, this requires a relatively expensive + piece of equipment (compared to typical modem costs). Furthermore, a + router requires an IP address not only for every host, but for the + router itself. Finally, a user-side router requires a dedicated + Logical IP Subnet (LIS) for each user. While this model is + appropriate for relatively small corporate networking environments, + it is not appropriate for large, public accessed networks. In this + scenario, it is advantageous to implement an IP networking model that + does not allocate an IP address for the modem (or other networking + equipment device at the user site), and especially not an entire LIS + for the user side LAN. + + Note that using this method to obtain IP addresses means that IP + addresses can only be obtained while communication to the central + site is available. Some host lan installations may use a local DHCP + server or other methods to obtain IP addresses for in-house use. + + + + + + + +Patrick Standards Track [Page 3] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + +1.2 DHCP Relay Agent in the Circuit Access Unit + + It is desirable to use DHCP to assign the IP addresses for public + high-speed circuit access. A number of circuit access units (e.g., + RAS's, cable modem termination systems, ADSL access units, etc) + connect to a LAN (or local internet) to which is attached a DHCP + server. + + For scaling and security reasons, it is advantageous to implement a + "router hop" at the circuit access unit, much like high-capacity + RAS's do today. The circuit access equipment acts as both a router + to the circuits and as the DHCP relay agent. + + The advantages of co-locating the DHCP relay agent with the circuit + access equipment are: + + DHCP broadcast replies can be routed to only the proper circuit, + avoiding, say, the replication of the DCHP reply broadcast onto + thousands of access circuits; + + The same mechanism used to identify the remote connection of the + circuit (e.g., a user ID requested by a Remote Access Server acting + as the circuit access equipment) may be used as a host identifier by + DHCP, and used for parameter assignment. This includes centralized + assignment of IP addresses to hosts. This provides a secure remote + ID from a trusted source -- the relay agent. + + A number of issues arise when forwarding DHCP requests from hosts + connecting publicly accessed high-speed circuits with LAN connections + at the host. Many of these are security issues arising from DHCP + client requests from untrusted sources. How does the relay agent + know to which circuit to forward replies? How does the system + prevent DHCP IP exhaustion attacks? This is when an attacker + requests all available IP addresses from a DHCP server by sending + requests with fabricated client MAC addresses. How can an IP address + or LIS be permanently assigned to a particular user or modem? How + does one prevent "spoofing" of client identifier fields used to + assign IP addresses? How does one prevent denial of service by + "spoofing" other client's MAC addresses? + + All of these issues may be addressed by having the circuit access + equipment, which is a trusted component, add information to DHCP + client requests that it forwards to the DHCP server. + + + + + + + + +Patrick Standards Track [Page 4] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + +2.0 Relay Agent Information Option + + This document defines a new DHCP Option called the Relay Agent + Information Option. It is a "container" option for specific agent- + supplied sub-options. The format of the Relay Agent Information + option is: + + Code Len Agent Information Field + +------+------+------+------+------+------+--...-+------+ + | 82 | N | i1 | i2 | i3 | i4 | | iN | + +------+------+------+------+------+------+--...-+------+ + + The length N gives the total number of octets in the Agent + Information Field. The Agent Information field consists of a + sequence of SubOpt/Length/Value tuples for each sub-option, encoded + in the following manner: + + SubOpt Len Sub-option Value + +------+------+------+------+------+------+--...-+------+ + | 1 | N | s1 | s2 | s3 | s4 | | sN | + +------+------+------+------+------+------+--...-+------+ + SubOpt Len Sub-option Value + +------+------+------+------+------+------+--...-+------+ + | 2 | N | i1 | i2 | i3 | i4 | | iN | + +------+------+------+------+------+------+--...-+------+ + + No "pad" sub-option is defined, and the Information field shall NOT + be terminated with a 255 sub-option. The length N of the DHCP Agent + Information Option shall include all bytes of the sub-option + code/length/value tuples. Since at least one sub-option must be + defined, the minimum Relay Agent Information length is two (2). The + length N of the sub-options shall be the number of octets in only + that sub-option's value field. A sub-option length may be zero. The + sub-options need not appear in sub-option code order. + + The initial assignment of DHCP Relay Agent Sub-options is as follows: + + DHCP Agent Sub-Option Description + Sub-option Code + --------------- ---------------------- + 1 Agent Circuit ID Sub-option + 2 Agent Remote ID Sub-option + + + + + + + + + +Patrick Standards Track [Page 5] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + +2.1 Agent Operation + + Overall adding of the DHCP relay agent option SHOULD be configurable, + and SHOULD be disabled by default. Relay agents SHOULD have separate + configurables for each sub-option to control whether it is added to + client-to-server packets. + + A DHCP relay agent adding a Relay Agent Information field SHALL add + it as the last option (but before 'End Option' 255, if present) in + the DHCP options field of any recognized BOOTP or DHCP packet + forwarded from a client to a server. + + Relay agents receiving a DHCP packet from an untrusted circuit with + giaddr set to zero (indicating that they are the first-hop router) + but with a Relay Agent Information option already present in the + packet SHALL discard the packet and increment an error count. A + trusted circuit may contain a trusted downstream (closer to client) + network element (bridge) between the relay agent and the client that + MAY add a relay agent option but not set the giaddr field. In this + case, the relay agent does NOT add a "second" relay agent option, but + forwards the DHCP packet per normal DHCP relay agent operations, + setting the giaddr field as it deems appropriate. + + The mechanisms for distinguishing between "trusted" and "untrusted" + circuits are specific to the type of circuit termination equipment, + and may involve local administration. For example, a Cable Modem + Termination System may consider upstream packets from most cable + modems as "untrusted", but an ATM switch terminating VCs switched + through a DSLAM may consider such VCs as "trusted" and accept a relay + agent option added by the DSLAM. + + Relay agents MAY have a configurable for the maximum size of the DHCP + packet to be created after appending the Agent Information option. + Packets which, after appending the Relay Agent Information option, + would exceed this configured maximum size shall be forwarded WITHOUT + adding the Agent Information option. An error counter SHOULD be + incremented in this case. In the absence of this configurable, the + agent SHALL NOT increase a forwarded DHCP packet size to exceed the + MTU of the interface on which it is forwarded. + + The Relay Agent Information option echoed by a server MUST be removed + by either the relay agent or the trusted downstream network element + which added it when forwarding a server-to-client response back to + the client. + + + + + + + +Patrick Standards Track [Page 6] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + + The agent SHALL NOT add an "Option Overload" option to the packet or + use the "file" or "sname" fields for adding Relay Agent Information + option. It SHALL NOT parse or remove Relay Agent Information options + that may appear in the sname or file fields of a server-to-client + packet forwarded through the agent. + + The operation of relay agents for specific sub-options is specified + with that sub-option. + + Relay agents are NOT required to monitor or modify client-originated + DHCP packets addressed to a server unicast address. This includes + the DHCP-REQUEST sent when entering the RENEWING state. + + Relay agents MUST NOT modify DHCP packets that use the IPSEC + Authentication Header or IPSEC Encapsulating Security Payload [6]. + +2.1.1 Reforwarded DHCP requests + + A DHCP relay agent may receive a client DHCP packet forwarded from a + BOOTP/DHCP relay agent closer to the client. Such a packet will have + giaddr as non-zero, and may or may not already have a DHCP Relay + Agent option in it. + + Relay agents configured to add a Relay Agent option which receive a + client DHCP packet with a nonzero giaddr SHALL discard the packet if + the giaddr spoofs a giaddr address implemented by the local agent + itself. + + Otherwise, the relay agent SHALL forward any received DHCP packet + with a valid non-zero giaddr WITHOUT adding any relay agent options. + Per RFC 2131, it shall also NOT modify the giaddr value. + +2.2 Server Operation + + DHCP servers unaware of the Relay Agent Information option will + ignore the option upon receive and will not echo it back on + responses. This is the specified server behavior for unknown + options. + + DHCP servers claiming to support the Relay Agent Information option + SHALL echo the entire contents of the Relay Agent Information option + in all replies. Servers SHOULD copy the Relay Agent Information + option as the last DHCP option in the response. Servers SHALL NOT + place the echoed Relay Agent Information option in the overloaded + sname or file fields. If a server is unable to copy a full Relay + Agent Information field into a response, it SHALL send the response + without the Relay Information Field, and SHOULD increment an error + counter for the situation. + + + +Patrick Standards Track [Page 7] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + + The operation of DHCP servers for specific sub-options is specified + with that sub-option. + + Note that DHCP relay agents are not required to monitor unicast DHCP + messages sent directly between the client and server (i.e., those + that aren't sent via a relay agent). However, some relay agents MAY + chose to do such monitoring and add relay agent options. + Consequently, servers SHOULD be prepared to handle relay agent + options in unicast messages, but MUST NOT expect them to always be + there. + +3.0 Relay Agent Information Sub-options + +3.1 Agent Circuit ID Sub-option + + This sub-option MAY be added by DHCP relay agents which terminate + switched or permanent circuits. It encodes an agent-local identifier + of the circuit from which a DHCP client-to-server packet was + received. It is intended for use by agents in relaying DHCP + responses back to the proper circuit. Possible uses of this field + include: + + - Router interface number + - Switching Hub port number + - Remote Access Server port number + - Frame Relay DLCI + - ATM virtual circuit number + - Cable Data virtual circuit number + + Servers MAY use the Circuit ID for IP and other parameter assignment + policies. The Circuit ID SHOULD be considered an opaque value, with + policies based on exact string match only; that is, the Circuit ID + SHOULD NOT be internally parsed by the server. + + The DHCP server SHOULD report the Agent Circuit ID value of current + leases in statistical reports (including its MIB) and in logs. Since + the Circuit ID is local only to a particular relay agent, a circuit + ID should be qualified with the giaddr value that identifies the + relay agent. + + SubOpt Len Circuit ID + +------+------+------+------+------+------+------+------+-- + | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... + +------+------+------+------+------+------+------+------+-- + + + + + + + +Patrick Standards Track [Page 8] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + +3.2 Agent Remote ID Sub-option + + This sub-option MAY be added by DHCP relay agents which terminate + switched or permanent circuits and have mechanisms to identify the + remote host end of the circuit. The Remote ID field may be used to + encode, for instance: + + -- a "caller ID" telephone number for dial-up connection + -- a "user name" prompted for by a Remote Access Server + -- a remote caller ATM address + -- a "modem ID" of a cable data modem + -- the remote IP address of a point-to-point link + -- a remote X.25 address for X.25 connections + + The remote ID MUST be globally unique. + + DHCP servers MAY use this option to select parameters specific to + particular users, hosts, or subscriber modems. The option SHOULD be + considered an opaque value, with policies based on exact string match + only; that is, the option SHOULD NOT be internally parsed by the + server. + + The relay agent MAY use this field in addition to or instead of the + Agent Circuit ID field to select the circuit on which to forward the + DHCP reply (e.g., Offer, Ack, or Nak). DHCP servers SHOULD report + this value in any reports or MIBs associated with a particular + client. + + SubOpt Len Agent Remote ID + +------+------+------+------+------+------+------+------+-- + | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... + +------+------+------+------+------+------+------+------+-- + +4.0 Issues Resolved + + The DHCP relay agent option resolves several issues in an environment + in which untrusted hosts access the internet via a circuit based + public network. This resolution assumes that all DHCP protocol + traffic by the public hosts traverse the DHCP relay agent and that + the IP network between the DHCP relay agent and the DHCP server is + uncompromised. + + Broadcast Forwarding + + The circuit access equipment forwards the normally broadcasted + DHCP response only on the circuit indicated in the Agent Circuit + ID. + + + + +Patrick Standards Track [Page 9] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + + DHCP Address Exhaustion + + In general, the DHCP server may be extended to maintain a database + with the "triplet" of + + (client IP address, client MAC address, client remote ID) + + The DHCP server SHOULD implement policies that restrict the number + of IP addresses to be assigned to a single remote ID. + + Static Assignment + + The DHCP server may use the remote ID to select the IP address to + be assigned. It may permit static assignment of IP addresses to + particular remote IDs, and disallow an address request from an + unauthorized remote ID. + + IP Spoofing + + The circuit access device may associate the IP address assigned by + a DHCP server in a forwarded DHCP Ack packet with the circuit to + which it was forwarded. The circuit access device MAY prevent + forwarding of IP packets with source IP addresses -other than- + those it has associated with the receiving circuit. This prevents + simple IP spoofing attacks on the Central LAN, and IP spoofing of + other hosts. + + Client Identifier Spoofing + + By using the agent-supplied Agent Remote ID option, the untrusted + and as-yet unstandardized client identifier field need not be used + by the DHCP server. + + MAC Address Spoofing + + By associating a MAC address with an Agent Remote ID, the DHCP + server can prevent offering an IP address to an attacker spoofing + the same MAC address on a different remote ID. + +5.0 Security Considerations + + DHCP as currently defined provides no authentication or security + mechanisms. Potential exposures to attack are discussed in section 7 + of the DHCP protocol specification in RFC 2131 [1]. + + This document introduces mechanisms to address several security + attacks on the operation of IP address assignment, including IP + spoofing, Client ID spoofing, MAC address spoofing, and DHCP server + + + +Patrick Standards Track [Page 10] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + + address exhaustion. It relies on an implied trusted relationship + between the DHCP Relay Agent and the DHCP server, with an assumed + untrusted DHCP client. It introduces a new identifer, the "Remote + ID", that is also assumed to be trusted. The Remote ID is provided + by the access network or modem and not by client premise equipment. + Cryptographic or other techniques to authenticate the remote ID are + certainly possible and encouraged, but are beyond the scope of this + document. + + This option is targeted towards environments in which the network + infrastructure -- the relay agent, the DHCP server, and the entire + network in which those two devices reside -- is trusted and secure. + As used in this document, the word "trusted" implies that + unauthorized DHCP traffic cannot enter the trusted network except + through secured and trusted relay agents and that all devices + internal to the network are secure and trusted. Potential deployers + of this option should give careful consideration to the potential + security vulnerabilities that are present in this model before + deploying this option in actual networks. + + Note that any future mechanisms for authenticating DHCP client to + server communications must take care to omit the DHCP Relay Agent + option from server authentication calculations. This was the + principal reason for organizing the DHCP Relay Agent Option as a + single option with sub-options, and for requiring the relay agent to + remove the option before forwarding to the client. + + While it is beyond the scope of this document to specify the general + forwarding algorithm of public data circuit access units, note that + automatic reforwarding of IP or ARP broadcast packets back downstream + exposes serious IP security risks. For example, if an upstream + broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back + downstream, any public host may easily spoof the desired DHCP server. + +6.0 IANA Considerations + + IANA is required to maintain a new number space of "DHCP Relay Agent + Sub-options", located in the BOOTP-DHCP Parameters Registry. The + initial sub-options are described in section 2.0 of this document. + + IANA assigns future DHCP Relay Agent Sub-options with a "IETF + Consensus" policy as described in RFC 2434 [3]. Future proposed + sub-options are to be referenced symbolically in the Internet-Drafts + that describe them, and shall be assigned numeric codes by IANA when + approved for publication as an RFC. + + + + + + +Patrick Standards Track [Page 11] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + +7.0 Intellectual Property Notices + + This section contains two notices as required by [5] for standards + track documents. + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + +8.0 References + + [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extension", RFC 2132, March 1997. + + [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [6] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + + + + + + + +Patrick Standards Track [Page 12] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + +9.0 Glossary + + DSLAM Digital Subscriber Link Access Multiplexer + IANA Internet Assigned Numbers Authority + LIS Logical IP Subnet + MAC Message Authentication Code + RAS Remote Access Server + +10.0 Author's Address + + Michael Patrick + Motorola Broadband Communications Sector + 20 Cabot Blvd., MS M4-30 + Mansfield, MA 02048 + + Phone: (508) 261-5707 + EMail: michael.patrick@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Patrick Standards Track [Page 13] + +RFC 3046 DHCP Relay Agent Information Option January 2001 + + +11.0 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Patrick Standards Track [Page 14] + |