1、协商的报文整体观察

从整体上出发，L2TP的协商被我的红框分为上面几个步骤，首先是客户端向服务端发送RQ隧道协商请求，然后服务端回复，最后客户端再确认，这个阶段完成后会协商出一个隧道ID。然后就是会话协商，也是三次数据包的交互，最后协商出一个会话ID。然后就是PPP协议中的LCP协商，到CHAP的认证，到最后的IPCP网络层地址协商。

2、L2TP的协商

SCCRQ报文：

其实和大部分的协商请求报文类似，无非是协商一些版本一些控制参数，Host Name就是客户端的标识符，这样虽然LNS上可能配置了多个l2tp隧道，这样就可以知道使用什么配置用于回应，Assigned Tunnel ID就是用于双方的隧道ID的协商的一个字段，Challenge这个主要就是用于隧道验证，它将我们的隧道密码和Hash函数结合在一起，比较简单的一种验证方式就i是将密码与盐做hash计算，然后交给服务端，服务端如果计算出来的hash值是相同的，那么就验证通过。其他就是一些用于拨号网络什么的控制参数，无伤大雅。

SCCRP报文： 

可以看到在SCCRP报文中还多了一个Challenge Response的字段，它和Challenge字段共同用于隧道的身份验证。

SCCCN报文：

 这是隧道ID协商的最后一个报文，主要起确认作用，里面的信息不是很多。

ICRQ报文：

会话ID协商请求报文

ICRP报文：

会话ID协商响应报文

ICCN报文：

可以看见在确认包中确认了相关的隧道ID和会话ID

所以总共经过六个包的协商协商了一些L2TP上的控制参数，隧道认证以及隧道ID和会话ID的确认。后续的传输报文就使用这些确定的控制参数，隧道ID以及会话ID进行数据传输。