refactor: move mandatory attribute validation after NLRI parsing (RFC 4760)

[digizeph]

Summary

Complete refactoring of BGP mandatory attribute validation to properly handle RFC 4760 (MP-BGP) "conditionally mandatory" semantics. The validation now occurs after NLRI parsing, enabling context-aware checks that eliminate false positives without introducing false negatives.

Breaking Change

parse_attributes() signature change: The function now returns a tuple (Attributes, [bool; 256]) where the second element tracks which attribute types were seen during parsing. This enables proper mandatory attribute validation after NLRI context is known.

RFC Compliance

RFC 4271 (BGP-4)

• ORIGIN and AS_PATH: required for any announcement
• NEXT_HOP: required when IPv4 NLRI is present

RFC 4760 (Multiprotocol Extensions)

• Section 3: MP_REACH_NLRI carries embedded next hop; no separate NEXT_HOP attribute needed when only MP prefixes are announced
• Section 4: Withdrawal-only messages (MP_UNREACH_NLRI only) require no attributes

Changes

Core Changes

• parse_attributes(): Now returns (Attributes, seen_attributes) tuple; removed inline mandatory validation
• validate_mandatory_attributes(): New public function that performs context-aware validation after NLRI parsing
• parse_bgp_update_message(): Calls validation after NLRI parsing with full context (has_ipv4_nlri, has_mp_reach_nlri, has_mp_unreach_nlri)

Test Updates

• Updated all test functions to handle new tuple return
• Renamed test_rfc7606_missing_mandatory_attribute to test_mandatory_attributes_validation with comprehensive NLRI context scenarios
• Updated RFC 4760 tests to use validation function directly

MRT Parsers

• Updated MRT RIB and table dump parsers to handle new tuple return (no validation performed for MRT dumps, as expected)

Validation Logic

// After NLRI parsing, we now know:
let has_announcements = has_ipv4_nlri || has_mp_reach_nlri;

if !has_announcements {
    // Withdrawals only - no mandatory attributes (RFC 4760 Section 4)
    return;
}

// ORIGIN and AS_PATH always required for announcements
if !has_origin { warn!(); }
if !has_as_path { warn!(); }

// NEXT_HOP only required for IPv4 NLRI (RFC 4271)
if has_ipv4_nlri && !has_next_hop { warn!(); }
// Note: RFC 4760 Section 3 - MP_REACH_NLRI has embedded next hop

Testing

All existing tests pass. Validation now correctly handles:

• ✅ IPv4-only announcements: requires ORIGIN, AS_PATH, NEXT_HOP
• ✅ MP-only announcements: requires ORIGIN, AS_PATH (no NEXT_HOP)
• ✅ Mixed IPv4+MP announcements: requires all three
• ✅ Withdrawals only: no mandatory attributes required

Files Changed

• src/parser/bgp/attributes/mod.rs - Core validation logic
• src/parser/bgp/messages.rs - UPDATE parsing with post-NLRI validation
• src/parser/mrt/messages/table_dump_v2/rib_afi_entries.rs - Handle tuple return
• src/parser/mrt/messages/table_dump.rs - Handle tuple return
• CHANGELOG.md - Document breaking change and fix

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.55%. Comparing base (632bbe7) to head (aa37708).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #280      +/-   ##
==========================================
+ Coverage   90.53%   90.55%   +0.01%     
==========================================
  Files          84       84              
  Lines       15835    15847      +12     
==========================================
+ Hits        14336    14350      +14     
+ Misses       1499     1497       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[digizeph]

prefer #281 implementation.