
原始 IPv6 地址为

```text
12CD:0000:0000:FF30:0000:0000:0000:0000/60
```

A 选项为

```text
12CD:0:0:FF30::/60
```

它能够完整、无歧义地还原成原地址，因此是正确写法。

这道题看起来只是在考 IPv6 地址的简写，真正容易失分的地方却有三个。一个是 `0000` 到底可以怎样省，一个是 `::` 究竟替代多少个 `0000`，另一个则是 `/60` 会不会允许把 `FF30` 写成 `FF3`。尤其是最后这一点，很容易受到 IPv4 CIDR 写法的影响，误以为 `/60` 已经把第四段的最后 4 bit 排除在网络前缀之外，所以最后那个十六进制数字 `0` 可以直接不写。

实际上不可以。

而且很巧，这道题几乎就是 IPv6 核心标准 RFC 4291 中一个 `/60` 示例的同构变形。RFC 4291 专门拿一个第四段为 `CD30` 的 `/60` 前缀说明，`CD30` 不能因为只有前 12 bit 属于前缀，就缩写成 `CD3`。理解了这个标准中的例子，这道选择题基本就没有悬念了。

我们先把地址恢复成 IPv6 最原始的结构。

IPv6 地址总长度为 128 bit。通常书写成 8 组，每组 16 bit，每一组用 4 个十六进制数字表达，因为一个十六进制数字正好对应 4 bit。

原地址可以按组编号为

```text
第 1 组    12CD
第 2 组    0000
第 3 组    0000
第 4 组    FF30
第 5 组    0000
第 6 组    0000
第 7 组    0000
第 8 组    0000
```

把它连起来，就是

```text
12CD:0000:0000:FF30:0000:0000:0000:0000
```

这里每一组都是完整的 16 bit。

例如

```text
12CD
```

转换成二进制后对应

```text
0001 0010 1100 1101
```

恰好 16 bit。

而

```text
FF30
```

对应

```text
1111 1111 0011 0000
```

同样是完整的 16 bit。

理解这一层以后，IPv6 的第一条压缩规则就很直观了。每一个 16 bit 分组内部，左侧多余的 `0` 可以删除。

因此

```text
0000
```

可以写成

```text
0
```

类似地

```text
000A
```

可以写成

```text
A
```

```text
0012
```

可以写成

```text
12
```

```text
0123
```

可以写成

```text
123
```

这条规则删除的是一个 16 bit 分组内部的前导零，也就是 leading zero。

所以题目中的原地址，可以先进行最普通的一层压缩

```text
12CD:0:0:FF30:0:0:0:0/60
```

到这里没有使用 `::`，只是把各个 `0000` 写成了 `0`。

这个结果仍然包含完整的 8 个 16 bit 分组。

按照顺序数一遍仍然是

```text
12CD
0
0
FF30
0
0
0
0
```

总共 8 组。

IPv6 地址还有一条更强的压缩规则，连续的全零分组可以使用 `::` 代替。

原地址尾部存在

```text
0000:0000:0000:0000
```

也就是连续 4 个全零的 16 bit 分组。

因此可以将它们整体替换成

```text
::
```

于是得到

```text
12CD:0:0:FF30::/60
```

这恰好就是 A。

检查 IPv6 简写是否正确时，有一个特别可靠的方法，不要只盯着地址觉得像不像，而是进行反向展开。

对 A

```text
12CD:0:0:FF30::/60
```

在 `::` 左边已经明确写出了 4 组

```text
12CD
0
0
FF30
```

IPv6 总共需要 8 组，所以 `::` 必须代表剩余的 4 组全零。

展开以后便是

```text
12CD:0:0:FF30:0:0:0:0/60
```

把每组补足 4 个十六进制数字后就是

```text
12CD:0000:0000:FF30:0000:0000:0000:0000/60
```

与题目的原地址逐位一致。

所以 A 没有任何歧义。

这里可以顺带建立一个很实用的判断习惯。遇到 IPv6 压缩题，与其记很多零散口诀，不如采用「展开验证」。

看到

```text
2001:DB8::1
```

可以先数显式出现的分组。

前面有

```text
2001
DB8
```

后面有

```text
1
```

共 3 组。

128 bit IPv6 需要 8 组，因此 `::` 必须代表 5 组 `0000`。

完整地址就是

```text
2001:0DB8:0000:0000:0000:0000:0000:0001
```

Linux、Windows、路由器以及大量网络管理软件显示 IPv6 地址时，经常能够看到这种形式。典型的 IPv6 loopback 地址完整形式为

```text
0000:0000:0000:0000:0000:0000:0000:0001
```

实际几乎总是显示成

```text
::1
```

`::` 在这里替代了前面的 7 个全零分组。

IPv6 unspecified address 完整形式为

```text
0000:0000:0000:0000:0000:0000:0000:0000
```

通常直接写成

```text
::
```

这两个现实中的 IPv6 地址，正好体现了零压缩规则的价值。IPv6 有 128 bit，如果永远坚持完整书写，日常配置和故障排查会非常痛苦，所以标准提供了这种文本压缩机制。

回到题目，真正具有迷惑性的其实是 B。

B 写成

```text
12CD:0:0:FF3/60
```

很多人在这里会产生一种很自然的想法。

`/60` 表示前 60 bit 是网络前缀，一个十六进制数字对应 4 bit，那么 60 bit 正好等于 15 个十六进制数字。前三组一共占

```text
16 × 3 = 48 bit
```

还需要

```text
60 - 48 = 12 bit
```

所以第四组只取前 12 bit。

第四组是

```text
FF30
```

拆成 4 个十六进制数字就是

```text
F F 3 0
```

前三个十六进制数字一共正好是 12 bit。

于是容易产生这样的推导

```text
FF30
↓
前 12 bit 是 FF3
↓
所以 /60 可以写成 FF3
```

问题恰恰出在最后一步。

`/60` 描述的是网络前缀有多少 bit，并没有修改 IPv6 地址本身的文本语法。

`/` 左边仍然必须是一个合法的 IPv6 地址表示。

RFC 4291 对 IPv6 prefix 的表示形式规定为

```text
ipv6-address/prefix-length
```

这里的关键是前半部分仍然是 `ipv6-address`。

也就是说，写 `/60` 并不等于获得了一种「只把前 60 bit 写出来即可」的新地址语法。

这和子网掩码的概念需要分开理解。

`/60` 可以告诉网络设备

```text
左边前 60 bit 属于网络前缀
```

但它不能告诉 IPv6 文本解析器

```text
第四个 16 bit 分组只写 12 bit 就行
```

一个普通的 IPv6 分组在文本中可以去掉前导 `0`，却不能随意去掉尾部 `0`。

例如

```text
0030
```

可以写成

```text
30
```

因为删除的是左侧前导零。

但

```text
FF30
```

不能写成

```text
FF3
```

因为这里删除的是右侧最后一个十六进制数字 `0`。

两者代表的 16 bit 数值完全不同。

`FF30` 对应

```text
1111 1111 0011 0000
```

而 `FF3` 在一个 IPv6 16 bit 分组里实际上等价于

```text
0FF3
```

对应

```text
0000 1111 1111 0011
```

两者当然不是同一个值。

也可以直接从十六进制数值理解。

```text
FF30
```

并不是

```text
FF3
```

后面一个没有意义的显示字符 `0`。

这个 `0` 本身就是 16 bit 数据的一部分。

`FF30` 的数值是十六进制 `FF30`，`FF3` 的数值则是十六进制 `0FF3`。删除尾部 `0` 相当于把一个十六进制数除以 `16`，数值已经改变。

这里恰好能对应 RFC 4291 中非常经典的 `/60` 示例。

RFC 给出的 60 bit 前缀中出现了

```text
2001:0DB8:0000:CD30:0000:0000:0000:0000/60
```

标准明确认可的压缩形式之一是

```text
2001:0DB8:0:CD30::/60
```

而

```text
2001:0DB8:0:CD3/60
```

被明确列为不合法写法。

原因正是一个 16 bit 分组可以删除 leading zero，却不能把 trailing zero 当作地址简写规则删除。

把 RFC 中的

```text
2001
0DB8
CD30
```

对应到本题中的

```text
12CD
0000
FF30
```

几乎可以看到完全相同的出题思路。

所以 B 并不是因为 `/60` 算错了，恰恰相反，很多选择 B 的思路已经正确计算出 `/60` 在第四组内部经过第 12 bit。真正的问题是把「网络前缀长度」与「IPv6 地址的文本压缩语法」混在了一起。

还有一个更直接的问题。

```text
12CD:0:0:FF3
```

本身只明确写出了 4 个分组，而且其中没有出现 `::`。

普通 IPv6 十六进制表示需要能够还原出完整的 8 个 16 bit 分组。少掉的分组不会因为后面存在 `/60` 就自动补零。

因此 B 从地址文本结构上已经存在问题，再加上 `FF30` 被错误改成了 `FF3`，自然不能成立。

C 的迷惑方式不同。

C 为

```text
12CD::FF30/60
```

很多人会看到原地址里确实存在大量 `0000`，于是觉得把中间和尾部的零全部压缩掉似乎很自然。

但 `::` 只能代表一段连续的全零分组。

原始地址为

```text
12CD:0000:0000:FF30:0000:0000:0000:0000
```

这里其实存在两段零。

第一段位于 `12CD` 与 `FF30` 之间

```text
0000:0000
```

第二段位于 `FF30` 后面

```text
0000:0000:0000:0000
```

它们被非零分组 `FF30` 隔开，并不是一整段连续的零。

再把 C 反向展开，就更清楚了。

```text
12CD::FF30
```

显式分组只有两个。

一个是

```text
12CD
```

另一个是

```text
FF30
```

IPv6 一共需要 8 组，所以这里的 `::` 要补 6 个 `0000`。

展开结果为

```text
12CD:0000:0000:0000:0000:0000:0000:FF30
```

而题目的原地址是

```text
12CD:0000:0000:FF30:0000:0000:0000:0000
```

两个地址中的 `FF30` 位置完全不同。

原地址的 `FF30` 位于第 4 组。

C 展开后的 `FF30` 位于第 8 组。

所以 C 看起来很短，却已经变成了另一个 IPv6 地址。

这一点也是 IPv6 地址压缩题最值得掌握的技巧。`::` 不是简单意义上的「这里省略了一些零」，它具有严格的位置含义。解析器会根据已经明确写出来的分组数量，自动推算 `::` 到底代表几个连续的 16 bit 零分组。

因此

```text
2001::1
```

和

```text
2001:0:0::1
```

虽然看起来不同，却可能展开成相同地址，具体要根据显式分组数量计算。

而

```text
12CD::FF30
```

也绝不会自动理解成

```text
12CD:0:0:FF30:0:0:0:0
```

因为解析器没有任何信息能够知道 `FF30` 应该放在第 4 组。

这也解释了 IPv6 为什么规定一个地址中 `::` 最多只能出现一次。

如果一个地址写成 D

```text
12CD::FF30::/60
```

这里出现了两次 `::`。

假如允许这种写法，就会产生无法消除的歧义。

IPv6 总共有 8 组，显式出现了

```text
12CD
FF30
```

还缺 6 组零。

可这 6 组到底怎样分配给前面的 `::` 和后面的 `::`，无法判断。

可能是

```text
2 + 4
```

也可能是

```text
3 + 3
```

还可能是

```text
4 + 2
```

甚至存在其他组合。

不同分配方式会让 `FF30` 出现在不同位置，从而得到不同的 128 bit 地址。

所以 IPv6 标准直接消除了这种歧义，一个地址里 `::` 只能使用一次。

这条规则在考试中非常好用。只要一个选项里看到两个 `::`，通常可以立即判错，无须再做复杂计算。

再回头看 A

```text
12CD:0:0:FF30::/60
```

这里只有一个 `::`，它明确替代末尾 4 个连续的全零分组。

展开以后地址完全一致，所以没有问题。

这里还可以继续把 `/60` 理清楚，因为这道题其实同时考了 IPv6 prefix。

IPv6 总长度是 128 bit。

`/60` 表示从最左侧开始的连续 60 bit 属于前缀。

前三个完整分组占

```text
16 + 16 + 16 = 48 bit
```

还差 12 bit。

所以 `/60` 的分界线确实落在第 4 个 16 bit 分组内部。

原来的第 4 组为

```text
FF30
```

转换成二进制为

```text
1111 1111 0011 0000
```

按照 `/60` 切割，可以看成

```text
1111 1111 0011 | 0000
```

左边 12 bit 属于前缀。

右边 4 bit 已经属于地址剩余部分。

因此整个 60 bit 网络前缀可以用十六进制理解成

```text
12CD
0000
0000
FF3
```

这里的 `FF3` 描述的是前缀的 12 bit 内容，而不是说 IPv6 地址文本中的第 4 个 hextet 可以直接写成 `FF3` 并在那里结束。

这是两种完全不同的语义。

如果我们研究的是「前 60 bit 的数值」，确实会得到最后三个十六进制数字 `FF3`。

如果我们书写的是 RFC 4291 定义的

```text
ipv6-address/prefix-length
```

那么 `/` 左边仍然应该是合法 IPv6 地址。

因此网络地址规范地写出来仍然是

```text
12CD:0:0:FF30::/60
```

这里还有一个很有意思的变化可以帮助检查理解是否真正到位。

设某个节点地址为

```text
12CD:0000:0000:FF3A:1234:5678:9ABC:DEF0/60
```

它的第 4 组是

```text
FF3A
```

而 `/60` 只取其中前 12 bit，也就是 `FF3`。

最后一个十六进制数字 `A` 已经属于 host 部分。

求这个节点所属的 `/60` 网络时，需要把所有 host bit 清零。

第 4 组最后 4 bit 于是从

```text
A
```

变成

```text
0
```

后面的 68 bit 也全部清零。

最终网络前缀会得到

```text
12CD:0:0:FF30::/60
```

这个例子恰好揭示了题目为什么使用 `FF30` 而不是随便选一个数。

`/60` 正好在 `FF30` 的 `3` 与 `0` 之间切开。

出题者显然希望我们判断，能不能因为最后这个 `0` 已经落在 prefix length 之外，就把它从地址文本中删掉。

答案仍然是不可以。

它可以因为计算网络地址而被置为零，却不能利用「删除尾部零」这种不存在的 IPv6 文本压缩规则把整个十六进制数字直接抹掉。

IPv6 地址的两个压缩规则其实可以压缩成一句很好记的话。

单个分组只能去掉左边的零，连续的全零分组才能交给 `::`。

例如

```text
000A
```

可以成为

```text
A
```

因为删除的是前导零。

```text
A000
```

不能成为

```text
A
```

因为右边三个零属于这个 16 bit 数值。

而

```text
0000:0000:0000
```

可以整体使用 `::` 压缩，因为这里压缩的是完整的 16 bit 全零分组。

这一点和十进制数其实很像。

十进制的

```text
000123
```

仍然可以写成

```text
123
```

但

```text
123000
```

显然不能写成

```text
123
```

前导零只是显示冗余，尾部零却改变数值。

IPv6 hextet 中的道理完全一样。

由此再看

```text
FF30
```

和

```text
FF3
```

就不会再受到 `/60` 的干扰。

`FF30` 中的最后一个 `0` 位于右侧，它不是 leading zero，所以不能依据 IPv6 单组压缩规则删除。

至于 RFC 5952，它后来进一步给出了 IPv6 地址文本规范化的推荐形式。实际系统为了日志比较、DNS 记录、配置管理、数据库存储以及字符串匹配能够保持一致，通常希望同一个 IPv6 地址有相对统一的文本形式，其中包括省略分组中的前导零，以及对于连续全零分组采用一致的 `::` 压缩方式。

按照 RFC 5952 的规范化建议，十六进制字母通常采用小写，所以题目 A 如果进一步写成常见的 canonical form，可以看到

```text
12cd:0:0:ff30::/60
```

不过考试中的 A 使用大写 `12CD` 和 `FF30` 并不会因此变成错误答案。IPv6 地址解析本身并不因为十六进制字母大小写而改变地址数值。

在真实的系统运维中，这类差异很常见。

某份网络规划文档可能记录

```text
2001:0DB8:0000:0000:0000:0000:0000:0001
```

Linux 命令输出可能呈现为

```text
2001:db8::1
```

应用数据库中又可能曾经保存过

```text
2001:0db8:0:0:0:0:0:1
```

从 128 bit 地址数值的角度，它们可以代表同一个地址。也正因为 IPv6 合法文本形式很多，RFC 5952 才提出统一文本表示建议，否则直接拿字符串做比较时，同一个地址可能被错误地认为是多个不同对象。

考试环境下更重要的是 RFC 4291 定义的基本合法性。

把四个选项重新压缩成最短判断过程，思路就很清晰了。

A

```text
12CD:0:0:FF30::/60
```

展开为

```text
12CD:0000:0000:FF30:0000:0000:0000:0000/60
```

与原地址完全相同，所以正确。

B

```text
12CD:0:0:FF3/60
```

把 `FF30` 的尾部 `0` 删除了，而且没有使用 `::` 补足完整 IPv6 地址。`/60` 不能改变 `/` 左边仍需遵守 IPv6 地址语法这一事实，所以错误。

C

```text
12CD::FF30/60
```

展开后为

```text
12CD:0000:0000:0000:0000:0000:0000:FF30/60
```

`FF30` 从原来的第 4 组跑到了第 8 组，地址已经改变，所以错误。

D

```text
12CD::FF30::/60
```

一个 IPv6 地址出现两次 `::`，零分组数量无法唯一确定，直接违反 IPv6 零压缩规则，所以错误。

因此本题最终答案为

```text
A. 12CD:0:0:FF30::/60
```

考试时甚至可以把整套判断浓缩成三个检查动作。看到 IPv6 地址，先确认 8 个 hextet 能不能通过展开恢复出来。遇到单个 hextet 缩短，只允许删除左侧前导零。遇到 `::`，确认整个地址只能出现一次，并计算它究竟补了多少个连续 `0000`。碰到 `/60`、`/52`、`/56` 这类不一定落在完整 16 bit 边界上的 prefix length，也不要把 prefix bit 数量误认为地址字符串可以写到那里就停止。

这道题最有价值的地方恰好就在 B。A、C、D 更多是在检查普通 IPv6 压缩规则，而 B 把 CIDR prefix 与 IPv6 textual representation 混到了一起。只要记住 `/60` 是在告诉我们「前 60 bit 属于前缀」，而不是告诉我们「IPv6 地址只需要写 60 bit」，类似题型基本都能够稳定判断出来。

更巧的是，RFC 4291 在地址前缀章节中使用的 `/60` 示例，几乎已经把这道题的 B 选项提前解释完了。标准中的 `CD30` 不能写成 `CD3`，本题中的 `FF30` 同样不能写成 `FF3`。从这个角度看，这不是一道需要死记口诀的题，而是一道可以直接回到 IPv6 标准语义解决的题。

参考资料

RFC 4291，IP Version 6 Addressing Architecture，重点可阅读第 2.2 节与第 2.3 节。[RFC 4291 官方页面](https://www.rfc-editor.org/rfc/rfc4291.html?utm_source=chatgpt.com)

RFC 5952，A Recommendation for IPv6 Address Text Representation，重点可阅读第 4 节关于 IPv6 文本规范化表示的规则。[RFC 5952 官方页面](https://www.rfc-editor.org/rfc/rfc5952.html?utm_source=chatgpt.com)

这道题最该记住的一句话就是，`/60` 可以在 `FF30` 内部切出前 12 bit 的 `FF3`，但它不能把 IPv6 地址文本中的 `FF30` 直接写成 `FF3`。

这道题看起来只是在考 IPv6 地址的简写，真正容易失分的地方却有三个。一个是 0000 到底可以怎样省，一个是 :: 究竟替代多少个 0000，另一个则是 /60 会不会允许把 FF30 写成 FF3。尤其是最后这一点，很容易受到 IPv4 CIDR 写法的影响，误以为 /60 已经把第四段的最后 4 bit 排除在网络前缀之外，所以最后那个十六进制数字 0 可以直接不写。

IPv6 地址的压缩问题

真正理解 SNMP，不能只背一句 Manager 管理 Agent。我们可以把它理解成一个非常典型的分布式监控系统。

紫薇堂堂主

网络与通信

正确IPv6压缩形式为12CD:0:0:FF30::/60，完整展开后与原地址一致。B项错误删除尾部零，C项错误使用::导致FF30位置改变，D项双::歧义。关键区分网络前缀长度与地址文本语法，/60不能省略hextet尾部零。

代码解释

数据库

路由器

Windows

路由

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

IPv6 地址的压缩问题-腾讯云开发者社区-腾讯云

IPv6 地址的压缩问题

IPv6 地址的压缩问题

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐