idnits 2.17.1 draft-ietf-pppext-lcpext-ds-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC-1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9385 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DayDreamer' is mentioned on line 1, but not defined ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. Simpson, Editor [DayDreamer] 2 Internet Draft 3 expires in six months August 1998 5 PPP LCP Extensions - 6 draft-ietf-pppext-lcpext-ds-03.txt | 8 Status of this Memo 10 This document is an Internet-Draft. Internet Drafts are working doc- 11 uments of the Internet Engineering Task Force (IETF), its Areas, and 12 its Working Groups. Note that other groups may also distribute work- 13 ing documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months, and may be updated, replaced, or obsoleted by other documents 17 at any time. It is not appropriate to use Internet Drafts as refer- 18 ence material, or to cite them other than as a ``working draft'' or 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 23 Directories on: 25 ftp.is.co.za (Africa) 26 nic.nordu.net (Northern Europe) | 27 ftp.nis.garr.it (Southern Europe) | 28 ftp.ietf.org (Eastern USA) | 29 ftp.isi.edu (Western USA) | 30 munnari.oz.au (Pacific Rim) 32 Distribution of this memo is unlimited. 34 Copyright Notice 36 Copyright (C) William Allen Simpson (1992-1994, 1996-1998). All 37 Rights Reserved. 39 Abstract 41 The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard | 42 method for transporting multi-protocol datagrams over point-to-point 43 links. PPP defines an extensible Link Control Protocol (LCP) for 44 establishing, configuring, and testing the data-link connection. | 45 This document defines the Identification and Time-Remaining messages. | 47 1. Additional LCP Packets 49 The Packet format and basic facilities are already defined for LCP | 50 [RFC-1661]. 52 Up-to-date values of the LCP Code field are specified in the most | 53 recent "Assigned Numbers" [RFC-1700]. This document concerns the 54 following values: 56 12 Identification 57 13 Time-Remaining 59 In this document, the key words "MAY", "MUST", "MUST NOT", "recom- + 60 mended", and "SHOULD", are to be interpreted as described in + 61 [RFC-2119]. 63 1.1. Identification 65 Description 67 This Code provides a method for an implementation to identify 68 itself to its peer. This Code might be used for many diverse pur- 69 poses, such as link troubleshooting, license enforcement, etc. 71 Identification is a Link Maintenance packet. Identification pack- 72 ets MAY be sent at any time, including before LCP has reached the 73 Opened state. 75 The sender transmits a LCP packet with the Code field set to 12 76 (Identification), the Identifier field set, the local Magic-Number 77 (if any) inserted, and the Message field filled with any desired 78 data, but not exceeding the default MRU minus eight. 80 Receipt of an Identification packet causes the RXR or RUC event. 81 There is no response to the Identification packet. 83 Receipt of a Code-Reject for the Identification packet SHOULD gen- 84 erate the RXJ+ (permitted) event. 86 Rationale: 88 This feature is defined as part of LCP, rather than as a separate 89 PPP Protocol, in order that its benefits may be available during 90 the earliest possible stage of the Link Establishment phase. It 91 allows an operator to learn the identification of the peer even 92 when negotiation is not converging. Non-LCP packets cannot be 93 sent during the Link Establishment phase. 95 This feature is defined as a separate LCP Code, rather than a Con- 96 figuration-Option, so that the peer need not include it with other 97 items in configuration packet exchanges, and handle "corrected" 98 values or "rejection", since its generation is both rare and in 99 one direction. It is recommended that Identification packets be 100 sent whenever a Configure-Reject is sent or received, as a final 101 message when negotiation fails to converge, and when LCP reaches 102 the Opened state. 104 A summary of the Identification packet format is shown below. The 105 fields are transmitted from left to right. 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 108 | Code | Identifier | Length | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Magic-Number | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Message ... 113 +-+-+-+-+-+-+-+-+ 115 Code 117 12 for Identification 119 Identifier 121 The Identifier field MUST be changed for each Identification sent. 123 Length 125 >= 8 127 Magic-Number 129 The Magic-Number field is four octets and aids in detecting links 130 which are in the looped-back condition. Until the Magic-Number 131 Configuration Option has been successfully negotiated, the Magic- 132 Number MUST be transmitted as zero. See the Magic-Number Configu- 133 ration Option for further explanation. 135 Message 137 The Message field is zero or more octets, and its contents are 138 implementation dependent. It is intended to be human readable, 139 and MUST NOT affect operation of the protocol. It is recommended 140 that the message contain displayable ASCII characters 32 through 141 126 decimal. Mechanisms for extension to other character sets are 142 the topic of future research. The size is determined from the 143 Length field. 145 Implementation Note: 147 The Message will usually contain such things as the sender's 148 hardware type, PPP software revision level, and PPP product 149 serial number, MIB information such as link speed and interface 150 name, and any other information that the sender thinks might be 151 useful in debugging connections. The format is likely to be 152 different for each implementor, so that those doing serial num- 153 ber tracking can validate their numbers. A robust implementa- 154 tion SHOULD treat the Message as displayable text, and SHOULD 155 be able to receive and display a full MRU length Message. 157 1.2. Time-Remaining 159 Description 161 This Code provides a mechanism for notifying the peer of the time 162 remaining in this session. 164 The nature of this information is advisory only. It is intended 165 that only one side of the connection will send this packet (gener- 166 ally a "network access server"). The session is actually con- 167 cluded by the Terminate-Request packet. 169 Time-Remaining is a Link Maintenance packet. Time-Remaining pack- 170 ets may only be sent in the LCP Opened state. 172 The sender transmits a LCP packet with the Code field set to 13 173 (Time-Remaining), the Identifier field set, the local Magic-Number 174 (if any) inserted, and the Message field filled with any desired 175 data, but not exceeding the peer's established MRU minus twelve. 177 Receipt of an Time-Remaining packet causes the RXR or RUC event. 178 There is no response to the Time-Remaining packet. 180 Receipt of a Code-Reject for the Time-Remaining packet SHOULD gen- 181 erate the RXJ+ (permitted) event. 183 Rationale: 185 This notification is defined as a separate LCP Code, rather than a 186 Configuration-Option, in order that changes and warning messages 187 may occur dynamically during the session, and that the information 188 might be determined after Authentication has occurred. Typically, 189 this packet is sent when the link enters Network-Layer Protocol 190 phase, and at regular intervals throughout the session, particu- 191 larly near the end of the session. 193 A summary of the Time-Remaining packet format is shown below. The 194 fields are transmitted from left to right. 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 197 | Code | Identifier | Length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Magic-Number | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Seconds-Remaining | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Message ... 204 +-+-+-+-+-+-+-+-+ 206 Code 208 13 for Time-Remaining 210 Identifier 212 The Identifier field MUST be changed for each Time-Remaining sent. 214 Length 216 >= 12 218 Magic-Number 220 The Magic-Number field is four octets and aids in detecting links 221 which are in the looped-back condition. Until the Magic-Number 222 Configuration Option has been successfully negotiated, the Magic- 223 Number MUST be transmitted as zero. See the Magic-Number Configu- 224 ration Option for further explanation. 226 Seconds-Remaining 228 The Seconds-Remaining field is four octets and indicates the num- 229 ber of integral seconds remaining in this session. This 32 bit 230 unsigned value is sent most significant octet first. A value of 231 0xffffffff (all ones) represents no timeout, or "forever". 233 Message 235 The Message field is zero or more octets, and its contents are 236 implementation dependent. It is intended to be human readable, 237 and MUST NOT affect operation of the protocol. It is recommended 238 that the message contain displayable ASCII characters 32 through 239 126 decimal. Mechanisms for extension to other character sets are 240 the topic of future research. The size is determined from the 241 Length field. 243 Security Considerations 245 There are no known security vulnerabilities. 247 Changes from RFC-1570 + 249 LCP Configuration Options were removed to separate documents. + 251 Otherwise, for your reading pleasure, this document has been wrapped + 252 in updated boilerplate. It contains the complete text of the origi- + 253 nal version. Not one word has been omitted. + 255 Acknowledgements 257 The Identification feature was suggested by Bob Sutterfield. 259 The Time-Remaining feature was suggested by Brad Parker. 261 Special thanks to Ascend Communications for providing computing 262 resources and network access support for writing this specification. 264 References 266 [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 267 STD-51, DayDreamer, July 1994. | 269 [RFC-1700] Reynolds, J.K., Postel, J.B., "Assigned Numbers", STD-2, | 270 USC/Information Sciences Institute, October 1994. | 272 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate | 273 Requirement Levels", BCP-14, Harvard University, March | 274 1997. 276 Contacts 278 Comments about this document should be discussed on the ietf- 279 ppp@merit.edu mailing list. 281 This document was reviewed by the Point-to-Point Protocol Working | 282 Group of the Internet Engineering Task Force (IETF). The working 283 group can be contacted via the current chair: 285 Karl Fox 286 Ascend Communications 287 3518 Riverside Drive Suite 101 288 Columbus, Ohio 43221 290 karl@Ascend.com - 292 Questions about this document can also be directed to: 294 William Allen Simpson 295 DayDreamer 296 Computer Systems Consulting Services 297 1384 Fontaine 298 Madison Heights, Michigan 48071 300 wsimpson@UMich.edu 301 wsimpson@GreenDragon.com (preferred) 303 Full Copyright Statement + 305 Copyright (C) William Allen Simpson (1992-1994, 1996-1998). All + 306 Rights Reserved. + 308 This document and translations of it may be copied and furnished to + 309 others, and derivative works that comment on or otherwise explain it + 310 or assist in its implementation may be prepared, copied, published + 311 and distributed, in whole or in part, without restriction of any + 312 kind, provided that the above copyright notice and this paragraph are + 313 included on all such copies and derivative works. However, this doc- + 314 ument itself may not be modified in any way, except as required to + 315 translate it into languages other than English. + 317 This document and the information contained herein is provided on an + 318 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR + 319 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF + 320 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + 321 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.