Internet Area Directors (s): o Stev Knowles: stev@ftp.com o Dave Piscitello: dave@mail.bellcore.com Area Summary reported by Dave Piscitello/Bellcore and Stev Knowles/FTP Working Groups in the Internet Area are actively involved in the development of Internet standards for: 1. IP and multi-protocol operation over emerging wide area technologies (ATM, SMDS, Frame relay) and point-to-point technologies (including narrowband ISDN). 2. Expanded use of the IP backbone by tunneling other widely used network protocols (Appletalk, SNA). 3. Development of a ``next generation'' IP; i.e., a replacement protocol and addressing/routing architecture for IPv4; 4. Miscellany (Dynamic host discovery, and multicast interdomain routing) The following Groups in the Internet Area met during the Columbus IETF: o Birds-of-a-Feather (BOFS) - Net Support for QOS and Real-Time Traffic - SNA Peer-to-Peer Networking o Working Groups - Dynamic Host Configuration - IP Address Encapsulation - IP over AppleTalk - IP over Asynchronous Transfer Mode - IP over Large Public Data Networks - P. Internet Protocol - Point-to-Point Protocol Extensions - Simple Internet Protocol - TCP/UCP over CLNP-addressed Networks Four candidates for IPng (``next generation'', we are no longer referring to this as IPv7)--PIP, SIP, and TUBA/CLNP, ULLMAN/IPv7--provided plenary status reports and three provided demonstrations throughout the week from the terminal room provided by OARnet. Many thanks to the participants for their efforts and to OARnet 1 for their support. SNA Peer-to-Peer Networking BOF (SNAPPER) The SNAPPER BOF was held on April 1, 1993, and chaired by Wayne Clark, cisco Systems, Inc. Three alternatives for handling SNA peer-to-peer (i.e., APPN) traffic across TCP/IP networks were presented: 1. APPN over TCP/IP 2. APPN/DLS using connection networks, and 3. APPI Pros and cons of the three alternatives were discussed and it was decided that (a) the topic is too political at this point; (b) neither IBM or the APPI Forum is ready to change at this point in time, and (c) the APPN market at present is too small to worry about. The conclusions of the BOF were: 1. A data link switching (DLS) working group would be very desirable.. 2. Willingness to participate in the Working Group would be investigated. 3. If the conditions of (2) are met, the snapper@cisco.com mailing list would be used to develop a working group Charter and a more applicable name. Dynamic Host Configuration Working Group (DHC) The DHC Working Group discussed the interface between DHCP and the Domain Name System (DNS). DHCP needs an interface that can allow dynamic updates to DNS entries in response to dynamic allocation of DNS names to DHCP clients. Rob Austein explained that the DNS Working Group is currently developing such an interface to DNS that considers the needs of DHCP. The Working Group discussed the possible use of SNMP with DHCP, to serve as a ``second-level'' bootstrap mechanism to transmit additional configuration parameters to a client. SNMP is not likely to be as useful as an implementation-specific interface for server management. SNMP is an interesting candidate for the server-server protocol, as it may provide the semantics and data representation tools required for exchange of DHCP binding information between servers. The Working Group discovered a technical problem with the current definition of the `chaddr' field, which allows `chaddr' to be used as either a hardware address or other unique identifier. As the `chaddr' value must be used to return DHCP reply messages to the client, that field will be reserved for use strictly as a hardware address, and the 2 client will be required to supply a unique identifier in a `client identifier' option. This identifier will be a typed value with the same structure as defined for the `chaddr' field. Mike Carney and Jon Dreyer submitted a new definition for encapsulating vendor-specific options that the Working Group accepted with minor modifications. In the accepted definition, the `vendor- specific information' option will include an initial value that identifies how to interpret the contents of the option, and other DHCP options, encoded in the same format as the current variable- length DHCP options. The initial identifying values will be centrally administered to avoid conflicts. One identifying value will be reserved for local use. The mechanism for determining the parameters returned to a particular client was discussed at length. The focal points of the discussion were the ways in which a client can identify its characteristics (`client type' option) and the rules by which a server can use those characteristics to choose the information to be returned to a host. No conclusion was reached at the meeting; an interim solution will be incorporated into the DHCP specification Internet Draft to allow the protocol to move forward to Proposed Standard. IP Address Encapsulation Working Group (IPAE) The IP Address Encapsulation (IPAE) Working Group met once during the Columbus IETF. Since IPAE re-aligned itself to provide transition technology for SIP, the foci of IPAE discussions have been: 1. Modifications to SIP that are likely to facilitate transition, and 2. Implementation experiences with SIP/IPAE. (Reference to IPAE usage is specifically to SIP-over-IP and SIP-mapped-to-IP. The first is to tunnel through the Internet and the second is to gateway to IPv4 hosts.) The Working Group held a brief discussion about the SIP/IPAE demonstration slated for later in the week, discussing the implementations being shown and their use. Bob Gilligan, of Sun, and Ron Jacoby, of Silicon Graphics, discussed their implementation work. The Beame&Whiteside, Intercon, and Network General, implementations, for DOS&Windows MacIntosh, and network monitoring, respectively, were not available to make presentations. Steve Deering raised the issue about whether SIP fragmentation is end-to-end only, or can occur en-route. He is interpreting the Group's response as supporting the position that SIP fragmentation need *not* occur en-route. IP Over Asynchronous Transfer Mode Working Group (ATM) 3 The IP over ATM Working Group met for three sessions at the March IETF meeting, to discuss the following topics: o ATM Forum Addressing Work o Address Resolution in ATM Network o Architecture, Address Translation, and Call Control o NBMA Address Resolution Protocol (NBMA ARP) o General Discussion of ATM Address Resolution o Issues in the Interconnection of LANs and ATM Networks Four presentations were given on ATM Addressing and ATM/Internet Address Resolution. Keith McCloghrie presented an overview of what the ATM Forum addressing work. Subbu Subramaniam presented his ideas on how ATM address resolution should work. Fong-Ching Liaw Presented pros and cons of Subnet and Peer model of address resolution in ATM networks and Juha Heinanen presented an overview of his NBMA Address Resolution Protocol (NBMA ARP) proposal. There was considerable discussion about how address resolution should work, and pros and cons of the subnet vs. peer model. There were strong views on both sides. The session ended with suggesting that neither one approach would prevail and proposed mechanisms for combining the two approaches. Mark Leabach presented slides with his thoughts on which areas the Working Group should focus on first. He saw two approaches in the Working Group: Functional layerists (ATM as a wire-replacement) versus ATM IP Morph'ist. He made a strong argument that the Working Group should first specify how IP over ATM should work in the ``classical IP'' mode where ATM networks are connected by routers. Mark went on to present a list of problems which need to be solved. Tim Salo presented a talk on the Gigabit Testbed Talk. The goal of the project is to create a seamless connection between ATM LAN's and ATM WAN's. His preliminary observations were that there are no complete proposals available today, some ares only slightly explored or identified, much new functionality must be implemented, and the most of the problems are in the wide area. His final observations were that we need a complete solution if ATM is going to be the solution. It is important to avoid making the customer the system integrator. Significantly more implementation experience is needed. Ramon Caceres presented the results of his simulation of different approaches for VC multiplexing. His conclusions were that one VC per connection gives the best performance, followed by one VC per type of traffic (e.g., telnet, ftp, mail, etc.). One VC per router pair gives poor performance. The overall goal should be to separate traffic as much as possible After a final discussion of subnet versus peer addressing models, the Working Group moved on to a discussion of important area to pursue and 4 the assignment of action items to complete. Joint IP over Large Public Data Networks Working Group (IPLPDN) and Point-to-Point Protocol Extensions Working Group (PPPEXT) The IP over Large Public Data Networks (IPLPDN) and PPP Extensions (PPPEXT) Working Groups met in joint session to discuss protocol specifications common to both. Since the objectives and requirements of the two working groups differ in some key respects, there was considerable difference of opinion at the outset. Two subjects were discussed: how to share load among a set of parallel links to increase apparent bandwidth and potentially reduce latency between two sites, and how the IPLPDN group might best avail itself of the facilities found in PPP negotiation. Both Fred Baker and Keith Sklower had proposals though the consensus was that Keith's approach was preferred, but required some modifications. Keith will appropriately edit his proposal for further discussion on the IPLPDN mailing list. The two Groups also discussed PPP Parameter Negotiation for Frame Relay. Consensus was reached on several issues. Keith Sklower and Bill Simpson have agreed to merge their efforts and their current proposals to implement this consensus. The output will be discussed on the IPLPDN list. IPLPDN and PPPEXT expect to have two joint meetings at the Amsterdam IETF. IP over Large Public Data Networks Working Group (IPLPDN) The revised draft of RFC 1294, ``Multiprotocol over Frame Relay,'' was approved for submittal to the IESG for release in a new RFC and for advancement from Proposed to Draft standard. RFC 1356, ``Multiprotocol over X.25,'' was reviewed for advancement in status. It was agreed to perform tests of interoperability of implementations. The revised RFC 1315, the Frame Relay MIB document, was discussed. It was agreed to keep this document as the ``DTE MIB'' and that the new work on a Frame Relay MIB would become the ``DCE MIB.'' The Charter of IPLPDN: the Chair agreed to talk with the Area Directors and with working group Chairs about the transfer of open issues to those groups. The Chair will report to the Group. Work progressed on the ``Multiprotocol over Circuit ISDN'' document. The draft was re-titled ``Encapsulation Determination for Circuit Switched Services.'' Keith Sklower will incorporate comments and will distribute the revised document by email for Working Group approval for submittal to the IESG. Two joint sessions were held with the PPPEXT Working Group. Bill Simpson and Keith Sklower were asked to co-author a ``Parameter 5 Negotiation over Frame Relay and X.25'' document. The P. Internet Protocol Working Group (PIP) The PIP Meeting was tutorial in nature. Paul Francis (formerly Tsuchiya) covered various aspects of the Pip protocol, starting with the header format and going through addressing. No serious problems were uncovered in the discussions, though Steve Deering did uncover a bug in the proposed caching mechanism. Attendees were invited to see a demonstration of PIP during the meeting. Simple Internet Protocol Working Group (SIP) The SIP Group discussed clarifications and changes to the SIP specification ' since last November. The most significant changes were the addition of hop-by-hop options and the specification of ``local-use'' SIP addresses that hosts can fabricate from 802.11 addresses for the purpose of auto-configuration. The group also discussed a tentative SIP Sensitivity Label Option and a SIP End-to-End Security Opti on, both based on recent work on IPv4 security. The SIP Group also discussed proposed modifications to RIP-2, OSPF, and IDRP to support SIP routing, as documented in recent Working-Group drafts. Finally, the Group received a status report on SIP ``host routing'' work-in-progress. TCP/UDP over CLNP-addressed Networks Working Group (TUBA) The TUBA Working Group met to discuss the following topics: o Implementation Status and Demonstration. o Document Status. o Priortization of TUBA Work. - Questions asked at Opening Plenary - Dynamic Host Address Assignment - Mobile Hosts - Routing and Addressing Plan - Transition Strategies - Discussion of Technical Advantages of CLNP o Demo and Implementation Targets Editor's Note (md): A detailed summary of each topic is provided in the Minutes which follow this Area Report. 6