Server Fault Asked on December 16, 2021
I’m skimming through some IPv6 related RFCs. Some claim that a prefix should be written outside of the square brackets, whereas others have it tacked on to the address directly.
Specifically, RFC4291, section 2.3 has it like this:
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
But then RFC4038, section 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.
Are they both right?
Does IPv6 address parsing have to support the additional complexity of the prefix being either on the address directly, or else outside of the square brackets that are used for URL embedding?
The requirement in RFC4038 5.1 looks like an intellectual gaffe. Why would the slash not stay with the address and instead go outside of the nicely enclosing, disambiguating square brackets, where it then creates ambiguity due to that character being a path component separator in URLs?
Is it not the case that the problem described by the closing sentences above:
[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.
is solved by putting the slash inside, like in RFC4291?
First, RFC 4038 is not normative, so you can basically ignore everything in it if you want.
Second, RFC 4291 had an update, RFC 5952, which specifies how to represent IPv6 addresses in text. It is very quiet about the use of brackets, except for this brief mention in section 6:
...[context omitted]... The [] style as expressed in RFC3986 SHOULD be employed, and is the default unless otherwise specified.
In particular section 3.2.2 addresses this, specifying that an IP address literal must appear in square brackets in a URL. The grammar for specifying an IPv6 address in brackets, however, does not include the scope ID, which suggests that it should appear outside the brackets. However, at that early time scope IDs were not part of the IPv6 specification, which is why this RFC does not include anything about them.
RFC 6874, an update to RFC 3986, addresses this omission. It states that the scope ID must appear inside the brackets, and in the case of a URL, the percent sign must itself be percent-encoded. Interestingly, major web browsers have all refused to implement RFC 6874, for various questionable reasons. But you should find that other applications which parse IPv6 addresses support it.
(Note that for security reasons scope IDs are only to be used with link-local addresses at this time. The RFC explains that obeying them for other address types may result in unwanted behavior such as traffic egress through an undesired interface.)
Answered by Michael Hampton on December 16, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP