blank.gif (43 bytes)

Church Of The
Swimming Elephant

8.2 Community Table Connected: An Internet Encyclopedia
8.2 Community Table

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1812
Prev: 8.1.1 SNMP Protocol Elements
Next: 8.3 Standard MIBS

8.2 Community Table

8.2 Community Table

For the purposes of this specification, we assume that there is an abstract `community table' in the router. This table contains several entries, each entry for a specific community and containing the parameters necessary to completely define the attributes of that community. The actual implementation method of the abstract community table is, of course, implementation specific.

A router's community table MUST allow for at least one entry and SHOULD allow for at least two entries.


A community table with zero capacity is useless. It means that the router will not recognize any communities and, therefore, all SNMP operations will be rejected. Therefore, one entry is the minimal useful size of the table. Having two entries allows one entry to be limited to read-only access while the other would have write capabilities.

Routers MUST allow the user to manually (i.e., without using SNMP) examine, add, delete and change entries in the SNMP community table. The user MUST be able to set the community name or construct a MIB view. The user MUST be able to configure communities as read-only (i.e., they do not allow SETs) or read-write (i.e., they do allow SETs).

The user MUST be able to define at least one IP address to which notifications are sent for each community or MIB view, if traps are used. These addresses SHOULD be definable on a community or MIB view basis. It SHOULD be possible to enable or disable notifications on a community or MIB view basis.

A router SHOULD provide the ability to specify a list of valid network managers for any particular community. If enabled, a router MUST validate the source address of the SNMP datagram against the list and MUST discard the datagram if its address does not appear. If the datagram is discarded the router MUST take all actions appropriate to an SNMP authentication failure.


This is a rather limited authentication system, but coupled with various forms of packet filtering may provide some small measure of increased security.

The community table MUST be saved in non-volatile storage.

The initial state of the community table SHOULD contain one entry, with the community name string public and read-only access. The default state of this entry MUST NOT send traps. If it is implemented, then this entry MUST remain in the community table until the administrator changes it or deletes it.


By default, traps are not sent to this community. Trap PDUs are sent to unicast IP addresses. This address must be configured into the router in some manner. Before the configuration occurs, there is no such address, so to whom should the trap be sent? Therefore trap sending to the public community defaults to be disabled. This can, of course, be changed by an administrative operation once the router is operational.

Next: 8.3 Standard MIBS

Connected: An Internet Encyclopedia
8.2 Community Table


Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

Have you gone to church today?
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609