net: add RFC 8754 Segment Routing Header support

[ryskn]

Summary

I would like to add support for the IPv6 Segment Routing Header (SRH), as defined in RFC 8754.

The dataplane already has generic IPv6 Routing Header support in net/src/ipv6/routing.rs, currently backed by etherparse::Ipv6RawExtHeader. However, Routing Type 4 is currently treated as an opaque routing-header payload, so SRH-specific fields and validation are not exposed.

Proposed scope

For the initial implementation, I would like to keep this limited to the net crate and add SRH wire-format support only:

• identify IPv6 Routing Type 4 as an SRH
• parse and expose:
  • Segments Left
  • Last Entry
  • Flags
  • Tag
  • Segment List
• parse and preserve the optional TLV area
• serialize/deparse an SRH
• validate RFC 8754 constraints and malformed headers
• add unit/property/fuzz tests

I am considering keeping the existing generic Routing representation and adding a typed SRH view/representation on top of it, rather than making Routing itself SRv6-specific. This would preserve support for other and unknown IPv6 Routing Header types.

Conceptually:

IPv6 Routing Header
        |
        +-- Routing Type 4 -> Segment Routing Header
        |
        +-- other types    -> generic/raw Routing Header

SRv6 forwarding behaviours such as End, End.X, End.DT6, Local SID handling, and SR Policy would be out of scope for this initial change and could be implemented separately in the routing/pipeline layers.

Questions

Before starting the implementation, I would like to confirm:

1. Does this separation between generic Routing Header support and an SRH-specific representation fit the current net crate design?
2. Would a typed view over the existing raw routing-header representation be preferred, or should SRH be represented as a distinct owned type?
3. Are there any existing plans for SRv6 support that this should align with?

If this direction looks reasonable, I would be happy to send a PR implementing the initial RFC 8754 parsing/deparsing support.