idnits 2.17.1 draft-ietf-pppext-l2tpadc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 58: '... MUST NOT do so until it both sen...' RFC 2119 keyword, line 66: '...fication, and it SHOULD be changed to ...' RFC 2119 keyword, line 103: '... this document. An implementation MUST...' RFC 2119 keyword, line 112: '... flows, L2TP SHOULD process all pa...' RFC 2119 keyword, line 117: '... Control packets MUST be sent over the...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 117 has weird spacing: '...ver the prima...' == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1997) is 9963 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group William Palter 3 Request for Comments: DRAFT Cisco Systems 4 Category: Internet Draft 5 Title: draft-ietf-pppext-l2tpadc-00.txt 6 Date: January 1997 8 L2TP Alternate Data Channel (``L2TPADC'') 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet- 20 Drafts as reference material or to cite them other than as a 21 ``working draft'' or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 26 munnari.oz.au. 28 Abstract 30 The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for 31 tunneling PPP sessions over arbitrary media. There exists a class of 32 services for which different types of data packets should be 33 segregated from each other, over the lower layer transport. This 34 document describes the solution space addressed, its underlying 35 motivations, and the protocol modifications required. This 36 enhancement to the L2TP protocol is called L2TP Alternate Data 37 Channel, or ``L2TPADC''. 39 1. Introduction 41 L2TP [1] defines a general purpose mechanism for tunneling PPP over 42 various media. By design, it insulates L2TP operation from the 43 details of the media over which it operates. There are conditions 44 where it may be desirable to send the data portion or some subset of 45 the data portion of an L2TP tunnel over a different media, or using 46 different options of the lower layer medium than is used for the 47 control portion of the tunnel. 49 2. Tunnel Establishment 51 2.1 Negotiation 53 L2TPADC is negotiated by an optional AVP ``L2TPADC'' which is 54 placed in the SCCRQ/SCCRP tunnel establishment messages. The 55 effect of this AVP on a given session will never occur until L2TP 56 reaches a state where payload data may be forwarded for a session 57 in the tunnel. Additionally, each side intending to use L2TPADC 58 MUST NOT do so until it both sends and receives this AVP. Unless 59 an L2TPADC AVP exists in both the SCCRQ and SCCRP packets, L2TP 60 will operate in its regular mode 62 2.2 AVP Format 64 The AVP L2TPADC is encoded as Vendor ID 9, Attribute is the 16-bit 65 quantity 2 (the ID 9 reflects Cisco Systems, the initial developer 66 of this specification, and it SHOULD be changed to 0 and an 67 official Attribute value chosen if this specification advances on 68 a standards track). The Value is divided into two fields one 69 indicating the channel type and usage of this alternate data 70 channel and one for media specific information about the channel. 71 This AVP itself is optional. The only type that is currently 72 defined is the Degraded IPSEC Channel (see section 2.3.1). 74 0 1 2 3 75 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 |0|0|0|0| 8 + data length | 9 | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | 2 | Channel Type | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | Media Specific Data ..... 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 2.3 Channel Types 86 2.3.1 Degraded IPSEC Channel 88 The Degraded IPSEC Channel, Channel Type 0, is for use when the 89 data flow on a tunnel may require strong security on some 90 sessions (or packets within a session) and less secure security 91 for other data packets and/or sessions. The control channel 92 (which is also the primary data channel) should be setup with 93 the highest level of security that is required. The media 94 specific data should be set to a 16 bit value indicating 95 another UDP port to which data packets can be sent that have 96 less security associated with them. For example, a tunnel is 97 created with IPSEC encryption on the control channel, and a 98 client establishes a PPP session over the tunnel in which ECP 99 is also enabled and doing encryption. In this case the ECP PPP 100 frames can be sent over the Degraded IPSEC Channel, and non ECP 101 protected frames can be sent over the primary data channel. The 102 policy for which packets can be sent over the degraded channel 103 is beyond the scope of this document. An implementation MUST 104 send traffic over the strongest channel, unless it has specific 105 policies permitting it to send a packet over the degraded 106 channel. 108 2.4 Data Packet Flow 110 When data packets for a single session are sent over more than 111 one, data channel the sequence number space is shared among both 112 flows, L2TP SHOULD process all packets for a tunnel without regard 113 for which channel the packet is received upon. 115 2.5 Control Packet Flow 117 Control packets MUST be sent over the primary channel. If a 118 control packet is received on the alternate channel, it MUST be 119 discarded. 121 3. Security Considerations 123 Security can be compromised by using this option. It is assumed that 124 implementation policies with regard to determining which packets can 125 go over a degraded channel will be sufficient to protect security. In 126 addition since the security policies may not be symmetrical, an 127 implementation should have the ability to be configured not to allow 128 this option to be used. 130 4. Acknowledgments 132 Thanks to Andrew J. Valencia, W. Mark Townsley, and Robert Adams of 133 Cisco Systems for help in creating, and reviewing this draft. 135 5. Contacts 137 William Palter 138 Cisco Systems 139 101 Cooper Street 140 Santa Cruz, CA 95060 141 palter@zev.net 143 6. References 145 [1] A. Valencia, ``Layer 2 Tunnel Protocol (L2TP)'', Internet Draft, 146 October 1997