How do I create a UNC to an IPv6 address?


Windows UNC notation permits you to use a raw IPv4 address in dotted notation as a server name: For example, net view \\127.0.0.1 will show you the shared resources on the computer whose IP address is 127.0.0.1. But what about IPv6 addresses? IPv6 notation contains colons, which tend to mess up file name parsing since a colon is not a valid character in a path component.

Enter the ipv6-literal.net domain.

Take your IPv6 address, replace the colons with dashes, replace percent signs with the letter "s", and append .ipv6-literal.net. This magic host resolves back to the original IPv6 address, but it avoids characters which give parsers the heebie-jeebies.

Note that this magic host is resolved internally by Windows and never hits the network. It's sort of a magic escape sequence.

Comments (18)
  1. Pierre B. says:

    Does this magic resolving of ipv6-literal.net extends to everything or just the networking filesystem? I don't know any literal ipv6 address to test it. (And in fact i'm pretty sure my current external connection doesn't support ipv6.)

    Since the documentation you mentioned is specifically about network resources, I doubt it, but maybe the documentation is only relaying a feature of the address resolving sub-system.

  2. GregM says:

    Apparently this has been around for a long time, because MS registered this domain in December of 2001.  :)

  3. Owen S says:

    Interesting, doing a DNS lookup on IPV6-literal.net for A records (an IPv4 address) takes you to bing, with "your-subdomain ipv6-literal" as the search string. Doing an AAAA (IPv6 address) lookup returns no records, somewhat ironically.

  4. asf says:

    echo.Hello > foo:bar

    more < foo:bar

    …colon in a path component (yes, its the filename part, but still)

  5. Niels says:

    asf:

    What you're doing there is creating/reading a file named "foo", and working on the named stream "bar" in it.

  6. SMW says:

    The ipv6-literal.net domain is also how you get to IPv6 addresses in IE6, for those who still have to use it on occasion.

  7. Soundman32 says:

    Does the RFC 2732 format not work?

    [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]

  8. asf says:

    Niels: yes, I know what it is

  9. Anonymous Coward says:

    Soundman32, I assume that it or something like it will work, but colons in pathnames make a lot of software sit in a corner and cry. (Remember that colons are only supposed to signify the volume, and recently the protocol for the web which just happened to be mostly compatible. So much software assumes there can only be one colon and that everything in front of it is the volume or web protocol.)

  10. Jules says:

    asf: the important thing to remember is that in your example, the colon is a separator, and not part of any actual filename.

  11. Wladimir Palant says:

    And as an added bonus, Bing gets some new customers – anybody who tries to use that address on a non-Windows operating system…

  12. asf says:

    @Jules: Of course its part of the name, it's the way to access alternative streams (Just because you can skip it to get the default stream does not mean it is not part of the name)

  13. Soundman32 says:

    Anonymous Coward: The rfc has only been around since 1999 !  

    I presume most people parsing filenames would use splitpath which could have been made to work a decade ago.  

    I tried it in Explorer but it didn't work.  Hello wheel, we've invented you again.

  14. Evan says:

    @asf, quit being pedantic. Of course saying "colons are not valid in path components" is *technically* incorrect, just because "c:foo.txt" is a valid path. They should also be allowed from within the POSIX subsystem.

    You know what Raymond means; don't make him bring back the nitpicker's corner.

  15. Dave Bacher says:

    @Soundman32:

    The issue with the RFC2732 format is that it breaks a huge number of existing RFC's.  This sort of an approach is what IP v6 should have used in the first place, and let me explain why in detail.

    Adding the bracket syntax breaks every existing URL parser, as of when the RFC was submitted.  Any software that performs user-interface level validation of inputs (i.e. most software) or configuration file level validation of inputs isn't going to work correctly with RFC2732.  The argument there, from the RFC's point of view, is who cares because the app doesn't support IP v6 in the first place.

    But pretend that you are using APR or WinINet for a minute.  When the shared library/DLL gets updated to support IP v6, your application gets the upgrade, too.  Except, since you're doing validation of the user's data entry, the user cannot actually enter literals.  Anything using a domain name works, on existing programs, without changes (provided they're going through one of these library stacks), but you can't do anything involving a literal — and you can't do it simply because of your own UI validation.

    Now — lets say that you convert an IP v6 address to numbers, letters and dashes — as the Microsoft domain is doing.  Then you register a valid domain name on the Internet, and you implement a rule in your resolver that parses it.  Instantly, you have the ability to connect to any IP v6 host, by address, without breaking any existing RFC — the names are fully compliant with the DNS spec.

    But the advantage doesn't end there — the resolver can actually cover for IP v4 applications that are not IP v6 aware.  Whether Microsoft's resolver actually does it or not is another story, but when a process requests one of these addresses, the resolver can instantly parse it and return an AAAA record, obviously.  However, the resolver could also set up an IP v4 port on a private-use subnet, and could return that as an A record.  If the OS later sees an attempt to connect to the private use address, it could transparently forward the port.

    And that can be done on up at the switch level, at a firewall level, at a proxy level, etc.  You can transparently proxy outbound IP v4 applications, so that they can connect to IP v6.

    So far as the RFC being around since 1999, if you check out Wikipedia, you'll see there was no production IP v6 support on any operating system until 2004, and the RFC became a STD much later than 1999.  Since IP v6 is still not widely deployed at an ISP level, and since many mobile systems cannot get IP v6 even with the current transition technologies, it isn't a priority for application authors to support it, and so support is very spotty at best still — especially in consumer entertainment applications such as videogames.  Even if you want to say that since Windows Vista/7 tries to enable IP v6 on every computer, and since the FCC is mandating it, that IP v6 is going to be widely supported in the near future.

    So far as does Windows support the [] syntax:


    C:UsersDaveB>net view [2001:(omitted intentionally):be77]

    Shared resources at [2001:(omitted intentionally):be77]

    Dave Quad

    Share name  Type  Used as  Comment


    C           Disk

    D           Disk

    ebooks      Disk

    F           Disk

    Installs    Disk

    Public      Disk

    Users       Disk

    videos      Disk

    The command completed successfully.


    Windows 6 and 6.1 appear to handle it correctly — I didn't test 5.2 or 5.1.

    I didn't try Raymond's syntax, because I can reasonably expect it to work on Windows 6 and 6.1, since that's his blog entry.

  16. asdbsd says:

    Obligatory IPv6 bashing: IPv6 addresses just suck. Where's the beauty of 127.0.0.1? Even reading FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 makes your eyes bleed, leave alone reciting it by the phone or suggesting to ping it or connect to it.

  17. Dwayne says:

    asbsd wrote:

    <blockquote>Obligatory IPv6 bashing: IPv6 addresses just suck. Where's the beauty of 127.0.0.1?</blockquote>

    ::1

  18. asdbsd says:

    Dwayne: Okay, where's the beauty of 192.168.1.1? :) ::FFFF:C0A80101. Even IPv4 addresses look worse when written in hex form.

Comments are closed.