☰

带前缀的 IPv6 地址文本表示法：方括号内还是方括号外？

tag-icon • tag-icon ipv6 rfc
带前缀的 IPv6 地址文本表示法：方括号内还是方括号外？

我正在浏览一些与 IPv6 相关的 RFC。有些声称前缀应该写在方括号外面，而另一些则直接将其附加到地址上。

具体来说，RFC4291第 2.3 节中是这样说的：

For example, the following are legal representations of the 60-bit
prefix 20010DB80000CD3 (hexadecimal):

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

但是之后RFC4038，第 5.1 节：

Therefore, the IP address parsers that take the port number separated
with a colon should distinguish IPv6 addresses somehow.  One way is
to enclose the address in brackets, as is done with Uniform Resource
Locators (URLs) [RFC2732]; for example, http://[2001:db8::1]:80.

Some applications also need to specify IPv6 prefixes and lengths:
The prefix length should be inserted outside of the square brackets,
if used; for example, [2001:db8::]/64 or 2001:db8::/64 and not
[2001:db8::/64].  Note that prefix/length notation is syntactically
indistinguishable from a legal URI; therefore, the prefix/length
notation must not be used when it isn't clear from the context that
it's used to specify the prefix and length and not, for example, a
URI.

他们两个都正确的？

IPv6 地址解析是否必须支持前缀的额外复杂性，前缀要么直接位于地址上，要么位于用于 URL 嵌入的方括号之外？

RFC4038 5.1 中的要求看起来像是一个智力失误。为什么斜线不留在地址中，而是超出了方括号的范围，而方括号很好地将地址括起来并消除了歧义，然后由于该字符是 URL 中的路径分隔符而产生了歧义？

这不就是上面结尾那句话所描述的问题吗：

[T]herefore, the prefix/length
notation must not be used when it isn't clear from the context that
it's used to specify the prefix and length and not, for example, a
URI.

是否可以通过在里面放置斜线来解决，就像在 RFC4291 中一样？

答案1

首先，RFC 4038 不是规范性的，因此如果您愿意，基本上可以忽略其中的所有内容。

其次，RFC 4291 进行了更新，RFC 5952，它指定了如何在文本中表示 IPv6 地址。除了第 6 节中简要提到这一点外，它对括号的使用几乎没有提及：

...[省略上下文]... [] 风格表达于RFC3986应该被采用，并且除非另有规定，否则这是默认的。

特别是第 3.2.2 节解决了这个问题，规定 IP 地址文字必须出现在 URL 的方括号中。然而，在括号中指定 IPv6 地址的语法不包括范围 ID，这表明它应该出现外部括号。然而，在早期，范围 ID 并不是 IPv6 规范的一部分，这就是为什么本 RFC 未包含有关它们的任何内容。

RFC 6874RFC 3986 的更新解决了这一遗漏。它规定范围 ID 必须出现在括号内，如果是 URL，百分号本身必须经过百分号编码。有趣的是，主流网络浏览器都拒绝实施 RFC 6874，例如各种可疑的原因。但你会发现其他解析 IPv6 地址的应用程序也支持它。

（请注意，出于安全原因，范围 ID 目前只能与链路本地地址一起使用。RFC 解释说，对其他地址类型遵循这些范围 ID 可能会导致不必要的行为，例如通过不必要的接口传出的流量。）

相关内容