01 · 128位地址模型与文本表示规范
1.1 地址结构
IPv6地址长度为128位（16字节），按RFC 4291定义由“网络前缀＋接口标识符”两部分构成：在全球单播地址（2000::/3）的SLAAC部署模型中，链路前缀为/64，低64位为接口标识符（IID）。基本报头（RFC 8200）固定40字节：版本（4位）、流量类别（8位）、流标签（20位）、载荷长度（16位）、下一个头（8位）、跳数限制（8位）、源地址（128位）、目的地址（128位）。流标签（Flow Label，RFC 6437）与源地址组合可标识一条流——在被动观测中可用于流聚合与会话还原，是IPv6区别于IPv4的测量维度之一。
1.2 RFC 5952：文本表示的核心规则
地址的字符串表示直接影响日志解析、数据库存储与情报关联的一致性。RFC 5952（2010）确立的规范要点：①小写字母；②每组16位省略前导零；③连续的全零组用“::”压缩一次，取最长序列（等长取最左）；④“::”不得用于压缩单个零组（如2001:db8:0:1:0:0:0:1应写为2001:db8:0:1::1，而非错误地写为2001:db8::1:0:0:1）；⑤ IPv4内嵌表示仅用于IPv4映射地址（::ffff:192.0.2.1）。
| 规范表示（RFC 5952） | 常见非规范写法（应归一化） |
|---|---|
| 2001:db8:0:1:0:0:0:1 → 2001:db8:0:1::1 | 2001:0DB8:0000:0001:0000:0000:0000:0001（全写且大写） |
| 2001:db8::1:0:0:1（多个等长零序列时压缩最左） | 2001:db8:0:0:1::1（压缩了较短/较右序列） |
| 2001:db8:0:0:1:0:0:1 → 2001:db8::1:0:0:1 | 2001:db8::1::1（“::”出现两次，非法） |
| ::ffff:192.0.2.1（IPv4映射地址的合法内嵌形态） | ::ffff:c000:201 与混写形态并存导致关联失败 |
测绘工程含义：情报源（DNS、CT日志、BGP、扫描结果）的地址表示常不一致；入库前必须按RFC 5952归一化，否则同一地址会产生多个“不同”台账条目，直接破坏资产归并能力。同时应拒绝解析单组零压缩（如2001:db8::1中的::仅代表一组零——此例合法，但“::”扩展为单组零的边界情形需在解析器中显式处理）。
02 · 特殊用途地址与保留前缀全景
IANA维护的IPv6 Special-Purpose Address Registry是语义解析的权威依据。下表汇总与测绘直接相关的关键前缀（目的地址为特殊前缀的探测通常不产生预期响应或不应发往全球互联网）：
| 前缀 | 用途（依据） | 测绘含义 |
|---|---|---|
| ::/128 | 未指定地址（RFC 4291） | 有效载荷中不应出现；出现提示伪造或采集错误 |
| ::1/128 | 环回（RFC 4291） | 仅本机意义，全局测绘应剔除 |
| fe80::/10 | 链路本地（RFC 4291） | 仅在本地链路路由，不可全球探测；被动观测可获取 |
| fc00::/7 | 唯一本地地址ULA（RFC 4193），其中fd00::/8为本地分配 | 不应在全球路由出现；出现在BGP宣告或扫描结果中是配置异常信号 |
| ff00::/8 | 组播（RFC 4291） | 非单播目标；MLD观测可用于本地主机发现 |
| ::ffff:0:0/96 | IPv4映射地址（RFC 4291） | 标识IPv4节点；在双栈测绘中承担协议族桥接 |
| ::/96 | 已废弃的IPv4兼容地址（RFC 4291） | 历史残留，遇之记录即可 |
| 64:ff9b::/96 | NAT64著名前缀WKP（RFC 6052） | 地址低32位即IPv4目标——可直接解析出被访问的IPv4服务 |
| 64:ff9b:1::/48 | 本地用翻译前缀（RFC 8215） | 私有WKP变体，语义同上但仅限本地语境 |
| 100::/64 | 仅丢弃前缀（RFC 6666） | 用于路由安全测试，非主机地址 |
| 2001::/23 | IETF协议分配区（RFC 2928） | 下挂多个特殊子块（见下行） |
| 2001::/32 | Teredo（RFC 4380） | 地址中混淆编码了Teredo服务器IPv4、客户端IPv4与UDP端口——反混淆即可提取真实IPv4（含NAPT穿越语义） |
| 2001:2::/48 | 基准测试（RFC 5180） | 设备测评用，不应出现在生产网络 |
| 2001:db8::/32 | 文档示例（RFC 3849） | 教程/文档专用；出现在真实日志中提示复制了示例配置 |
| 2001:10::/28 | ORCHID（RFC 4843，已废弃） | 历史加密散列标识符 |
| 2001:20::/28 | ORCHIDv2（RFC 7343） | 加密散列标识符第二版 |
| 2002::/16 | 6to4（RFC 3056，已被RFC 7526废弃中继） | 2002:WWXX:YYZZ::/48直接嵌入IPv4公网地址——残留探测可发现存量6to4节点 |
| 3ffe::/16 | 6bone试验网（RFC 3701，已退役） | 历史数据清理 |
| 5f00::/16 | SRv6 SID专用地址块（RFC 9602，2024年4月由IANA分配） | 段路由语义地址，出现于SRv6域内（不全局可达）；非终端主机 |
实践要点：探测目标生成阶段必须剔除链路本地（fe80::/10）、ULA（fc00::/7）、组播（ff00::/8）与环回/未指定地址；对2002::/16、2001::/32等特殊前缀应单独立项分析而非混入常规活跃地址统计——否则台账会被协议分配地址“灌水”，资产画像失真。
03 · 接口标识符生成机制对比：可预测性谱系
IID生成机制是地址可发现性的决定性变量。下表对比四种主流机制（RFC 8064给出了系统性的生成机制建议，明确不推荐EUI-64）：
| 机制 | 依据 | 生成方式 | 可预测性与测绘价值 |
|---|---|---|---|
| EUI-64（MAC派生） | RFC 4291（实践上被RFC 8064不推荐） | 48位MAC中间插入FFFE扩展为64位，并翻转u/l位 | 完全可预测：由MAC可推地址、由地址可还原MAC（去除FFFE、再翻转u/l位即得），进而暴露网卡厂商（OUI） |
| 稳定隐私地址 | RFC 7217 | 以F(前缀, 网络接口标识, 网络ID, DAD计数, 密钥)散列生成，同一网络内稳定、跨网络不同 | 无密钥者不可预测；防御友好（反测绘），审计需依赖SAVI/DHCP日志补偿 |
| 临时地址 | RFC 4941 → RFC 8981 | 随机IID，按策略周期更换，用于对外发起连接 | 高随机性、短生命周期：主动枚举几乎不可行，被动情报也难以长期跟踪——双向测绘的共同盲区 |
| DHCPv6分配 | RFC 8415 | 服务器集中分配，策略可为顺序分配或随机分配 | 取决于服务器策略：顺序分配（低字节计数）可被枚举；随机分配则不可。集中日志是审计金矿 |
| 手工／服务编码 | 运维惯例 | 低字节计数（::1网关、::2、::53 DNS）、服务端口嵌入、IPv4尾号延续 | 极低熵：网络设备与基础设施地址几乎都落在少数可猜模式内——定向枚举首选目标 |
主流操作系统现状（定性）：现代桌面与移动系统默认采用随机化IID（RFC 7217式稳定随机＋RFC 8981临时地址组合）：Windows自Vista起默认使用随机化接口标识符，Windows 8及以后版本默认启用临时地址；Linux内核的临时地址扩展（use_tempaddr）内核默认关闭、由发行版决定是否启用，主流桌面发行版多已默认开启——具体默认值应以目标系统的实际配置为准；网络设备（路由器、交换机、防火墙）则普遍保留手工/计数式地址。这一“终端随机、基础设施低熵”的分布特征，决定了测绘策略应区别对待。
04 · 地址分配层级与前缀规划惯例
4.1 分配层级
IPv6地址按“IANA→RIR→LIR→终端站点→链路”逐级分配：IANA向五大RIR分配（粒度随各RIR政策与剩余池状态而定，常见为/23或更细）；RIR向会员单位（LIR）默认分配通常为/32；终端站点按RFC 6177可获/48—/64（RFC 3177早期“一律/48”的建议已被取代，强调按需求分配）；链路前缀在SLAAC模型下为/64。中国境内的CNNIC承担国家级互联网注册机构（NIR）职能，对接APNIC分配体系。
4.2 前缀级画像要素
- RIR注册数据（delegation files）：前缀→持有机构、国家、分配日期、分配粒度，每日更新，是资产归属判定的一手依据；
- BGP宣告可见性：被宣告前缀与实际分配前缀的差异（如更长的/48接入宣告）提示多归属、流量工程或劫持嫌疑，需结合RPKI ROA（RFC 6482）状态判断合法性；
- 前缀活跃度分层：按“有活跃地址的前缀/已分配前缀”比例评估网络的实际启用程度——该指标亦可反哺国家IPv6部署监测（CNNIC、信通院口径）。
与IPv4的关键差异：IPv6极少做前缀聚合外的细粒度再分配公示，且一个组织可能持有多个不相邻前缀；资产台账应以“前缀集合＋ASN＋域名”三元组为归并键，单看地址块容易把云租户、CDN份额误判为单一资产。
05 · 地址中的语义信号挖掘
5.1 嵌入IPv4的地址：翻译与隧道语义
| 地址形态 | 编码内容 | 提取方法 |
|---|---|---|
| 2002:WWXX:YYZZ::/48（6to4） | WWXX:YYZZ即公网IPv4地址的点分十进制直接转十六进制（如192.0.2.1→c000:0201） | 取第2—4组即得IPv4，可直接反查归属与暴露面 |
| 2001::/32（Teredo） | 服务器IPv4（32位）＋标志位（含锥形NAPT指示）＋混淆的客户端IPv4（32位）＋混淆的UDP端口（16位） | 按RFC 4380定义的位布局与0xFFFFFFFF异或反混淆，可还原客户端真实IPv4/端口——安全研究价值高 |
| 64:ff9b::a.b.c.d（NAT64 WKP） | 低32位为IPv4目标地址 | 直接读取；可观察IPv6-only网络实际访问的IPv4目的分布 |
| ::ffff:a.b.c.d（IPv4映射） | 低32位为IPv4地址 | 直接读取；双栈主机测绘中的协议族归并键 |
| EUI-64地址 | IID中嵌入MAC（FFFE标志位） | 去除FFFE并翻转u/l位还原MAC→OUI厂商识别；隐私风险可量化 |
5.2 行为与元数据信号
- rDNS（ip6.arpa，RFC 3596）：反向解析命名惯例（如rtr1-abc.pop3.example.net）常泄露设备角色与机房位置，是低成本资产画像源；
- 端口／角色嵌入：部分网络将服务端口或VLAN号编入IID低字节（::53、::443），命中即知角色；
- 时序信号：临时地址的出现频率与更换周期（RFC 8981默认调度）可反推终端类型与在线时长；
- 流标签（RFC 6437）：源地址＋流标签组合支持无状态流追踪，被动观测侧可用于区分同地址多会话。
本节参考来源（第2页）
以下均为真实可查的权威来源，用于支撑本页事实性表述；注册表类来源持续更新，引用时以其最新版本为准。
IETF RFC 4291《IP Version 6 Addressing Architecture》（2006年2月）：rfc-editor.org/rfc/rfc4291；IANA IPv6 Special-Purpose Address Registry：iana.org/assignments/iana-ipv6-special-registry。
IETF RFC 5952《A Recommendation for IPv6 Address Text Representation》（2010年8月）：rfc-editor.org/rfc/rfc5952；RFC 6437《IPv6 Flow Label Specification》（2011年11月）：rfc-editor.org/rfc/rfc6437。
IETF RFC 4862《IPv6 Stateless Address Autoconfiguration》（2007年9月）：rfc-editor.org/rfc/rfc4862；RFC 7217（2014年4月）：rfc-editor.org/rfc/rfc7217；RFC 8064《Recommendation on Stable IPv6 Interface Identifiers》（2017年2月）：rfc-editor.org/rfc/rfc8064；RFC 8981（2021年2月）：rfc-editor.org/rfc/rfc8981。
IETF RFC 8415《Dynamic Host Configuration Protocol for IPv6 (DHCPv6)》（2018年7月）：rfc-editor.org/rfc/rfc8415；RFC 6177《IPv6 Address Assignment to End Sites》（2011年3月）：rfc-editor.org/rfc/rfc6177；RFC 4193《Unique Local IPv6 Unicast Addresses》（2005年10月）：rfc-editor.org/rfc/rfc4193。
过渡技术相关：RFC 3056《Connection of IPv6 Domains via IPv4 Clouds (6to4)》（2001年2月）：rfc-editor.org/rfc/rfc3056；RFC 4380《Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)》（2006年2月）：rfc-editor.org/rfc/rfc4380；RFC 6052《IPv6 Addressing of IPv4/IPv6 Translators》（2010年10月）：rfc-editor.org/rfc/rfc6052；RFC 8215《Local-Use IPv4/IPv6 Translation Prefixes》（2017年8月）：rfc-editor.org/rfc/rfc8215。
IETF RFC 3596《DNS Extensions to Support IP Version 6》（2003年10月）：rfc-editor.org/rfc/rfc3596；RFC 8402《Segment Routing Architecture》（2018年7月）：rfc-editor.org/rfc/rfc8402；RFC 3849《IPv6 Address Prefix Reserved for Documentation》（2004年7月）：rfc-editor.org/rfc/rfc3849。