Internet Area Report, Orlando, FL, 12/98
VPN BOF (reported by Naganand Doraswamy <naganand@BayNetworks.COM>)
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 <kre@munnari.OZ.AU>)
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@example.com>)
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" <firstname.lastname@example.org>)
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@example.com>)
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 <firstname.lastname@example.org>)
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@example.com (Mike St. Johns))
IP over Cable Data Networks - 43rd IETF - Orlando
The chair opened the meeting with a number of status reports:
- The Telco Return MIB is on hold pending some actual experience with the DOCSIS telco return products.
- 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.
- 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.
- 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.
- 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.
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 <firstname.lastname@example.org>)
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@example.com>
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" <firstname.lastname@example.org>)
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.
The WG did not meet.
Point-to-Point Protocol Extensions (pppext) (reported by Matt Holdrege <email@example.com>)
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" <eguttman@germany.Sun.COM>)
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.