idnits 2.17.1 draft-ietf-pppext-vines-01.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-20) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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 74: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 77: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 80: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 86: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 88: '...h does not include this option MUST be...' (2 more instances...) 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 (November 1994) is 10749 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) Summary: 11 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 Steven J. Senum 3 Internet Draft DigiBoard 4 expires May 1995 November 1994 6 The PPP Banyan Vines Control Protocol (BVCP) 7 draft-ietf-pppext-vines-01.txt 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 31 Rim). 33 Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. PPP 37 defines an extensible Link Control Protocol, and proposes a family of 38 Network Control Protocols for establishing and configuring different 39 network-layer protocols. 41 This document defines the Network Control Protocol for establishing 42 and configuring the Banyan VINES protocol over PPP. 44 1. Introduction 46 PPP has three main components: 48 1. A method for encapsulating multi-protocol datagrams. 50 2. A Link Control Protocol (LCP) for establishing, configuring, 51 and testing the data-link connection. 53 3. A family of Network Control Protocols for establishing and 54 configuring different network-layer protocols. 56 In order to establish communications over a point-to-point link, each 57 end of the PPP link must first send LCP packets to configure and test 58 the data link. After the link has been established and optional 59 facilities have been negotiated as needed by the LCP, PPP must send 60 BVCP packets to choose and configure the VINES network-layer 61 protocol. Once BVCP has reached the Opened state, VINES datagrams 62 can be sent over the link. 64 The link will remain configured for communications until explicit LCP 65 or BVCP packets close the link down, or until some external event 66 occurs (an inactivity timer expires or network administrator 67 intervention). 69 1.1. Specification of Requirements 71 In this document, several words are used to signify the requirements 72 of the specification. These words are often capitalized. 74 MUST This word, or the adjective "required", means that the 75 definition is an absolute requirement of the specification. 77 MUST NOT This phrase means that the definition is an absolute 78 prohibition of the specification. 80 SHOULD This word, or the adjective "recommended", means that there 81 may exist valid reasons in particular circumstances to 82 ignore this item, but the full implications must be 83 understood and carefully weighed before choosing a 84 different course. 86 MAY This word, or the adjective "optional", means that this 87 item is one of an allowed set of alternatives. An 88 implementation which does not include this option MUST be 89 prepared to interoperate with another implementation which 90 does include the option. 92 1.2. Terminology 94 This document frequently uses the following terms: 96 datagram The unit of transmission in the network layer (such as IP). 97 A datagram may be encapsulated in one or more packets 98 passed to the data link layer. 100 frame The unit of transmission at the data link layer. A frame 101 may include a header and/or a trailer, along with some 102 number of units of data. 104 packet The basic unit of encapsulation, which is passed across the 105 interface between the network layer and the data link 106 layer. A packet is usually mapped to a frame; the 107 exceptions are when data link layer fragmentation is being 108 performed, or when multiple packets are incorporated into a 109 single frame. 111 peer The other end of the point-to-point link. 113 silently discard 114 This means the implementation discards the packet without 115 further processing. The implementation SHOULD provide the 116 capability of logging the error, including the contents of 117 the silently discarded packet, and SHOULD record the event 118 in a statistics counter. 120 2. A PPP Network Control Protocol for VINES 122 The Banyan VINES Control Protocol (BVCP) is responsible for 123 configuring, enabling, and disabling the VINES protocol modules on 124 both ends of the point-to-point link. BVCP uses the same packet 125 exchange mechanism as the Link Control Protocol. BVCP packets may 126 not be exchanged until PPP has reached the Network-Layer Protocol 127 phase. BVCP packets received before this phase is reached should be 128 silently discarded. 130 The Baynan VINES Control Protocol is exactly the same as the Link 131 Control Protocol [1] with the following exceptions: 133 Frame Modifications 135 The packet may utilize any modifications to the basic frame format 136 which have been negotiated during the Link Establishment phase. 138 Data Link Layer Protocol Field 140 Exactly one BVCP packet is encapsulated in the Information field 141 of a PPP Data Link Layer frame where the Protocol field indicates 142 type hex 8035 (Banyan VINES Control Protocol). 144 Code field 146 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 147 Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack 148 and Code-Reject) are used. Other Codes should be treated as 149 unrecognized and should result in Code-Rejects. 151 Timeouts 153 BVCP packets may not be exchanged until PPP has reached the 154 Network-Layer Protocol phase. An implementation should be 155 prepared to wait for Authentication and Link Quality Determination 156 to finish before timing out waiting for a Configure-Ack or other 157 response. It is suggested that an implementation give up only 158 after user intervention or a configurable amount of time. 160 Configuration Option Types 162 BVCP has a distinct set of Configuration Options. 164 2.1. Sending VINES Datagrams 166 Before any VINES datagrams may be communicated, PPP must reach the 167 Network-Layer Protocol phase, and the Banyan VINES Control Protocol 168 must reach the Opened state. 170 Exactly one VINES packet is encapsulated in the Information field of 171 a PPP Data Link Layer frame where the Protocol field indicates type 172 hex 0035 (Banyan VINES datagram). The maximum length of a VINES 173 datagram transmitted over a PPP link is the same as the maximum 174 length of the Information field of a PPP data link layer frame. 176 The format of the Information field itself is the same as that 177 defined in [2]. 179 2.2. General Considerations 181 VINES supports an Address Resolution Protocol, VINES ARP, primarily 182 used for address assignment. Since this protocol is part of VINES 183 IP, it is fully supported over BVCP. VINES also supports a data-link 184 Echo Protocol (VINES Echo), used to test connectivity to a VINES 185 Server in a LAN environment, which is not supported over BVCP. 187 3. BVCP Configuration Options 189 BVCP Configuration Options allow modifications to the standard 190 characteristics of the network-layer protocol to be negotiated. If a 191 Configuration Option is not included in a Configure-Request packet, 192 the default value for that Configuration Option is assumed. 194 BVCP uses the same Configuration Option format defined for LCP [1], 195 with a separate set of Options. 197 Up-to-date values of the BVCP Option Type field are specified in the 198 most recent "Assigned Numbers" RFC [3]. Current values are assigned 199 as follows: 201 Value Option 203 1 BV-NS-RTP-Link-Type 204 2 BV-FRP 205 3 BV-RTP 207 ***** 208 Editorial note: A suggestion was made to combine the BV-NS-RTP-Link- 209 Type option and the BV-RTP option into a single option that could 210 negotiate one of four settings (S-RTP, NS-RTP-LAN, NS-RTP-WAN, NO-RTP). 211 This suggestion has been rejected because VINES must already deal with a 212 mix of S-RTP and NS-RTP, and that pushing this information down to the 213 PPP layer is not desirable. 214 ***** 216 3.1. BV-NS-RTP-Link-Type 218 Description 220 This Configuration Option provides a way to negotiate the way the 221 VINES 4.11 Non-Sequenced Routing Update Protocol (NS-RTP) will run 222 on the link. VINES 4.11 handles updates differently depending on 223 whether the interface is a LAN type or a WAN type. For a LAN 224 type, the full routing table is rebroadcast every update interval 225 (90 seconds). For a WAN type, the full routing table is only 226 transmitted for the first 3 update intervals after the link comes 227 up. After that only changes are transmitted (for 5 update 228 intervals). Note that this has no effect if VINES 5.5 (Sequenced 229 RTP) is being used. More information on this can be found in [2]. 231 This option negotiates what an implementation is willing to 232 receive, and is negotiated separately per side of the PPP 233 connection. The acceptance of this option (by the peer) indicates 234 that the peer will send NS-RTP updates as if the link was a LAN 235 type. The rejection (or absence) of this option indicates that 236 the peer will send NS-RTP updates as if the link was a WAN type. 238 By default, NS-RTP updates are sent as if the link was a WAN type. 240 A summary of the BV-NS-RTP-Link-Type Configuration Option format is 241 shown below. The fields are transmitted from left to right. 243 0 1 244 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Type 251 1 253 Length 255 2 257 3.2. BV-FRP 259 Description 261 This Configuration Option provides a way to negotiate the use of 262 VINES Fragmentation Protocol (FRP). This protocol is used to 263 allow fragmentation and reassembly of a VINES packet over the 264 link. FRP prepends a two octet field to every packet going over 265 the link that contains a begin and end fragment information and a 266 sequence number. With PPP's default MRU of 1500, FRP is not 267 normally needed, and no FRP header would be sent with the VINES 268 packet. If a MRU of less than 1484 is negotiated, FRP will be 269 needed to send a full size VINES packet over the link. More 270 information on this can be found in [2]. 272 This option negotiates what an implementation is willing to 273 receive, and is negotiated separately per side of the PPP 274 connection. The acceptance of this option (by the peer) indicates 275 that the peer will send VINES packets with a FRP header. The 276 rejection (or absence) of this option indicates that the peer will 277 send VINES packets without a FRP header. 279 By default, VINES packets are sent without a FRP header. 281 A summary of the BV-FRP Configuration Option format is shown below. 283 The fields are transmitted from left to right. 285 0 1 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type | Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Type 293 2 295 Length 297 2 299 3.3. BV-RTP 301 Description 303 This Configuration Option provides a way to negotiate whether RTP 304 is used over the link. If dial-up lines with static routes are 305 being used, the use of RTP may be totally suppressed to conserve 306 bandwidth on the link. 308 This option negotiates what an implementation is willing to 309 receive, and is negotiated separately per side of the PPP 310 connection. The acceptance of this option (by the peer) indicates 311 that the peer will not send RTP packets. The rejection (or 312 absence) of this option indicates that the peer will send any RTP 313 packets. 315 By default, RTP packets are sent over the link. 317 A summary of the BV-RTP Configuration Option format is shown below. 318 The fields are transmitted from left to right. 320 0 1 321 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Type 328 3 330 Length 332 2 334 Security Considerations 336 Security issues are not discussed in this memo. 338 References 340 [1] Simpson, W. A., "The Point-to-Point Protocol (PPP)", STD 51, 341 RFC 1661, July 1994. 343 [2] Banyan, "VINES Protocol Definition", June 1993, Order No. 344 003673. 346 [3] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 347 1700, USC/Information Sciences Institute, October 1994. 349 Acknowledgements 351 Some of the text in this document is taken from previous documents 352 produced by the Point-to-Point Protocol Working Group of the Internet 353 Engineering Task Force (IETF). 355 In particular, Bill Simpson provided the boiler-plate used to create 356 this document. 358 Chair's Address 360 The working group can be contacted via the current chair: 362 Fred Baker 363 Cisco Systems 364 519 Lado Drive 365 Santa Barbara, California 93111 367 Phone: (805) 681-0115 368 EMail: fred@cisco.com 370 Author's Address 372 Questions about this memo can also be directed to: 374 Steven J. Senum 375 DigiBoard 376 6400 Flying Cloud Drive 377 Eden Prairie, Minnesota 55344 379 Phone: (612) 943-9020 380 EMail: sjs@digibd.com 381 Table of Contents 383 1. Introduction .......................................... 1 384 1.1 Specification of Requirements ................... 1 385 1.2 Terminology ..................................... 2 386 2. A PPP Network Control Protocol for VINES .............. 3 387 2.1 Sending VINES Datagrams ......................... 4 388 2.2 General Considerations .......................... 4 389 3. BVCP Configuration Options ............................ 5 390 3.1 BV-NS-RTP-Link-Type ............................. 5 391 3.2 BV-FRP .......................................... 6 392 3.3 BV-RTP .......................................... 7 393 SECURITY CONSIDERATIONS ...................................... 9 394 REFERENCES ................................................... 9 395 ACKNOWLEDGEMENTS .......................................... 9 396 CHAIR'S ADDRESS .............................................. 9 397 AUTHOR'S ADDRESS ............................................. 9