Editor's note: These minutes have not been edited.
IETF PPP Extensions Working Group
San Jose, 12/10/96
Minutes taken by Matt Holdrege <
[email protected]>
L2TP - Andy Valencia, Gurdeep Singh Pall (absent)
Consensus on all pending issues
Transport independence - Not dependent on TCP/IP
Security
Attribute numbering
Control message delivery via small LAPD-like reliable protocol
Organization of attribute-value pair number required several iterations
Consensus on
number globally
document locally
Where possible, share a common description
For IP tunnel media, L2TP recommends IPsec
Next:
Edit and insert markups submitted
Andy will publish draft hopefully in 4 weeks
Implement!
Initial interoperability testing at CIUG in May 1997
John Shriver (Shiva) wants authentication to occur earlier before the
tunnel begins to accommodate users with older protocols. This issue
will move to the list.
L2TP Security - Baiju Patel
Basically it was recommended to use IPSEC.
PPP over Sonet/SDH - RFC 1619 - Bill Simpson
[email protected] is the new list for this protocol.
[New information:
[email protected] is the address to subscribe
to pppsdh. In the body of the message, say subscribe pppsdh YOUR NAME]
PPP Vendors Extensions - Bill Simpson - draft-ietf-pppext-vendor-00.txt
Recommended to move to an Informational RFC. All implementors should
review before requesting numbers from IANA.
Protocol Spoofing - Randy Sales of Novell - draft-ietf-pppext-spoof-00.txt
Novell has a current implementation in their lab. Randy said that the
draft author (Ian - Not Present) has not been able to further refine
the draft. Novell would like the PPPEXT WG to help further refine this
protocol. It was brought up that this draft has a scalability issue in
reference to callback numbers. Novell said that they hope to use
tunneling protocols to aid this scaling issue. Further work on timer
negotiation needs to be done.
John Shriver from Shiva requested that Novell publish a paper
detailing just how to spoof NCP. Novell agreed.
Bill Simpson noted that IPXCP already covers IPX spoofing. Bill also
noted that we have too many protocols that use callback. Bill hopes
that we can make whatever changes are necessary to IPXCP to satisfy
needs.
LCP extensions & callback. Bill sent two drafts out after the deadline.
BACP - Craig Richards (absent), Kevin Smith (absent) -
draft-ietf-pppext-bacp-05.txt
Change the number for BAP so that it doesn't compress. Recommend to
create a new version of this draft. Karl will request new numbers from
IANA. Ascend is the only vendor in the room shipping BACP.
ISSLOW - Carsten Bormann
They want to provide fragmentation and suspend/resume mechanisms,
header compression, and obtain compressability hints from the
application.
Big packets can be fragmented by MP, small packets would be sent
outside of MP.
As for suspending, they need something like H.324 or DSVD. The V.80
modem standard has much lower latency than V.34 and was recommended
for RTP applications.
They want to make use of the reserved bits in MP header to define
classes of priority.
They want to define a scheme where the fragmenters and suspenders can
happily interoperate. Refer to isslow-fragment-ext-00.txt and
draft-ietf-issll-isslow-mcml-00.txt
Anita Freeman noted that the next Pac Bell PPP interoperability
testing would take place from May 12-16th.
-----------------------------------------------------------------------------
IETF PPP Extensions Working Group
San Jose, 12/11/96
Minutes taken by Scott Wasson <
[email protected]>
Steve Casner, IP/UDP/RTP Compression
- Steve gives a presentation of RTP compression, which is similar to
VJ TCP/IP Header Compression.
- Need PPP packet types assigned, to differentiate between the IPv4
compression, and several new flavors to support compressed RTP and
UDP.
- Desire is to combine IPv4 and IPv6 compression into one document.
- Discussion about whether both compressions should/would run
concurrently. Both NCPs could be Open, allowing independence.
Decision was to not allow concurrence so that the existing VJ
Protocol ID's could be recycled.
John Vollbrecht, Larry Blunk, EAP
- No changes needed to the current draft; any new additions to go into
a new add-on draft.
IP Address option negotiation
- None of the original protagonists were present, so the group
discussed the issue in their absence. Anything "decided" obviously
has to be taken to the mailing list to reach full consensus.
- If unit sends:
Req(0) ->
and peer sends back:
<- Nak(addr) ;That's OK.
<- Nak(0) ;Prohibited! Never do!
<- Rej() ;take default value, "Not Configured".
<- Ack(0) ;Prohibited! Never do!
Question is: What is the default value of this option? Unnumbered?
Manually configured? Not configured? Decided "Not configured"
should be the default. This is no change from before.
- Discussion about adding a 2-byte "Numbered/Unnumbered" option.
- We found that some vendors send cr-0, expecting the peer to supply
an IP address. They hoped that the peer would send ca-0, meaning,
"I don't have an address to give you, so if you really do have an
address but were just trying to be polite and let me pick it, and
since I don't have one to give you, now send me yours."
- Consensus was that the originator shouldn't have attempted to be so
polite. Just send its address.
- Frank K. stepped up and pointed out that we were going in circles on
the numbered/unnumbered issue, and that we should write up our
discussion and bring it to the mailing list.
- Brief mention of the next L2TP draft - hope to have it by the end of
January.
-----------------------------------------------------------------------------
--
Karl Fox, servant of God, employee of Ascend Communications
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841
