MOBIKE----IKEv2 Mobility and Multihoming Protocol

想要解决的问题：当客户端的IP地址（隧道封装模式的外层IP）或者服务端的IP地址有变化时，不重新协商就能工作。
场景：客户端是一个移动设备，从一个接入点换到另一个接入点；服务端提供多种接入方式：有线或无线，直接切换。
为什么不直接重建呢？因为有时候认真比较麻烦，比如需要密钥令牌，总是切换会让用户很烦吧。
限制：只能是隧道模式，且两遍必须有一边IP是不变的。在nat的情况下，只能发起端处在nat设备之后。
对NAT的特殊处理。如果双方都支持MOBIKE和NAT，那么一开始就要转为4500，这样的话，如果后面的路径上有NAT就
不用再换了。

一些可能导致地址切换的原因：
1、控制面重传失败
2、一个包含ADDITIONAL_IPV*_ADDRESS的通知载荷，或包含NO_ADDITIONAL_ADDRESSES的通知载荷。
3、作为请求响应，一个UNACCEPTABLE_ADDRESSES的通知载荷。即发起方应该重新选一个地址。
4、发起方收到一个NAT_D通知消息，里面的地址和之前提供的UPDATE_SA_ADDRESSES的回应里不一致。

当发起方决定要更新地址了，需要做如下事情：
1、用新地址更新IKE_SA，并将IKE_SA设置为挂起更新状态（pending_update）
2、更新IPsec SAs的地址。注意，如果发起方的策略里要求新地址的可路由性检查，那么需要做了检查后才能更新。
3、如果上述的IPsecSAs更新完毕，那么再做如下操作：如果没有启用NAT穿越，并且接收方支持NAT穿越，发起方
如果知道或者怀疑可能有NAT，那么就启用NAT穿越。---？？？这个不太明白哦，猜测是只要接收方支持，那么就用NAT-T。
4、如果还有未得到响应的IKEv2的请求，继续重传。
5.。。。

作为接收方。。。。

MOBIKE里的安全考虑
1、NAT穿越导致的重定向、中间人攻击，这个其实原先IKE就有，只不过MOBIKE里增加了一个不允许使用NAT的通知载荷。
2、IPsec载荷的安全性，原先只需要针对协商的双方地址的流进行保护，引入MOBIKE后，针对保护的流的外层地址会发生变化，这个
需要额外的处理。
3、第三方的拒绝服务攻击。这个看不出MOBIKE的区别。。。
4、欺骗网络连接。这个对选择更新地址的方法有关系，是有可能导致不断地换地址，但这个不在MOBIKE协商的考虑层面。
5、地址和网络拓扑的暴露。由于IKE外层协商 IP地址不被包含，地址换来换去确实是有可能暴露地址信息和拓扑信息。
此外，协商消息中的ADDITIONAL地址可能会暴露其他网络的信息。具体看RFC