Internet Area Report, Orlando, FL, 12/98
VPN BOF (reported by Naganand Doraswamy <
[email protected]>)
-------
This was the second BOF on VPN's. It concentrated on requirements for
VPN's over shared IP infrastructure. There were 7 presentations on the
requirements. The requirements concentrated on framework, services
security, routing and addressing, traffic mgmt, and membership mgmt.
The goal of the BOF was to charter a working group to produce a
framework and architecture document that would enable interoperable
implementations. In addition, the goal was to investigate how
existing protocols can be used to provide the services and define any
extensions, if needed, to them.
Some folks felt that the charter was too broad and formation of a
working group with this broad a charter was doomed to fail. Other
folks felt there was a need to discuss the basic architecture and
framework and define how existing protocols can be put together to
provide the services defined by the VPN's. In the end, the general
feeling was that the problem is something we should work on. However,
it was felt there is a need for a more focussed charter. This has to
be investigated futher.
AToM MIB (atommib)
------------------
This WG did not meet. It's work is winding down. Of the nine active
WG drafts, 6 have are in the final stages of IESG approval (In IETF
Last Call or later). Two others are almost ready for Last Call, and
work on the last remaining document will likely be stopped, as it
overlaps with work since done elsewhere.
DNS IXFR, Notification, and Dynamic Update (dnsind) (reported by Robert Elz <
[email protected]>)
---------------------------------------------------
The DNSIND working group met for 75 minutes on Tuesday December 8,
1998, attended by approximately 116 people.
The WG currently has a large number of work items. Four of its
earlier products are at PS status, and being considered for DS. Three
of those seem almost ready (serial, notify, dyndns), one (ixfr) is
waiting upon sufficient implementations for interoperability testing.
DynDNS won't move forward until there is a security mechanism ready
for DS status, and that is some distance away yet. There are two
additional PS rfcs (clarify, ncache) for which consideration of DS
should commence soon (though the working group did not actually
consider that issue).
Two drafts (binary labels and dname) are in the AD queue for IETF last
call. Those are waiting upon edns0 being ready to join them.
There are two drafts (rfc2052bis and tsig) currently in WG last call.
A new draft is expected soon for 2052bis, to answer some comments, a
new WG Last Call will be held once that is available. Tsig needs some
minor adjustments in response to its working group last call, after
which it will be forwarded to the IESG for PS consideration.
A WG last call had previously been held on edns0, but almost no-one
remembered it, so it will be repeated. WG last calls will also be
done on test-tlds and local-names. None of those received significant
discussion during the meeting.
There are five drafts still actively being worked upon by the working
group. edns1 was not discussed at the meeting, but simple update,
apl, utf-8, and local compression were all debated at various levels
of detail. Each of those requires more work, and new drafts are
expected, along with discussion on the list.
The WG also received a brief report on the ipngwg draft dns-lookups,
which defines the A6 RR type for the DNS.
Outside the WG meeting, there was an interoperability test session,
during which the interoperability of 6 implementations of the DNS
extensions Notify and DynDNS were tested (but not IXFR, of which only
one implementation was present) That testing was successful, and the
necessary implementation reports to move NOTIFY and DynDNS to DS
status should be forthcoming.
DS1/DS3 MIB (trunkmib)
----------------------
This WG did not meet. All three of the WG's active drafts have been
approved by the IESG and are in the RFC editor's publication queue.
Dynamic Host Configuration (dhc) (reported by Ralph Droms <
[email protected]>)
--------------------------------
The DHC WG met twice in Orlando. The WG discussed the "failover
protocol" in the first (one hour) meeting and DHCP issues in the
second (two hour) meeting. The failover protocol session yielded a
1-page list of questions from the WG. About half of these questions
were answered in the meeting. The other half will be taken to the WG
mailing list for further discussion. Kim Kinnear suggested an interim
ming on the failover protocol - perhaps late January or early February
- to make additional progress on the protocol.
The general issues session addressed several issues but didn't really
come to closure on any of them. There were reports from the LDAP
schema meeting, the failover protocol meeting and the DHCP futures
panel. Two external groups expressed interest in the LDAP schema
work: the DMTF and the policy framework WG. Three old I-Ds were
mentioned as "resurrected":the DHCP-DNS interaction draft, the domain
search option and the user class option. The latter two drafts each
sparked some discussion that will be taken to the WG mailing list. A
related draft was also discussed that describes techniques for
allocating network addresses based on user class.
The authentication draft was reviewed. The authors agreed to describe
a way to use PK technology with the current draft. The SLP option was
discussed and a suggestion was made to add a "flag byte" to the
option; further discussion was sent to the WG mailing list. The use
of DHCP for configuring VoIP equipment raised the issue of specifying
DHCP client hardware/software configurations for more controlled
configuration allocation. The issue is related to the "host system
characateristics" option. Finally, the WG discussed whether to bring
the auto-configuration options to Standards Track or BCP status.
Frame Relay Service MIB (frnetmib) (reported by "Andrew G. Malis" <
[email protected]>)
----------------------------------
The Frame Relay Service MIB working group held its first meeting in a
year. The new chair, Andy Malis, reviewed the current status of the
five existing drafts, and asked for editors for two new drafts that
had been proposed in the past. The chair reviewed the results of the
December 1997 meeting. The new editor of the RFC 1604 update, Ken
Rehbehn, reviewed the proposed changes from version 02 to 03 of the
draft. He expects to issue 03 by the beginning of January. The chair
briefly presented the recent version of the SPVC MIB, representing the
editor who was unable to attend. We expect the DTE SVC MIB to be
updated soon, and the chair will soon begin working group last call on
the data compression draft. The chair intends to move the group's
email list and update the workplan.
IP Over Fibre Channel (ipfc) (reported by Murali Rajagopal <
[email protected]>)
----------------------------
31 attendees signed the blue sheet. There were many new company reps,
including international attendees from Korea, Germany, Japan, and
France.
The meeting addressed issues and comments raised by many on the reflector
1.NAA Issue : Compaq wanted to optionally include other NAA Types
besides the IEEE 48-bit addresses. Their motivation was that their
future SAN were likely to use other addressing schemes. The WG was
generally opposed to this and the suggested resolution was to define
the other NAA types in a separate draft.
2. MTU Issue: There was some disagreement on the MTU sizes in the
03.txt draft because it did not include optional IP
headers. Resolution: Min MTU and Max MTU was specified to include the
IP Optional headers.
3. Inverse ARP Issue: Raj Bhagwat initiated this protocol as a way to
solve the lack of broadcast support in some implementations.
Resolution: The group was against making this is a mandatory
requirement. The group agreed to include this as an optional parameter
with the proper wording without causing a concern for interoperability
problems.
4. Multiple IP Addresses per MAC address for InARP Issue: This
requirement was originated by Jeff Stai from Brocade as a Fibre
Channel VI requirement. Resolution: It was pointed out that the
proposed solution of just one IP address representing a group of IP
addresses was inconsistent with the way InARP works in Frame
Relay. The suggestion was to look at the Frame Relay solution. If
this is really required include the new scheme in the next draft.
5. Modes of FARP and Interoperability Issue: Ezio from Brocade
believes that the spec. as it is written today may end up having
interoperability problems. FARP specifies two
mechanisms. 1). Resolving <WW_PN, Port_ID> 2) Resolving <IP Address,
Port_ID>. Although, FARP is optional today, if a node receives a
request to resolve the WW_PN to Port_ID then the Reply is
mandatory. The real problem arises when an implementation only
supports the second FARP mechanism and not the first. Resolution: The
group felt that the second method should be entirely removed form the
document. The group felt that the only way the second method could
stay in the document if it was properly reworded. EMC's suggestion was
to require all implementations to support the first method in a reply
and to optionally allow support for the second method. So if a FARP
request using the second method arrives first where there is no
support, then a silent behavior is acceptable as it states today, but
additionally the node ought to be able to retry using the first
method. Note that still means that a FARP implementation is optional
on Requests for either mechanism and optional for Reply using the
second mechanism (silent behavior). Action: The suggestion was that
04.txt draft shall word-smith the document specifying this behavior.
6. The next rev of draft-ietf-ipfc-fibre-channel-03.txt document will
include the suggested changes. The goal is to send out the 04.txt
document out before the end of the year.
7. MIB: It is anticipated that the MIB work will reassume during the
March/April meeting.
IP Over IEEE 1394 (ip1394) (reported by Tony Li <
[email protected]>)
--------------------------
The WG did not meet in Orlando.
Since the 42nd IETF meeting, the IP/1394 has completed the twelfth
version of the IPv4/1394 draft. This draft addresses all known issues
except for those related to 1394 bridges. We expect to have bridging
issues resolved before the 44th IETF meeting.
In addition, we have produced the first draft of DHCP extensions
for IP/1394. The next draft will include learnings from the
bridging discussion.
Our plans no longer include delivering specifications for IPv6
over 1394 or IP over 1394 isochronous services. We still
plan to produce an SNMP MIB, but the MIB has not been started.
IP Payload Compression Protocol (ippcp)
---------------------------------------
This WG did not meet. Its work effectively ended in March, but closure
of the WG was delayed pending publication of its RFCs (wich depended
on the IPSec document set). The WG was officially shutdown 12/98.
IP over Cable Data Network (ipcdn) (Reported by
[email protected] (Mike St. Johns))
----------------------------------
IP over Cable Data Networks - 43rd IETF - Orlando
The chair opened the meeting with a number of status reports:
Document status:
o The Telco Return MIB is on hold pending some actual experience with
the DOCSIS telco return products.
o The RF MIB has been through two passes with the MIB doctor and is
pending minor edits by the chair to complete it. No further changes
are anticipated prior to the MIB going to the IESG as a proposed
standard.
o The cable device MIB has been through a single pass with the MIB
doctor and the chair is negotiating the changes required.
Specifically, the revised MIB will include an expanded section
describing the filtering model, and the compliance section for some
objects related to SNMPv1/2 community strings will change to make them
not required for SNMPv3 agents. There was some additional discussion
from the floor related to the applicability of various objects to
Cable Modems with multiple CPE interfaces (e.g. with USB interfaces as
well as Ethernet), as well as some discussion of which if any objects
not previously identified should be implemented as non-volatile within
a cable modem. Discussion is to continue on the mailing list. The
chair's goal is to complete the next pass of the MIB editing by the
second week in January.
o DOCSIS 1.1 expands the quality of service definitions substantially
and the DOCSIS QOS work has included creation of a MIB or MIB objects.
There was a brief discussion on how to rationalize the QOS work with
the existing cable device MIB.
o A new version of the Baseline Privacy MIB was submitted just prior
to the IETF, but not in time to be added to the internet drafts
directory. The BPI MIB will require some additional editing to
incorporate support for the DOCSIS Baseline Privacy Plus
specifications which are in progress. Specifically, the MIB will add
objects describing digital certificates for the cable modems and for
the manufacturing entities and a set of policies associted with those
certificates.
DOCSIS 1.1:
The DOCSIS group is in the process of finalizing the next version of
cable modem specifications. The specifications will add specific
support for IP multicasting, conditional access for IP multicasting
and and expanded quality of service model. The specifications will be
posted at www.cablemodem.com as they are completed and released to the
public.
Ran Atkinson gave a brief presentation on how not to do packet rate
limiting describing @Home's experience with several DOCSIS cable
modems.
There was some further discussion from the floor about clarifying
filtering specifications related to DOCSIS. There is some confusion
about which interface types can actually have which types of filters
applied to them and the affect of those filters on traffic. The
consensus was that only interfaces without parents (e.g. the MAC and
Ethernet interfaces) should be able to have IP filters applied.
The chair inquired as to whether anyone had used the "AGENT
CAPABILITIES" SNMP macros to describe the capabilities of their cable
modem agents. The silence was deafening.
IP over VBI (ipvbi) (reported by Dan Zigmond <
[email protected]>)
-------------------
The IPVBI working group discussed two major topics: How to wrap up the
work on a specification for transmitting IP datagrams using the NABTS
encoding scheme, and how to re-start work on a specification using the
WST encoding scheme. We briefly reviewed the response to our WG
last-call on the NABTS draft, during which we received only a few minor
suggestions to correct typos. However, shortly after the last call,
we received a proposal for a major overhaul of the draft from
WavePhore. We decided to discuss this proposal on the mailing list
for one week before making a final decision of whether to re-open the
draft or send it on to the IESG for the IETF last call.
During the WST discussion, we heard a presentation from the European
Association of Consumer Electronics manufacturers on their efforts to
introduce a new packet type ("Packet B") in the European VBI standards.
Packet B looks quite appropriate for our WST spec, but unfortunately uses a
slightly different FEC scheme than that used in our NABTS draft. We decided
to look at using Packet B in our forthcoming WST draft, but to ask EACEM to
consider adopting our FEC scheme in place of the slightly different one
(developed by Philips) they now have.
IPNG (ipngwg) (Reported by Bob Hinden <
[email protected]>
-------------
The IPng working group meet for two sessions at the Orlando IETF.
Topics discussed included:
IPv6 Code Points / R. Hinden: Assignments for ICMPv6 and IPv6 numbers
are now being maintained by IANA and can be viewed at
http://www.iana.org/numbers.html. It was noted that procedures for
having future IANA assignments made needs to be documented in an RFC.
IPv6 6REN Status and Plans / R. Fink: IPv6 Research & Education
Networks Initiative will act as a rallying point for all RENs
world-wide in providing production IPv6 service. Emphasis is on
production (6bone is experimental).
Addressing to Draft Standard / R. Hinden: Document editor will start
working group last call to move the IPv6 addressing specifications to
Draft Standard.
Initial IANA Sub-TLA Assignments / R. Hinden: IP registries plan to
start allocating IPv6 address Q1 1999. They need to obtain address
blocks from IANA in order to do this. Document suggests details on how
that could be done. Brian Carpenter reported that the IAB had earlier
in the week sent a request to IANA to assign blocks of sub-tla's to
APNIC, ARIN, and RIPE-NCC in the same manner as specified in the
draft.
Mobile IPv6 Status / D. Johnson: Completed mobileip WG Last Call and
has been submitted to IESG for advancement as PS.
IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter: WG agreed
document was ready to go. When new draft appears, send to IESG for PS.
Basic API Revision / J. Bound: As soon as new draft is out, submit to
IESG as informational.
DNS Extension to Support IP Version 6 / M. Crawford: Document has
dependencies on other DNS documents that aren't quite finished.
Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering:
Submitted to IESG, waiting for IETF Last Call.
Jumbograms / S. Deering: Two interoperable implementations exist. Note
that this document was created when base IPv6 document advanced to
Draft Standard due to lack of interoperability
demonstration. Suggestion was made to advance document directly to
Draft. Another suggestion was made to combine this document with the
jumbogram one. Authors will decide.
Router Renumbering / M. Crawford: IESG raised some issues, new draft
needed.
Multicast Listener Discovery Protocol / S. Deering: One problem has
been found (easy to fix), new draft needed. It was also noted that
this document depends on the Router Alert document.
Separating Identifiers and Locators in Addresses: An Analysis of the GSE
Proposal for IPv6 / L. Zhang, et. al: WG Last Call started, ready for
submission as informational document.
Site Prefixes in Neighbor Discovery / E. Nordmark: general support in
WG for continuing the work.
IPv6 TCP and anycast address / Jun-ichiro Itoh: If TCP opens a
connection to an anycast address, no way to close/abort it, because
response packet would need to have anycast address as a source, which
is illegal today. Suggestion was to define an ICMP message to
indicate this condition. Much discussion, further work needed.
Tunnel Broker / A. Durand: Proposal aims to make it easier to setup
tunnels (i.e., without configuration). Lots of dicussion, more work needed.
Future Work / S. Deering: Much of basic work is done. What should
happen with this WG next? Lots of items that WG could pick
up. Alternatively, coudl push additional work off to other WGs. There
will be a interim working group meeting February 2-4, 1999 to discuss
the current state of IPv6 and transition mechanics. A meeting
location will be announced to the mailing list.
Interfaces MIB (ifmib)
----------------------
The WG did not meet. Work is still progressing on revising the
interfaces MIB document and advancing it to Draft Standard.
Internetworking Over NBMA (ion) (Reported by "Andrew G. Malis" <
[email protected]>)
-------------------------------
The ION WG met in one session. It was announced that George Swallow
will be leaving as co-chair of the ION group following this meeting to
concentrate on his MPLS duties. Andy presented the usual working
group document status update since the last meeting. There have been
four WG RFCs since the last meeting, and 18 total. Two drafts are
awaiting RFC publication, seven are in IESG review, and eight others
are in various stages of progress. Andy asked for RFC 1356
implementation experience so that it can be advanced to full standard.
Cliff Wang presented the SCSP MIB draft. Dan Grossman presented the
RFC 1483 update draft. Joel Halpern presented the SCSP for ATMARP
draft. Bernhard Petri presented the VPN ID draft, and its
relationship to NHRP, MPOA, and RFC 1483 encapsulation was discussed.
Mikhail Smirnov presented a QoS multicast over ATM implementation
report. Andy announced that there will probably be one more WG
meeting in March, after which the group will transition to a quiescent
state to allow development of implementations.
PacketWay (pktway)
------------------
The WG did not meet.
Point-to-Point Protocol Extensions (pppext) (reported by Matt Holdrege <
[email protected]>)
-------------------------------------------
Over our two sessions, we had 110 people sign the blue sheet. We
followed the scheduled agenda except for one presenter who cancelled
and one who asked to be added. We didn't have much controversy. One
topic on adding mobility features to L2TP had a lot of questions about
the architecture.
After the meeting we held a couple of L2TP drafting sessions which were
very productive and will continue.
Service Location Protocol (svrloc) (Reported by "Erik Guttman" <
[email protected]>)
----------------------------------
The SVRLOC WG did not meet at IETF 43 in Orlando. The remaining work
before the group consists of reaching closure on discussion of the core
documents resulting from WG last call. After the SLPv2 protocol spec
and related documents are published the SVRLOC WG will have concluded
its work. The considerations before the WG are minor and so should
definitely be resolved well before the IETF 44 meeting.
