idnits 2.17.1 draft-ietf-pppext-vendor-00.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-03-29) 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 64: '...Specific packets MAY be sent at any ti...' RFC 2119 keyword, line 76: '...t for the packet SHOULD generate the R...' RFC 2119 keyword, line 104: '...Identifier field MUST be changed for e...' RFC 2119 keyword, line 118: '... Number MUST be transmitted as ze...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 1996) is 10149 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) -- Looks like a reference, but probably isn't: 'RFC-1700' on line 189 ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Simpson 3 Internet Draft DayDreamer 4 expires in six months June 1996 6 PPP Vendor Extensions 7 draft-ietf-pppext-vendor-00.txt 9 Status of this Memo 11 Distribution of this memo is unlimited. 13 This document is an Internet-Draft. Internet Drafts are working doc- 14 uments of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute work- 16 ing documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months, and may be updated, replaced, or obsoleted by other documents 20 at any time. It is not appropriate to use Internet Drafts as refer- 21 ence material, or to cite them other than as a ``working draft'' or 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 26 Directories on: 28 ftp.is.co.za (Africa) 29 nic.nordu.net (Europe) 30 ds.internic.net (US East Coast) 31 ftp.isi.edu (US West Coast) 32 munnari.oz.au (Pacific Rim) 34 Abstract 36 The Point-to-Point Protocol (PPP) [1] provides a standard method for 37 transporting multi-protocol datagrams over point-to-point links. PPP 38 defines an extensible Link Control Protocol (LCP) for establishing, 39 configuring, and testing the data-link connection; and a family of 40 Network Control Protocols (NCPs) for establishing and configuring 41 different network-layer protocols. This document defines a general 42 mechanism for proprietary vendor extensions. 44 1. Control Packets 46 The Packet format and basic facilities are already defined for LCP 47 [1] and related NCPs. 49 Up-to-date values of the LCP Code field are specified in the most 50 recent "Assigned Numbers" [2]. This document concerns the following 51 values: 53 0 Vendor Specific 55 1.1. Vendor Specific Packet 57 Description 59 Some implementors might not need nor want to publish their propri- 60 etary algorithms and attributes. This mechanism is available to 61 specify these without encumbering the IANA with proprietary number 62 requests. 64 Vendor Specific packets MAY be sent at any time, including before 65 LCP has reached the Opened state. 67 The sender transmits a LCP or NCP packet with the Code field set 68 to 0 (Vendor Specific), the Identifier field set, the local Magic- 69 Number (if any) inserted, the OUI and Kind fields set, and the 70 Value(s) field filled with any desired data, but not exceeding the 71 default MRU minus twelve. 73 Receipt of a Vendor Specific packet causes the RXR or RUC event. 74 The response to the Vendor Specific packet is vender specific. 76 Receipt of a Code-Reject for the packet SHOULD generate the RXJ+ 77 (permitted) event. 79 Rationale: 81 This is defined as general feature of all PPP Control Protocols, 82 to avoid future conflicts in vendor secretly self-assigned Code 83 numbers. 85 A summary of the Vendor Specific packet format is shown below. The 86 fields are transmitted from left to right. 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | Code | Identifier | Length | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | Magic-Number | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | OUI | Kind | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Value(s) ... 96 +-+-+-+-+-+-+-+-+ 98 Code 100 0 for Vendor Specific 102 Identifier 104 The Identifier field MUST be changed for each Vendor Specific 105 packet sent. 107 Length 109 >= 12 111 When the Length is twelve, no Value(s) field is present. 113 Magic-Number 115 The Magic-Number field is four octets and aids in detecting links 116 that are in the looped-back condition. Until the Magic-Number 117 Configuration Option has been successfully negotiated, the Magic- 118 Number MUST be transmitted as zero. See the Magic-Number Configu- 119 ration Option for further explanation. 121 OUI 123 three octets. The vendor's Organizationally Unique Identifier, 124 assigned by IEEE 802 (see [RFC-1700] for contact details). The 125 bits within the octet are in canonical order, and the most signif- 126 icant octet is transmitted first. 128 Kind 130 one octet. Indicates a sub-type for the OUI. There is no stan- 131 dardization for this field. Each OUI implements its own values. 133 Value(s) 135 Zero or more octets. The details are implementation specific. 137 2. Configuration Options 139 The Configuration Option format and basic options are already defined 140 for LCP [1]. 142 Up-to-date values of the LCP Option Type field are specified in the 143 most recent "Assigned Numbers" [2]. This document concerns the fol- 144 lowing values: 146 0 Vendor-Specific 148 2.1. Vendor-Specific Option 150 Description 152 Some implementors might not need nor want to publish their propri- 153 etary algorithms and attributes. This mechanism is available to 154 specify these without encumbering the IANA with proprietary number 155 requests. 157 Before accepting this option, the implementation must verify that 158 the Organizationally Unique Identifier and Kind specify a known 159 mechanism, and that any vendor specific negotiation values are 160 fully understood. 162 Rationale: 164 This is defined as general feature of all PPP Control Protocols, 165 to avoid future conflicts in vendor secretly self-assigned Type 166 numbers. 168 A summary of the Vendor-Specific Configuration Option format is shown 169 below. The fields are transmitted from left to right. 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Length | OUI 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 ... | Kind | Value(s) ... 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 176 Type 178 0 180 Length 182 >= 6 184 When the Length is six, no Value(s) field is present. 186 OUI 188 three octets. The vendor's Organizationally Unique Identifier, 189 assigned by IEEE 802 (see [RFC-1700] for contact details). The 190 bits within the octet are in canonical order, and the most signif- 191 icant octet is transmitted first. 193 Kind 195 one octet. Indicates a sub-type for the OUI. There is no stan- 196 dardization for this field. Each OUI implements its own values. 198 Value(s) 200 Zero or more octets. The details are implementation specific. 202 Security Considerations 204 Security issues are not discussed in this document. 206 References 208 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 209 RFC-1661, December 1993. 211 [2] Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700, 212 July 1992. 214 Contacts 216 Comments about this document should be discussed on the ietf- 217 ppp@merit.edu mailing list. 219 This document is a submission to the Point-to-Point Protocol Working 220 Group of the Internet Engineering Task Force (IETF). The working 221 group can be contacted via the current chair: 223 Karl Fox 224 Morning Star Technologies 225 3518 Riverside Drive Suite 101 226 Columbus, Ohio 43221 228 karl@MorningStar.com 229 karl@Ascend.com 231 Questions about this document can also be directed to: 233 William Allen Simpson 234 DayDreamer 235 Computer Systems Consulting Services 236 1384 Fontaine 237 Madison Heights, Michigan 48071 239 wsimpson@UMich.edu 240 wsimpson@GreenDragon.com (preferred)