Return-Path: Received: from pescadero.stanford.edu by NRI.NRI.Reston.VA.US id aa09367; 6 Jan 90 18:43 EST Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA08497; Sat, 6 Jan 90 15:45:16 PDT Date: 6 Jan 1990 15:30-PST From: Steve Deering Subject: Router Discovery WG meeting report To: gvaudre@nri.reston.va.us, pgross@nri.reston.va.us Message-Id: <90/01/06 1530.279@pescadero.stanford.edu> Greg and Phill, Here are the minutes of the first meeting of the Router Discovery WG, for you to file away. Note that the minutes refer to "gateway" discovery, rather than "router" discovery, which was our terminology at that time. Steve -------------------------------------------------------------------- Gateway Discovery Working Group Chairperson: Steve Deering/Stanford REPORT ON MEETING OF DECEMBER 12, 1989 at DEC Western Research Lab, Palo Alto, CA. Reported by Steve Deering ATTENDEES 1. Art Berggreen art@salt.acc.com 2. Noel Chiappa * jnc@ptt.lcs.mit.edu 3. Farokh Deboo sun!iruucp!ntrlink!fjd 4. Steve Deering deering@pescadero.stanford.edu 5. Richard Fox sytek!rfox@sun.com 6. Keith McCloghrie sytek!kzm@hplabs.hp.com 7. Jeff Mogul mogul@decwrl.dec.com 8. Stephanie Price cmcvax!price@hub.ucsb.edu 9. Greg Satz satz@cisco.com * Noel Chiappa attended by speaker phone. MINUTES This was the first meeting of the Gateway Discovery Working Group, although it has been very active by email since it was formed on October 27, 1989. The meeting was held back-to-back with the first MTU Discovery Working Group meeting. Our thanks to Jeff Mogul and DECWRL for hosting the meeting. As the first item of business, Deering suggested that the group might wish to elect a new chairperson, because of potential conflict-of- interest on his part. (As the designer of one of the candidate gateway discovery protocols, he might not be sufficiently impartial.) The attendees chose not to take him up on his suggestion. We then reviewed the various candidate gateway discovery protocols that had been identified and discussed on the mailing list: stub RIP - using default-route-only RIP broadcasts to inform hosts of gateway presence; usable by any gateway, not just those using RIP as their IGP. cisco GDP - a UDP-based protocol very similar in functionality to the IS-discovery part of the ISO ES-IS protocol. ICMP-D - Deering's proposed ICMP extensions, based on low- frequency periodic multicasts by gateways (i.e., not frequent enough for timely detection of gateway failure). ES-IS subset - the gateway-discovery/gateway-failure-detection subset of ISO 9542, with the minimum of changes required to carry IP addresses in IS Hellos. Proxy ARP - eliminating the need for "gateway discovery" by making the gateways invisible. PP1 - Prindeville's proposal #1, in which an IP unicast datagram is sent as a LAN multicast packet when no gateway address is known, triggering a Redirect. PP2 - Prindeville's proposal #2, in which hosts send ICMP multicast queries to locate gateways. The proposal was unclear on whether or not queries are for a specific destination/TOS, or for default gateway only. [It has since been clarified: the queries are for specific destination&TOS.] X.Y.Z.1 - using a well-known address (such as address number 1 on every subnet) to identify the "current default router". The routers run an election algorithm to decide which one answers to that address at any time. BOOTP - three popular protocols used to supply hosts with Sun BootParam one or more gateway addresses (along with other info) MIT NIP at boot time. Might be extended to supply gateway addresses at other times. The list was then trimmed to three candidates -- RIP, GDP, ICMP-D -- for further discussion. The others were eliminated for the following reasons: ES-IS - use of ISO packet formats unnecessarily complicates implementation on simple IP-only hosts; no "preference level" field; political hot-potato. Proxy ARP - if hosts don't know they are talking to a gateway, they won't obey Redirects; difficult for gateways to decide which is "best" choice; "slowest gateway wins" phenomenon. PP1 - difficult for gateways to decide which is "best" choice; Redirect implosion; duplicate delivery. PP2 - incomplete specification; scales poorly with large numbers of hosts. X.Y.Z.1 - won't work with existing hosts that don't time out ARP entries; too late to reserve a special address on all subnets. BOOTP, BootParam, NIP - not designed for dynamic, on-going discovery of gateway addresses; hosts might get confused on receiving an unsolicited, partial BOOTP broadcast; beyond charter of this group. We then proceeded to identify the following pros and cons of stub RIP: Pro: - already supported by many hosts and gateways. Con: - uses broadcast rather than multicast. - is named "RIP" -- it has become politically incorrect to advocate the continued use of RIP. (Possibly solved by giving the stub RIP subset a new name?) - no "holding time" field, which is important if doing ES-IS-style gateway failure detection. It means that hosts have to have wired-in knowledge of the gateway broadcast rate, which would have to be 30 seconds for the scheme to work with existing RIP implementations. Unfortunately, 30 seconds is too long for reasonable dead gateway detection, and much shorter than needed for discovery only. - [not mentioned at the meeting, but in an earlier mail message: danger of stub-RIP broadcasts from non-RIP gateways confusing full-RIP gateways on the same wire.] We also discussed using full RIP packets (i.e., containing per- destination routes, rather than just default routes) for the sake of multi-homed hosts, which have to do more than just discover a default gateway. By comparing routing metrics reported on each connected subnet, a multi-homed host can decide which subnet to use as the first hop towards a given destination. However, RIP is less than ideal for this application, because: - RIP packets do not carry Autonomous System numbers, which would allow hosts to know whether or not RIP metrics from different subnets can sensibly be compared. - RIP routes are per-destination only, rather than per-destination&TOS. - The RIP packet encoding for IP routes is very inefficient, which means that large routing tables must be split across more packets than necessary. Unlike RIP, the remaining two candidates -- GDP and ICMP-D -- are amenable to change (no need for backward compatibility). Therefore, rather than going through the pros and cons of each protocol, we identified the differences between the two and agreed on a resolution of those differences, thus coming up with the "best" of the two. Those differences are: - GDP is a UDP application; ICMP-D is an ICMP extension. Resolution: use ICMP. This is the logical place for this functionality in the IP suite. It was recognized that it is generally easier to add UDP applications to an existing implementation than to extend ICMP, but that the need for the protocol to manipulate the IP default gateway list might be more easily met by an ICMP-level implementation in some cases. It was noted that, for 4.3bsd Unix and derivatives (e.g., current versions of SunOS and Ultrix), the required ICMP extensions can be implemented either inside the kernel or in a user-level process. - GDP uses broadcast; ICMP-D uses multicast. Resolution: specify the use of multicast, but recognize that some vendors and network administrators will use broadcast anyway, at least until hosts and gateways are upgraded to support multicast. Therefore, discourage the use of broadcast but do not forbid it ("SHOULD multicast"). - GDP includes a "holding time" field; ICMP-D does not. Resolution: include a holding time field. This field allows a gateway to control how long a host continues to believe that the gateway is alive, in the absence of new information; it is important if the protocol is to be used for gateway failure detection as well as gateway discovery, and is useful in any case. (There is some controversy over how gateway failure detection ought to be done and, in order to progress the gateway discovery protocol, we are putting off resolution of that issue for now. It is expected that this working group will evolve into the "black-hole detection" working group after it's initial charter has been satisfied. Including the holding time field in the packet format will leave the options open for that future work.) - GDP allows more than one gateway address to be reported in a single packet; ICMP-D only allows one (the IP source address of the packet. Resolution: allow more than one gateway address. This is NOT intended to allow one gateway to report other gateways' addresses (although it does permit such usage); it is for gateways connected to LANs that carry more than one IP subnet, where a gateway may have a different address for each subnet. Hosts receiving the gateway reports must pick out only those addresses that belong to the same subnet as the host, and ignore the rest. - GDP does not carry subnet masks in its gateway reports; ICMP-D does. Resolution: do NOT include subnet masks. This means that, before engaging in the gateway discovery protocol, a host must know its own mask (as well as its own address). There are already several existing mechanisms for acquiring that information, e.g., static configuration, BOOTP, and ICMP Mask Reply; it is expected that the Host Configuration Working Group will standardize on a mechanism for obtaining various subnet parameters, of which the mask is only one. - GDP allows for 2^16 preference levels (priorities); ICMP-D allows for only 8 preference levels. Resolution: no big deal, but 8 levels should be sufficient. However, there is some doubt as to the value of including preference levels at all. The working group does not want to specify at this time how hosts shall deal with preference levels, but agrees to include the field for private use or possible consideration at a later time. - GDP does not specify randomization of periodic gateway reports (to avoid synchronized transmissions) or any mechanism to reduce the traffic during simultaneous boot-up by many hosts; ICMP-D specifies both. Resolution: specify randomized reporting intervals; the ICMP-D mechanism for replying to multiple multicast queries with a single multicast reply is to be suggested but not required. Deering volunteered to revise his draft RFC to reflect these decisions, to be ready by the February IETF meeting. Greg Satz generously agreed to let us use his (cisco's) BSD Unix implementation of GDP as the basis of a freely-distributable implementation of the revised protocol. We hope to have that ready by the February meeting as well. The next meeting of the Gateway Discovery Working Group will be at the February IETF meeting in Tallahassee, Florida. We intend to split a single afternoon session between us and the MTU Discovery Working Group, which has many of the same members.