1.标准GRE封装
GRE出现之前，很多早期的隧道封装协议已经出现。一些RFC已经被用来建议几个封装方法，例如在IP上封装IPX等。然而，与这些方法相比，GRE是一种最为通用的方法，也因而成为当前被各厂商普遍采用的方法。
GRE是一种在任意协议上承载任意一种其他协议的封装协议。顾名思义，GRE是为尽可能高的普遍适用性而设计的，它本身并不要求何时、何地、何种协议或实现应使用GRE，而只是规定了一种在一种协议上封装并传送另一种协议的通用方法。通过为不同的协议分配不同的协议号码，GRE可用于在绝大部分的隧道封装场合。
考虑一种最常见的情况——一个设备希望跨越一个协议A的网络发送B协议包到对端。称A为承载协议（delivery protocol），A的包为承载协议包（delivery protocol packet）；B为载荷协议（delivery protocol），B的包为载荷协议包（payload protocol packet）。
直接发送B协议包到协议A网络上是不可能的，因为A不会识别B数据。此时，设备须执行以下操作：
（1）首先设备需要将载荷包封装在GRE包中，也就是添加一个GRE头。
（2）再把这个GRE包封装在承载协议包中。
（3）设备便可以将封装后的承载协议包放在承载协议网络上传送。
图5.11 GRE协议栈
因为GRE头的加入也是一种封装行为，因此把GRE称为封装协议（encapsulation protocol），把经过GRE封装的包称为封装协议包（encapsulation protocol packet）。GRE不是唯一的封装协议，但或许是最通用的封装协议。
这个加入的GRE头本身就可以告诉目标设备“上层有载荷分组”，从而目标设备就可以做出不同于A协议标准包的处理。当然这还是不够的，GRE必须表达一些其他的信息，以便设备继续执行正确的处理。例如GRE头必须包含上层协议的类型，以便设备在解封装之后，可以把载荷分组递交到正确的协议栈继续处理，协议栈如图5.11所示。
RFC 1701定义的标准GRE头格式如图5.12所示。其中主要字段的含义如下：
（1）Flags and version（2octets） GRE标志位字段，位于前两个octet中，从第0位到第15位。其中第5到12位保留未使用，第13到15位保留作为Version field。这里仅介绍已定义的位。
图5.12 RFC 1701GRE头格式
（2）Checksum Present（bit 0） 这一位等于1说明GRE头中存在Checksum field。如果Checksum Present bit与Routing Present bit同时为1，则GRE头中同时存在Checksum field和Offset field。
（3）Routing Present（bit 1） 如果Routing Present bit设置为1，则说明GRE头中包含有Offset field和Routing field。
（4）Key Present（bit 2） 如果为1，则GRE头中存在Key field，否则不存在。
（5）Sequence Number Present（bit 3） 如果为1，则说GRE头中存在Sequence Number field。否则不存在。
（6）Strict Source Route（bit 4） 用于指示严格源路由选项。
（7）Recursion Control（bits 5—7） 用于控制领外的封装次数，通常应该设置为0。
（8）Version Number（bits 13—15） 对标准GRE封装来说，必须等于0。
（9）Protocol Type（2octets） 指示载荷包的协议类型。
（10）Offset（2octets） 从Routing field开始到第一个active Source Route Entry的偏移量。
（11）Checksum（2octets） GRE头与载荷包的校验和，用于确保数据的正确性。
（12）Key（4octets） 由封装设备加入的一个数字，可以用于鉴别包的源。
（13）Sequence Number（4octets） 由封装设备加入的一个无符号整数，可以用于明确数据包的次序。
（14）Routing（variable） 这是一个选项，仅当Routing Present bit设置为1时才出现。Routing field保扩，一组Source Route Entries（SREs）。
每个SRE格式如图5.13所示。每个SRE均表明了沿源路由路径上的一个节点。可以用于控制分组的实际传送路径。以运算代价、实现复杂性以及安全性考虑，此种选项实际上很少使用，所以本书不再讨论其中的各字段含义。
图5.13 RFC 1701SRE格式
GRE使用IANA定义的以太协议类型来标识载荷包的协议。
经过一段时间的实际使用和总结，GRE不断成熟和完善。RFC 2784终于规定了GRE的标准头格式。相对于之前的格式而言，这是一个经过极大简化的格式，它只保留了必须的字段。
RFC 2784规定的GRE头格式如图5.14所示。其主要字段含义如下：(www.xing528.com)
图5.14 RFC 2784GRE标准头格式
（1）Checksum Present（bit 0） 如果Checksum Present bit设置为1，则GRE头中存在Checksumfield和Reservedl field。
（2）Reserved0（bits 1—12） 必须为0。
（3）Version Number（bits 13—15） 版本号必须为0，表示标准GRE封装。
（4）Protocol Type（2octets） 指示载荷协议的类型。GRE使用RFC1700定义的以太协议类型指示上层协议的类型。
（5）Checksum（2octets） 对整个GRE头和载荷协议包的16位校验和。计算时Checksum field值设置为全零。
（6）Reserved1（2octets） 保留。
2.扩展GRE封装
出于对日益复杂的网络环境和应用的适应，RFC 2890对GRE进行了增强，形成了扩展GRE标准。
扩展的GRE头在原有GRE头格式基础上，增加了两个可选字段Key和Sequence Number，从而使GRE具备了标识数据流和分组次序的能力。GRE扩展头格式如图5.15所示
图5.15 GRE扩展头格式
其中的两个新增字段和新定义标志位解释如下：
（1）Key Present（bit 2） 如果设置为1，则说明GRE头中存在Key field，否则Key field不存在。
（2）Sequence Number Present（bit 3） 如果设置为1，则说明GRE头中存在Sequence Number field；否则Sequence Number field不存在。
（3）Key Field（4octets） 由执行封装的一方写入。用于标识一个数据流。
（4）Sequence Number（4octets） 由执行封装的一方写入，用于标识一个数据流中包的次序。数据流中第一个包的序列号值为0，之后不断递增。接收方因而可以了解到每一个数据包是否按照正确的次序到达。
3.以IP作为承载协议和载荷协议
由于IPv4协议的普遍使用，以IPv4作为承载协议或载荷协议的GRE值得我们重点关注。理解了GRE在IPv4环境下如何工作，也就可以了解在任意协议环境下GRE如何工作。
图5.16显示了以IP作为承载协议的GRE封装。
图5.16 以IP作为承载协议的GRE封装
图5.17 以IP作为载荷协议的GRE封装
在此封装形式下，链路层协议后面紧跟IPv4协议，然后IPv4用IP协议号47标识GRE头。同理，路由器处理IP报文时，当看到IP头中的Protocol字段值为47时，说明IP包头后面紧跟的是GRE头。
另外一种封装方法是以IP作为载荷协议的GRE封装，如图5.17所示。
图5.18 IP over IP的GRE封装
在此封装形式下，链路层协议后面紧跟着承载协议，之后是GRE，然后再跟着IP报文。在GRE报文中，GRE Protocol Type值为0x800，指明GRE报文中封装的是IP报文。
在以IP作为载荷协议的GRE封装中，最常见的是IP over IP的GRE封装，如图5.18所示。
在IP over IP te1GRE封装中，链路层协议后面紧跟着IP协议作为承载协议，使用IP协议号47来指明后面跟着GRE报文；然后在GRE报文中使用Protocol Type值0x800来指明GRE报文中封装的是IP报文。
这种封装结构正是我们重点讨论的所谓IP GRE VPN的封装结构。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
