see also:http://www.tcpipguide.com/free/t_IPSecAuthenticationHeaderAH-3.htm
1.为什么需要IPSEC
原因：因为常规的IP协议没有提供认证，数据校验和加密。
让我们来看看IP包头。最小的IP包只是有20个byte.其中16bit的Header checksum是用来对包头（不包括后面的数据）做
校验用。以供传输过程中错误侦测。没传输到一个中间路由器，就会计算checksum,如何和header checksum里面的不一致，
那这个包就要被丢弃。
Checksum的计算方法，定义在RFC 1071.
计算实例：
说简单点就是把包头20个byte,每2个byte为一组数字相加。check sum 那2个byte算做0去加。
最后求1的反码得到的就是checksum,然后将这个checksum插入到header checksum中去。
另外，因为包头中的TTL字段数值每经过一个路由会减少，所以checksum在每个路由器那里都会
重新计算然后改写到IP包里头。
接收包的一段只需要按同样的算法计算checksum并与包内的checksum数值比较即可知道数据是否完整。
这个算法是透明的，只是供传输错误校验用，因此起不到对IP包数据源验证的作用。任何中间节点都可以
修改IP包头然后计算出正确的checksum改写源包。
这时候，人们就发明了IPSEC AH 和 ESP.
AH提供：connectionless integrity，data authentication，optional replay protection，但是不提供confidentiality（加密）
ESP、AH对比
1、AH没有ESP的加密特性
2、AH的authtication是对整个数据包做出的，包括IP头部分，因为IP头部分包含很多变量，比如type of service（TOS），flags，fragment offset，TTL以及header checksum.所以这些值在进行authtication前要全部清零。否则hash会mismatch导致丢包。
相反，ESP是对部分数据包做authentication，不包括IP头部分。
IPsec 认证头协议（IPsec AH）是 IPsec 体系结构中的一种主要协议，它为 IP 数据报提供无连接完整性与数据源认证，并提供保护以避免重播情况。一旦建立安全连接，接收方就可能会选择后一种服务。 AH 尽可能为 IP 头和上层协议数据提供足够多的认证。但是，在传输过程中某些 IP 头字段会发生变化，且发送方无法预测当数据包到达接受端时此字段的值。 AH 并不能保护这种字段值。因此， AH 提供给 IP 头的保护有些是零碎的。
2.IPSEC AH是如何封包的。为什么要这样封包。
因为这样可以校验数据的完整性。
让我们来看一看原始的IP包，和传输模式的AH数据包，以及隧道模式的AH数据包是如何组包的。
如下图：
AH的运行模式其实和IP包头中的Checksum字段的运行原理差不多。
让我们来回顾一下IP包中的checksum的运行流程：
发送方用一个标准算法计算出包头的checksum值并在包中发送该值，接收方收到包后同样用这个算法计算出一个checksum值并对比收到的checksum值。
如果2者不匹配那么就丢弃包。
那么AH同样也是类似，只不过只是改换了一下方式，不使用对任何人都透明的标准算法，而是使用一个只有发送和接收方知道的
密钥和一个特别的HASH算法来生成一个"checksum"
接收和发送方会建立一个SA安全关联去协商这些具体细节，这样只有发送方和接收方知道如何去计算"checksum"
On the source device, AH performs the computation and puts the result (called the Integrity Check Value or ICV) into a special header with other fields for transmission. The destination device does the same calculation using the key the two devices share, which enables it to see immediately if any of the fields in the original datagram were modified (either due to error or malice).
It's important that I point out explicitly that just as a checksum doesn't change the original data, neither does the ICV calculation change the original data. The presence of the AH header allows us to verify the integrity of the message, but doesn't encrypt it. Thus, AH provides authentication but not privacy (that's what ESP is for
IPSec Authentication Header (AH) Format
ICV Computation for IPv4
IPSEC AH 计算ICV需要用到的字段：蓝色部分
3.3.3.1.1.1. Base Header Fields
The IPv4 base header fields are classified as follows:
Immutable
Version
Internet Header Length
Total Length
Identification
Protocol (This should be the value for AH.)
Source Address
Destination Address (without loose or strict source routing)
Mutable but predictable
Destination Address (with loose or strict source routing)
Mutable (zeroed prior to ICV calculation)
Differentiated Services Code Point (DSCP)
(6 bits, see RFC 2474 [NBBB98])
Explicit Congestion Notification (ECN)
(2 bits, see RFC 3168 [RFB01])
Flags
Fragment Offset
Time to Live (TTL)
Header Checksum
注意：AH计算ICV并没有包括TTL和header checksum,因为这2个值经常在传输过程中要被路由器改变。所以AH只将那些不经常
发送改变的部分加入了计算。
3. IPSEC AH为什么和NAT不兼容？
因为AH计算ICV的时候把source IP,des IP都放在一起计算了。
当到达NAT设备的时候，这些Source IP,Des IP会被改变。
那样的话，接收端算出来的ICV就会不一致了。会认为包被篡改了。
因此天生的AH无法和NAT兼容。