Handle malformed attributes without inventing trust
07RFC 7606 updates community error handling. A recognized community attribute with an invalid value length is not the same as an unfamiliar, well-formed tag.
The attribute-length rule also rejects zero. This bounded illustration does not parse a full UPDATE or turn a community into proof of route ownership.
Source for this drawing: RFC 1997 · Read RFC source: COMMUNITIES format · p.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A community value length must be a nonzero multiple of four; a malformed Community attribute uses treat-as-withdraw. This is not a universal rule for every BGP parse failure.
Read the updated RFC section ↗RFC 7606 §7.8: the community attribute SHALL be considered malformed if its length is not a non-zero multiple of four. An UPDATE with it SHALL use treat-as-withdraw.
- RFC 7606 §7.8: the community attribute SHALL be considered malformed if its length is not a non-zero multiple of four. An UPDATE with it SHALL use treat-as-withdraw.
- Treat-as-withdraw removes affected UPDATE routes instead of automatically resetting the session, assuming their network-layer reachability information (NLRI) can otherwise be parsed. If it cannot, RFC 7606 §3(j) retains session-reset or AFI/SAFI-disable procedures. This bounded scene does not parse a full UPDATE.
- A well-formed ordinary value with unknown local meaning is not malformed merely for being unfamiliar. Its acceptance and use depend on policy.
- Four-octet community tags are not signatures, encryption or authorization proofs. RFC 1997 itself does not discuss security; these pictures make no route-origin validation claim.
Fictional routes and private AS numbers. These are bounded teaching examples, not a complete BGP implementation. Display a tag as AS:local only to help read its two 16-bit parts; the wire contains four octets.
Read the RFC section ↗