RAW套接字收包IPv6无法携带头部信息重要么

结论

RAW套接字收IPv6报文无法获取IPv6头部信息,可能没有想象中的那么严重。

您甚至可以完美地伪造头部信息出来!

澄清常见使用误解

网络协议 IP_HDRINCL or IPV6_HDRINCL recvfrom携带IPv*头部字段
IPv4
IPv4
IPv6
IPv6

无论您是否设定IP_HDRINCL,IPv4 RAW Socket固定可以在收包时,携带IPv4的头部信息给用户;但,IPv6的RAW Socekt,无论设定,还是不设定IPV6_HDRINCL套接字选项,都无法携带完整的头部字段出来!

虽然,在Linux 4.5的内核以后,内核就支持了IPV6_HDRINCL的宏定义和套接字选项操作,但是,它也并不是为了支持收包时携带完整的IPv6头部信息出来。

在Ubuntu 20.04版本上试验,IPv6设定选项后,依然无法收取IPv6头出来

无论是IP_HDRINCL,还是IPV6_HDRINCL套接字选项,更侧重于发包时的使用,对于收包影响没有那么大。

IPPROTO_RAW

生成IPPROTO_RAW协议号的RAW套接字,暗含着IP_HDRINCL的操作语义;但是,IPPROTO_RAW类型的RAW套接字仅是sendOnly发送套接字,并不能指望它能够收取任意协议的IP报文

设定IP_HDRINCL无法分片的BUG

设定IP_HDRINCL套接字选项,或生成IPPROTO_RAW类型的RAW套接字,都会导致报文消息无法正确分片的bug。即使在IPv6的RAW Socket实现中,IPV6_HDRINCL依然保持了这种一致性,以至于都可以认为它要成为一个众说周知的特性!

RAW Socket在收包时,无论是否设定IP_HDRINCL or IPV6_HDRINCL套接字选项,支持分片的重组操作

如何支持发送时分片

  • 尽量不设定IP_HDRINCL套接字选项,或使用IPPROTO_RAW类型的RAW套接字
  • 做用户层面的自主分片;但如果需要非常高的正确性、可靠性,就要考虑路径MTU探测问题,而不单是考虑网卡上设定的MTU

RAW套接字,几乎可以支撑起微型化核心网发送平面的所有工作

IPv6收报无法携带头部字段的解决方法

伪造头部信息

伪造的头部在很大程度上,可以完美复原,并不需要担心太多!

理论分析

IPv6头部格式

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
typedef struct _IPv6_HEADER_t 
{
 union
 {
   uint8_t abVTF[4]; //版本信息最高4位 traffic class、flow label
   uint32_t dwVTF;  //低20 bits Flow Label信息
 };
 
 uint16_t u16PayloadLen; //数据包长度
 uint8_t  bNextHeader; //数据包标识
 uint8_t  bHopLimit; // max hop limit

 union 
 {
    uint8_t   abSrcAddr[16];
    u_int32_t au32SrcAddr[4];
    u_int64_t au64SrcAddr[2];
 };

 union 
 {
    uint8_t   abDstAddr[16];
    u_int32_t au32DstAddr[4];
    u_int64_t au64DstAddr[2];
 };
 
} __attribute__((packed)) IPv6_HEADER_t, *IPv6_HEADER_t_Ptr;

分析

通过阅读IPv6的rfc规范,在IPv6头部信息中比较重要的是flow labeltraffic class。对于要求不高的网络层处理,和其上层应用来说,其他头域信息可以完美推导出来,例如,下个头的协议号、源地址、目的地址;或无关紧要,例如,报文限制的最大跳数。

在IPv6 rfc规范中flow label认为可以在源和目的之间,结合源地址、目的地址、流标签形成某种三元组管理;但,traffic class头域就没有那么重要了,被界定为网络层使用,且规范认为,即使在收包时能够获取到此字段信息,也不能认为此字段和源头一模一样,所以,重要的信息就只剩下flow label了。

The 8-bit Traffic Class field in the IPv6 header is used by the network for traffic management. The value of the Traffic Class bits in a received packet or fragment might be different from the value sent by the packet’s source.

好的福音是,对于flow label的信息,我们可以在socket send/recv套接字接口的struct sockaddr_in6地址参数中进行设定或获取,所以,flow label信息也可以完美恢复出来!

struct sockaddr_in6 {
    sa_family_t     sin6_family;   /* AF_INET6 */
    in_port_t       sin6_port;     /* port number */
    
    uint32_t        sin6_flowinfo; /* IPv6 flow information */
    
    struct in6_addr sin6_addr;     /* IPv6 address */
    uint32_t        sin6_scope_id; /* Scope ID (new in 2.4) */
};

以我个人的猜测,IPv6收报时不携带头部字段,可能是觉得无需携带,因为IPv6头部信息比较标准和简单,可以比较无损地恢复出来;或被遗忘了,忘记与IPv4保持一致性了。。。

特别的隧道应用

如果您是终点应用,IPv6头部信息,除了flow label信息外,都可以不用关心;但对于中间节点应用,特别是隧道应用,就会担心如果不是原始的头部信息,擦除了flow label等信息,可能会存在一些风险。

分析来看,IPv6 RAW Socket收取报文,无法携带完整头部确实存在那么一点风险,但通过对于rfc规范的研读,以及完美地恢复出和源紧密相关的头部flow label信息,即使再次伪造出头部,一样可以完成任务!

参考

  • man 7 raw
  • man 7 ipv6
  • IPv6 Specification
  • IPv6 Flow Label Specification

你可能感兴趣的:(网络,笔记,IP_HDRINCL,IPV6_HDRINCL,分片,fragment,RAW,Socket)