CURRENT_MEETING_REPORT_ Reported by Vince Fuller/Stanford and Philip Almquist/ Consultant Minutes: Tuesday, 1-May (AM) o TOS routing - Two aspects - internal queue handling vs. next hop choice * RREQ document deals primarily with later (external behavior) - Number of bits: 3 currently defined for TOS, 2 other ``spare'' bits * does router need to know what bits mean or can it just match against information available via routing protocols? * is TOS a hint or a requirement (more discussion later) - hint implies it is safe to ignore extra bits for now * issue: other groups may want to use those two bits for other things * requirement: all routers must make the same routing choices regarding TOS and all must implement TOS (but not all protocols will use) to prevent routing loops (Chair's statement) * issue: may have to change routing protocols if the number of bits changes (tough) * quote: ``keep your paws off those two bits'' - JNC, Area Director * DECISION: use 3 bits (problem made moot by above quote) o TOS semantics: - hint philosophy: deliver packets to default TOS if no match exists - requirement philosophy: drop packets if no TOS match exists (editors note: a very long and heated discussion of these differing philosophies consumed most of the first part of this session) - TOS unreachable ICMP message for "requirement" case - Proteon OSPF implementation allows per-TOS metric setting on lines; setting to infinity and dropping on no TOS match allows some small amount of policy control over line usage - problem: handling of TOS unreachable message is undefined - problem: won't work if host ignores TOS unreachables (or falls-back automatically to default TOS) - problem: TOS bits are not defined absolutely (i.e. in bps, etc.) - suggestion (Satz): two sides write up their cases; include both in draft document for further review (any takers?) - idea: use one of the "unused" bits to specify hint/required TOS - Milo believes looping can occur if TOS is treated as a hint - need specific scenarios 1 o Fragmentation - Review of each option outlined in draft text: * option 1: no longer needed by MTU discovery * option 3: invalid, since 576 is NOT the minimum required MTU size - if anyone has empirical evidence of a good way to do it, them document should discuss it; otherwise, defer to IP RFC * action: talk to Jeff Mogul and Van Jacobson about their experiments o Reassembly - Router MUST reassemble packets destined to itself (i.e. ICMP messages) * router is acting as host in this case, must follow HR * HR says must reassemble max of 576 bytes or connected interface MTUs - Router MUST NOT reassemble packets that are forwarded * reassembly not possible if multiple paths exist, etc. etc. - Multicast handling Minimal discussion. Steve Deering (``Mr. Multicast'') volunteered to write some draft text o TTL - Long discussion about schizophrenic use of TTL as time AND hop count * TCP makes assumptions about real time of packet life vs. TTL handling (problem can occur with sequent number wraparound) * no implementors expect to implement use of TTL as time (fact of life) * deprecate ``SHOULD'' to ``MAY'' for decrementing TTL by time * include discussion of why this should be done (what TCP expects, etc) - Handling of TTL boundary conditions: * TTL 0 - router MUST NOT drop packets to itself on TTL = 0 (HR sez) * router MUST NOT ever send a packet with TTL = 0 (ditto) * router SHOULD return ICMP time exceeded if it decrements TTL to 0 * router MUST NOT ``pre-discard'' packets with TTL > 0 even if it knows (via link-state routing, for example) how many hops a destination is (it breaks ``traceroute'' to do so and doesn't really gain much) * should there be some discussion of ``traceroute's'' expectations? 2 Minutes: Tuesday, 1-May (PM) A review of writing assignments/document sections was done The following (mostly un-written) sections were worthy of mention (mainly because no one is doing anything about them): 7. Routing protocols - RIP, EGP, BGP (Yakov Rekhter/IBM), OSPF 8. Network Management Protocols - SNMP (Steve Willis/Wellfleet), CMIP/CMOT 9. Administrative and Policy controls, including: filters (both traffic and routing info), interchange between EGP's and IGP's, preference of routes by [protocol, neighbor, network number, etc.], conditions for default generation, etc. (subcommittee formed and had preliminary discussion over lunch - included Steve Willis/Wellfleet, Philip Almquist/Consultant/Stanford, Vince Fuller/Stanford/BARRNet, Michael Reilly/DEC, and one or two others forgotten by the editor -- they and others interested in these issues (Milo, Jeff?) should get in touch with the Chair ASAP) 10. Initialization, operation, management Appendix A - Internet-specific requirements Appendix B - Requirements for specific uses (i.e. regional network) o Multicast - forwarding of multicasts is not yet required - router SHOULD perform host multicast functions (per RFC1112 and HR) - router MUST NOT pass ``letter-bomb'' multicasts (as target of source route) - record route doesn't present a problem (according to Steve D.) - multicasts should not be used as an hop in a source route either o TOS, take 2 (Yakov had a few things to say) - in current Internet, virtually no use (according to NSFNet statistics) - chicken and egg problem (Steve D.) - 3 bits are too coarse to be useful for policy control - all routers in AS (at least) must make same routing decision on TOS in order to prevent loops * what about for paths through multiple AS's? * what if AS's are multi-homed? - how to use in presence of sources (protocols) of routing information? * use to prefer protocol if it has exact TOS match? 3 - opinion: TOS 0 is default - must always exist and is used if no exact match - opinion: forbid setting of multiple TOS bits (``Christmas tree'') - enforce by treating as treating as TOS 0 (?) - no definite conclusion (no surprise here!) o Broadcast handling - Directed broadcasts * routers MUST support, MAY provide knob to disable * justification: widely used, part of IP architecture - All-subnets broadcast * current behavior: only sent to first subnet seen * Chair will make case to IESG to make it an obsolete part of the IP architecture (by creating a successor to RFC922) * consider as a SHOULD NOT - may support, but MUST provide knob which defaults behavior to disabled o IP options - Record route - MAY in HR, specify as MUST in RREQ - Timestamp - ditto * long discussion about when during packet processing the timestamp should be added - no conclusion * document should state that when it happens is not defined and will be implementation-dependent * Yakov (opinion): all routers should do timestamp at same point in packet processing - not much agreement from rest of WG - Option insertion by routers * security option must be inserted, so it MUST be allowed (RFC1108) * what if no option space available - Martin Gross/DCA will address * are there other options that need to be inserted? - non-understood options - MUST be passed unchanged - source route - only one source route option may exist o Precedence - OSPF mandates that routers set precedence to Internet Control - BGP - ditto - issue: may be political problems with this - what about network management traffic? - DCA group is working on paper describing scheme o Martian address filtering MUST provide functionality and provide switch to enable/disable (long discussion ensued about performance impact of making it strictly a MUST) o What's next? - video-conference will take place in June (tentatively, Monday, June 11th) 4 - Internet-Draft is expected after August IETF 5 ATTENDEES Richard Smith smiddy@dss.com David Waitzman djw@bbn.com John Wobus jmwobus@suvm.acs.syr.edu Pablo Brenner Jonathan Wenocur jhw@shiva.com Dave Forster Steve Willis swillis@wellfleet.com Michael Reilly reilly@nsl.dec.com Martin Gross martin@protolaba.dca.mil Peter Vinsel farcomp!pcv@apple.com Stev Knowles stev@ftp.com Vince Fuller fuller@jessica.stanford.edu Frank Kastenholz kasten@interlan.interlan.com John Moy jmoy@proteon.com Roxanne Streeter streeter@nsipo.arc.nasa.go David Miller dtm@mitre.org Douglas Bagnall bagnall_d@apollo.hp.com Walt Wimer ww0n@andrew.cmu.edu Kanchei Loa loa@sps.mot.com Yoni Malachi yoni@cs.stanford.edu Karen Frisa karen@kinetics.com Stepanie Price price@mcvax!ucsbcsl.edu Stan Froyd sfroyd@salt.acc.com John Cavanaugh john.cavanaugh@stpaul.ncr.com John Veizades veizades@apple.com Steven Senum sjs@network.com Kannan Varadhan kannan@oar.net Steven Bruniars Paul Tsuchiya tsuchiya@thumper.bellcore.com Kathy Huber khuber@bbn.com Steve Deering deering@pescadero.stanford.edu Greg Satz satz@cisco.com Curtis Cox zk0001@nhis.navy.mil Milo Medin medin@nsipo.nasa.gov Phil Karn Karn@Thumper.Bellcore.Com Y Wang Keith Hogan keith%penril@uunet.uu.net Richard Woundy rwoundy@ibm.com Mary Youssef mary@ibm.com Jim Sheridan jsherida@ibm.com Dino Farinacci dino@bridge2.3com.com Steve Storch sstorch@bbn.com Phil Park ppark@bbn.com Sze-Ying Wuu wuu@nisc.junc.net Tim Hunter thunter@allegum.bitnet Steve Hubert hubert@cac.washington.edu John Vollbrecht jrv@merit.edu Joel Replogle replogle@ncsa.uiuc.edu Paul Pomes paul-pomes@uiuc.edu Drew Perkins ddp@andrew.cmu.edu Stephanie Price price@cmcvax!uscbcsl.edu 6 7