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