Question

我正在尝试解码基于RFC 5389的STUN成功响应：

如果IP地址系列是IPv6，则通过获取映射的IP地址来计算X地址在主机字节顺序中，与魔术的串联进行异或 cookie和96位事务ID，并将结果转换为网络字节顺序。

Magic cookie是一个常量，它是0x2112A442。

我的情况下的交易ID是：0x6FA22B0D9C5F5AD75B6A4E43。

主机字节顺序中的我的X地址（IPv6）是：

0x034A67D82F4B3657B193039A8BA8FDA1

我是否需要xor Host Byte Order X-Address以及网络或主机字节顺序中Magic Cookie和Transaction ID的串联？

在第一种情况下，网络字节顺序连接等于：

0x2112A442 6FA22B0D9C5F5AD75B6A4E43

第一个字节0x03的xored为0x21，最后一个字节0xA1的xored为0x43

但在第二种情况下，Host Byte Order连接是：

0x434E6A5BD75A5F9C0D2BA26F 42A41221

第一个字节0x03的xored为0x43，最后一个字节0xA1的xored为0x21。

另一种可能的行为是，它将魔术cookie和事务ID分别转换为主机字节顺序，但它会连接它们，保留标题顺序：

0x42A41221 434E6A5BD75A5F9C0D2BA26F

第一个字节0x03的xored为0x42，最后一个字节0xA1的xored为0x6F。

Answer 1

一切都在网络字节顺序中完成。

但是，对于IPv6地址，“主机字节顺序”和“网络字节顺序”之间没有区别。 IPv6地址始终被理解为16字节的数组。并且单个字节没有“字节顺序”。在“C”代码中，我们只是将IPv6地址表示为：

 unsigned char ipv6address[16];

或者就sockaddr_in6结构而言;

 struct sockaddr_in6 addr;
 unsigned char* ipv6addresss = addr.sin6_addr.s6_addr; // points to a sequence of 16 bytes

与IPv4形成对比，后者通常在代码中作为32位整数传递。在IPv4情况下，您经常需要调用htonl和ntohl函数。

除非您正在将IPv6地址维护为8个16位整数而不是数组字节的数组，否则您不必过多地考虑字节序和字节顺序。（事实上，我建议你不要考虑16字节ip地址的字节顺序。）

示例：

我的IPv6地址是：

2001:0000:9d38:6abd:347d:0d08:3f57:fefd

作为十六进制字节的数组，逻辑上写为：

200100009d386abd347d0d083f57fefd

当我的STUN服务器收到来自此IPv6地址的绑定请求时，它会应用以下XOR操作来发送回XOR-MAPPED-ADDRESS。我们假设它与您的事务ID相同，它包含表示RFC 5389支持的神奇cookie（2112A442 6FA22B0D9C5F5AD75B6A4E43）

XOR:
     200100009D386ABD347D0D083F57FEFD
     2112A4426FA22B0D9C5F5AD75B6A4E43

结果：

     0113A442F29A41B0A82257DF643DB0BE

类似地，接收STUN绑定响应的客户端对具有相同事务ID的此字节数组应用反XOR运算。

XOR:
     0113A442F29A41B0A82257DF643DB0BE
     2112A4426FA22B0D9C5F5AD75B6A4E43

结果：

     200100009D386ABD347D0D083F57FEFD

如果有助于提供如何应用xor映射操作的示例，则可以将源代码引用到Stuntman。 XOR操作是here on GitHub。这里的代码不区分具有魔术cookie的事务ID和不具有魔术cookie的事务ID。它只是将事务id视为16字节的逻辑序列。

以上内容负责IPv6地址。但是，如果将16位端口值视为short或16位整数，则必须将字节翻转。在C代码中，通常通过调用ntohs来处理。