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

[src]

impl Ipv6Extensions

[src]

pub fn from_slice(
start_ip_number: u8,
slice: &[u8 ]
) -> Result<(Ipv6Extensions, u8, &[u8 ]), ReadError>

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.

[src]

pub fn read<T: Read + Seek + Sized>(
reader: &mut T,
start_ip_number: u8
) -> Result<(Ipv6Extensions, u8 ), ReadError>

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.

[src]

pub fn write<T: Write + Sized>(
 &self,
 writer: &mut T,
 first_header: u8
) -> Result<(), WriteError>

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

[src]

pub fn header_len(&self) -> usize

Length of the all present headers in bytes.

[src]

pub fn set_next_headers(&mut self, last_protocol_number: u8) -> u8

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.

[src]

pub fn next_header(&self, first_next_header: u8) -> Result<u8, ValueError>

Return next header based on the extension headers and the first ip protocol number.

[src]

pub fn is_fragmenting_payload(&self) -> bool

Returns true if a fragmentation header is present in the extensions that fragments the payload.

Note: A fragmentation header can still be present even if the return value is false in case the fragmentation headers don’t fragment the payload. This is the case if the offset of all fragmentation header is 0 and the more fragment bit is not set.

[src]