Struct etherparse::Ipv6Extensions [−][src]
pub struct Ipv6Extensions {
pub hop_by_hop_options: Option<Ipv6RawExtensionHeader>,
pub destination_options: Option<Ipv6RawExtensionHeader>,
pub routing: Option<Ipv6RoutingExtensions>,
pub fragment: Option<Ipv6FragmentHeader>,
pub auth: Option<IpAuthenticationHeader>,
}
Expand description
IPv6 extension headers present after the ip header.
Currently supported:
- Authentication Header
- Hop by Hop Options Header
- Destination Options Header (before and after routing headers)
- Routing Header
- Fragment
- Authentication Header
Currently not supported:
- Encapsulating Security Payload Header (ESP)
- Host Identity Protocol (HIP)
- IP Mobility
- Site Multihoming by IPv6 Intermediation (SHIM6)
Fields
hop_by_hop_options: Option<Ipv6RawExtensionHeader>
destination_options: Option<Ipv6RawExtensionHeader>
routing: Option<Ipv6RoutingExtensions>
fragment: Option<Ipv6FragmentHeader>
auth: Option<IpAuthenticationHeader>
Implementations
Reads as many extension headers as possible from the slice.
Returns the found ipv6 extension headers, the next header ip number after the read headers and a slice containing the rest of the packet after the read headers.
Note that this function can only handle ipv6 extensions if each extension header does occur at most once, except for destination options headers which are allowed to exist once in front of a routing header and once after a routing header.
In case that more extension headers then can fit into a Ipv6Extensions
struct are
encountered, the parsing is stoped at the point where the data would no longer fit into
the struct. In such a scenario a struct with the data that could be parsed is returned
together with the next header ip number and slice containing the unparsed data.
It is in the responsibility of the caller to handle a scenario like this.
The reason that no error is generated, is that even though according to RFC 8200 packets “should” not contain more then one occurence of an extension header the RFC also specifies that “IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet”. So packets with multiple headers “should” not exist, but are still valid IPv6 packets. As such this function does not generate a parsing error, as it is not an invalid packet, but if packets like these are encountered the user of this function has to themself decide how to handle packets like these.
The only exception is if an hop by hop header is located somewhere else then directly at
the start. In this case an ReadError::Ipv6HopByHopHeaderNotAtStart
error is generated as
the hop by hop header is required to be located directly after the IPv6 header according
to RFC 8200.
Reads as many extension headers as possible from the reader and returns the found ipv6 extension headers and the next header ip number.
If no extension headers are present an unfilled struct and the original first_header
ip number is returned.
Note that this function can only handle ipv6 extensions if each extension header does occur at most once, except for destination options headers which are allowed to exist once in front of a routing header and once after a routing header.
In case that more extension headers then can fit into a Ipv6Extensions
struct are
encountered, the parsing is stoped at the point where the data would no longer fit into
the struct. In such a scenario a struct with the data that could be parsed is returned
together with the next header ip number that identfies which header could be read next.
It is in the responsibility of the caller to handle a scenario like this.
The reason that no error is generated, is that even though according to RFC 8200, packets “should” not contain more then one occurence of an extension header, the RFC also specifies that “IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet”. So packets with multiple headers “should” not exist, but are still valid IPv6 packets. As such this function does not generate a parsing error, as it is not an invalid packet, but if packets like these are encountered the user of this function has to themself decide how to handle packets like these.
The only exception is if an hop by hop header is located somewhere else then directly at
the start. In this case an ReadError::Ipv6HopByHopHeaderNotAtStart
error is generated as
the hop by hop header is required to be located directly after the IPv6 header according
to RFC 8200.
Writes the given headers to a writer based on the order defined in the next_header fields of the headers and the first header_id passed to this function.
It is required that all next header are correctly set in the headers and no other ipv6 header
extensions follow this header. If this is not the case a ValueError::Ipv6ExtensionNotReferenced
Length of the all present headers in bytes.
Sets all the next_header fields of the headers based on the adviced default order with the given protocol number as last “next header” value. The return value is the protocol number of the first existing extension header that should be entered in the ipv6 header as next_header.
If no extension headers are present the value of the argument is returned.
Return next header based on the extension headers and the first ip protocol number.
Trait Implementations
Returns the “default value” for a type. Read more
This method tests for self
and other
values to be equal, and is used
by ==
. Read more
This method tests for !=
.
Auto Trait Implementations
impl RefUnwindSafe for Ipv6Extensions
impl Send for Ipv6Extensions
impl Sync for Ipv6Extensions
impl Unpin for Ipv6Extensions
impl UnwindSafe for Ipv6Extensions
Blanket Implementations
Mutably borrows from an owned value. Read more