RFC 6431 on Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)
A new Request for Comments is now available in online RFC libraries. RFC 6431 Title: Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP) Author: M. Boucadair, P. Levis, G. Bajko, T. Savolainen, T. Tsou Status: Informational Stream: Independent Date: November 2011 Mailbox:mohamed.boucad...@orange.com, pierre.le...@orange.com, gabor.ba...@nokia.com, teemu.savolai...@nokia.com, tina.tsou.zout...@huawei.com Pages: 16 Characters: 33981 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-boucadair-pppext-portrange-option-09.txt URL:http://www.rfc-editor.org/rfc/rfc6431.txt This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: RFC 1619 (PPP over SONET/SDH) to HISTORIC RFC
The IESG has received a request from an individual to reclassify RFC 1619 (PPP over SONET/SDH) to HISTORIC. RFC 1619 has been obsoleted by RFC 2615 and its current status is PROPOSED STANDARD. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-11-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6361 on PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol
A new Request for Comments is now available in online RFC libraries. RFC 6361 Title: PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol Author: J. Carlson, D. Eastlake 3rd Status: Standards Track Stream: IETF Date: August 2011 Mailbox:carls...@workingcode.com, d3e...@gmail.com Pages: 8 Characters: 17705 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pppext-trill-protocol-08.txt URL:http://www.rfc-editor.org/rfc/rfc6361.txt The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. [STANDARDS-TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Experimental RFC to be: draft-simpson-isis-ppp-unique-02.txt
The IESG recommends that 'Generation of Unique IS-IS System Identifiers' draft-simpson-isis-ppp-unique-02.txt NOT be published as an Experimental RFC. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-simpson-isis-ppp-unique/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary RFC Editor Note The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. If the ISE decides to proceed with publication without the requested redirection to the ISIS (or TRILL) WG, the IESG requests the opportunity to add an IESG note to the document before publication. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'PPP TRILL Protocol Control Protocol' to Proposed Standard (draft-ietf-pppext-trill-protocol-08.txt)
The IESG has approved the following document: - 'PPP TRILL Protocol Control Protocol' (draft-ietf-pppext-trill-protocol-08.txt) as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ Technical Summary The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. Working Group Summary There is consensus in the WG to publish this document. There was some discussion in the working group about IS-IS System IDs, and the draft reflects the consensus. Note that the document author is the working group chair. There is no document shepherd due to this, and the responsible Area Director has verified that WG discussions were conducted properly and that there was consensus to send the document forward. Document Quality There is a long list of vendors implementing TRILL, but at this point there are none that have announced support for TRILL over PPP. The PPP extensions described here are trivial, and the overall system implementation issues have been discussed in detail with several of the TRILL WG participants. No significant implementation, deployment, or interoperability concerns exist. Significant reviewers include Bill Simpson, Donald Eastlake, and Vern Schryver. Personnel There is no Document Shepherd. The responsible Area Director is Jari Arkko. RFC Editor Note N.A. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-ietf-pppext-trill-protocol-06.txt (PPP TRILL Protocol Control Protocol) to Proposed Standard
This document has been in IESG review last week. A number of technical issues were raised (thank you!) and we are almost done with addressing them. Still negotiating what change, if any, to be done based on the Security AD's Discuss. However, the IESG has also asked me to treat this document as if it were an Individual Submission. This is not a negative assessment of the document content, the document was appreciated. But the IESG correctly noted that its not within the PPPEXT group's charter. It was my mistake to not catch this earlier. Sorry. In any case, as a result, we will deal with this document as an Individual Submission. The main change is the last call period. The last call of this document will continue until it has been under review for four weeks, and will be re-evaluated in the IESG telechat on June 23rd. We'd be happy to receive additional reviews. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pppext-trill-protocol-06.txt (PPP TRILL Protocol Control Protocol) to Proposed Standard
The RTG-dir review comments : http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01533.html Should be addressed before publication. - Stewart On 25/05/2011 17:13, The IESG wrote: The IESG has received a request from the Point-to-Point Protocol Extensions WG (pppext) to consider the following document: - 'PPP TRILL Protocol Control Protocol' draft-ietf-pppext-trill-protocol-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-pppext-trill-protocol-06.txt (PPP TRILL Protocol Control Protocol) to Proposed Standard
The IESG has received a request from the Point-to-Point Protocol Extensions WG (pppext) to consider the following document: - 'PPP TRILL Protocol Control Protocol' draft-ietf-pppext-trill-protocol-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-06-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5578 on PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
A new Request for Comments is now available in online RFC libraries. RFC 5578 Title: PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics Author: B. Berry, Ed., S. Ratliff, E. Paradise, T. Kaiser, M. Adams Status: Informational Date: February 2010 Mailbox:bbe...@cisco.com, sratl...@cisco.com, pd...@cisco.com, timothy.kai...@harris.com, michael.d.ad...@l-3com.com Pages: 24 Characters: 54936 Obsoletes: RFC4938 I-D Tag:draft-bberry-rfc4938bis-00.txt URL:http://www.rfc-editor.org/rfc/rfc5578.txt This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5072 on IP Version 6 over PPP
A new Request for Comments is now available in online RFC libraries. RFC 5072 Title: IP Version 6 over PPP Author: S.Varada, Ed., D. Haskins, E. Allen Status: Standards Track Date: September 2007 Mailbox:[EMAIL PROTECTED] Pages: 16 Characters: 33910 Obsoletes: RFC2472 See-Also: I-D Tag:draft-ietf-ipv6-over-ppp-v2-03.txt URL:http://www.rfc-editor.org/rfc/rfc5072.txt The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links. It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration. This document obsoletes RFC 2472. [STANDARDS TRACK] This document is a product of the IP Version 6 Working Group Working Group of the IETF. This is now a Draft Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4938 on PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
A new Request for Comments is now available in online RFC libraries. RFC 4938 Title: PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics Author: B. Berry, H. Holgate Status: Informational Date: June 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 17 Characters: 38288 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-bberry-pppoe-credit-06.txt URL:http://www.rfc-editor.org/rfc/rfc4938.txt This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with a credit-based flow control mechanism and Link Quality Metric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4937 on IANA Considerations for PPP over Ethernet (PPPoE)
A new Request for Comments is now available in online RFC libraries. RFC 4937 Title: IANA Considerations for PPP over Ethernet (PPPoE) Author: P. Arberg, V. Mammoliti Status: Informational Date: June 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 6 Characters: 11070 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-arberg-pppoe-iana-03.txt URL:http://www.rfc-editor.org/rfc/rfc4937.txt This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IP Version 6 over PPP' to Draft Standard
The IESG has approved the following document: - 'IP Version 6 over PPP ' draft-ietf-ipv6-over-ppp-v2-03.txt as a Draft Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-03.txt Technical Summary The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP and the method for forming IPv6 link-local addresses on PPP links. It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration. Working Group Summary The IPv6 working group has reviewed this document and it reflects the consensus of the group. Protocol Quality This specification has been reviewed for the IESG by Margaret Wasserman. In the working group, it was reviewed by the members of the mailing list and by the working group chairs. Note to RFC Editor Please move reference [4] (IANA assigned numbers) to be informative. Please replace reference [5] with the following: [5] IEEE, Guidelines For 64-bit Global Identifier (EUI-64), http://standards.ieee.org/regauth/oui/tutorials/EUI64.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'IANA Considerations for PPP over Ethernet (PPPoE)' to Informational RFC
The IESG has approved the following document: - 'IANA Considerations for PPP over Ethernet (PPPoE) ' draft-arberg-pppoe-iana-03.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arberg-pppoe-iana-03.txt Technical Summary This document provides for an IANA registry of PPPoE TAG and Code fields. Known existing usages are reserved, and a first come first served policy is established for future codes. Working Group Summary The PPPEXT working group reviewed the document and there are no known concerns with the work. PPPoE itself is not a standard protocol (L2TP and DHCP are standards-track alternatives), and future extensions are thus not encouraged. However, the new registry will help prevent possible conflicts that may develop before the standards-based solutions are adopted by PPPoE users. Protocol Quality This document does not specify any protocol. The registry established reflects current practice within the community. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4618 on Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks
A new Request for Comments is now available in online RFC libraries. RFC 4618 Title: Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks Author: L. Martini, E. Rosen, G. Heron, A. Malis Status: Standards Track Date: September 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 16 Characters: 33141 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.txt URL:http://www.rfc-editor.org/rfc/rfc4618.txt A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol. This enables service providers to offer emulated HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire. [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks' to Proposed Standard
The IESG has approved the following document: - 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks ' draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.txt as a Proposed Standard This document is the product of the Pseudo Wire Emulation Edge to Edge Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.txt * Technical Summary This draft describes how a Point to Point Protocol (PPP), or High- Level Data Link Control (HDLC) Protocol Data Units over an MPLS network without terminating the PPP/HDLC protocol. This enables service providers to offer emulated HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a PW. * Working Group Summary This work has been thoroughly analysed by the working group and there is consensus for the design. * Protocol Quality There are many implementations of this protocol, and it is in operational service. Note to RFC Editor OLD: It is also recommended that PPP devices MUST NOT negotiate PPP MRUs larger than that of the AC MTU. NEW: It is also RECOMMENDED that the PPP devices be configured to not negotiate PPP MRUs larger that of the AC MTU. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IANA Considerations for PPP over Ethernet (PPPoE)' to BCP (draft-arberg-pppoe-iana)
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for PPP over Ethernet (PPPoE) ' draft-arberg-pppoe-iana-01.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-arberg-pppoe-iana-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks' to Proposed Standard
The IESG has received a request from the Pseudo Wire Emulation Edge to Edge WG to consider the following document: - 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks ' draft-ietf-pwe3-hdlc-ppp-encap-mpls-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-08.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IP Version 6 over PPP' to Draft Standard
The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'IP Version 6 over PPP ' draft-ietf-ipv6-over-ppp-v2-02.txt as a Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-02.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)' to Proposed Standard
The IESG has approved the following document: - 'Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) ' draft-ietf-pkix-rfc3770bis-03.txt as a Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Sam Hartman and Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-03.txt Technical Summary This document defines mechanisms supporting Extensible Authentication Protocol (EAP) authentication methods that employ X.509 public key certificates. This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN System Service identifiers (SSIDs), and describes how these mechanisms may be applied to support authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN). Working Group Summary The working group had consensus to advance the draft to Proposed Standard. Protocol Quality This document obseletes and replaces RFC 3770. It has been reviewed by the PKIX working group. It has been reviewed for the IESG by Sam Hartman. Note to RFC Editor Section 1.1: old: Three changes are included new: Five significant changes are included: ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RE: PPP RFCs
Start with 1661 - PPP 1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links 1332 IPCP (N/w Control Protocol) 1333 PPP Link Quality Monitoring 1334 PPP Authentication Protocols. 1994 PPP Challenge Handshake Authentication Protocol (CHAP) Hope this helps. Thanks, Srivatsan -Original Message- From: Bill Cunningham [mailto:[EMAIL PROTECTED]] Sent: Thu 6/27/2002 1:10 AM To: [EMAIL PROTECTED] Cc: Subject:PPP RFCs Are there RFC's or drafts on the various LCP's that PPP uses or the Network Control Protocol of PPP?
PPP RFCs
Are there RFC's or drafts on the various LCP's that PPP uses or the Network Control Protocol of PPP?
RE: PPP RFCs
Start with RFC 1661, which obsoletes 1548. -Original Message- From: Bill Cunningham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 9:40 AM To: [EMAIL PROTECTED] Subject: PPP RFCs Are there RFC's or drafts on the various LCP's that PPP uses or the Network Control Protocol of PPP?
Re: PPP RFCs
* From [EMAIL PROTECTED] Wed Jun 26 12:55:35 2002 * X-Authentication-Warning: ietf.org: majordom set sender to [EMAIL PROTECTED] using -f * From: Bill Cunningham [EMAIL PROTECTED] * To: [EMAIL PROTECTED] * Subject: PPP RFCs * Date: Wed, 26 Jun 2002 15:40:23 -0400 * MIME-Version: 1.0 * Content-Transfer-Encoding: 7bit * X-Priority: 3 * X-MSMail-Priority: Normal * X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 * Content-Transfer-Encoding: 7bit * Content-Transfer-Encoding: 7bit * X-Loop: [EMAIL PROTECTED] * X-AntiVirus: scanned by AMaViS 0.2.1 * * Are there RFC's or drafts on the various LCP's that PPP uses or the Network * Control Protocol of PPP? * We suggest that you go to the RFC Editor web page and search for PPP. You will get 81 hits. RFC Editor
Re: PPP RFCs
You know, I have been wondering about cable modems and their analog usage...:-) - Original Message - From: Lloyd Wood [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED] Cc: ietf [EMAIL PROTECTED] Sent: Wednesday, June 26, 2002 4:41 PM Subject: Re: PPP RFCs On Wed, 26 Jun 2002, Bill Cunningham wrote: Are there RFC's or drafts on the various LCP's that PPP uses or the Network Control Protocol of PPP? Yes. You're quite capable of finding them, you know. L. Hoping to forestall another 'modems' thread. http://www.ee.surrey.ac.uk/Personal/L.Wood/[EMAIL PROTECTED]
RE: PPP
* switching but a rose by any other name ...). So all of these, including * PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, * transport, application) ... * (catching up on old email) Note that this is not the common-accepted definition of the Internet layering model. The Host Requirements working grouip went through this in detail in 1988, and agreed on the definitions in section 1.1.3 of RFC 1122. Strictly speaking, there IS no network layer in the Internet model, although we commonly tolerate calling the Internet layer (layer 3) the network layer. Layer 2 is the link layer. Bob Braden
Re: PPP
Brian Lloyd wrote: At 11:59 PM 3/6/2002, you wrote: sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. Karl chaired only the pppext WG. Then at the time L2TP or the precursor discussions were done within the PPPEXT WG because the discussion was with Karl. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. That would have been nice, but, the requirements were that it be possible for user authorization be completed at the LNS (the edge device at the target network), and at the LAC (NAS). Thank you for reminding me. LNS and LAC were the terms I was looking for. WRT authentication, there is no reason not to do it in both places. Let the protocol carry the information. In addition, we could not require the user to enter a username and password twice. You simply had to be able to drop in L2TP, and everything look the same as it did before to the end user. I agree that is the more desirable scenario. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. Yup, that would have been nicer. Yes, it would. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. That's OK, we'll forgive you ;-) Thank you. It may seem silly but that has really bugged me for a number of years. I hate the thought of having done flawed work. Barring redesign of PPP, getting around the wrong things being located in the LCP negotiation would have been made a little easier if we had been allowed to go through LCP negotiation twice. So, you could have LCP negotiated at the LAC, But you wouldn't have needed to do LCP negotiation twice. The LAC negotiates LCP because that is the terminus of the link. Not just that, the LAC may also need to get authentication information from the user so that it can know which LNS to forward to. The LAC communicates the options negotiated back to the LNS. That's what we do now. Please read section 4.4.5 of RFC2661. Remember, the LCP options negotiate only indicate what the client is willing to accept therefore it doesn't really matter what it negotiates. It is just there to prevent its peer from sending something it can't handle. But, if the LNS, say, want's to do some different authentication... Say, PAP with an OTP but the LAC negotiated CHAP, then, well... We have to start over PPP LCP, which should be OK except that it used to break a lot of PPP clients. forward any necessary link parameters to the LNS so that it could set them correctly during LCP round 2, and then renegotiate LCP at the LNS to get things like MLPPP and perhaps authentication type which should have been designed into the negotiation process later. Right. That is the crux of the problem. But -- and here is the point about broken PPP stacks -- at the time there were a lot of PPP stacks which would simply roll over and die if you tried to reneogtiate LCP after you had already begun (yes, in great violation to what it says in RFC 1661). This wasn't discovered until L2TP came along because before that, you really didn't see LCP renegotiation occur very much. sigh But we did know. The argument was that it took too long to negotiate PPP as it was so anything we did to speed it up was necessary. I have kicked myself for caving in to that argument for many years now. Then let me give you a collective kick from all of the l2tp developers out there ;-) I thought it was just a bug. I remember telling Robert Webster about this little problem at a pacbell bakeoff many years ago. His jaw dropped, and he went back and made an on-the-fly bugfix for it and afterwards it worked great. Note that Robert worked at Shiva then, and maintained code for the PPP stack that for a while was the original code base for much of the dialup client industry (e.g. Windows, OS/2, and probably some others...). But, it was way too late as there were so many clients in the field with this bug. So, we ended up with Proxy LCP and Proxy Authentication like you see them today. I know: add more ugliness in order to deal with other ugliness. I preferred the old days where people found problems, fixed them, and the fixes then found their ways into new versions
Re: PPP
That top-layer-calls-next-layer etc ad-nauseam model seems to have been one of the original ideas for how to implement a stack. Actual current implementations do all kinds of wierd stuff, but mostly pass around accumulating collections of buffers; so the payload buffer doesn't get copied to accomodate each new header, instead the kernel has a second buffer to contain the header (and later layers can add more). What gets passed around (by way of various queues and internal plumbing schemes) is a structure of pointers to pieces of packet, which gets put together on transmission, often by the DMA engine in the device or by the device driver. The layering is just a conceptual model for the logic of what is going on, and has no resemblance to the flow of control in a typical actual implementation. There are simple educational implementations that follow the layering fairly closely, and they are interesting to read but tend not to be practical for high performance applications. --On Tuesday, 5 March 2002 11:02 p.m. -0800 Christopher Evans [EMAIL PROTECTED] wrote: Here is a question that will tax your synapes to bursting point! How is PPP and TCP/IP libs wired together? Like, DO I (OSI 8) call TCP and it calls IP and down the chain till it spills over and gets real physical (OSI 1)? I am confused. At 10:02 AM 3/5/02 -0500, you wrote: whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL. - Original Message -
Re: PPP
At 11:59 PM 3/6/2002, you wrote: sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. Karl chaired only the pppext WG. Then at the time L2TP or the precursor discussions were done within the PPPEXT WG because the discussion was with Karl. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. That would have been nice, but, the requirements were that it be possible for user authorization be completed at the LNS (the edge device at the target network), and at the LAC (NAS). Thank you for reminding me. LNS and LAC were the terms I was looking for. WRT authentication, there is no reason not to do it in both places. Let the protocol carry the information. In addition, we could not require the user to enter a username and password twice. You simply had to be able to drop in L2TP, and everything look the same as it did before to the end user. I agree that is the more desirable scenario. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. Yup, that would have been nicer. Yes, it would. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. That's OK, we'll forgive you ;-) Thank you. It may seem silly but that has really bugged me for a number of years. I hate the thought of having done flawed work. Barring redesign of PPP, getting around the wrong things being located in the LCP negotiation would have been made a little easier if we had been allowed to go through LCP negotiation twice. So, you could have LCP negotiated at the LAC, But you wouldn't have needed to do LCP negotiation twice. The LAC negotiates LCP because that is the terminus of the link. The LAC communicates the options negotiated back to the LNS. Remember, the LCP options negotiate only indicate what the client is willing to accept therefore it doesn't really matter what it negotiates. It is just there to prevent its peer from sending something it can't handle. forward any necessary link parameters to the LNS so that it could set them correctly during LCP round 2, and then renegotiate LCP at the LNS to get things like MLPPP and perhaps authentication type which should have been designed into the negotiation process later. Right. That is the crux of the problem. But -- and here is the point about broken PPP stacks -- at the time there were a lot of PPP stacks which would simply roll over and die if you tried to reneogtiate LCP after you had already begun (yes, in great violation to what it says in RFC 1661). This wasn't discovered until L2TP came along because before that, you really didn't see LCP renegotiation occur very much. sigh But we did know. The argument was that it took too long to negotiate PPP as it was so anything we did to speed it up was necessary. I have kicked myself for caving in to that argument for many years now. But, it was way too late as there were so many clients in the field with this bug. So, we ended up with Proxy LCP and Proxy Authentication like you see them today. I know: add more ugliness in order to deal with other ugliness. I preferred the old days where people found problems, fixed them, and the fixes then found their ways into new versions, usually with a backward-compatibility switch. I reject the argument, but we have lots of systems in the field; we can't fix them now. Engineers from Microsoft (among others but they come immediately to mind) has been known to use that argument. It is specious because they then turn around and reissue code on a regular basis to fix other bugs in their products. There's not much else you can do if you want to complete PPP negotiation at the LNS, but *start* it at the LAC so that you can get the @domain portion of the username to determine where to tunnel the user. Sigh... Yes, if we had thought about running PPP over IP from the beginning, things might have looked very different in general... A more seperate link layer negotiation would have been one of them. But, PPP isn't nearly as difficult as, say, TDM over IP ;-) This reared its ugly head when we started to do multilink PPP. The problem was *very* clear then. Pointing out that LCP and NCP were really completely separate protocols and represented different layers
Re: PPP
Brian Lloyd wrote: At 03:12 AM 3/4/2002, you wrote: I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. Other than it was designed for IP and the other stuff came along for the ride. PPP was a relatively early product of the IETF and specifically designed for IP. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). This is a common misconception. The lower layers (1 and 2) that you mention are often completely routable networks in and of themselves. You can even encapsulate IP within IP therefore IP is operating at layer 2 from that interpretation. Ethernet is regularly routed now (people call it switching but a rose by any other name ...). So all of these, including PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, transport, application) or layers 1-3b in the ISORM. This problem plagues developers working with PPP for the first time because they keep thinking in terms of PPP being only a link-layer protocol. If they would remember that PPP operates at the network layer then they would stop making stupid mistakes like a badly-designed L2TP. I don't see how classification of PPP as a layer 2, layer 3, or any other layer would have had an affect on how we designed L2TP (perhaps it would have affected the name of the protocol though). Layers aside, PPP was already deployed and it was pretty obvious what we wanted to do - make it run over IP without the installed base of PPP clients being made aware of it. How would you have done this that is substantially different than L2TP? (As an aside, of the list of obscene things we did have to do to make L2TP work, the worst were more due to badly implemented PPP stacks than anything else.) Tunneling, particularly L2 tunneling, is by its very definition a layer violation. The perfect world where this is not necessary or desirable does not exist beyond textbooks and laboratories. So here we are in the real world, tunneling not just PPP but a plethora of L2 or L2-like layers. - Mark E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. I love watching people slavishly adhere to this or that model of layering. Layering is a convenience, not a religion. (Actually, I got that backwards.) With the widespread use of encapsulating one networking or internetworking protocol in another, the whole concept of rigid layering goes out the window. The cry of, its a network layer; its a link layer, should be right up there with, its a dessert topping; its a floor wax! --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) ISO spent a lot of time trying to sell the 7-layer model and then didn't know how to backtrack when they discovered that there were really two network layers when you interconnect dissimilar networks using an internetworking protocol. ATM, FR, Ethernet, etc., are all routable layer-3 protocols in their own regard so they opted to break layer three into three sublayers. (It is really three layers by their reckoning but ISO already had so much invested in the ISO Seven Layer Reference Model [tm] that they couldn't really switch to the ISO Nine Layer Reference Model Formerly Known As The Seven Layer Reference Model [tm].) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network. To some extent you are right but your model needs to accommodate things like L2TP which tunnels traffic at layer 1|2 (depending on the model of the day) in a layer 4 (transport) protocol, or IP tunneled in IP. It is probably better to be able to keep the concept of duality in your mind, i.e. when you hold you tongue one way
RE: PPP
WARNING : this answer will be very basic. My intention is not to go deep into the details but to give a short answer. Suppose you have an Operating System supporting TCP/IP, whatever applications you run. Suppose you have a modem and you use PPP to talk to a remote server. Then data coming from an application on your system will be transported by either TCP segments or UDP segments and use port numbers. Then those segments will be encapsulated into IP datagrams/packets and use IP addresses. Then those datagrams/packets will be encapsulated into PPP frames with no particular addresses (HDLC broadcast address will be used, always set to FF Hex - this is normal, since this is a point-to-point connection, so only 2 DCEs are communicating and there's no particular need for individual physical addressing, like in a multi-point shared Ethernet network). Then all those bits (frames actually represent organized groups of bits) will be converted into a particular signal (signal = electricity, light, micro-waves,...) using a particular encoding scheme (encoding scheme = AMI, Manchester, NRZI,...) able to be transported on a specific medium (medium = copper cable, fiber optics, air,...). That's it. I know, I know : this is a VERY basic answer. Some people will not forgive me for this, but when asked a basic question I can't do anything but give a basic answer. And BTW, when facing a very complex question, I don't even think of answering it. I gladly leave it up to a more competent guy to answer it. Then I sit down and listen, too. ;) -Original Message- From: Christopher Evans [mailto:[EMAIL PROTECTED]] Here is a question that will tax your synapes to bursting point! How is PPP and TCP/IP libs wired together? Like, DO I (OSI 8) call TCP and it calls IP and down the chain till it spills over and gets real physical (OSI 1)? I am confused. At 10:02 AM 3/5/02 -0500, you wrote: whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL.
Re: PPP
At 02:42 AM 3/6/2002, you wrote: I don't see how classification of PPP as a layer 2, layer 3, or any other layer would have had an affect on how we designed L2TP (perhaps it would have affected the name of the protocol though). PPP actually consists of two distinct and separate sets of protocols. The LCP and its negotiation should be totally separate from the NCPs and their negotiation. Layers aside, PPP was already deployed and it was pretty obvious what we wanted to do - make it run over IP without the installed base of PPP clients being made aware of it. Do it right would not have changed that. How would you have done this that is substantially different than L2TP? (As an aside, of the list of obscene things we did have to do to make L2TP work, the worst were more due to badly implemented PPP stacks than anything else.) sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. So, as I said, this is water under the bridge and it isn't going to change. Any attempt to do so would be met with a barrage of but we have lots of systems in the field and this would break them arguments. Tunneling, particularly L2 tunneling, is by its very definition a layer violation. The perfect world where this is not necessary or desirable does not exist beyond textbooks and laboratories. So here we are in the real world, tunneling not just PPP but a plethora of L2 or L2-like layers. There is nothing wrong with tunneling per-se. In fact, it solves many problems. IMHO tunneling is a good thing. My comments had only to do with the fallacy of rigid layering, how many people don't really understand layering, and as a side issue, how PPP was really a suite of protocols at different layers and how that affects MLPPP and L2TP. YMMV Brian Lloyd [EMAIL PROTECTED] +1.530.676.1113 - voice +1.360.838.9669 - fax
Re: PPP
Brian Lloyd wrote: At 02:42 AM 3/6/2002, you wrote: I don't see how classification of PPP as a layer 2, layer 3, or any other layer would have had an affect on how we designed L2TP (perhaps it would have affected the name of the protocol though). PPP actually consists of two distinct and separate sets of protocols. The LCP and its negotiation should be totally separate from the NCPs and their negotiation. Layers aside, PPP was already deployed and it was pretty obvious what we wanted to do - make it run over IP without the installed base of PPP clients being made aware of it. Do it right would not have changed that. How would you have done this that is substantially different than L2TP? (As an aside, of the list of obscene things we did have to do to make L2TP work, the worst were more due to badly implemented PPP stacks than anything else.) sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. Karl chaired only the pppext WG. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. That would have been nice, but, the requirements were that it be possible for user authorization be completed at the LNS (the edge device at the target network), and at the LAC (NAS). In addition, we could not require the user to enter a username and password twice. You simply had to be able to drop in L2TP, and everything look the same as it did before to the end user. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. Yup, that would have been nicer. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. That's OK, we'll forgive you ;-) Barring redesign of PPP, getting around the wrong things being located in the LCP negotiation would have been made a little easier if we had been allowed to go through LCP negotiation twice. So, you could have LCP negotiated at the LAC, forward any necessary link parameters to the LNS so that it could set them correctly during LCP round 2, and then renegotiate LCP at the LNS to get things like MLPPP and perhaps authentication type which should have been designed into the negotiation process later. But -- and here is the point about broken PPP stacks -- at the time there were a lot of PPP stacks which would simply roll over and die if you tried to reneogtiate LCP after you had already begun (yes, in great violation to what it says in RFC 1661). This wasn't discovered until L2TP came along because before that, you really didn't see LCP renegotiation occur very much. But, it was way too late as there were so many clients in the field with this bug. So, we ended up with Proxy LCP and Proxy Authentication like you see them today. There's not much else you can do if you want to complete PPP negotiation at the LNS, but *start* it at the LAC so that you can get the @domain portion of the username to determine where to tunnel the user. Sigh... Yes, if we had thought about running PPP over IP from the beginning, things might have looked very different in general... A more seperate link layer negotiation would have been one of them. But, PPP isn't nearly as difficult as, say, TDM over IP ;-) There are even other bugs in the field we have had to code around with IPCP negotiation, and don't even get me started on ACCM mapping So, as I said, this is water under the bridge and it isn't going to change. Any attempt to do so would be met with a barrage of but we have lots of systems in the field and this would break them arguments. Right. The same argument that led to some of the choices we had to make in L2TP. Tunneling, particularly L2 tunneling, is by its very definition a layer violation. The perfect world where this is not necessary or desirable does not exist beyond textbooks and laboratories. So here we are in the real world, tunneling not just PPP but a plethora of L2 or L2-like layers. There is nothing wrong with tunneling per-se. In fact, it solves many problems. IMHO tunneling is a good thing. My comments had only to do with the fallacy of rigid layering, how many people don't really understand layering, and as a side issue, how PPP was really a suite of protocols at different layers and how that affects MLPPP and L2TP. Then we agree more than we
RE: PPP
Brian (and anyone concerned), I humbly think that before practicing literature, you need to learn ABC. I'm not a researcher, not a great expert, not a guru : I'm a trainer and a consultant. (Well actually I AM a guru... for my wife and my children! But this is out of purpose... ;) I don't intend to develop new complex things but to explain the existing ones and make them understandable. My answer tried to respect the same basic level as Bill's question's. That's my job, teaching LAN WAN technologies (and Datacom in general). My humble experience led me to teach such matters in different steps. First you teach ABC, then you teach grammar, then you can teach literature. Trying to teach literature without preparation can create confusion. Sorry if I shocked you with such a basic view on PPP compared to OSI and TCP/IP. [May I recommend 2 basic books? A World of Protocols and Computer Networks...] One can read that PPP is a suite - a combination of several protocols. Among them : BCP, CHAP, LCP, MLP, PAP, PPPoE,... But seriously, does Bill care? And also a different Network Control Protocol for each network layer supported. If I had to go deeply into such details, my answer would have been too long - and out of purpose. Hope you understand the need for basic ABC and don't only tolerate complex literature. :) -Original Message- From: Brian Lloyd [mailto:[EMAIL PROTECTED]] Sent: lundi 4 mars 2002 17:49 To: TOMSON ERIC Cc: [EMAIL PROTECTED] Subject: RE: PPP At 03:12 AM 3/4/2002, you wrote: I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. Other than it was designed for IP and the other stuff came along for the ride. PPP was a relatively early product of the IETF and specifically designed for IP. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). This is a common misconception. The lower layers (1 and 2) that you mention are often completely routable networks in and of themselves. You can even encapsulate IP within IP therefore IP is operating at layer 2 from that interpretation. Ethernet is regularly routed now (people call it switching but a rose by any other name ...). So all of these, including PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, transport, application) or layers 1-3b in the ISORM. This problem plagues developers working with PPP for the first time because they keep thinking in terms of PPP being only a link-layer protocol. If they would remember that PPP operates at the network layer then they would stop making stupid mistakes like a badly-designed L2TP. E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. I love watching people slavishly adhere to this or that model of layering. Layering is a convenience, not a religion. (Actually, I got that backwards.) With the widespread use of encapsulating one networking or internetworking protocol in another, the whole concept of rigid layering goes out the window. The cry of, its a network layer; its a link layer, should be right up there with, its a dessert topping; its a floor wax! --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) ISO spent a lot of time trying to sell the 7-layer model and then didn't know how to backtrack when they discovered that there were really two network layers when you interconnect dissimilar networks using an internetworking protocol. ATM, FR, Ethernet, etc., are all routable layer-3 protocols in their own regard so they opted to break layer three into three sublayers. (It is really three layers by their reckoning but ISO already had so much invested in the ISO Seven Layer Reference Model [tm] that they couldn't really switch to the ISO Nine Layer Reference Model Formerly Known As The Seven Layer Reference Model [tm].) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology
RE: PPP
At 03:12 AM 3/4/2002, you wrote: I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. Other than it was designed for IP and the other stuff came along for the ride. PPP was a relatively early product of the IETF and specifically designed for IP. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). This is a common misconception. The lower layers (1 and 2) that you mention are often completely routable networks in and of themselves. You can even encapsulate IP within IP therefore IP is operating at layer 2 from that interpretation. Ethernet is regularly routed now (people call it switching but a rose by any other name ...). So all of these, including PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, transport, application) or layers 1-3b in the ISORM. This problem plagues developers working with PPP for the first time because they keep thinking in terms of PPP being only a link-layer protocol. If they would remember that PPP operates at the network layer then they would stop making stupid mistakes like a badly-designed L2TP. E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. I love watching people slavishly adhere to this or that model of layering. Layering is a convenience, not a religion. (Actually, I got that backwards.) With the widespread use of encapsulating one networking or internetworking protocol in another, the whole concept of rigid layering goes out the window. The cry of, its a network layer; its a link layer, should be right up there with, its a dessert topping; its a floor wax! --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) ISO spent a lot of time trying to sell the 7-layer model and then didn't know how to backtrack when they discovered that there were really two network layers when you interconnect dissimilar networks using an internetworking protocol. ATM, FR, Ethernet, etc., are all routable layer-3 protocols in their own regard so they opted to break layer three into three sublayers. (It is really three layers by their reckoning but ISO already had so much invested in the ISO Seven Layer Reference Model [tm] that they couldn't really switch to the ISO Nine Layer Reference Model Formerly Known As The Seven Layer Reference Model [tm].) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network. To some extent you are right but your model needs to accommodate things like L2TP which tunnels traffic at layer 1|2 (depending on the model of the day) in a layer 4 (transport) protocol, or IP tunneled in IP. It is probably better to be able to keep the concept of duality in your mind, i.e. when you hold you tongue one way it looks like a link protocol but when you hold your tongue a different way it looks like a transport protocol. I suspect that something like this gave early physicists fits when they were faced with the duality of nature. So trying to be rigid in your categorization of any protocol is likely to cause you heartburn down the road (ask ISO). It is far better to understand where it makes sense to put interfaces and then perform the functions that need to be performed. --- The extended answer ends here --- -Original Message- From: vint cerf [mailto:[EMAIL PROTECTED]] IP is encapsulated in PPP for all practical purposes. PPP can support multiple protocols on a single point to point link in the same way ethernet can support multiple protocols And, no, as the above quote shows, Vint did not say that PPP does not belong to the TCP/IP protocol suite. He just says that PPP usually encapsulates/transports IP datagrams as its
Re: PPP
whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL. - Original Message - From: Brian Lloyd [EMAIL PROTECTED] To: TOMSON ERIC [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, March 04, 2002 11:49 AM Subject: RE: PPP At 03:12 AM 3/4/2002, you wrote: I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. Other than it was designed for IP and the other stuff came along for the ride. PPP was a relatively early product of the IETF and specifically designed for IP. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). This is a common misconception. The lower layers (1 and 2) that you mention are often completely routable networks in and of themselves. You can even encapsulate IP within IP therefore IP is operating at layer 2 from that interpretation. Ethernet is regularly routed now (people call it switching but a rose by any other name ...). So all of these, including PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, transport, application) or layers 1-3b in the ISORM. This problem plagues developers working with PPP for the first time because they keep thinking in terms of PPP being only a link-layer protocol. If they would remember that PPP operates at the network layer then they would stop making stupid mistakes like a badly-designed L2TP. E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. I love watching people slavishly adhere to this or that model of layering. Layering is a convenience, not a religion. (Actually, I got that backwards.) With the widespread use of encapsulating one networking or internetworking protocol in another, the whole concept of rigid layering goes out the window. The cry of, its a network layer; its a link layer, should be right up there with, its a dessert topping; its a floor wax! --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) ISO spent a lot of time trying to sell the 7-layer model and then didn't know how to backtrack when they discovered that there were really two network layers when you interconnect dissimilar networks using an internetworking protocol. ATM, FR, Ethernet, etc., are all routable layer-3 protocols in their own regard so they opted to break layer three into three sublayers. (It is really three layers by their reckoning but ISO already had so much invested in the ISO Seven Layer Reference Model [tm] that they couldn't really switch to the ISO Nine Layer Reference Model Formerly Known As The Seven Layer Reference Model [tm].) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network. To some extent you are right but your model needs to accommodate things like L2TP which tunnels traffic at layer 1|2 (depending on the model of the day) in a layer 4 (transport) protocol, or IP tunneled in IP. It is probably better to be able to keep the concept of duality in your mind, i.e. when you hold you tongue one way it looks like a link protocol but when you hold your tongue a different way it looks like a transport protocol. I suspect that something like this gave early physicists fits when they were faced with the duality of nature. So trying to be rigid in your categorization of any protocol is likely to cause you heartburn down the road (ask ISO). It is far better to understand where it makes sense
Re: PPP
Here is a question that will tax your synapes to bursting point! How is PPP and TCP/IP libs wired together? Like, DO I (OSI 8) call TCP and it calls IP and down the chain till it spills over and gets real physical (OSI 1)? I am confused. At 10:02 AM 3/5/02 -0500, you wrote: whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL. - Original Message -
RE: PPP
I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network. --- The extended answer ends here --- -Original Message- From: vint cerf [mailto:[EMAIL PROTECTED]] IP is encapsulated in PPP for all practical purposes. PPP can support multiple protocols on a single point to point link in the same way ethernet can support multiple protocols vint At 08:01 AM 3/1/2002 -0500, Bill Cunningham wrote: Is IP actually encapsulated in PPP, or is PPP and IP sent out at the same time at different protocol layers? Kinda holding hands in a sense to each other.
Re: PPP
Layering dogma get all confused and convoluted when faced with engineering ingenuity At what layer is ATM in the old Cells in Frames spec? Or PPP when running ppp sessions over TCP? Or blah over MPLS frames over PPP (over TCP)? Or? PPP is a layer below the one it serves, and a layer above the one it uses Just like most other protocols cheers, gja -- Grenville Armitage http://gjaspace4mecom
Re: PPP
Is IP actually encapsulated in PPP, or is PPP and IP sent out at the same time at different protocol layers? Kinda holding hands in a sense to each other. - Original Message - From: vint cerf [EMAIL PROTECTED] To: Christopher Evans [EMAIL PROTECTED]; Bill Cunningham [EMAIL PROTECTED]; Brian Lloyd [EMAIL PROTECTED] Sent: Friday, March 01, 2002 7:16 AM Subject: Re: PPP christopher, it is called tcp/ip because the encapsulation was read left to right so, for example: smtp/tcp/ip telnet/tcp/ip ftp/tcp/ip http/tcp/ip and ip/ppp/ethernet ip/ethernet ip/ppp/dial-up ip/ppp/dsl and so on the ordering is arbitrary, of course - we just picked higher level protocol to the left as in higher order bit to the left as a way of presenting the protocol layers. vint cerf At 11:58 PM 2/28/2002 -0800, Christopher Evans wrote: Why do they call it TCP/IP ? that sound reversed. it should be IP/TCP-UDP as that makes sense in my head.
Re: PPP
IP is encapsulated in PPP for all practical purposes PPP can support multiple protocols on a single point to point link in the same way ethernet can support multiple protocols vint At 08:01 AM 3/1/2002 -0500, Bill Cunningham wrote: Is IP actually encapsulated in PPP, or is PPP and IP sent out at the same time at different protocol layers? Kinda holding hands in a sense to each other
PPP
In what layer is PPP in the TCP/IP suite?
Re: PPP
On Thu, 28 Feb 2002, Bill Cunningham wrote: In what layer is PPP in the TCP/IP suite? The top of Layer 1 - it's part of the Network Interface layer of the TCP/IP conceptual model PD -- Paul Day Web: wwwburst/~bonfire
RE: PPP
Bill - It is essentially a Data Link Layer protocol, operating at Layer 2. /Michel -Original Message-From: Bill Cunningham [mailto:[EMAIL PROTECTED]]Sent: Thursday, February 28, 2002 6:55 AMTo: [EMAIL PROTECTED]Subject: PPP In what layer is PPP in the TCP/IP suite?
RE: PPP
PPP is a link layer protocol based on the TCO/IP model. In the OSI model, PPP spans Data link and Network layer. Hope this helps. Regards, Paul -Original Message-From: Bill Cunningham [mailto:[EMAIL PROTECTED]]Sent: Thursday, February 28, 2002 6:55 AMTo: [EMAIL PROTECTED]Subject: PPP In what layer is PPP in the TCP/IP suite?
RE: PPP
On Thu, 28 Feb 2002, Michel Gilbert wrote: It is essentially a Data Link Layer protocol, operating at Layer 2 Bill was after where it fits into the TCP/IP model I think you've got that mixed up with the OSI model? :) Layer 2 under the TCP/IP model is the Internet layer, which corresponds to layer 3, Network, of the OSI model If we want to get picky though, you could say PPP overlaps layer 1 and 2 of the TCP/IP model, so saying Layer 2 isn't incorrect, but by using the term Data Link as opposed to Internet fot layer 2 makes me think you're referring of the OSI model *Back in his box now* PD -- Paul Day Web: wwwburst/~bonfire
Re: PPP
DIVFONT face=3DArial size=3D2In what layer is PPP in the TCP/IP= =20suite?/FONT/DIV/BODY/HTML Layer 271828
RE: PPP
Title: RE: PPP Paul - Yep! Didn't read closely enough. Layer 2 in the OSI Reference Model, top of Layer 1 in TCP/IP - except for all of the places it appears elsewhere! :) How's THAT for clarity? /Michel -Original Message- From: Paul Day [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 28, 2002 10:49 AM Cc: [EMAIL PROTECTED] Subject: RE: PPP On Thu, 28 Feb 2002, Michel Gilbert wrote: It is essentially a Data Link Layer protocol, operating at Layer 2. Bill was after where it fits into the TCP/IP model. I think you've got that mixed up with the OSI model? :) Layer 2 under the TCP/IP model is the Internet layer, which corresponds to layer 3, Network, of the OSI model. If we want to get picky though, you could say PPP overlaps layer 1 and 2 of the TCP/IP model, so saying Layer 2 isn't incorrect, but by using the term Data Link as opposed to Internet fot layer 2 makes me think you're referring of the OSI model. *Back in his box now* PD -- Paul Day Web: www.bur.st/~bonfire
Re: PPP
At 03:55 AM 2/28/2002, you wrote: In what layer is PPP in the TCP/IP suite? I have read some of the other responses and it reinforces my belief that most people don't understand PPP's relationship to IP and either the 5-layer (internet) or 7-layer (ISO) models. PPP is really both the link and lower network layers. (The ISORMites discovered that layer three was really several layers in itself but found it difficult to say that the 7-layer model was really a 9-layer model so they created sublayers, i.e. layers 3A, 3B, and 3C. Something about Padlipsky comes to mind here.) The best way to think of PPP is a degenerate network of two nodes, not a link between two devices. If you think of it in this way, things like multilink and L2TP begin to make some sense. The problem occurs when people forget this. The way that I think of it is that the LCP negotiation represents configuration of the link layer while the NCP negotiation configuration at the network layer. And I continue to kick myself for allowing negotiation of multilink as part of LCP instead of doing it after authentication. I fear that this helped screw up L2TP too. I admit I caved to people who were worried about how long it took PPP to complete negotiation, something that just isn't very important. Brian Lloyd [EMAIL PROTECTED] +1.530.676.1113 - voice +1.360.838.9669 - fax
Re: PPP
On Thu, 2002-02-28 at 12:20, Matt Crawford wrote: DIVFONT face=3DArial size=3D2In what layer is PPP in the TCP/IP= =20suite?/FONT/DIV/BODY/HTML Layer 271828 I should have exp()ected that
Re: PPP
From: Brian Lloyd [EMAIL PROTECTED] When all you have is a hammer, everything looks like a nail. ... I must admit, we all laughed when Karl Fox indicated that he had implemented PPP over TELNET back in 1993 or so. We thought it a hilarious joke. I guess my blood should have run cold back then. And to think that, the reason for PPP was a response to the limitations of SLIP and, oh by the way, we can use it to encapsulate IP over T1 lines between dissimilar routers. Why are you surprised? Simple tools (e.g. a screwdriver) have always had the characteristic that they can be used for more things than complex ones (e.g. a mortise-cutting bit for a drill press - now there's a cool tool, BTW - but I digress). The ability of people to use tools for the wrong things (e.g. using a screwdriver as a chisel) is somewhat independent of the complexity of the tool, but does seem to be more common for simple ones, which are more protean. Anyway, simple protocols, like PPP and ARP (another canonical subject of abuse) get reused in vile ways because the architecture which they are components of is fundamentally under-provisioned with mechanisms. But, oh, I forgot, the IPv4 architecture is basically fine, it just needs some engineering refinements. And Eastasia is at war with Oceania... Noel
Re: PPP
From: J. Noel Chiappa [EMAIL PROTECTED] Why are you surprised? Simple tools (e.g. a screwdriver) have always had the characteristic that they can be used for more things than complex ones (e.g. a mortise-cutting bit for a drill press - now there's a cool tool, BTW - but I digress). ... That may be a digression, but it is a good elaboration of the all the world's a nail saying. Screwdrivers and hammers are not only more flexible, but they are a lot harder to break and vastly easier to repair or just sharpen when they get worn. A mortise-cutting bit is an awesome improvement over the alternative, even if you are crazy about grinding your chisels to two angles, diamond stones, strops, and so forth. However, as far as I can tell, hand sharpening a mortise-cutting bit calls for real talent and skill, and don't even think about the equivalent of grinding a new end onto a wrecked screwdriver. ... Anyway, simple protocols, like PPP and ARP (another canonical subject of abuse) get reused in vile ways because the architecture which they are components of is fundamentally under-provisioned with mechanisms. But, oh, I forgot, the IPv4 architecture is basically fine, it just needs some engineering refinements. And Eastasia is at war with Oceania... That's backwards. The architectures that are not under-provisioned with mechanisms are total disasters, as anyone who was even slightly technically involved with TP1-4 knows instinctively, unless they're repressing painful memories. In fact, absolutely everything is fundamentally under-provisioned with mechanisms next year when someone comes up with a new application or other idea. It is a fraud and a deceit to claim to be able to architect provisions for a significant or even noticable part of the unforeseen future. If your design covers any of the real future, as opposed to the future you predicted, you're very lucky. It is not honest to confound great luck with great skill or talent. Vernon Schryver[EMAIL PROTECTED]
RE: PPP
I think Matt really meant PiPiPi which is layer 3.1415926535897932384626433832795(and just keeps on going) John Buda -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Crawford Sent: Thursday, February 28, 2002 12:21 PM To: Bill Cunningham Cc: [EMAIL PROTECTED] Subject: Re: PPP DIVFONT face=3DArial size=3D2In what layer is PPP in the TCP/IP= =20suite?/FONT/DIV/BODY/HTML Layer 2.71828
Re: PPP
From: Vernon Schryver [EMAIL PROTECTED] Anyway, simple protocols, like PPP and ARP (another canonical subject of abuse) get reused in vile ways because the architecture which they are components of is fundamentally under-provisioned with mechanisms. The architectures that are not under-provisioned with mechanisms are total disasters, as anyone who was even slightly technically involved with TP1-4 knows instinctively Ahem. Just because your name is Vern doesn't mean my name is not-Vern. Similarly, not all architectures which are not under-provisioned are over-provisioned. There is a space in the middle... It is a fraud and a deceit to claim to be able to architect provisions for a significant or even noticable part of the unforeseen future. If your design covers any of the real future, as opposed to the future you predicted, you're very lucky. It is not honest to confound great luck with great skill or talent. I don't agree with your contention that it's luck. Let's take as an example Unix, which I would argue has lasted as long as it has for two reasons: first, it was written in a basically portable language, and second, the initial system provided basically the right set of fundamental mechanisms/objects. Looking at the latter point, I think Unix V6 had the things it had not through luck, but because Ken Thompson et al displayed *exactly* great skill and talent. It is true that if you're striking off into a new area, it's more of a gamble - and when you have a success, sometimes there is some luck involved. For instance, in TCP/IP, I think it's lucky that the system has working congestion control - because we certainly didn't understand how to do it right when we went down the no congestion control in the switches road back in the mid/late-70's. It's to some degree luck that there was a workable solution for someone clever to figure out. So when people are moving into a new area, it often takes a while before you find out what the envelope of what's viable is. However, outside things like that, there is clearly a great part of system layout where study of past systems and how they failed and succeeded, along with some guidelines, allows people to design great architecture. If you look, you will actually find that quite often they knew that they had created a successful architecture, and knew how and why they had done it, a long time before it became obvious. Go look at the classic Thompson/Richie paper on V6 Unix for an example; and there are numerous others. The System/360 architects, and the PDP-11 architects, for example, both knew they had great designs at a very, very early stage in the life cycle. Also, you need to distinguish between commercially successful and technically successful. Sometimes systems fail to succeed in the market, but not because they are poorly architected (i.e. a technical failure), but because the company screws up in other ways. Multics is a classic example; I was involved with one in the router business. Someone (maybe Napoleon - or maybe someone said it of Rommel) once said that great generals make their own luck. So it is with system architects. Noel
Re: PPP
I have received several responses and most people say it's in the data layer, and a couple of people think it's in the network layer. I don't really pay much attention to the OSI model, I think it complicates the complicated. I try to focus more on TCP/IP. Does PPP establish a link, then terminate, or continue throughout session in UDP and TCP? I posted this question on the PPP mailing list with less familiaritive response than ietf general list. - Original Message - From: Brian Lloyd [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 28, 2002 11:52 AM Subject: Re: PPP At 03:55 AM 2/28/2002, you wrote: In what layer is PPP in the TCP/IP suite? I have read some of the other responses and it reinforces my belief that most people don't understand PPP's relationship to IP and either the 5-layer (internet) or 7-layer (ISO) models. PPP is really both the link and lower network layers. (The ISORMites discovered that layer three was really several layers in itself but found it difficult to say that the 7-layer model was really a 9-layer model so they created sublayers, i.e. layers 3A, 3B, and 3C. Something about Padlipsky comes to mind here.) The best way to think of PPP is a degenerate network of two nodes, not a link between two devices. If you think of it in this way, things like multilink and L2TP begin to make some sense. The problem occurs when people forget this. The way that I think of it is that the LCP negotiation represents configuration of the link layer while the NCP negotiation configuration at the network layer. And I continue to kick myself for allowing negotiation of multilink as part of LCP instead of doing it after authentication. I fear that this helped screw up L2TP too. I admit I caved to people who were worried about how long it took PPP to complete negotiation, something that just isn't very important. Brian Lloyd [EMAIL PROTECTED] +1.530.676.1113 - voice +1.360.838.9669 - fax
Re: PPP
I kinda working on my own tcp/ip lib and this is how I interprete it. Your dumb terminal scripter makes connection that activates PPP (with LCP confsync) if that get an IP and return good then you can splat (encapulate) IP/TCP/UDP packets out the line er. and I must warn you I havnt got a working version so dont listen to me, I am a techno moron. Why do they call it TCP/IP ? that sound reversed. it should be IP/TCP-UDP as that makes sense in my head. At 02:25 AM 3/1/02 -0500, Bill Cunningham wrote: I have received several responses and most people say it's in the data layer, and a couple of people think it's in the network layer. I don't really pay much attention to the OSI model, I think it complicates the complicated. I try to focus more on TCP/IP. Does PPP establish a link, then terminate, or continue throughout session in UDP and TCP? I posted this question on the PPP mailing list with less familiaritive response than ietf general list. - Original Message - From: Brian Lloyd [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 28, 2002 11:52 AM Subject: Re: PPP At 03:55 AM 2/28/2002, you wrote: In what layer is PPP in the TCP/IP suite? I have read some of the other responses and it reinforces my belief that most people don't understand PPP's relationship to IP and either the 5-layer (internet) or 7-layer (ISO) models. PPP is really both the link and lower network layers. (The ISORMites discovered that layer three was really several layers in itself but found it difficult to say that the 7-layer model was really a 9-layer model so they created sublayers, i.e. layers 3A, 3B, and 3C. Something about Padlipsky comes to mind here.) The best way to think of PPP is a degenerate network of two nodes, not a link between two devices. If you think of it in this way, things like multilink and L2TP begin to make some sense. The problem occurs when people forget this. The way that I think of it is that the LCP negotiation represents configuration of the link layer while the NCP negotiation configuration at the network layer. And I continue to kick myself for allowing negotiation of multilink as part of LCP instead of doing it after authentication. I fear that this helped screw up L2TP too. I admit I caved to people who were worried about how long it took PPP to complete negotiation, something that just isn't very important. Brian Lloyd [EMAIL PROTECTED] +1.530.676.1113 - voice +1.360.838.9669 - fax
PPP in HDLC framing
Title: PPP in HDLC framing Hi !! I am working on PPP in HDLC like framing. I have a doubt.. In case packet length exceeds MRU , then what is the fate of the packet and how it is handled.. Regards, sunil
Re: PPP in HDLC framing
Title: PPP in HDLC framing Actually the sender will see to it that it will not send any packet which exceeds the MRU. If the packet size is more than MRU then it isfragmented into the packets which are less than of MRU and sent by the sender. Chandra - Original Message - From: Sunil Shukla To: [EMAIL PROTECTED] Sent: Wednesday, September 12, 2001 3:10 PM Subject: PPP in HDLC framing Hi !! I am working on PPP in HDLC like framing. I have a doubt.. In case packet length exceeds MRU , then what is the fate of the packet and how it is handled.. Regards, sunil The Information contained and transmitted by this E-MAIL is proprietary to Wipro and/or its Customer and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail notify us immediately at [EMAIL PROTECTED]
ML-PPP
Hello: I would like to request for following information: -- pointers to the Deployment experiences from Network Service Providers on the ML-PPP -- pointers to the archived mailing list on the PPP/ML-PPP I would greately appreciate, if some one could provide with the above. Regards, Srihari Varada S/MIME Cryptographic Signature
