Internet Standards/CD1.mdf/INET/IETF/94DEC/INTERNET

Text File | 1995-02-28 | 10.8 KB | 237 lines

Internet Area

Directors:


   o Stev Knowles:  [e-mail]
   o Claudio Topolcic:  [e-mail]


Area Summary reported by Stev Knowles/FTP Software and
Claudio Topolcic/BBN

The following BOFs and working groups met during the December IETF
meeting in San Jose, California:


   o Multiprotocol Transport BOF (MPTRANS)
   o Dynamic Host Configuration Working Group (DHC)
   o DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND)
   o Internet Stream Protocol V2 Working Group (ST2)
   o IP Over Asynchronous Transfer Mode Working Group (IPATM)
   o Point-to-Point Protocol Extensions Working Group (PPPEXT)
   o Service Location Protocol Working Group (SVRLOC)


Multiprotocol Transport BOF (MPTRANS)

Diane Pozefsky presented the principles of MPTN as embodied in the
ANYNET family of IBM products.  She explained the philosophy behind
MPTN, not to use encapsulation, but to use protocol transformation at
the proper level in the various stacks.  She presented the challenges of
MPTN: function compensation, address mapping, transport gateway, and
network management.  Diane presented the experiences of implementing
MPTN in the cases of SNA over TCP, Sockets over SNA, Netbios over SNA,
Sockets over Netbios.  A key question came up, of the usefulness of MPTN
to the IETF, or why was this BOF scheduled?  The main answer given was
that this is an opportunity for IBM to cooperate with the IETF on
technology of common interest.  The discussion continued and the subject
of writing several Informational RFCs was brought up.  This will be
looked at by Sig Handelman and Diane.  Also, the intersection of MPTN
and SNA could solve TN3270E problems, and create a general solution for
3270, and other SNA sessions (i.e LU6.2).  Finally, the idea of using
MPTN as model for the IPv4 to IPv6 transition was proposed.


Dynamic Host Configuration Working Group (DHC)

The DHC Working Group met twice.  The latest round of changes between
RFC 1541 and the November Internet-Draft were discussed.  They are based
on the results of the Toronto bakeoff; there were changes, none
significant.  The issue of a new DHCP message, ``DHCPINFORM,'' was
discussed as a way for DHCP clients to get local configuration
information without requesting a network address.  After a discussion of
a server-to-server protocol, it was suggested (and, in fact, several
vendors have already done this) that DHCP servers could use existing
distributed database technology such as NIS or Oracle, rather than
reinventing the wheel.

The working group discussed the relationship between IPv6 addrconf and
DHCP. By consensus, the existing semantics in DHCP can support the IPv6
address configuration model, with the possible addition of a new
message, DHCPREACQUIRE, which is intended as a hint to clients that they
should reacquire IP addresses.  The group also discussed DHCP and
dynamic DNS updates; this group will define the set of DNS updates it
expects to require and pass that list to the DNS Working Group.  Along
with dynamic DNS update, this working group discussed authentication and
security; the DHC Working Group will define its authentication and
security requirements.  Finally, the group discussed the
server-to-server protocol, and came to the conclusion that, although
some sites may choose to use external distributed databases in support
of multiple DHCP servers, other sites will still want to use a
DHCP-specific server-to-server protocol.  The working group will expand
on a conceptual proposal presented on Wednesday.



DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND)

Thomas Brisco's Load Balancing draft is moving toward becoming an
Informational RFC. There were no objections to this.  The code for it
may or may not be in the next BIND, but will at least be in the contrib
directory.

Masataka Ohta presented the Internet-Draft
draft-ietf-dnsind-ixfr-00.txt.  It is very different from the previous
proposal in that the server maintains no state about the client.  There
was general agreement on the approach, but more work is needed on the
draft.  Security issues need review.  He will have a new Internet-Draft
soon with the plan for an RFC in Danvers.

Susan Thomson presented the status of the Dynamic Update work.
Broadening the scope of the work has raised questions about requirements
that need to be supported and consequent new design issues.
Requirements and issues were enumerated and explored.  They are included
in the DNSIND minutes.

The DynUpd crew felt they had sufficient guidance to produce a new
draft.  They expect more input from the mailing list.

There will be an interim meeting of the DNSIND Working Group in late
January or early February, specifically to progress toward a new DynUpd
draft.  This is likely to be 8 February, just before the IPng interim,
in the Bay Area.  The plan is to produce an new Internet-Draft in time
for a cycle at Danvers.

Mark Lottor discussed problems in the COM domain.  The COM domain is
annoying in terms of size, trademark issues, etc.  Write to [e-mail]
if you are interested in the subject.

Paul Vixie described the status of the Notify drafting work.  He will
publish a new draft in the next weeks, with the intent of an RFC by
Danvers.

It was the general consensus that the current nibble IPv6 address to
name translation was the safest.


Internet Stream Protocol V2 Working Group (ST2)

The ST2 Working Group met twice.  The majority of the time was spent on
a detailed walk through of the current Internet-Draft.  Some minor
technical issues were reviewed and resolved.  The group as a whole
believes that all issues are resolved and the Internet-Draft should be
completed by mid-January.  Once the Internet-Draft is published as an
RFC, the only work remaining for the working group will be publishing
state machines for the protocol.  The state machines will be published
separately from the protocol specification.  The state machines are
scheduled to be issued as an Internet-Draft in RFC quality form prior to
the Danvers meeting.  The main activity in Danvers will be the review
and acceptance of the state machines.  The key actions resulting from
the working group are to complete the Internet-Draft by mid-January and
to issue the next version of state machines in January.

Some minor issues are mentioned in the detailed minutes.


IP Over Asynchronous Transfer Mode Working Group (IPATM)

  o Drew Perkins gave a report on the ATM Forum.  He will send an e-mail
    report to the mailing list for the Kyoto meeting.

  o There are now about ten implementations of RFC 1577 in progress and it
    is possible that Digital has even passed the first interoperability test
    with two other vendors.

  o Dario Ercole gave a presentation on interpersonal multimedia
    communications over ATM. This was shown at Interop '94.

  o Grenville Armitage led a review of the IP Multicast draft.  Its goals
    are to work within RFC 1577 context and utilize UNI 3.1 multicast
    services.

  o Discussion of the framework document was led by David Shur.  The general
    consensus is that the group needs to close on this real soon.

  o Mark presented the suggested FY95 work plan.



Point-to-Point Protocol Extensions Working Group (PPPEXT)


The status of the issues with Motorola regarding the Compression Control
Protocol are as follows.  Motorola has advised Steve Coya, Executive
Director of the IETF, that they plan to offer licenses on fair terms.
Letters describing those terms have not yet been received by either
Steve or Fred.

Fred, in the absence of its author (Steve Senum), presented the updated
draft of the PPP Banyan Vines Control Protocol (BVCP)
(draft-ietf-pppext-vines-01.txt) and the updated draft of the PPP XNS
IDP Control Protocol (XNSCP) (draft-ietf-pppext-xnscp-00.txt).  The
former formalizes the use of the control and data protocols specified by
Assigned Numbers, and three options relating to routing protocol
messages and fragmentation.  The latter formalizes the use of the
control and data protocols specified by Assigned Numbers, and proposes
no options.  The working group approved the advancement of both to
Proposed Standard.

Gerry Meyer presented the PPP Encryption Control Protocol (ECP). This is
draft-ietf-pppext-encryption-00.txt.  This protocol is modeled on the
CCP, including the use of separate informational documents describing
separate encryption procedures.  Jeff Weiss suggested adding an
encryption reset and acknowledge, for use by non-self-synchronizing
encryption procedures.  Jeff feels he can eliminate another potential
patent problem.

The Synchronous Data Compression Consortium made a presentation to the
Working Group at the last IETF meeting, describing its use of PPP
between DSUs.  It has now largely completed its design and is about to
ask TR 30.1 to recommend the use of the procedure.  They produced three
Internet-Drafts.  Several questions were raised concerning technical
aspects.  The people concerned about them will contact the author and
discuss them on the dsu-compress[-request]@paradyne.com list.  These
will be published as Informational RFCs when complete, due to their
status in ANSI.

In the currently widely held security model, exchange of passwords in
the clear does not appear wise.  Thus, PAP is no longer a recommended
procedure.  CHAP, however, is still believed to be acceptable for a
certain class of problems.  Bill will create a new Authentication
Internet-Draft which does not have PAP in it.  The IESG can declare
RFC 1334 ``Historical,'' making PAP a historical procedure, and the new
CHAP-only draft will become a Draft Standard when a consensus on the
list supports that.

The Kerberos and one-time passwords effort (Carrels, Blunk, and Parker)
has not produced a requirements document.  Two companies, however, have
deployed incompatible authentication procedures of that type.  Brad
Parker will update the draft-ietf-pppext-gap-00.txt draft according to
deployment experience, and we will publish that, probably as a Proposed
Standard.  Fred will contact Larry Blunk to determine whether the
combined effort is still likely to occur.


Service Location Protocol Working Group (SVRLOC)

The Service Location Working Group met to discuss changes to the current
draft (including reorganization of the protocol header, field size
changes, query example and multiple addresses in the service instance),
SCOPE, IPv6 and implementation experience.

The changes in the current draft were described in detail.

The current SCOPE mechanism was discussed and explained in detail
including the relationship between foreign scope and DNS.

The differences in the Internet-Draft for IPv4 and IPv6 were discussed.
The main differences are in the service instance address formats.

The implementation status was reviewed.  Only one group is currently
working on an implementation of the protocol.  Implementation experience
has shown that this protocol can be easily implemented on modern PC
operating systems.