[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

IETF Secretariat                                             N. Bourbaki
INTERNET-DRAFT                                                      IETF
draft-ymbk-termroom-op-07.txt                                 2002.06.13

                IETF Meeting Network Infrastructure Lore

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

0. Abstract

   Creating and running the 'terminal room' for an IETF meeting is
   tantamount to building, running, and dismantling a small computer
   center.  Although this is a well-known area of operations, the unique
   environment and its ephemeral nature warrant passing on the lore in a
   mildly organized fashion.  It is expected that this document will be
   updated regularly.  However, it is not clear that this will ever be
   published as an RFC.

   As the IETF can ill afford failure of this service, it is assumed
   that the host and organizers have the experience and resources to
   build such environments, understand power facilities, cabling, WAN
   and LAN building, workstation provisioning, staffing, etc.  So this
   document does not attempt to detail how to build computer facilities
   or carry out prudent project management.  Rather it concentrates on
   the unique aspects of the IETF 'terminal room'.

N. Bourbaki                Expires 2002.12.13                   [Page 1]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

1. External Network Connectivity

   The picky and analytic nature of a large number of IETF participants
   means that the connectivity and performance of that connectivity will
   be measured, whined about, ...  Do not worry.  Move the packets well,
   and the nit pickers will pick each other to death.

   1.1 Bandwidth Requirements

       Bandwidth consumption is approximately 5kbps per attendee.  So
       currently 10mbps of external connectivity seems sufficient.
       Unicast peaks at about five, and multicast at three.  The
       addition of streaming services may require more bandwidth,
       especially if they are not cached off-site.

   1.2 Path Diversity

       If possible, diverse physical and logical paths should be
       provided.  It is understood that few conference centers have
       connectivity, let alone diversity.  But it is prudent to
       coordinate with the ISP to get as much redundancy as reasonably
       possible.  Redundant and diverse paths out of the local
       provider's POP(s) are advised when possible.

   1.3 WAN Multicast Considerations

       It has been suggested that multicast WAN connectivity would
       benefit from being separated from unicast.  This has been tried
       and worked, though it is not believed to be necessary.

   1.4 IPv6 Considerations

       Increasingly it is expected that IPv6 connectivity is available.
       Ideally this would be via some production IPv6 service.  If that
       is not available, at least 6bone access SHOULD be provided.

2. The Internal Network

   This has been the transport area of most concern at recent meetings.
   The bulk of the users require IPv4 unicast.  IPv4 multicast is needed
   to originate MBONE content from selected Working Group sessions.
   Some users who have forgotten how to walk or may be extremely
   antisocial find it convenient to be able to receive the multicast
   feeds and other multicast content.  Increasingly, some form of IPv6
   connectivity is desirable.

   Like many academic computer centers, the IETF terminal room and LANs
   get 24 hour use for the duration of the meeting.  While users do not

N. Bourbaki                Expires 2002.12.13                   [Page 2]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

   expect staffed support at all times, they do expect the network to
   remain up even at 2AM.  IETF attendees often do not recover from jet
   lag or operate on hacker [JARGON] schedules.

   A number of IETF old-timers consistently show up on the Saturday
   prior to the meeting; clever terminal room staff will leverage them
   in helping to crimp, cable, and configure the terminal room setup.
   Historically, terminal room staff who take a crisp officious view on
   when the terminal room and wireless LAN first become available are
   less successful than those who take a more flexible and friendly

   While set-up will take a very large staff, if it has been done well,
   the staff needs during the meeting are small.  General experience has
   been three to four people during the day, with some spares able to
   cover during meals etc.  Having someone on cell phone or in the same
   hotel at night is prudent.

   Most IPv4 multicast traffic originates from one of the two
   concurrently operating multicast Working Group sessions.  However,
   some multicast will be originating outside and consumed by IETF
   attendees in the terminal room.  It is helpful if the IPv4 multicast
   router supports IGMPv2 [RFC-2236].

   While current use is primarily IPv4 unicast or IPv4 multicast, in
   future the terminal room SHOULD also provide some form of IPv6
   connectivity.  If IPv6 [RFC-2460, RFC-2463] is deployed in the IETF
   network, at least IPv6 Neighbor Discovery [RFC-2461] with stateless
   autoconfiguration [RFC-2462] SHOULD be enabled to enable plug and
   play networking.

   2.1 LAN Separation

       As they seem to interfere with each other, at least three
       separately routed LAN segments SHOULD be used for the terminal
       room, wireless ethernet, and multicast services.  In particular,
       the high speed multicast feed exceeds the capacity of the
       wireless ethernet, and therefore MUST be separate.  In case
       multicast causes wireless problems, be prepared to keep all IP
       multicast traffic off the wireless LAN.

       There MUST NOT be firewalls, NATs, or other end-to-end breakage
       between the public LAN(s) and the global internet.

   2.2 Meeting Infrastructure Connectivity

       The registration desk SHOULD be provisioned to accommodate the
       Secretariat's firewall and LAN.  It is also helpful if the

N. Bourbaki                Expires 2002.12.13                   [Page 3]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

       Wireless LAN (more below) has good coverage around the
       registration desk.

       The IAB/IESG meeting room SHOULD have LAN coverage, and it SHOULD
       also have 802.11b wireless support.

   2.3 Meeting Rooms

       Two of the meeting rooms MUST be provisioned for origination of
       IP multicast audio/video content.  The IETF Secretariat will
       specify which rooms shortly before setup.

   2.4 Mains Power Availability

       A scattering of mains power outlets in all meeting rooms is much
       appreciated by laptop-based attendees.  Having a few power strips
       in the lobby, bar, and other places laptop users congregate is
       also much appreciated.  Wireless folk use large qualities of
       power strips.

       Attendees appreciate having advance notice of which sort of power
       (i.e.  voltage, frequency) and which sort of power connector will
       be present at the meeting location.  This permits attendees to
       obtain appropriate adapters and widgets before coming to the
       meeting.  This information SHOULD be included on the IETF meeting
       web page and SHOULD also be included in a message to the IETF
       Announce mailing list.

   2.5 Wireless LAN

       Drops to connect the wireless ethernet base stations SHOULD be
       supplied at strategic locations throughout the facility.  The
       primary targets should be large gathering areas with seating,
       e.g. the lobby and bar areas.  All meeting rooms SHOULD have
       wireless coverage if at all possible.

       Historically, IETF used Digital RoamAbouts, the proprietary pre-
       standard WaveLAN technology that operated at 915 MHz (and 2.4 GHz
       outside North America).  Recently, the IETF user base has been
       moving to the new IEEE Standard 802.11 wireless LAN technology at
       2.4 GHz.  This transition is now largely completeand the new IEEE
       802.11 wireless standard [IEEE-99a] is dominant in the IETF user

       The IEEE standardized two incompatible variants within the 802.11
       standards.  One variant uses a Frequency Hopping Spread Spectrum
       (FH) technique.  This is commonly called IEEE 802.11-FH.  The
       second, far more widely deployed, variant uses a Direct Sequence

N. Bourbaki                Expires 2002.12.13                   [Page 4]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

       Spread Spectrum (DS) technique.  This is commonly called IEEE

       The IETF Wireless LAN MUST support at least the 802.11-DS
       technology.  As these systems are able to automatically scan all
       the channels, the terminal room operator SHOULD configure
       immediately adjacent Access Points to use different channels
       within the 2.4 GHz band.

       The IEEE recently approved a higher-performance (11 Mbps)
       extension [IEEE-99b] to the basic 802.11 specification.  The
       802.11 Access Points SHOULD be configured to support the 11 Mbps
       speed.  However, the Access Points SHOULD NOT be locked to only
       support 11 Mbps, as some attendees will have older PCMCIA cards
       that only operate at the older, slower speeds.

       It is assumed that attendees using wireless use (self-supplied)
       end-to-end encryption (e.g. SSH, ESP) or are suicidal.  So the
       wireless network itself is run in the clear, i.e. encryption is
       turned off.

       If parameter values are chosen which are different from those
       described in this document, substantial advance public notice
       MUST be given to the IETF Announce mailing list and on the IETF
       meeting web page.

       To allow IPv6 operation, certain ethernet-layer multicast must be
       able to go through the wireless links.  Some wireless
       basestations offer the ability to turn off bridging of ethernet-
       layer multicast packets.  You MUST configure basestations to
       properly bridge at least ethernet-layer multicast as used by
       IPv6, i.e. 33:33:xx:xx:xx:xx.

       Any additional wireless types beyond the IETF supported wireless
       standard, IEEE 802.11-DS, and all applicable user configuration
       parameters SHOULD be announced on the IETF meeting web page and
       to the IETF Announce mailing list well before the meeting so that
       attendees have an opportunity to obtain compatible adapters for
       their laptops.  Examples of possible wireless additions include
       the older proprietary 915 MHz or 2.4 GHz RoamAbouts and/or

   2.5.1 Wireless LAN (IEEE 802.11-DS)

       The IETF 802.11-DS systems and 802.11-FH systems have one primary
       configuration parameter.  This is variously called "ESS ID",
       "Network Name", or "Network ID", depending on which documentation
       one is reading.  This parameter MUST be set to the 4 character

N. Bourbaki                Expires 2002.12.13                   [Page 5]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

       string "IETF" in all capital letters for the IETF 802.11 wireless
       LANs.  Encryption SHOULD be disabled (see comment in 2.5 above).

   2.5.2 Wireless LAN (Historic)

       Support for the older proprietary RoamAbout 915 MHz and 2.4 GHz
       systems MAY be provided as a convenience to those attendees yet
       to convert.  The proprietary RoamAbout 915 MHz and 2.4 GHz wired-
       to-wireless bridges have parameters global to all bridges which
       MUST be set as follows:

                Domain ID:   0x1
                Beacon key:  0x1E1F

       The proprietary RoamAbout 915 MHz and 2.4 GHz wired-to-wireless
       bridges have a Network ID (NWID) parameter that MUST have a
       unique value for each bridge location and which SHOULD be set as
               1st location's NWID:  0xAAAA
               2nd location's NWID:  0xBBBB
               3rd location's NWID:  0xCCCC
               4th location's NWID:  0xDDDD
               and so forth.

       For users whose laptops do not support roaming, a map detailing
       the location of each bridge and its associated NWID SHOULD be

   2.6 Multicast

       Multicast-based streaming of IETF working group meetings has
       evolved considerably over the years.  Provisioning of multicast
       is straightforward as there is a complete hardware kit brought to
       each meeting.

       The requirements for multicast are divided into two parts: (1)
       network support for multicast transmission, and (2) application
       layer support including encoding equipment, cameras, event staff,

   2.6.1 Network support for multicast transmission means the IETF
         network SHOULD support PIM-SM, MBGP, and MSDP.  The network
         MUST ensure there is a feed for the multicast-capable part of
         the network into the two multicast rooms.  The network MUST use
         vendor equipment which supports PIM-SM, MSDP, and MBGP.  There
         are enough scalability problems with dense mode protocols, that
         DVMRP tunnels SHOULD NOT be used.  Typically there is enough

N. Bourbaki                Expires 2002.12.13                   [Page 6]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

         local expertise to configure and test multicast without
         problem.  If help is needed, the IETF technical team is

   2.6.2 The work of generating the content to be delivered over the
         multicast network has evolved into a fairly stable system.  The
         current setup is a "traveling IPTV server".  Currently, the
         University of Oregon provides the encoding hardware for the two
         multicast rooms.  This hardware is a set of two "refrigerator-
         sized" boxes that have a complete set of encoders, cables,
         etc., basically, all the necessary hardware.  All cameras and
         tripods are owned by the IETF and brought to each meeting.

         In terms of personnel, the two senior engineers who run the two
         channels are currently supplied by the IETF engineering
         community.  The IETF engineering community coordinates the
         volunteers who control cameras and monitor operation during
         stable periods.  If the local host is interested in adding
         local volunteers, this should be coordinated through the IETF
         technical team.

   2.7 Cabling

       IETF networks have been crippled when very long ad hoc fiber runs
       have been inadvertently smashed by workfolk and others, and no
       spare cable was available.  Spares should be kept, and it might
       be advisable to mark the runs with caution tape (so users know
       where to kick), etc.

3. Network Services

   A lot of stress is put on DHCP, printing, and everything else.

   3.1 Network Outlets

       Laptop users outnumber users needing desktop platforms.
       Currently one terminal room 10baseT Ethernet laptop drop per 15
       attendees is comfortable.  10baseT Ethernet (e.g. RJ-45
       connector) is sufficient, as 10base2 Ethernet has essentially
       disappeared, particularly in the laptop computer community.

   3.2 DHCP Service

       A very wide range of DHCP clients are in use within the IETF
       community.  The DCHP server SHOULD be widely interoperable and
       fully conformant to the DHCP standards [RFC-2131, RFC-2132].
       Specifically, a WIDE DHCP or an ISC DHCP server running on a UNIX
       platform is strongly recommended until other DHCP servers have

N. Bourbaki                Expires 2002.12.13                   [Page 7]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

       demonstrated better compatibility and standards-compliance.  The
       IP address pool MUST be large enough to avoid shortages given
       constant connection churn.

       Repeated experience indicates that it is desirable to have a
       sufficiently large pool on standby to permit rolling over DHCP
       servers without making a mess.  The Internet Registries have a
       temporary Class B (or equivalent) address that may be used if
       they are asked nicely.  Of course it has to be registered routed
       to the WAN.

       The DCHP server will likely have to serve multiple subnets.  This
       will also require router configuration.

       The DHCP lease timeout must be set short enough to roll over
       leases quickly (where 'quickly' is relative to the address space
       available for the pool) while not overwhelming the network with
       renewal requests.  A lease lifetime of one hour appears to work
       well if address space is short.  A lease lifetime of days can be
       used if there is a large free address pool.  Too long a lease
       time followed by address pool shortage has been a problem at past
       meetings.  It is important that the DHCP server normally renew
       DHCP leases and give out the same IP address to a given node as
       long as that node continuously renews its DHCP lease in a timely
       manner.  This avoids loss of existing network sessions due to
       unexpected and needless change of the host's IP address by the
       DHCP server.  Moderation in all things.

       Support for IPv6 DHCP has been provided but seldom used.  It is
       appreciated by the (very few, if any) IPv6 users.

   3.3 Static IP Addresses

       A pool of IP addresses for static assignment to laptop users
       without DHCP is necessary for approximately one client per 20
       attendees.  We do not know why that number is so high.  There
       SHOULD be a mechanism at the help desk to allocate and register
       their use.

       Providing for allocation by email before the meeting is kind to
       those who need to configure security parameters with their normal
       home/corporate network prior to the meeting.  The static IP
       allocation process SHOULD be announced to the IETF Announce
       mailing list well before the meeting.

       For static allocation at the meeting venue, pieces of paper have
       been used.  Allocation using 'pegs' [RFC-2322] is an alternative
       mechanism which has been used successfully in RIPE and other

N. Bourbaki                Expires 2002.12.13                   [Page 8]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

       meetings for some years.

   3.4 Printing

       Printer services are very like those in a small computer center.
       Two paper printers SHOULD be provided, and a third for spare is
       advisable.  The printing rate is about .05 PPM / attendee, and a
       typical attendee prints approximately 15 pages during the

       At a recent meeting, the desktop terminal room printer used twice
       the amount of paper than the laptop room (which was twice the
       size).  This suggests that people who bring laptops don't print
       as much, copying documents to hard drives instead.

       One transparency printing facility MUST be provided.  The
       transparency printing rate is about .01 PPM / attendee, and a
       typical attendee prints approximately 1.5 pages during the

       A reasonable alternative to a transparency printer is a copier
       machine with transparencies loaded.  Such a copier SHOULD be
       clearly marked as being loaded with transparencies, lest someone
       erroneously attempt to use it to create paper copies.

       Network printers provided in the terminal room MUST provide BSD
       lpd, and PostScript level-2 support.  It is helpful to indicate
       in advance whether the printers will be supporting standard A4
       paper or the strange but patriotic American 8.5x11 inch paper.

       Many laptop users are running some version of UNIX.  It is
       helpful if these users can print documents without resorting to
       proprietary printing protocols.  Accordingly, at least one
       printer that supports the BSD Line Printer (LPR) protocol
       [RFC-1179] SHOULD be provided.  Configuration parameters for this
       printer SHOULD be posted in the terminal room.

       Deployment or use of the Internet [sic] Printing Protocol (IPP)
       is negligible, so supporting this is purely optional.  Absence of
       IPP support is unlikely to create a furor among the IETF user

       Non-printer transparencies MUST NOT be available near the
       printers, or someone will put them in a printer and ruin it.

       Macintosh and MS-Windows systems need a print spooling server,
       either Samba-based or NT-based.  A Samba-based approach will
       facilitate the use of the same printers for users of any OS and

N. Bourbaki                Expires 2002.12.13                   [Page 9]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

       has worked well in the past.

   3.5 Transparencies

       The cost of transparencies and their tendency to jam printers
       often warrants manual queue operation.  It is kind to train a
       local and a nocturnal denizen or two in queue-running to reduce
       whining at three in the morning.

   3.6 Mail Service

       A local SMTP server SHOULD be available for those whose home
       servers will not do mail forwarding for clients with strange DNS
       names and/or unknown addresses.  This server MUST be configured
       to accept SMTP relay only when the source IP address is within
       the IETF LAN address space, as the IETF does not wish to
       contribute to SPAM.

   3.7 Time Service

       An increasing number of users are running either NTP [RFC-1305]
       or SNTP [RFC-1769] on their laptops.  A local NTP server SHOULD
       be available to serve ntpdate requests for users and to chime
       with locals who run NTP clients.  The NTP parameters SHOULD be
       clearly documented in the terminal room.  A UNIX ntpd daemon is
       strongly recommended.

   3.8 Domain Name Service

       At least two local DNS servers MUST be available to users.
       Caching DNS servers are preferred.  The IP addresses of these
       servers MUST be posted in the terminal room and SHOULD be
       included in the terminal room documentation supplied in the
       registration packet.

   3.9 Server Load Considerations

       Consider splitting the UNIX server functions over more than one
       machine.  Print spooling or X duty may bog down a single server.
       Consider one server for print queue and Xhost, another for DHCP
       and SMTP relay, and a third for NTP and DNS.  Isolate the
       critical and non-critical server functions on different machines
       so a non-critical function, like print queuing, if it stalls or
       hangs the machine, won't stop DHCP and DNS.

N. Bourbaki                Expires 2002.12.13                  [Page 10]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

   3.10 Web Proxy/Cache

       As noted later, it is helpful to have all of the IETF RFCs and
       Internet-Drafts archived on a local server.  Ideally this is
       accessible via http and also ftp.

       In some situations, performance can be boosted by providing a web
       proxy cache.  If one is used, it is preferred that it NOT be of
       the 'transparent web cache' variety, due to concerns about the
       compatibility of such devices with all forms of web-based
       content.  If a 'transparent web cache' will be used, this MUST be
       disclosed to users via the IETF Announce list prior to the
       meeting.  It is reasonable to configure web browsers on the
       provided desktops to use the web proxy by default, provided users
       are able to disable this manually if needed.

   3.11 Help Desk

       The help desk SHOULD be staffed from early morning to late
       evening by people of patience and clue.  As many attendees are
       rather experienced, their questions can be rather technical.  Of
       course, like the typical user population, they also have less
       sophisticated needs and temperaments.  An emergency contact
       number SHOULD be available when the help desk is not staffed.

   3.12 Office Supplies

       A small stash of office supplies such as staplers, tape, markers,
       etc. is often much appreciated.  It has been suggested that a
       lively market could develop in RJ4x adapters, RJ11 kits, AC plug
       converters, local phone to RJ11 adapters, etc.  Small ethernet
       hubs have also proven useful for network debugging, etc.

   3.13 Advanced Technology

       While it is tempting for a host/vendor to show off fancy
       technology at an IETF, this audience runs and uses the most
       arcane assortment of services, and is a very poor place to find
       out that your fancy new switch breaks when someone tries to run
       IPv42 through it.  Run a simple production network.  If one must
       run a technology demo, isolate it onto a separate network segment
       so that it is unable to interfere with the production network.

   3.14 Failed Technology

       Two attempts have been made to use ATM LAN Emulation, aka LANE,
       as the primary backbone protocol connecting all ethernet switches
       and routers at IETF meetings.  Both attempts were disasters.

N. Bourbaki                Expires 2002.12.13                  [Page 11]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

       Some have asserted that IETF traffic patterns are unusually
       unsuited to LANE.  You MUST NOT try to use LANE.

4. Computer Systems

   Some users prefer UNIX and X11, while others prefer MS-Windows or
   Macintosh.  Many users are agnostic.  But UNIX and Linux bigotry is
   increasing.  The number of laptops is increasing, and a large number
   (circa 20) 802.11b wireless base stations are now regularly available
   for IETF meetings.  So the need for supplied desktop systems seems to
   be declining markedly.

   Its preferred that the terminal room support multiple platforms,
   though there have been successful terminal rooms with only one system
   or the other.  Macintosh users tend to being their own systems and so
   Mac systems need not be supplied in the terminal room.  Some folk
   need commercial tools (MS-PowerPoint, StarOffice, WordPerfect, etc.)
   to prepare presentations.

   Approximately one workstation per 40 attendees is more than adequate.
   The percentage of laptop users within the community has continued to
   increase to the extent that we now believe that approximately one
   desktop system per 30 or more attendees is sufficient.  Some months
   before the meeting, the IETF Secretariat gives the local host an
   estimate of the number of attendees.

   4.1 Desktop Software

       All provided desktops need at least the following:
          standards-compliant web browser
          SSHv1 client
          X11 server (i.e. the user/display portion)
          Telnet client
          FTP client

       It is very helpful if the following are also provided:
          One-Time Passwords (OTP) [RFC-2289] generator
          Adobe Acrobat (PDF) reader
          miscellaneous other plug-ins for the web browser

   4.2 Presentation Tools

       A dozen desktops with presentation software applications SHOULD
       be provided for those very few <smirk> working on presentations
       at the last moment in full panic.  These SHOULD have floppy
       drives for folk who must use sneaker-net to move files around.

N. Bourbaki                Expires 2002.12.13                  [Page 12]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

   4.3 Environmental

        Air conditioning for the entire terminal room SHOULD be
       sufficient for the time of year, the heat load from the machines,
       and a lot of people.

5. Documentation

   As the users' needs mature, so do their expectations of
   documentation.  It is helpful to document information about the
   terminal room and LAN facilities before the meeting on the IETF
   meeting web page.  A summary should be provided in the registration
   packet.  Full updated information should be posted in the terminal

   5.1 Address Plan

       Some weeks before the meeting, the network prefixes (with
       netmask) to be used SHOULD be announced on the IETF Announce
       list.  This allows users with security issues to have their home
       networks adjusted if necessary.

   5.2 Handout

       A single-page document SHOULD be included in the attendees'
       registration packets explaining the network layout, addressing,
       workstation facilities, printing facilities, LPR parameters, NTP
       parameters, SMTP parameters, wireless parameters, et cetera.

   5.3 Opening Session

       A short presentation on the terminal room and wireless LAN
       arrangements is usually given by the local host at the opening

   5.4  IETF Documentation

       A full on-site mirror of the RFC and I-D directories will lower
       demand on the circuits as well as the associated servers.  The
       address of the mirror should be stated loudly in all
       documentation.  It is also helpful to post this in the terminal
       room.  An ftp-accessible or http-accessible on-site repository is
       desirable, even if one is using a caching web proxy of some sort.

6. Security Considerations

   As in most computer facilities, physical as well as network security
   is important.

N. Bourbaki                Expires 2002.12.13                  [Page 13]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

   6.1 Physical Security

       Physical security is difficult, with attendees walking in and out
       with laptops and other gear at all hours.  The guards SHOULD be
       told to expect strange things, but to not let large equipment
       walk out without a green badge.  Equipment has been "lost" in the
       past just before, during, or just after an IETF.

       Secure on-site storage for boxes and equipment makes life a lot

   6.2 Network Security

       Network security is traditional, see the Site Security Handbook
       [RFC2196].  The IETF network has been attacked from the outside a
       number of times.  The risk of attack on the IETF network seems to
       rise over time.  The IETF network SHOULD be configured to perform
       source IP address filtering in accordance with [RFC-2267].  Any
       SMTP servers configured with mail relay enabled, SHOULD disable
       relaying from outside the IETF network.  Enabling MD5
       authentication of any routing protocols in use (e.g. RIPv2,
       OSPFv2, BGP4) is recommended to reduce risk of a routing-based

       There have been exciting incidents where laptop users have
       inadvertantly run DHCP servers, started forwarding packets on the
       same wire, etc.  If each computer drop (desktop or laptop) is on
       its own switched port, it aids in both finding the culprit and in
       rapidly reconfiguring for damage mitigation.  It can be helpful
       if the switches have port filtering and RMON capabilities.

       It is believed that written warnings to users against these
       dangerous configurations are both prudent and ineffective.

7. Prudence

   Spares of all critical components, workstations, switches, routers,
   etc. SHOULD be on-site.  "A fool and their data are soon parted." --
   M Williams

8. References

   [IEEE-99a] IEEE, Information Technology -- Telecommunications and
              information exchange between systems -- Local and
              metropolitan area networks Part 11: Wireless LAN Medium
              Access Control (MAC) and Physical Layer (PHY)
              specifications.  ISBN 0-7381-1658-0, 1999.

N. Bourbaki                Expires 2002.12.13                  [Page 14]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

   [IEEE-99b] IEEE, Information Technology -- Telecommunications and
              information exchange between systems -- Local and
              metropolitan area networks Part 11: Wireless LAN Medium
              Access Control (MAC) and Higher-speed Physical Layer (PHY)
              extension in the 2.4 GHz band, ISBN 0-7381-1809-5, 1999.

   [JARGON]   E. Raymond (Editor), The New Hacker's Dictionary, MIT
              Press, September 1996.  ISBN 0-262-68092-0.  Also,

   [RFC-1179] L. McLaughlin, Line Printer Daemon Protocol, RFC-1179,
              August 1990.

   [RFC-1305] D. Mills, Network Time Protocol version 3, RFC-1305, March

   [RFC-1769] D. Mills, Simple Network Time Protocol (SNTP), RFC-1769,
              March 1995.

   [RFC-2131] R. Droms, Dynamic Host Configuration Protocol (DHCP),
              RFC-2131, March 1997.

   [RFC-2132] S. Alexander & R. Droms, DHCP Options and BOOTP Vendor
              Extensions, RFC-2132, March 1997.

   [RFC-2196] B. Fraser, Site Security Handbook, RFC-2196, September

   [RFC-2236] B. Fenner, Internet Group Management Protocol version 2,
              RFC-2236, November 1997.

   [RFC-2267] P. Ferguson, Network Ingress Filtering: Defeating Denial
              of Service Attacks which employ IP Source Address
              Spoofing, RFC-2267, January 1998.

   [RFC-2289] N. Haller, A One-Time Password System (OTP), RFC-2289,
              February 1998.

   [RFC-2322] Management of IP numbers by peg-dhcp. K. van den Hout, A. Koopal,
              R. van Mook, RFC-2322, April 1998.

   [RFC-2460] S. Deering & R. Hinden, IP version 6 Specification,
              RFC-2460, December 1998.

   [RFC-2461] T. Narten et alia, Neighbor Discovery for IPv6, RFC-2461,
              December 1998.

   [RFC-2462] S. Thomson & T. Narten, IPv6 Stateless Address

N. Bourbaki                Expires 2002.12.13                  [Page 15]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13

              Autoconfiguration, RFC-2462, December 1998.

   [RFC-2463] S. Deering, Internet Control Message Protocol for IPv6,
              RFC-2463, December 1998.

9. Acknowledgments

   The author is indebted for very constructive contributions by a
   number of IETF local hosts, the IETF Secretariat, a NANOG local host,
   some operators of large networks, a Dutch geek, an amateur linguist,
   and of course Mr. (sorreeee) Wireless.

10. Author's Address

    N. Bourbaki
    666 Rue le Jour

11. Specification of Requirements

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    document are to be interpreted as described in RFC 2119.

12. Full Copyright Statement

    Copyright (C) The Internet Society (2000).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph
    are included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an

N. Bourbaki                Expires 2002.12.13                  [Page 16]

INTERNET-DRAFT  IETF Meeting Network Infrastructure Lore      2002.06.13


N. Bourbaki                Expires 2002.12.13                  [Page 17]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/