idnits 2.17.1 draft-ietf-l2tpext-adc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 ** 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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 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 3 characters 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 66: '... MUST NOT do so until it both sen...' RFC 2119 keyword, line 74: '...fication, and it SHOULD be changed to ...' RFC 2119 keyword, line 111: '...this document. An implementation MUST...' RFC 2119 keyword, line 120: '... flows, L2TP SHOULD process all pa...' RFC 2119 keyword, line 125: '... Control packets MUST be sent over the...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 125 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 (October 1999) is 8960 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: 9 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group William Palter 2 Request for Comments: DRAFT RedBack Networks 3 Category: Internet Draft 4 Title: draft-ietf-l2tpext-adc-00.txt 5 Date: October 1999 7 L2TP Alternate Data Channel (``ADC'') 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet- 22 Drafts as reference material or to cite them other than as a 23 ``working draft'' or ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To learn the current status of any Internet-Draft, please check the 32 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 33 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 34 munnari.oz.au. 36 Abstract 38 The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for 39 tunneling PPP sessions over arbitrary media. There exists a class of 40 services for which different types of data packets should be 41 segregated from each other, over the lower layer transport. This 42 document describes the solution space addressed, its underlying 43 motivations, and the protocol modifications required. This 44 enhancement to the L2TP protocol is called L2TP Alternate Data 45 Channel, or ``L2TPADC''. 47 1. Introduction 49 L2TP [1] defines a general purpose mechanism for tunneling PPP over 50 various media. By design, it insulates L2TP operation from the 51 details of the media over which it operates. There are conditions 52 where it may be desirable to send the data portion or some subset of 53 the data portion of an L2TP tunnel over a different media, or using 54 different options of the lower layer medium than is used for the 55 control portion of the tunnel. 57 2. Tunnel Establishment 59 2.1 Negotiation 61 L2TPADC is negotiated by an optional AVP ``L2TPADC'' which is 62 placed in the SCCRQ/SCCRP tunnel establishment messages. The 63 effect of this AVP on a given session will never occur until L2TP 64 reaches a state where payload data may be forwarded for a session 65 in the tunnel. Additionally, each side intending to use L2TPADC 66 MUST NOT do so until it both sends and receives this AVP. Unless 67 an L2TPADC AVP exists in both the SCCRQ and SCCRP packets, L2TP 68 will operate in its regular mode 70 2.2 AVP Format 72 The AVP L2TPADC is encoded as Vendor ID 9, Attribute is the 16-bit 73 quantity 2 (the ID 9 reflects Cisco Systems, the initial developer 74 of this specification, and it SHOULD be changed to 0 and an 75 official Attribute value chosen if this specification advances on 76 a standards track). The Value is divided into two fields one 77 indicating the channel type and usage of this alternate data 78 channel and one for media specific information about the channel. 79 This AVP itself is optional. The only type that is currently 80 defined is the Degraded IPSEC Channel (see section 2.3.1). 82 0 1 2 3 83 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 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 |0|0|0|0| 8 + data length | 9 | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | 2 | Channel Type | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | Media Specific Data ..... 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 2.3 Channel Types 94 2.3.1 Degraded IPSEC Channel 96 The Degraded IPSEC Channel, Channel Type 0, is for use when the 97 data flow on a tunnel may require strong security on some 98 sessions (or packets within a session) and less secure security 99 for other data packets and/or sessions. The control channel 100 (which is also the primary data channel) should be setup with 101 the highest level of security that is required. The media 102 specific data should be set to a 16 bit value indicating 103 another UDP port to which data packets can be sent that have 104 less security associated with them. For example, a tunnel is 105 created with IPSEC encryption on the control channel, and a 106 client establishes a PPP session over the tunnel in which ECP 107 is also enabled and doing encryption. In this case the ECP PPP 108 frames can be sent over the Degraded IPSEC Channel, and non ECP 109 protected frames can be sent over the primary data channel. The 110 policy for which packets can be sent over the degraded channel 111 is beyond the scope of this document. An implementation MUST 112 send traffic over the strongest channel, unless it has specific 113 policies permitting it to send a packet over the degraded 114 channel. 116 2.4 Data Packet Flow 118 When data packets for a single session are sent over more than 119 one, data channel the sequence number space is shared among both 120 flows, L2TP SHOULD process all packets for a tunnel without regard 121 for which channel the packet is received upon. 123 2.5 Control Packet Flow 125 Control packets MUST be sent over the primary channel. If a 126 control packet is received on the alternate channel, it MUST be 127 discarded. 129 3. Security Considerations 131 Security can be compromised by using this option. It is assumed that 132 implementation policies with regard to determining which packets can 133 go over a degraded channel will be sufficient to protect security. In 134 addition since the security policies may not be symmetrical, an 135 implementation should have the ability to be configured not to allow 136 this option to be used. 138 4. Acknowledgments 140 Thanks to Andrew J. Valencia, W. Mark Townsley, and Robert Adams of 141 Cisco Systems for help in creating, and reviewing this draft. 143 5. Contacts 145 William Palter 146 RedBack Networks 147 1389 Moffett Park Drive 148 Sunnyvale, CA 94089 149 palter.ietf@zev.net 151 6. References 153 [1] A. Valencia, ``Layer 2 Tunnel Protocol (L2TP)'', Internet Draft, 154 October 1997