| [ internet ] in KIDS 글 쓴 이(By): fleur (모티푸컴파熹) 날 짜 (Date): 1994년12월10일(토) 12시33분48초 KST 제 목(Title): [re]ppp... 이거 좀 길어요.. ppp Background In the last few years, the Internet has seen explosive growth in the number of hosts supporting TCP/IP. The vast majority of these hosts are connected to Local Area Networks (LANs) of various types, Ethernet being the most common. Most of the other hosts are connected through Wide Area Networks (WANs) such as X.25 style Public Data Networks (PDNs). Relatively few of these hosts are connected with simple point-to-point serial links. Yet, point-to-point links are among the oldest methods of data communications, and almost every host supports point-to-point connections. For example, asynchronous RS-232-C interfaces are essentially ubiquitous. One reason for the small number of point-to-point IP Links was the serious bandwidth limitations of affordable modems. Asynchronous dial-up modems were limited to 1200 or 2400 bps, which is marginal for most applications. This limitation has been significantly improved with the availability of V.32bis modems providing 14,400 bps connections over the same dial-up lines. This compares to what is available on dedicated access lines to PDNs at a much higher cost. Another reason for the small number of point-to-point links was the lack of a widely-adopted standard encapsulation method. A common, non-standard method for sending Internet Protocol (IP) over low speed point-to-point links is called Serial Line IP (SLIP). The free source code is available with BSD 4.2 UNIX and is very simple for vendors to integrate into their products. However, vendors soon discovered that SLIP lacks many useful link-level functions. Problems with SLIP As described by RFC-1055, "Nonstandard for transmission of IP datagrams over Serial Lines," SLIP provides a very simple framing scheme for sending IP packets over a serial line. A typical packet is shown in Figure 1. In fact, the reason it is so simple to implement is because it does so little. Nearly one-third of RFC-1055 describes a long list of deficiencies. Probably the most crippling problem being that it does not provide support for any protocol other than IP.As router vendors created multi-protocol products, this became a serious failing. Some vendors tried sending IPX packets over the SLIP link together with IP, since the first 4 bits may be used to distinguish the two packet types (0100 for IP, 1111 for IPX). However, that stopped working when Novell began generating checksums for its packets. And the technique interfered with Van Jacobson header compression for IP. The limits of SLIP only begin with network protocols. It provides no method for detecting or correcting errors, which grow more important as the speed of the link increases. Some network protocols like IPX depend on the link to discard bad packets. SLIP instead relies on the IP header to detect damaged packets. This works if you're running IP, but not other protocols. SLIP provides no mechanism for hosts to communicate addressing information. Yet, when hosts dial up a router, the addressing scheme may be quite dynamic and the router may need to inform the dialing host of the host's IP address. SLIP also lacks packet type identification. It contains no type field. Thus, once again, only one protocol can be run over a SLIP connection. Configuration options are not dynamic with SLIP. Every parameter change requires the SLIP driver to be recompiled, relinked, and rebooted. Therefore, products employing SLIP require the attention of very patient technicians. Also, SLIP only works on one kind of link -- simple, dedicated, character-oriented, asynchronous lines like RS-232. Most higher speed links are bit-synchronous (SDLC or HDLC). SLIP does not work well over many dial-up links, because of the loss of ASCII control characters used by modems for flow control. Finally, SLIP does not provide any link-level security. Early SLIP implementations were in terminal server products, where they provided IP access for remote single user workstations. Link level authentication was of limited concern: the same user login was used for any remote terminal access. As these links have grown to connect entire networks rather than single users, security has become a major issue. Other methods outside SLIP are necessary to identify the user of a connection and prevent network black-holes arising from "spoofing" by a few malicious crackers. Interoperability is never a guarantee with SLIP because vendors often develop proprietary methods to make up for its shortcomings. These enhancements are optimized for each vendor's own products and don't encourage interoperability with other vendors' products. PPP Rises The Point-to-Point Protocol (PPP) was derived from earlier work on SLIP. PPP is a more robust, full-featured protocol, and as such is close to becoming a standard. It is the product of the Internet Engineering Task Force's PPP Working Group, and has been blessed by the IETF and IAB as a standard-evolving protocol. The PPP Working Group was formed by the IETF, an open forum primarily composed of IP vendors and regional network providers. Learning from the shortcomings of SLIP, the developers started with the concept that any standard would need to be extensible. Not all vendors need the same features in every product. New features could be added over time, without affecting the older implementations. This is accomplished through "negotiation." Each end of the link advertises which features it has implemented. The peers agree on a common set of features to be used. This allows interoperability between a wide range of products. The most important aspect of PPP negotiation is that it is automatic. This can result in a large savings of human configuration time. Described most recently in RFC 1331, "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links," PPP is comprised of three main components: 1) a method for encapsulating datagrams over serial links, 2) a Link Control Protocol (LCP) for establishing, configuring, and testing data-link connection, and 3) a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. The singular "protocol" is a bit of a misnomer, since PPP is really a suite of protocols. PPP is suited to encapsulate protocols other than just TCP/IP. PPP automatically discovers which network protocols are supported through NCP negotiation. The NCPs are defined in independent RFCs. (See Point-to-Point Protocol RFCs) To establish communications over a point-to-point link, each end of the PPP link first sends LCP packets to configure and test the data link. After the link has been established, the peer may be authenticated. Then, PPP sends NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, data can be sent of the link. The LCP is used to automatically agree upon the encapsulation format options, handle varying limits on packet sizes, decide authentication and compression techniques, determine when a link is functioning properly and when it is down, detect a looped-back link, and terminate the link. The LCP and the NCPs use the same negotiation technique, which results in a compact, efficient code base, and easy implementation of new features. The default framing is based on HDLC. This allows PPP to be used with all known asynchronous and bit-synchronous hardware, as well as WAN links which are also based on HDLC, such as X.25 and Frame Relay. Because careful attention was paid to issues such as word alignment, PPP is suitable for RISC processors and very high speed fiber links. Although the typical PPP packet is shown in Figure 2, PPP peers can negotiate compression techniques which will reduce packet size to look more like the one shown in Figure 3. Compression allows PPP to scale downward for slower links. PPP uses Password Authentication Protocol (PAP) or Challenge-Handshake Authentication Protocol (CHAP) to enforce link security. For more information on these security methods see attached sidebar. PPP can be used over any transport service capable of supporting ASCII terminals, including Telnet connections. PPP's asynchronous control character mapping option allows transparent use of these links, even though they do not inherently support binary data. PPP uses HDLC to encapsulate data from multiple links. It uses LCP to test and configure data links through low-level authentication, link loopback detection, and link monitoring that can be run along side of other traffic. PPP Today Vendors supporting PPP have formed a consortium for interoperability testing. The latest such meeting occurred in the fall of 1992 and successfully resulted in interoperability between more than 30 vendors. Information resulting from testing sessions is important for users that must integrate separate vendor networks as well as for those seeking a lower cost solution that cannot be provided through one vendor. Although the burden of multivendor interoperability does not rely solely on the shoulders of PPP, as such tests continue to evolve, they accomplish a large hurdle towards meeting this goal. PPP has now been widely implemented in most routers. The bridge community has been slower to implement PPP, as the bridging specification is currently undergoing minor revision. When SLIP was first developed, it quickly became popular among those systems administrators with the considerable skills required to make it work. Enhancements that overcome the serious limitations of the protocol cannot be implemented without compromising interoperability. SLIP has thus effectively exhausted its potential. PPP, on the other hand, is designed to be extensible and contains a negotiation mechanism. This ensures that as enhancements are implemented, neighbors in the network can automatically determine which features are supported and use the best available feature combination. For this reason, PPP is enjoying market acceptance among router and terminal server manufacturers. As new vendors enter the market, interoperability tests ensure that users will receive seamless, standards-based connectivity. Point-to-Point Protocol RFCs RFC 1220 PPP for Bridging (under revision) RFC 1331 Point-to-Point Protocol (PPP) RFC 1332 The PPP Internet Protocol Control Protocol (IPCP) RFC 1333 PPP Link Quality Monitoring (LQM) RFC 1334 PPP Authentication Protocols RFC 1376 The PPP DECnet Phase IV Control Protocol (DPCP) RFC 1377 The PPP OSI Network Layer Control Protocol (OSINCP) RFC 1378 The PPP AppleTalk Control Protocol (ATCP) RFC 1471 MIB for Link Control Protocol (LCP) RFC 1472 MIB for Security Protocol RFC 1473 MIB for Internet Protocol Control Protocol (IPCP) RFC 1474 MIB for Bridging In the IETF tradition, work is not published until it has been tested. Further work under test which is not yet published includes: The PPP Internetwork Packet eXchange Control Protocol (IPXCP), Compressing IPX Headers Over WAN Media (CIPX), PPP over X.25, PPP over ISDN, PPP over Frame Relay, and PPP over Sonet and the Synchronous Digital Hierarchy. In the network management arena, the MIBs for LCP, IPCP, Bridging, and Security were recently published in June 1993. Persons who wish to be part of the specification and testing of PPP are invited to send a message to ietf-ppp-request@ucdavis.edu. Security Methods The Point-to-Point Protocol (PPP) uses Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP) to enforce link security. PAP uses a 2-way handshake for the peer to establish its identity. This occurs only upon initial link establishment. An ID/password pair is repeatedly sent by the peer to the authenticator until verification is acknowledged or the connection is terminated. Passwords are sent over the circuit in text format which offers no protection from playback. CHAP periodically verifies the identity of the peer using a three-way handshake. This is done throughout the life of the connection. Once established, the authenticator sends a "challenge" message to the peer. The peer responds with a value calculated using a "one-way hash" function. The authenticator then checks this response against its own calculation. If the values match, the authentication is acknowledged; otherwise the connection is terminated. CHAP provides protection against playback attack because the challenge value changes in every message. Since the password is never sent over the link, it is virtually impossible to learn it. _________ Lars Poulsen is a software engineer and senior member of the technical staff at Rockwell International Corp.'s CMC Network Products unit. As such, he is responsible for implementing PPP into the company's dialup router and terminal server products. Bill Simpson is the PPP Working Group editor. 2. WHAT IS PPP? Introduction PPP features which may or may not be present PPP glossary PPP-relevant RFC's 2.1 Introduction PPP is the Internet Standard for transmission of IP packets over serial lines. PPP supports async and sync lines. For a general discussion of PPP, and of the PPP vs. SLIP question, look at the paper ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z (paper) and sug91-cheapIP.shar.Z (overhead projector slides) 2.2 PPP features which may or may not be present Above and beyond compatibility with basic PPP framing, note whether the software implements the following features. Not all features are needed or even desired in every product. Please note also that not every free or commercial product description in this document has a complete list of all features includes. demand-dial Bring up a PPP interface and dial the phone when packets are queued for delivery; bring the interface down after some period of inactivity. redial (For lack of a better term) Bring up a PPP interface whenever it goes down, to keep a line up. (sometimes called camping) camping (on a line) see redial scripting Negotiate through a series of prompts or intermediate connections to bring up a PPP link, much like the sequence of events used to bring up a UUCP link. parallel Configure several PPP lines to the same destination and do load sharing between them. (In process of getting standardized.) filtering Select which packets to send down a link or whether to bring up a "demand-dial" link based on IP or TCP packet type or TOS, e.g. don't dial the phone for ICMP ping packets. header compression TCP header compression according to RFC1144. Marginally useful on high speed lines, essential for low speed lines. server Accept incoming PPP connections, which might well also include doing the right things with routing. tunneling Build a virtual network over a PPP link across a TCP stream through an existing IP network. extra escaping Byte-stuffing characters outside the negotiated asyncmap, configurable in advance but not negotiable. 2.3 PPP glossary Every new technology breeds its own set of acronyms. PPP is no different. Here is a glossary of sorts. ack Acknowledgement. AO Active open [state diagram] (no lonter part of the FSM as of RFC1331) C Close [state diagram] CHAP Challenge-Handshake Authentication Protocol (RFC1334) D Lower layer down [state diagram] DES Data Encryption Standard DNA Digital Network Architecture IETF Internet Engineering Task Force. IP Internet Protocol IPCP IP Control Protocol. IPX Internetwork Packet Exchange (Novell's networking stack) FCS Frame Check Sequence [X.25] FSA Finite State Automaton FSM Finite State Maschine LCP Link Control Protocol. LQR Link Quality Report. MD4 MD4 digital signature algorithm MD5 MD5 digital signature algorithm MRU Maximum Receive Unit MTU Maximum Transmission Unit nak Negative Acknowledgement NCP Network Control Protocol. NRZ Non-Return to Zero bit encoding. (SYNC ppp default because of availability) NRZI Non-Return to Zero Inverted bit encoding. (SYNC ppp preferred alternative to NRZ) OSI Open Systems Interconnect PAP Password Authentication Protocol (RFC1334) PDU Protocol Data Unit (i.e., packet) PO Passive open [no longer part of state diagram] PPP Point to Point Protocol ( RFC1548 / RFC1549, 1332, 1333, 1334, 1551, 1376, 1377, 1378) RCA Receive Configure-Ack [state diagram] RCJ Receive Code-Reject [state diagram] RCN Receive Configure-Nak or -Reject [state diagram] RCR+ Receive good Configure-Request [state diagram] RER Receive Echo-Request [no longer part of state diagram] RFC Request for Comments (internet standard) RTA Receive Terminate-Ack [state diagram] RTR Receive Terminate-Request [state diagram] RUC Receive unknown code [state diagram] sca Send Configure-Ack [state diagram] scj Send Code-Reject [state diagram] scn Send Configure-Nak or -Reject [state diagram] scr Send Configure-Request [state diagram] ser Send Echo-Reply [no longer part of state diagram] sta Send Terminate-Ack [state diagram] str Send Terminate-Request [state diagram] ST-II Stream Protocol TO+ Timeout with counter > 0 [state diagram] TO- Timeout with counter expired [state diagram] VJ Van Jacobson (RFC1144 header compression algorithm) XNS Xerox Network Services 2.4 PPP relevant RFCs Here's a list with descriptions. Note some of these are obsolete. You might also want to search for recent RFCs or internet drafts in an up-to-date RFC archive. 1663 Rand, DPPP Reliable Transmission. 1994 July; 8 p. (Format: TXT=17281 bytes) 1662 Simpson, W.,edPPP in HDLC-like Framing. 1994 July; 25 p. (Format: TXT=48058 bytes) (Obsoletes RFC 1549) 1661 Simpson, W.,edThe Point-to-Point Protocol (PPP). 1994 July; 52 p. (Format: TXT=103026 bytes) (Obsoletes RFC 1548) 1638 Baker, F.; Bowen, R.,edsPPP Bridging Control Protocol (BCP). 1994 June; 28 p. (Format: TXT=58477 bytes) 1619 Simpson, WPPP over SONET/SDH. 1994 May; 4 p. (Format: TXT=8893 bytes) 1618 Simpson, WPPP over ISDN. 1994 May; 6 p. (Format: TXT=14896 bytes) 1598 Simpson, WPPP in X.25. 1994 March; 7 p. (Format: TXT=13835 bytes) 1570 Simpson, W.,ed. PPP LCP Extensions. 1994 January; 18 p. (Format: TXT=35719 bytes) (Updates RFC 1548) 1553 Mathur, S.; Lewis, M. Compressing IPX Headers Over WAN Media (CIPX). 1993 December; 23 p. (Format: TXT=47450 bytes) 1552 Simpson, W. The PPP Internetwork Packet Exchange Control Protocol (IPXCP). 1993 December; 14 p. (Format: TXT=29174 bytes) 1551 Allen, M. Novell IPX Over Various WAN Media (IPXWAN). 1993 December; 22 p. (Format: TXT=54210 bytes) (Obsoletes RFC 1362) 1549 Simpson, W.,ed. PPP in HDLC Framing. 1993 December; 18 p. (Format: TXT=36353 bytes) (Obsoleted by RFC 1662) 1548 Simpson, W. The Point-to-Point Protocol (PPP). 1993 December; 53 p. (Format: TXT=111638 bytes) (Obsoletes RFC 1331; Obsoleted by RFC 1661; Updated by RFC 1570) 1547 Perkins, D. Requirements for an Internet Standard Point-to-Point Protocol. 1993 December; 21 p. (Format: TXT=49811 bytes) 1378 PPP AppleTalk Control Protocol (ATCP). Parker, B. 1992 November; 16 p. (Format: TXT=28496 bytes) 1377 PPP OSI Network Layer Control Protocol (OSINLCP). Katz, D. 1992 November; 10 p. (Format: TXT=22109 bytes) 1376 PPP DECnet Phase IV Control Protocol (DNCP). Senum, S.J. 1992 November; 6 p. (Format: TXT=12448 bytes) 1362 Allen, M. Novell IPX Over Various WAN Media (IPXWAN). 1992 September; 18 p. (Format: TXT=30220 bytes) 1334 PPP authentication protocols. Lloyd, B.; Simpson, W.A. 1992 October; 16 p. (Format: TXT=33248 bytes) 1333 PPP link quality monitoring. Simpson, W.A. 1992 May; 15 p. (Format: TXT=29965 bytes) 1332 PPP Internet Protocol Control Protocol (IPCP). McGregor, G. 1992 May; 12 p. (Format: TXT=17613 bytes) (Obsoletes RFC1172) 1331 Point-to-Point Protocol (PPP) for the transmission of multi-protocol datagrams over point-to-point links. Simpson, W.A. 1992 May; 66 p. (Format: TXT=129892 bytes) (Obsoletes RFC1171, RFC1172; obsoleted by RFC 1548) 1220 Point-to-Point Protocol extensions for bridging. Baker, F.,ed. 1991 April; 18 p. (Format: TXT=38165 bytes) 1172 Point-to-Point Protocol (PPP) initial configuration options. Perkins, D.; Hobby, R. 1990 July; 38 p. (Format: TXT=76132 bytes) (Obsoleted by RFC1331, RFC1332) 1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links. Perkins, D. 1990 July; 48 p. (Format: TXT=92321 bytes) (Obsoletes RFC1134; Obsoleted by RFC1331) 1134 Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links. Perkins, D. 1989 November; 38 p. (Format: TXT=87352 bytes) (Obsoleted by RFC1171) 1144 Compressing TCP/IP headers for low-speed serial links. Jacobson, V. 1990 February; 43 p. (Format: TXT=120959 PS=534729 bytes) In comp.protocols.ppp (Message-ID: <BOB.92Dec3145948@volitans.MorningStar.Com>) bob@MorningStar.Com (Bob Sutterfield) wrote : All of 1134, 1171, and 1172 (and 1055, for that matter :-) have been obsoleted. They're interesting only if you want to debug a connection with an ancient PPP implementation, and you're wondering why (e.g.) it asked you for IPCP option 2 with a length of only 4, and Compression-Type 0x0037. (There's a lot of that still running around - be careful out there.) *** Go back here. To the top page here. Read on here. -- -- Ignatios Souvatzis - Solaris 2.1: it's slow, needs 200M of disk space and comes without C compiler, which makes it remarkably close to MS-Windows. oleg@gd.cs.csufresno.edu 특기:날라리 때려주기,취미:방에혼자있기,그건 가끔함.엄청난 독서량:매달 꾸준히 두개의 책을 정독함.(p?a?b*,?en*se),주식:밀가루루 만든거아님 안먹음. 포 모어 인포메이숀 플리즈 유즈유어 모자익오알 넷스케이프 엣(@)�@ http://www.cen.uiuc.edu/~hp8825 공사중.(광고하실려면 역시 요기괄호를쓰세요) |