Bug 11773 – IPv6 addresses with interface don't do anything when clicked

• Status: RESOLVED
• Resolution: INVALID
• Component: New Bugs

[Nicholas Shanks]

An IPv6 address as currently needed by Mac OS X requires an interface specified to work. This is done by appending %en0 for ethernet, etc. For example: http://nicholas:passwd@[fe80::205:2ff:fe0f:149e%25en0]:81/ which is my local Apache 2 installation (the % must be URL-escaped to %25). Sadly clicking on links with the interface specified does nothing, even though they are highlighted correctly. Copying and pasting the link into the address bar works just fine.
I don't know if this is a WebKit or NSURL bug, but first saw it in Colloquy.
See http://colloquy.info/project/ticket/932

[Mark Rowe (bdash)]

I've done a little digging into this case: the reason the link has no effect is that KURL::parse decides the URL is invalid due to the presence of non-IPv6 address characters inside the hostname portion of the URL (the invalid characters being "%en0").  The reason why these are considered invalid is somewhat interesting...  RFC 2732, Format for Literal IPv6 Addresses in URL's, (<http://www.faqs.org/rfcs/rfc2732.html>) changes the host portion of the URL syntax to:

      host          = hostname | IPv4address | IPv6reference
      ipv6reference = "[" IPv6address "]"

where IPv6address is defined over in RFC 2373, IP Version 6 Addressing Architecture (<http://www.faqs.org/rfcs/rfc2373.html>).  It's definition is:

      IPv6address = hexpart [ ":" IPv4address ]
      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

      IPv6prefix  = hexpart "/" 1*2DIGIT

      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
      hexseq  = hex4 *( ":" hex4)
      hex4    = 1*4HEXDIG

which is, more or less, a colon-delimited sequence of hexadecimal digits.  It makes no allowance for the scoped address format.  The scoped address format is introduced in RFC 4007, IPv6 Scoped Address Architecture (<http://www.faqs.org/rfcs/rfc4007.html>), and optionally append a percent character followed by an arbitrary zone identifier to the end of an IPv6 literal address.  Unfortunately in section 11.7 it says:

   [T]his document does not specify how the format for non-global
   addresses should be combined with the preferred format for literal
   IPv6 addresses.  In any case, it is recommended to use an FQDN
   instead of a literal IPv6 address in a URL, whenever an FQDN is
   available.

So in summary, the scoped address format appears to be totally unspecified when used in the context of a URL.

Recent builds of Firefox also appear to have issues with URLs of this format, attempting to treat them as a hostname to be resolved.  This leads to a "host not found" error being displayed, which is misleading but in many ways more useful than ignoring the mouse click like WebKit currently does.  It's not obvious whether the loader code that is used to load pages will function correctly in the presence of the scoped address, or whether this would also need addressed at other levels.

[Alexey Proskuryakov]

(In reply to comment #1)
> So in summary, the scoped address format appears to be totally unspecified when
> used in the context of a URL.

This sounds just about right: it would be very strange for an URL to depend on a local machine setup.

[Mark Rowe (bdash)]

As outlined in comment 1, the use of a scoped IPv6 address in a URL is unspecified and therefore the current behaviour is not incorrect.

[Alexey Proskuryakov]

*** Bug 16932 has been marked as a duplicate of this bug. ***

[Deirdre Saoirse Moen]

<rdar://problem/8406834>

[Sascha Silbe]

Use of IPv6 link-local addresses as part of a URL is now covered by RFC 6874 [1].

IPv6 link-local addresses are quite useful for interacting with embedded devices. They require neither manual configuration (like static IPv4 addresses do) nor additional equipment (like a DHCP server for giving out IPv4 addresses).


[1] http://www.rfc-editor.org/rfc/rfc6874.txt