CURRENT_MEETING_REPORT_ Reported by F. Baker/Vitalink, S. Senum/Network Systems Corporation, P. Almquist/Consultant and J. Forster/cisco Systems MINUTES The IETF Router Requirements Working Group is a new working which met for the first time during the IETF meeting in Tallahassee. The IESG formed this working group to draft a standard for Internet IP routers which will be up to date and which will match the level of clarity and completeness achieved in the recent Host Requirements RFC's (RFC1122 and RFC1123). The group intends to submit its document to the Internet standards process in early 1991. If it is accepted, it will replace RFC1009, the current standard for Internet routers. The group held three half-day meetings in Tallahassee. Topics discussed fall into four basic categories: 1. Group startup activities. This included such things as discussing the charter and the schedule and agreeing on exactly what is the task to be performed. 2. Creation of an outline. The co-chairs drew up a strawman outline for the document in advance of the meeting. The group adopted this outline with some modifications. 3. Distribution of writing assignments. Many of the group members agreed to draft sections of the document before next meeting, tentatively scheduled to be a videoconference in late March, 1990. 4. Initial discussion of technical issues. Close to half of the meeting was devoted to discussion of what the document should say about a variety of issues, such as ARP and IP option support. UPCOMING SCHEDULE o February 6-9, 1990: IETF meeting, FSU o Late March, 1990: video conference o May 1-4, 1990: IETF meeting, PSC o mid-June, 1990: video conference o July 31-August 3, 1990: IETF meeting, UBC o August 15, 1990: first Internet draft version submitted o mid-September, 1990: video conference o early November 1990: IETF meeting, Washington University o December 3, 1990: second Internet draft version submitted o mid-December, 1990: video conference o January 15, 1991: final Internet draft version submitted o early February 1991: IETF meeting, NCAR o February 15, 1991: final version submitted to IESG and RFC editor 1 MINUTES - 2/6/89 Introduction: The charter of the working group calls for a descendant of the Router Requirements Document (RFC 1009), modelled on the general format and spirit of the Host Requirements Document (RFCs 1122 and 1123). The initial submission is an outline, which may be reorganized, and will be fleshed out by the submissions of a number of authors. There is also a proposed schedule for the work to be done, culminating in a final RFC in early 1991. In support of this, a commitment is requested and required of all participants, to expedite the delivery of this document. Charter: Several documents feed into this process: o RFC 1009 Router Requirements o RFC 1122 Requirements for Internet hosts - Communication Layers. o RFC 1123 Requirements for Internet hosts - Application and Support. o Many RFCs included by reference There was general agreement on the charter as written, with the suggestion of some extra wording on the general subject of Interoperability. Presentation Style: The IESG proposes a document much like the Host Requirements Document, especially in the sense of flagging sections as 'required' and 'optional', flagging requirements stated in those sections as 'must [not]', 'should [not]', and 'may', and the concepts of 'full' and 'conditional' compliance. Compliant Routers (full or conditional) should interoperate by definition. This is accepted as the initial strategy, and the usage of those terms is intended to be as much like its predecessor as possible. By way of example, ARP is generally an optional protocol, and should be stated as optional; However, if Ethernet interfaces are implemented, ARP implementation is required, and certain operational experience since the original RFC was written must be accounted for. A postscript version of the document may come into existence; however, to facilitate world wide ease of access to the document, a text version WILL be available. A number of points that came out in a general discussion (not all of which represent any kind of concensus of the group): 2 Vendors need the document in order to know how to implement a universally acceptable product, and Network Managers need to one to specify in RFQs. Net Managers ALSO need a document indicating how the features of a compliant Router are intended to be used. These are not necessarily the same document. We need a Multi-protocol Router Document, although this is technically outside the working group's charter. This document should explicitly not preclude alternative architectures, and will attempt to state requirements that will allow multi-protocol routers to be compliant. There needs to be a section regarding global traffic engineering. Congestion Management is a special case of traffic engineering. There will be a discussion of Congestion Management, especially Fair Queuing, but the details may be referred to another working group. Verbiage needs to be clear and consistent, and consistent (where relevant) with the Host Requirements Document. A Glossary may be helpful. IP Multicast needs to be dealt with on a MAC by MAC basis. The 'All Subnets' Broadcast, although required by RFC1009, is probably not implemented by anyone, and its originally intended function is probably better served by IP multicast. Also, the all subnets broadcast would be dangerous if implemented, since hosts which are unaware that the network is subnetted may generate packets that look like all subnets broadcasts unintentionally. There seem to be two options for dealing with the all subnets broadcast. The first is to require it, since it would not be useful unless widely enough implemented that applications could reasonably expect it to work. If we do that, we should also specify an/the agorithm for the flooding. An alternative is to declare the entire notion of the all subnets broadcast to be obsolete. Philip Almquist will write an RFC suggesting the latter. Line protocols recommended by this document must have some sort of protocol discriminator field. Point-to-Point and ISO 7776/8880(3) both have this. Apple Localtalk has an RFC in progress. X.25 protocol: o there are several alternatives for discriminating between protocols on X.25 - most notably using a discrimination octet on each packet and running separate Virtual Circuits by protocol, TOS, destination tuple. o several de facto standards exist: DDN 'basic' and 'standard', Blacker, and European. 3 ARP needs to be fairly closely spelled out, especially regarding Proxy ARP and ARP Response to IP Multicast Address. (See minutes from 2-7-90) Hyperchannel and ARCnet have inadequate current interest to justify a section in the document. There needs to be a precedence statement indicating that this document takes precedence over the base RFCs for each feature, and over the Host Requirements Document in certain cases. Writers are expected to reference the Host Requirements Document regularly; in the draft versions, please include the relevant text to simplify reviewer's cross-referencing; this will be removed from the final draft. The Objective (writers take note!) is to specify the external characteristics of an Internet standard Router, not the algorithms it uses to implement that behavior. For example, this document should state that the ARP cache should lose track of information about hosts that disappear from the network, and should do so reasonably expeditiously. Whether this depends on internal timers 'popping', or on entries being found to be invalid upon reference, or some other algorithm, is not for this document to specify. Routing Protocols: Thou shalt not digress into religion, politics, or the correct standard IGP! The IESG and IAB are expected to decide on the standard Internet IGP, and this document should reference their decision. EGP2 and BGP should be documented; EGP3 should not be. Re: Filters and Controls, the effects of these should be specified without specifying the specific syntax or semantics. Network Management: By default, routers should allow public SNMP read access to at least the subset of the MIB required for diagnosis of end-to-end connectivity problems. However, the manager of the router should be able to disable the public access. The security aspects of SNMP need to be examined in more depth. There needs to be universal read access to a subset of the SNMP readable information, with significant control of the ability to write. However, attention should be given to the security aspects of SNMP readability. Performance requirements should include or reference standard tests, network stability under load, the forwarding and timely processing of updates, and the priority (if any) those updates should enjoy. There should perhaps be a vendor independent (potentially SNMP based) user interface to all Routers. 4 MINUTES - 2/7/90 Address Resolution Section The day started out with a detailed discussion of ARP. Generally, people seemed to feel that MAC-specific details of ARP should be discussed in the relevant MAC layer sections, but a stand- alone section should cover common ARP issues. This section should be called Address Resolution, and should also cover X.213/X.25 addressing issues (referencing the PDN Working Group's work). Several viewpoints were brought out on most of the following points, but these represent the endpoints of several (sometimes simultaneous) discussions: o Routers are generally triggered to ARP by a message which needs to be forwarded to a currently unknown system. While the impact of not holding the triggering packet is not great, a Router 'should' hold and re-transmit a small number of such messages for a limited period of time. o The ARP procedure calls for periodic refreshing of the ARP database, potentially using a broadcast in case the system has changed its MAC address. Generally, the first refresh attempt should be a unicast to the last known MAC address. o Proxy ARP is useful in circumstances where the Network Administrator can't or doesn't choose to advise his hosts of the local subnet architecture, or where the architecture is ambiguous, as in a multi-rail FDDI with some single rail systems on each ring. It may be viewed as a simplistic Router Discovery Protocol or a subnet disambiguator. Use of Proxy ARP in normal networks, however, is discouraged. Routers 'may' provide it, it 'must' be configurable, it 'must' be disabled by default, and 'should' be configurable by interface. o Systems 'must not' respond to an ARP for any recognizable Broadcast or Multicast address (Class D, 0.0.0.0, 255.255.255.255, Network or Subnet variants). o Routers 'should' emit an ARP request for their own address upon startup, and log an error in the event that anyone responds. Similarly, during normal operation, any ARP Request or Response sourced from a Router's IP address and indicating a Hardware Address other than the Router's should be logged. o In the event that a Router's Hardware Address is changed, it should broadcast a gratuitous ARP reply advising the world of the event. However, on startup in a multiprotocol Router, this should NOT occur when the Router changes from its native address to its protocol-specific MAC address; instead, the Router should wait for the completion of the configuration sequence to send its initial ARP reply. Internet Protocol Section Routers 'must' implement options: 5 o see RFC 1009 in case we forgot something o Loose Source Route and Record o Strict Source Route and Record o Record Route o Standard Security Option ('must' be first in option list) o Timestamp o NOP o End of List Routers 'may' implement o Extended Security Option o Detection of combined or multiple Strict/Loose/Record Route o MTU Options Routers 'may' ('should not'?) implement obsolete IP options o SATNET Stream ID o Revised Security Option Routers 'must not' o Combine or multiply Strict/Loose/Record Route Options There are some computational order dependencies: o most options only make sense after the forwarding decision has been made. o Strict and Loose Source Route apply BEFORE the forwarding decision, but only in systems addressed by the Destination IP Address. o Routers must fragment traffic. There was some feeling that the Router should make the first n-1 fragments the size of the MTU, and let the last be the modulus, and some feeling that the fragments should all be approximately the same size (we learned later that the currently proposed MTU discovery mechanism requires the first choice - ed). o Time to Live must be decremented on each hop. No vendor present decrements in seconds, but there was some feeling that decrementing by two when presenting traffic to a congested queue was doable and not all bad. o Routers should recognize and correctly deal with all recognized broadcast addresses (Class D, 0.0.0.0, 255.255.255.255, Network or Subnet variants) at the same time; configuration parameters deal with what the Router emits, not what it recognizes. o Routers 'must' not route traffic directed to a MAC broadcast or multicast address back to the same MAC. Routers 'should' not forward traffic directed to a MAC broadcast or multicast address at all. Initial Writing Assignments 6 Fred Baker: Address Resolution, ARP section Art Berggreen: Address Resolution, X.25/X.213 section Steven Senum: Hyperchannel, IP Options John Hamner: Time to Live Stev Knowles: Fragmentation and Re-assembly Stev Knowles: Treatment of IP Broadcast Addresses Stev Knowles: Glossary John Veizades: LocalTalk Mike Ride, Jeff Burgan, Roxanne Streeter: Internet IGPs, IP Filtering, IGP Translation Steve Willis: IEEE 802 LANs, Ethernet Martin Gross: ICMP Philip Almquist: Introduction Bill Melohn and Fred Baker: Serial Line Protocols Jeff Burgan: External Gateway Protocols Jim Forster: Variable Length Subnet Masks Steve Willis: SNMP Philip Almquist: Forwarding Jim Forster: Congestion Management MINUTES - 2/8/90 Additional requirements discussed: o Ignore reserved bits in IP packets o Router should not require network services (like DNS) to boot (Jeff Burgan will write a section on this) o Specify that if a Routing Protocol is implemented, it must be fully implemented (must follow appropriate RFC) o Discuss multiple subnets (addresses) on an interface. o Require SNMP for a router o Performance requirements (like IS-IS) (Steve willis will write a section on this) 7