NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Chair(s):
Karl Fox <karl@ascend.com>
Internet Area Director(s):
Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>
Internet Area Advisor:
Jeffrey Burgan <burgan@home.net>
Mailing Lists:
General Discussion:ietf-ppp@merit.edu
To Subscribe: ietf-ppp-request@merit.edu
Archive: ftp://merit.edu/pub/ietf-ppp-archive
Description of Working Group:
Note: A seperate list has been set up for L2TP discussions
L2TP Discussions:l2tp@zendo.com To Subscribe: l2tp-request@zendo.com Archive: http://bodhi.zendo.com/vandys/l2tp-mail
The Point-to-Point Protocol (PPP) was designed to encapsulate multiple protocols. IP was the only network layer protocol defined in the original documents. The working group is defining the use of other network layer protocols and options for PPP. The group will define the use of protocols including: bridging, ISO, DECNET (Phase IV and V), XNS, and others. In addition, it will define new PPP options for the existing protocol definitions, such as stronger authentication and encryption methods.
No Goals and Milestones
Internet-Drafts:
· PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol
· Point-to-Point Tunneling Protocol--PPTP
· Layer Two Tunneling Protocol 'L2TP'
· IP Header Compression over PPP
· Layer Two Tunneling Protocol 'L2TP' Security Extensions for Non-IP networks
· The PPP DES Encryption Protocol, Version 2 (DESE-bis)
· The PPP Triple-DES Encryption Protocol (3DESE)
· PPP LCP Self Describing Padding
· PPP EAP ISAKMP Authentication Protocol
· Layer Two Tunneling Protocol 'L2TP' Management Information Base
· PPP EAP TLS Authentication Protocol
· L2TP Header Compression (''L2TPHC'')
· PPP Consistent Overhead Byte Stuffing (COBS)
· PPP EAP KEA Public Key Authentication Protocol
· PPP Fortezza Encryption Encapsulation Protocol
· PPP EAP DSS Public Key Authentication Protocol
· PPP Certificate Exchange Protocol
· L2TP-over-IP Path MTU Discovery (''L2TPMTU'')
· L2TP Alternate Data Channel (``L2TPADC'')
· Layer Two Tunneling Protocol ''L2TP'' IP Differential Services Extension
· Layer Two Tunneling Protocol ''L2TP'' Multi-Protocol Label Switching Extension
· Microsoft PPP CHAP Extensions
· Microsoft Point-To-Point Encryption (MPPE) Protocol
· PPP LCP Language and Character Set Configuration Option
· PPP Link Balancing Detection (LBD)
· L2TP Dynamic Data Window Adjustment
· Layer Two Tunneling Protocol (L2TP) over Frame Relay
Request For Comments:
RFC |
Status |
Title |
RFC1332 |
PS |
The PPP Internet Protocol Control Protocol (IPCP) |
RFC1378 |
PS |
The PPP AppleTalk Control Protocol (ATCP) |
RFC1377 |
PS |
The PPP OSI Network Layer Control Protocol (OSINLCP) |
RFC1473 |
PS |
The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol |
RFC1472 |
PS |
The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol |
RFC1471 |
PS |
The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol |
RFC1474 |
PS |
The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol |
RFC1553 |
PS |
Compressing IPX Headers Over WAN Media (CIPX) |
RFC1552 |
PS |
The PPP Internetwork Packet Exchange Control Protocol (IPXCP) |
RFC1547 |
Requirements for an Internet Standard Point-to-Point Protocol | |
RFC1570 |
PS |
PPP LCP Extensions |
RFC1598 |
PS |
PPP in X.25 |
RFC1618 |
PS |
PPP over ISDN |
RFC1619 |
PS |
PPP over SONET/SDH |
RFC1638 |
PS |
PPP Bridging Control Protocol (BCP) |
RFC1663 |
PS |
PPP Reliable Transmission |
RFC1662 |
S |
PPP in HDLC-like Framing |
RFC1762 |
DS |
The PPP DECnet Phase IV Control Protocol (DNCP) |
RFC1763 |
PS |
The PPP Banyan Vines Control Protocol (BVCP) |
RFC1764 |
PS |
The PPP XNS IDP Control Protocol (XNSCP) |
RFC1968 |
PS |
The PPP Encryption Control Protocol (ECP) |
RFC1969 |
The PPP DES Encryption Protocol (DESE) | |
RFC1973 |
PS |
PPP in Frame Relay |
RFC1977 |
PPP BSD Compression Protocol | |
RFC1975 |
PPP Magnalink Variable Resource Compression | |
RFC1979 |
PPP Deflate Protocol | |
RFC1967 |
PPP LZS-DCP Compression Protocol (LZS-DCP) | |
RFC1974 |
PPP Stac LZS Compression Protocol | |
RFC1976 |
PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) | |
RFC1963 |
PPP Serial Data Transport Protocol (SDTP) | |
RFC1990 |
DS |
The PPP Multilink Protocol (MP) |
RFC1989 |
DS |
PPP Link Quality Monitoring |
RFC1978 |
PPP Predictor Compression Protocol | |
RFC1993 |
PPP Gandalf FZA Compression Protocol | |
RFC1994 |
DS |
PPP Challenge Handshake Authentication Protocol (CHAP) |
RFC2043 |
PS |
The PPP SNA Control Protocol (SNACP) |
RFC2097 |
PS |
The PPP NetBIOS Frames Control Protocol (NBFCP) |
RFC2118 |
Microsoft Point-To-Point Compression (MPPC) Protocol | |
RFC2125 |
PS |
The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) |
RFC2153 |
PPP Vendor Extensions | |
RFC2290 |
PS |
Mobile-IPv4 Configuration Option for PPP IPCP |
RFC2284 |
PS |
PPP Extensible Authentication Protocol (EAP) |
RFC2363 |
PS |
PPP Over FUNI |
RFC2364 |
PS |
PPP over AAL5 |
PPPEXT WG
Chicago, IL
Chair: Karl Fox <karl@ascend.com>
Reported by: Matt Holdrege <matt@ascend.com>
Day One, August 25th 1998
Anita Freeman (afreema@cisco.com) spoke on the next interoperability workshop
covering IPSEC, IKE, L2TP and L2TP with IPSEC. It's in Binghamton,cNew York on
October 27-30 and announcements have been sent to the list.
Mark Townsley (townsley@cisco.com) and Bill Palter (palter@network-alchemy.com)
gave an L2TP update. L2TP is not yet at Proposed Standard. The IESG is reviewing the
standard and there will be a draft -12. The IESG is concerned with security and reserved
numbers for IANA.
IANA needs new section listing what numbers IANA should be concerned about 20
An IETF approved document must exist for the numbers to be assigned by IANA.
For security, the floating IP address is an issue. The IESG says that the security threats
outweigh the potential benefits. Text stating that an implementation MUST always
respond to the source IP address will be removed.
It was noted that if you use IPSEC, the problem with changing IP addresses is no longer
a concern.
It was asked whether IPSEC should be mandatory for L2TP, but the WG did not agree
to do that.
In congruence with no floating IP address, the UDP port will also remain fixed after
tunnel establishment.
In keeping with the TFTP model, the following exchanged is still permissible (x and y
can be any port number, including 1701):
=E0 SCCRQ (src=3Dx,dest=3D1701)
=DF SCCRP (src=3Dy, dest=3Dx)
=E0SCCCN (src=3Dx,dest=3Dy)
The IESG is worried about NAT and firewalls with this arrangement. There was some
discussion and it was resolved that we would take it to the list.
Paolo Crivellari <pcri@sebb.bel.alcatel.be>=20
draft-alcatel-pppext-l2tp-atmext-00.txt
This is a draft for L2TP access over ATM over media such as XDSL. The LAC performs
bridging of a PPP session between AAL5 and L2TP transport. A generic packet based
network would connect the LAC and LNS.
They need to add two extra bits to identify non-HDLC access network types. The other
bit is to identify Broadband bearer capabilities. This is under the framing type AVP and
the bearer type AVP
Also a minimum bit per second upstream AVP and a maximum bit per second upstream
AVP are needed. An ATM cause code AVP is needed to determine failure conditions.
And the dial number AVP should be binary encoded. A Maximum Receive Unit AVP
is also added.
Bill Simpson <wsimpson@greendragon.com> covered the following drafts
draft-ietf-pppext-lcpext-ds-03.txt
draft-ietf-pppext-callback-ds-02.txt
draft-ietf-pppext-padding-ds-01.txt
draft-ietf-pppext-conversion-01.txt
draft-ietf-pppext-framerelay-ds-01.txt
draft-ietf-pppext-x25-ds-01.txt
draft-ietf-pppext-ether-00.txt
Bill said the first six of these drafts had expired and he wanted the IESG to put them
forward. The LCP extensions draft had some comments from the IESG which Bill
added to a new draft.
SDP has zero implementations because it slows negotiation and because hardware
doesn't appear to exist anymore that requires it. Bill said that other protocols refer to
SDP. But he thinks it should be put out as proposed standard so people can use it in
the future.
PPP Framing conversion is waiting for the chair to forward the draft.
PPP in Frame Relay has multiple implementations. The chair and AD's will check up
on the status.
PPP in X.25 hasn't been implemented much. Bill asked if anyone cared about this
protocol. Someone said yes it is useful. Thomas Narten said to either advance it or
make it historic. It is also referenced in the AO/DI protocol.
PPP in Ether-like framing is new. The motivation behind this draft is to provide
something simpler than HDLC for high-speed networks. Everything is on 32-bit
boundaries to make it easier to implement in hardware. Bill wants this to go to
proposed standard.
Karl asked if this should go to ANSI since it seems to be about framing over Sonet.
Lucent noted that hardware framers at OC-48 exist today.
Rollins Turner rturner@eng.paradyne.com
L2TP over ATM
Draft-ietf-pppext-l2tp-atm-00.txt
Based on RFC 1483. How to use ATM for the link between LAC and LNS. The draft
suggests supporting large MTU's such as 9180 and the authors are looking for
suggestions. QoS is an implementation decision. Two encapsulation methods, LLC and
VC Mux. Method negotiated on SVC setup and pre-configured for PVC's.
SVC signaling is based on RFC 2364. A BLLI IE specified by originators the desired
encapulation. For detecting and recovering from unsolicited L2TP encaps transitions,
LLC encapsulated frames always begin with a fixed 8 byte sequence. Upon change in
encaps, tear down tunnel or if SVC terminate connection.=20
It was noted that this draft shouldn't reference a byte position but should follow the
L2TP spec.
It was asked what would happen if an intermediate ATM switch uses EPD or PPD. The
author didn't see how this is different from L2TP over IP, but he would look into it.
It was noted that RFC 1483 has been updated and it should be examined.
Day 2
August, 26th 1998
Evan Caves <evan@acc.com>
L2TP MIB
Draft-ietf-pppext-l2tp-mib-02.txt
The changes from -01 include:
- Added tunnel domain group (optional)
- Removed redundant objects
- More consistent object names
- L2TP notifications
- Removed UDP configuration table
- Updated MIB relationships section
Still to be done:
- Update L2TP UDP stats table
- Add shared secret to tunnel (and domain?) config tables
- Finalize indexing session table
This will be taken back to the list and updated over the next few weeks and then move
to WG last call.
Glen Zorn <glennz@microsoft.com>
LCP Internationalization Config Option
draft-ietf-pppext-charset-02.txt
New LCP option has character set and language specification. It uses an enumerated
value of updated country codes, but allows a string value for new languages.
Glen Zorn <glennz@microsoft.com>
MS-CHAP v2
This is the first public discussion of MS-CHAP v2 and it will result in a forthcoming draft.
Features:
- Mutual authentication
- Asymmetric keying
- Defeat of pre-computed dictionary attacks.
- New algorithm number of 0x81 from IANA
- 16 octet challenges
- Peer challenge in response
Authenticator authenticator in the success packet which is 40 hex digits in ASCII. It's
ASCII so it could be printable in an error message.
New password change protocol. It has a peer challenge in password change request.
Auth Auth in success packet.
The MPPE key derivation method is different. It's based on an NT password hash with
master send/receive keys. Keys are changed on every packet.
There should be a new Radius attribute to differentiate between MS-CHAP v1 and v2.
Bill Simpson <wsimpson@greendragon.com>
PPP over Sonet
This adds ATM style payload scrambling and a draft ITU-T PPP indicator value of
0x16. 0x17 is reserved in the draft for ppp in etherlike framing which is another draft.
For OC-48 and above, the default framing is etherlike. Below OC-48 can use octet
stuffing and scrambling.
The group debated whether to specify etherlike framing or HDLC for OC-48+. Most
people in the room who had direct interest preferred HDLC. At least a couple of people
wanted the option of using an alternative like etherlike framing if it becomes standardized.
It was noted that this draft should coordinate with MPLS over PPP/Sonet to specify the
location of the shim.
Several questions and comments related to Sonet/SDH were made and commentators
were urged to take their comments and questions to the main PPP list.
Bill's goal is to resolve the Sonet and SDH interoperability issues. Others said that all
we should do is document our issues with Sonet/SDH interoperability and that it is up
to other forums to resolve the interoperability issues.
None received.