home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
pppext
/
pppext-minutes-96jun.txt
< prev
next >
Wrap
Text File
|
1996-10-07
|
12KB
|
308 lines
Editor's note: These minutes have not been edited.
The PPP Extensions Working Group met at the Montreal IETF meeting
on Wednesday, June 26th from 1300-1500 and on Thursday, June 27th
from 1300-1500.
Minutes of the two meetings follow:
Reported by: Ed Allen
Wednesday meeting
1. LCP Extensions (draft-ietf-pppext-lcpext-ds-00.txt)
Bill Simpson led a discussion of the various LCP extensions described in
the document.
Bill said this draft has been on hold waiting for someone who wanted
to change callback.
An informal poll showed that there are 2 implementations of the
Identification option, and 2 implementations of callback. Discussion
revealed there is concern that the callback option is not ready yet.
Resolution is that Callback option will be stripped from current draft
and made into a separate draft, so that the remaining LCP extensions
can continue on the standards track. draft-ietf-pppext-lcpext-ds will
then be resubmitted and sent out for working group last call.
2. Vendor Extensions (draft-ietf-pppext-vendor-00.txt)
Bill Simpson explained the rationale of this draft. He explained that
this cannot be standards track document due to no possibility of
interoperable versions, but noted that CCP already has the same
vendor-specific option, which is standards-track. Bill asked what do
people think about going standards track? Area Director Jeff Burgan
said he thought it would be Informational.
Resolution is that this draft will be sent as Informational RFC by Bill
Simpson to the IESG.
3. SONET (RFC 1619)
Bill Simpson explained that there are already commercial
implementations of this RFC. Bill explained that PPP has been
designed to run from very low speeds to very high speeds, and briefly
explained SONET, which runs at 155 Mbits/sec, with 622 Mbs and 2
Gbps in development. He explained that although ATM runs over
SONET, it has a larger overhead than PPP. He noted that one major
chip vendor has admitted not conforming to SONET spec in loss of state.
The chip only detects 72 bit sequences of zeros.
Bill proposed to add two sentences and an appendix to PPP over SONET
which will describe a settable third byte and how to escape long
sequences of zeros. This text will provide a workaround for the chip
problem.
4. Multilink Protocol(MP) (draft-ietf-pppext-multilink-12.txt)
Karl Fox led a discussion of Multilink, RFC 1717. Karl said MP has been
sent to Draft Standard.
Karl recalled a discussion which took place on the list to the effect
that the caller being responsible for initiating bringup of links (with
respect to dialed lines and bandwidth-on-demand). Resolution of this
issue was that there would be no change to MP. It is on desk of RFC
editor and will have a new RFC number assigned to it. There was
discussion as to whether there should be an informational RFC
describing current practices in this area. It was decided that there is
sufficient interest, and Dan Brennan volunteered to head up the effort
to write the informational RFC.
5. Extensible Authentication Protocol(EAP)
(draft-ietf-pppext-eap-auth-02.txt and draft-ietf-pppext-eaprsa-
02.txt)
Karl Fox noted the main document fell off the six month timer. Since
there are two interoperable implementations the main document will
be resubmitted. There was interest by three to four vendors in working
on this extension.
6. Protocol Spoofing Control Protocol(PSCP) (draft-ietf-pppext-spoof-
00.txt)
The author was not present.
A discussion of the merits of this approach occurred. A representative
from one vendor mentioned they had done some work on retaining
context while spoofing, when zero links (retaining context across
disconnects). One benefit is that a client can retain its dynamically
assigned IP address.
There was a proposal that doing a spoofing protocol was not
worthwhile in and of itself.
Long discussion occurred about persistent state, suspend/resume notion,
spoofing.
Group rejected idea of putting spoofing capabilities into BACP. At least
one vendor has implemented PSCP.
Resolution was that Dana Blair would work with Ian Puleston (draft
author) to describe current practices.
7. STAC compression (draft-ietf-pppext-stacker-09.txt)
It was agreed that draft 10 will consist of draft .09 plus fixed typos.
Draft 10 will then be sent to the IESG for upgrade to proposed standard.
One questioner asked whether anyone has gone ahead w/ Motorola
license agreement? Only one company said they had executed the
license agreement.
Hands showed there were about 10 implementers of Stacker. A
representative from Stac said that there is a deal where you can get
access to Motorola license proposal from Stac. It contains terms of
license agreement.
8. Status of other work by PPP WG.
CHAP and LQM are now approved Draft Standards, and will get RFC
numbers soon. Netbios CP is at Proposed Std status.
Other drafts:
Status of WCP (draft-ietf-pppext-wcp-00.txt) was discussed. Ed Allen
explained that WCP can be negotiated using CCP, and is thus not a
standard which competes with WCP.
draft-ietf-pppext-dataencap-03.txt has expired, and as there is no
interest from the WG, will be allowed to die.
draft-ietf-pppext-encryption-04.txt is at Proposed Standards draft-
ietf-pppext-des-encrypt-01.txt is an informational. draft-ietf-pppext-
frame-relay-03.txt is stds track, and is at PS and will receive an RFC
number from the RFC editor at some point in the future.
draft-ietf-pppext-snacp-01.txt has been implemented by one vendor,
and will become and informational RFC.
11. PacBell bakeoff
Anita Freeman of PacBell stated there will be another interoperability
bakeoff either Oct 20-25 or Nov 17-22.
(The October choice was chosen by the WG.) Anita stated that there
will be a max. of 68 tables. There will be up to 8 PRI interfaces and 136
BRIs 1st couple days are remedial testing for MP, followed by testing
for CCP and BACP.
Location is San Ramon, San Ramon Marriott was suggested for advance
reservations.
bob@Larribeau.com is organizer of the bakeoff.
12. Assorted other PPP extensions.
Bill Simpson asked the working group about assorted other PPP
extensions.
IPXCP
Bill Simpson asked the WG if there were any changes need to IPXCP.
Twelve vendors said they had implemented IPXCP. The WG agreed to
send IPXCP to IESG as draft standard.
PPP over ISDN (RFC 1618)
Bill said there have questions and comments about this draft. Dana
Blair will solicit list for comments.
PPP over X.25
A (non) show of hands revealed , nobody in room had implemented this
one Bill knows of 3 vendors shipping this.
There will be an effort to get a number of protocols either to draft std
status or to kill them.
---------------------
Thursday meeting
13. BACP - Craig Richards
Current draft is draft-ietf-pppext-bacp-03.txt, is based on comments
from LA IETF meeting and experiences at May Pacbell bakeoff. The
draft is now in last call status.
Craig said the most recent changes were the removal of Link Drop
request, Bundle Drop request and 2 other msgs.
He said he improved & clarified phone number format, he noted other
changes as well.
Craig noted there was successful interoperability at PacBell bakeoff.
All were alpha or beta code.
There were questions and suggestions for rewording regarding:
o section 6.2 Phone-Delta Unique Digits suboption o substituting
transmitter/receiver for peer. o Link-Drop-query request wording.
o sect 2.1 Link Discriminator, description of wrapping. o discussion re:
Callback-request value and concern of is value. o link-type option only
being 8 bits.
Craig indicated he would clarify the wording where necessary.
Karl Fox polled the WG to find out the WG opinion of BACP. A show of
hands revealed there are 4 BACP implementations and 8 more planned.
25 hands indicated they thought BACP was valuable, while zero
hands thought BACP was not valuable.
14. Point-to-Point Tunneling Protocol(PPTP) - draft-ietf-pppext-pptp-
00.txt
Gurdeep Singh Pall presented concepts, terminology, design goals and
protocol details of PPTP.
He presented Incoming Call states for each end of a tunnel. He also
presented a comparison between PPTP and L2F. Gurdeep stated future
goals for PPTP, which included the following:
o Converge with L2F
o Include new features which have been identified, but which
are not in PPTP today.
o Leverage other IETF efforts, including IPSEC. Gurdeep provided the
following URL for PPTP source code:
http://ftp.microsft.com/developer/drg/pptp/src
Here are some of many questions/discussions following Gurdeep's
presentation:
o How does PPTP go thru firewall
o How handle shared credentials, and other security issues.
15. Level Two Forwarding(L2F) - draft-ietf-pppext-l2f-02.txt
Andy Valencia discussed a number of detailed L2f issues that are
outstanding. Some are included here:
o out of seq recovery
o uniform len-type-value encoding
o mandatory/optional flag
o vendor specific fields
o outbound calling
There was a lot of discussion on question of whether to use IP instead of
UDP. Resolution was to use GRE, which has its own IP protocol number.
Coulduse and IP prot # instead, and sve 20 bytes pkt hdr. AV has
concern that if eeveryone did this, all IP #s would be used up Concern
that firewalls would not be able to filter on IP prot #. Pat asks why not
use GRE, which has prot number Disc of Ipv6
There was discussion of various other issues, such as:
o how IPv6 fits in
o MTU issues
o clear text passwords across tunnel when PAP or SLIP is used o pre-
encrypted passwords
o other possible security attacks
o the second negotiation of LCP, and how client LCP
implementations handle LCP going down.
o minimal or no L2f header
A discussion of the LCP options recommended for use with L2F suggested
the following options:
o Multilink
o 1500 byte MTU
o others to be solicited from the PPP WG list.
Andy presented L2F status as this:
1. holding up well in IETF
2. interoperable implementations
3. L2F and PPTP folks have been talking
Andy categorized commonalities between L2F and PPTP and also
aspects unique to each.
16. Combine PPTP and L2F
After discussion a goal was stated to combine PPTP and L2F before the
next IETF meeting.
Proponents of each will work together to come up with a new draft,
tentatively called L2TP.
Andy Valencia made some suggestions as to what L2TP would inherit
from PPTP and L2F.
L2TP would:
Keep layer 2 tunnel
keep GRE format
Adopt uiformat content format
L2TP would inherit from PPTP:
media semantics (BACP)
calling (but modularize)
optional flow control
L2TP would inherit from L2F:
optional ID
optional LCP
others were mentioned
Andy also highlighted some L2TP futures as being:
encryption
integration with BACP
multicasting
fancy queuing issues
There was a discussion of using a reliable channel for data.
Ian Duncan agreed to set up a mailing list for discussions related to L2TP
and to send the email address to the PPP list.
17. Secure Dynamic Tunneling Protocol(SDTP) Pat Calhoun and Ellis
Wong
Pat Calhoun and Ellis Wong presented concepts of SDTP. The following
are some SDTP concepts:
o can be used as a router to router tunneling protocol o can be used as a
NAS to gateway tunneling protocol o PPP is terminated at the NAS for
dial-up access. o security for the tunnel uses IPSEC
o high scalability due to multiple tunnel capability o multiple protocol
support (any level 2 and level 3) o some SDTP concepts are borrowed
from Mobile IP
Questions/discussion followed regarding how SDTP is different from
ATMP. Ellis Wong agreed to send a path to slides to the mailing list.
Some participants expressed the opinion that SDTP concepts should be
combined into L2TP.