CURRENT_MEETING_REPORT_ Reported by Steve Deering/Stanford Minutes: This was the third meeting of the Router Discovery Working Group. Steve Deering started by apologizing for not having produced a draft specification of the proposed router discovery protocol in time for this meeting, and promised to do so before the July IETF meeting. He then reviewed the current proposal, for the sake of newcomers. The router discovery protocol uses a pair of new ICMP messages: o Router Advertisement messages, which are periodically multicast by routers. o Router Solicitation messages, which may be multicast by hosts at start-up time only, to solicit immediate Router Advertisements instead of waiting for the periodic ones. (These were formerly called ``Router Report'' and ``Router Query'' messages, respectively.) Advertisements are sent to the ``all-hosts'' IP multicast address, and solicitations are sent to the ``all-routers'' IP multicast address. Hosts and/or routers may be configured to use IP broadcast addresses instead, though this is discouraged. The router discovery protocol is not applicable to networks that do not support either IP multicast or IP broadcast. 1 The format of the Router Advertisement message is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Count | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | Type identifies this as an ICMP Router Advertisement. Checksum standard ICMP checksum. Code and Reserved zero. Count number of (Router Address, Preference Level) pairs included in the message. Holding Time number of seconds that hosts should consider the information in this message to be valid. Router Address one of the sending router's IP addresses on the physical network on which this message is sent. Preference Level preferability of the preceding router address as a default router address, relative to other router addresses belonging to the same IP subnet. The usual case in which a router has more than one address on a single physical network is when that network is supporting more than one IP subnet. A receiving host is expected to ignore those (Router Address, Preference Level) pairs that do not belong to the same IP subnet as the 2 host. (This implies that a host must know its own IP address and subnet mask before it may use the information in a Router Advertisement message.) 3 The format of the Router Solicitation message is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type identifies this as an ICMP Router Solicitation. Checksum standard ICMP checksum. Code and Reserved zero. The group then discussed a number of topics that had been raised on the mailing list since the previous meeting. o Preference Level field Deering tried again to convince the group that the Preference Level field was unnecessary and undesirable, and again he failed. It was agreed that the field shall be present in the Router Advertisement messages, if for no other reason than that the Host Requirements document requires a preference level to be associated with each default router (even though it does not require hosts to do anything with it). Deering then proposed that the Preference Level be encoded as a signed, 32-bit, twos-complement integer, such that a higher value means more preferable. A router that is not configured with a specific preference level (or that does not compute its own preference level, based on routing information), will advertise a level of 0. The minimum level (80000000 hex) is reserved to indicate routers that must not be used as default routers (i.e., that may be used only for specific destinations, of which the hosts have been informed by ICMP Redirect or static configuration). Greg Satz had proposed that a router's preference level be derived from that router's metric for its ``default'' route, rather than from manual configuration. After some discussion of the merits and weaknesses of that approach, it was agreed that it would be allowed but not required by the router discovery specification. It was noted that a routing metric will normally have to be converted to a preference level, rather than being used directly, since for most routing metrics, smaller values mean more preferable. 4 No objections were raised to Deering's proposed encoding for the Preference Level field. o multicast vs. unicast replies to Solicitations o dallying Two unresolved issues were: should Advertisements sent in response to Solicitations be multicast or unicast, and should randomized delays be required before Solicitations and/or before responding Advertisements? Some people felt that dallying before Solicitations was important to prevent massive collisions when a LANful of hosts all boot at once, for example, after power is switched on (in a classroom, say) or is restored after a power failure. After much debate, it was agreed that hosts should dally for a short, random interval (between 0 and 1 seconds was suggested) before sending a Solicitation. If a host receives an Advertisement while dallying, it should refrain from sending a Solicitation. The optimal router behavior in response to a Solicitation is not at all clear -- a case was made for dallying or not, and for either unicast or multicast responses. Therefore, this will be left to the implementors' discretion for now, with a suggestion that the behavior be configurable. The group would welcome any analysis, simulation results, or reports of field experience that might favor a particular behavior. o periodic advertising rate Another outstanding issue was how often the periodic, unsolicited Advertisements should be sent. The choice depends on whether or not the advertisements are being used for black-hole detection, in addition to simple router discovery. For black-hole detection, the advertising rate must be high enough to allow router failures to be detected before transport connections fail (an interval of 10 seconds is the value used for this purpose in the ISO ES-IS protocol). If the advertisements are only used for router discovery, a much longer interval (10 minutes, say) would be adequate -- in this case the periodic advertisements serve only for recovery from the situation in which hosts and routers boot up on different sides of a subnet partition, which is later healed. In the absence of agreement on how black-hole detection should be done, the advertising interval must be configurable. The initial version of the document will suggest a default interval of 10 minutes. Subsequent decisions on black-hole detection may cause a smaller default value to be recommended. o black-hole detection Once the router discovery specification has been agreed upon, it has been suggested that this working group might turn its attention to the black-hole detection problem. A general discussion of the problems and possible solutions ensued, with no agreements being reached. (It was pretty much a rehash of previous discussions on the group mailing list; an archive of those messages is available for the interested reader.) 5 Action Items o Deering to generate a draft Router Discovery specification before the July IETF meeting. o Experimental implementations of the proposed protocol to be developed and deployed -- no promises, but Andrew Cherenson and John Veizades both offered to help (presumably for Unix and for the Macintosh OS, respectively), as soon as Deering gets the specification done. Greg Satz has previously offered the source code for his BSD Unix implementation of cisco's Gateway Discovery Protocol (GDP) as one possible starting point. Next Meeting The Router Discovery Working Group will next meet in Vancouver, at the July/August IETF meeting. 6 ATTENDEES Pat Barron pat@transarc.com Fred Bohle fab@saturn.acc.com Steven Bruniges David Burdelski daveb@ftp.com Duane Butler dmb@network.com John Cavanaugh J.Cavanaugh@StPaul.NCR.COM Andrew Cherenson arc@sgi.com Noel Chiappa jnc@PTT.LCS.MIT.EDU Steve Deering deering@pescadero.stanford.edu Dave Forster Richard Fox sytek!rfox@sun.com Karen Frisa karen@kinetics.com Steve Hubert hubert@cac.washington.edu Van Jacobson van@helios.ee.lbl.gov Stev Knowles stev@ftp.com Yoni Malachi yoni@cs.stanford.edu Keith McCloghrie sytek!kzm@hplabs.HP.COM Leo J. McLauglin III ljm@twg.com Jeff Mogul mogul@decwrl.dec.com John Moy jmoy@proteon.com Mike Patton MAP@LCS.MIT.EDU Drew Perkins ddp@andrew.cmu.edu Stephanie Price cmcvax!price@hub.ucsb.edu Michael Reilly reilly@nsl.dec.com Greg Staz satz@cisco.com Tim Seaver tas@mcnc.org Frank Slaughter fgs@shiva.com Richard Smith smiddy@pluto.dss.com Brad Strand bstrand@cray.com Cal Thixton cthixton@next.com John Veizades veizades@apple.com Jonathan Wenocur jhw@shiva.com 7