随着IPv6的广泛应用，云厂商都面临着在原有网关上支持IPv6的需求。大多云厂商网关侧均在往可编程交换机的方向演进，需要控制面将携带IP地址的流表下发到可编程交换机上之后由可编程交换机进行转发。由于同时支持IPv4和IPv6，通常有以下几种实现方案。

        方案一：IPv4和IPv6是两张流表，控制面将IP地址分别下发到对应的流表中，以120M RAM为例，图1为IPv4最大支持表项以及资源占用情况（195万流表），图2为Pv6最大支持表项数以及资源占用情况（78万流表）。

图1

图2

        优点：控制面简单

        缺点：随着业务的发展，IPv4和IPv6的比例很难预估，从而导致部分表项浪费以及版本频繁迭代

        方案二：IPv4和IPv6是一张流表，且流表的key位宽为128bits，以120M RAM为例，图3位IPv4和IPv6合表的最大支持表项数以及资源占用情况（78万流表）

图3

        优点：控制面相对简单

        缺点：硬件资源过于浪费

        所具有的优点和效果:

          1) 无需关心IPv4和IPv6地址比例。

          2) 降低版本迭代速度。

          3) 最大化利用硬件资源。

1. 下发流表

   1.1 IPv4地址则直接下发至IPv4和IPv6合表, 且标记为v4地址

   1.2 IPv6地址按照约定的算法进行压缩，查询是否与原有IPv6地址压缩值冲突

   1.2.1 若冲突则下发至转发面前置冲突表

   1.2.2 若不冲突则下发至IPv4和IPv6的合表中，并将IPv6地址与压缩值进行持久化，且标记为v6地址

   1.3 压缩算法

   实现hash因子与转发面相同的CRC32算法，将128B压缩成32B

2. 转发面：

   2.1 IPv6流量

   2.1.1 查询前置冲突表

   2.1.1.1 命中则按对应action处理

   2.1.1.2 未命中查询IPv4和IPv6合表

   2.2 IPv4流量

   2.2.1 查询IPv4和IPv6合表

   2.3 转发面表关键信息

   2.3.1 hash算法

   CRCPolynomial<bit<32>>(0x741B8CD7, true, false, false, 32w0xFFFFFFFF, 32w0xFFFFFFFF) CRC32_UDF; Hash<bit<32>>(HashAlgorithm_t.CRC32, CRC32_UDF) ipv6_hash;

   ig_md.lkp_addr = ipv6_hash.get(ig_md.lkp_addr6);

   2.3.2 前置冲突表

   table prefix {

   ig_md.lkp_addr6 : exact;

   }

   2.3.3 IPv4、IPv6合表

   table ip {

   ig_md.is_v6: exact;

   ig_md.lkp_addr : exact;

   }

   2.3.4 说明: ig_md.lkp_addr6为128B, ig_md.lkp_addr为32B，ig_md.is_v6为1B

3. 表项规格：64K冲突表 + 180万流表

技术要点

1. 控制面和转发面对IPv6地址进行压缩且压缩算法一致

2. 保证极低的压缩冲突率（hash因子的选择以及大量的测试）

3. IPv4和IPv6合表。