Network Working Group W A Simpson [DayDreamer] Internet Draft expires in six months August 1998 PPP in Ether-like Framing draft-ietf-pppext-ether-00.txt Status of this Memo This document is an Internet-Draft. Internet Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as refer- ence material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Northern Europe) ftp.nis.garr.it (Southern Europe) ftp.ietf.org (Eastern USA) ftp.isi.edu (Western USA) munnari.oz.au (Pacific Rim) Distribution of this memo is unlimited. Copyright Notice Copyright (C) William Allen Simpson (1998). All Rights Reserved. Abstract The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ethernet-like framing for PPP encapsulated packets. Simpson expires in six months [Page i] DRAFT PPP in Ethernet-like Framing August 1998 1. Introduction This specification provides for framing over both bit-oriented and octet-oriented synchronous links, and asynchronous links with 8 bits of data and no parity. These links MUST be full-duplex, but MAY be either dedicated or circuit-switched. Some protocols expect error free transmission, and either provide error detection only on a conditional basis, or do not provide it at all. PPP uses the Ethernet 32-bit Frame Check Sequence for error detection. This is commonly available in hardware implementations, and a software implementation is provided in [RFC-1662]. 1.1. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119]. To remain consistent with standard Internet practice, and avoid con- fusion for people used to reading RFCs, all binary numbers in the following descriptions are in Most Significant Bit to Least Signifi- cant Bit order, from Most Significant Byte to Least Significant Byte, reading from left to right, unless otherwise indicated. Note that this is contrary to ISO and ITU practice, which orders bits as trans- mitted (network bit order). Keep this in mind when comparing this document with the other documents. 2. Physical Layer Requirements The only absolute requirement imposed by PPP is the provision of a bi-directional full-duplex circuit, either dedicated (permanent) or frame-switched, that can operate in either a bit-synchronous, or octet-synchronous mode, transparent to PPP Data Link Layer frames. Interface Format PPP presents an octet interface to the physical layer. There is no provision for sub-octets to be supplied or accepted. Transmission Rate PPP does not impose any restrictions regarding transmission rate, other than that of the particular DTE/DCE interface. Simpson expires in six months [Page 1] DRAFT PPP in Ethernet-like Framing August 1998 Control Signals PPP does not require the use of control signals. When available, using such signals can allow greater functionality and perfor- mance. Implications are discussed in [RFC-1662]. 2.1. Transmission Considerations The definition of various encodings is the responsibility of the DTE/DCE equipment in use, and is outside the scope of this speci- fication. 3. The Data Link Layer This specification uses the principles, terminology, and frame structure described in [IEEE-802?]. The purpose of this specification is not to document what is already standardized in [IEEE-802?]. Instead, this document attempts to give a concise summary and point out specific options and features used by PPP. 3.1. Frame Header This specification describes the PPP Protocol encapsulation. These fields are transmitted from left to right. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPP Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information* | Padding* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PPP Protocol field and the following Information and Padding fields are described in the Point-to-Point Protocol Encapsulation [RFC-1661]. Simpson expires in six months [Page 2] DRAFT PPP in Ethernet-like Framing August 1998 3.2. Modification of the Basic Frame The Link Control Protocol can negotiate modifications to the basic frame structure. This is not compatible with ethernet-like fram- ing. Address-and-Control-Field-Compression Since the Address and Control fields are not present, Address- and-Control-Field-Compression cannot affect the frame format. FCS-Alternatives Since ethernet-like framing requires a 32-bit FCS, FCS- Alternatives cannot affect the frame format. In general, framing-related LCP Configuration Options are not rec- ognizable, and are not acceptable for negotiation. The implemen- tation MUST NOT send ineffectual options in a Configure-Request, and SHOULD respond to such requested options with a Configure- Reject. See [RFC-ffff] for details. 3.3. Modification of the Basic Packet The Link Control Protocol can negotiate modifications to the basic packet structure. These are transparent to Frame Relay. Protocol-Field-Compression The fixed header aligns the PPP Information field on a 32-bit boundary. The implementation MUST respond with a Configure- Reject. Self-Describing-Padding Negotiation of Self-Describing-Padding to a 4-byte multiple is required. 4. Configuration Details The standard LCP configuration defaults apply to ethernet-like framing, except that 32-bit FCS is assumed (instead of 16-bit FCS). The following Configuration Options are recommended: Simpson expires in six months [Page 3] DRAFT PPP in Ethernet-like Framing August 1998 Magic Number No Address and Control Field Compression No Protocol Field Compression Link Quality Monitoring Self Describing Padding Security Considerations This specification introduces no known security vulnerabilities. Acknowledgements PPP using a simple non-HDLC framing was first proposed by Peter Lothberg (Sprint). References [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD-51, DayDreamer, July 1994. [RFC-1662] Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51, DayDreamer, July 1994. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP-14, Harvard University, March 1997. [RFC-ffff] Simpson, W., "PPP with Framing Conversion", work in progress. Simpson expires in six months [Page 4] DRAFT PPP in Ethernet-like Framing August 1998 Contacts Comments about this document should be discussed on the ietf- ppp@merit.edu mailing list. This document was reviewed by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the current chair: Karl Fox Ascend Communications 655 Metro Place South, Suite 370 Dublin, Ohio 43017 karl@Ascend.com Questions about this document can also be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) Simpson expires in six months [Page 5] DRAFT PPP in Ethernet-like Framing August 1998 Full Copyright Statement Copyright (C) William Allen Simpson (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, except as required to translate it into languages other than English. This document and the information contained herein is provided on an "AS IS" basis and the author(s) DISCLAIM 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. Simpson expires in six months [Page 6]