Bug 4548 - IPv6 requires support for Link Local addresses
IPv6 requires support for Link Local addresses
Status: RESOLVED FIXED
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
Other All
: P3 normal
: ---
Assigned To: Jeff Layton
:
: 6159 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-25 06:41 UTC by David Holder
Modified: 2009-09-10 07:30 UTC (History)
4 users (show)

See Also:


Attachments
patch -- mount.cifs: add support for sending IPv6 scope ID to kernel (1.22 KB, patch)
2009-09-10 07:30 UTC, Jeff Layton
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Holder 2007-04-25 06:41:21 UTC
IPv6 version of CIFS will not work over link-local addresses as the interface must be specified in some way.
Recommend adding an interface parameter to the mount which defines the interface device to be used when using link-local addresses.
Any questions please ask. Also, I am happy to test!
Comment 1 Steve French 2007-07-22 16:32:29 UTC
Suggestions on what to call such an interface parm - should this be parsed in user space (something returned by the getaddrinfo?) and automatically generated as a param passed to the kernel?

Does NFS or other OS have such a precedent for what to call such a mount param?

I have a patch for mount.cifs to handle ipv6 resolving host names - any interest in reviewing it?

Any thoughts about SCTP IPv6?
Comment 2 David Holder 2007-07-23 04:51:55 UTC
Other commands specify the interface (or scope id) using a command line parameter. For example, ping6 uses the -I option. Here is an example:

ping6 -I eth0 fe80::1

Without the -I option the command generates an error since the scope of the link-local address is unknown.

However, the intention has always been that the scope of an address would be specified in the address itself. For example, in Windows the ping command is written:

ping ff80::1%4

Where the %4 is the interface index for the "Local Area Connection".

This notation is standardised in RFC4007. So on Unix or Linux the following is possible:

ping6 ff80::1%eth0

This works on FC7 with kernel 2.6.21 but I don't know when this was introduced in the kernel. I assume (but don't know) that this means this notation is supported by getnameinfo(). If this format can be used I'd recommend using it.

Regarding NFS and other OSes I have not seen a parameter for this. On FreeBSD you can use the % notation shown above.

> I have a patch for mount.cifs to handle ipv6 resolving host names - any
interest in reviewing it?

I'd be very happy to review this.

> Any thoughts about SCTP IPv6?

SCTP is something that I've not looked at - yet! Are you planning to use it with the CIFS client? Is that possible? 


Comment 3 Jeff Layton 2009-03-20 05:05:41 UTC
Seems reasonable to allow this and parsing the notation that David mentions shouldn't be too tough...

The part I'm not sure about is how we turn that interface name into a sin6_scope_id field in the sockaddr_in6 that we pass to the connect op.

Comment 4 Jeff Layton 2009-03-20 05:12:06 UTC
There's also the matter of how userspace should pass this info to the kernel...

I imagine that most people using link-local addresses aren't going to be using name resolution. We'll need to standardize how IPv6 addresses should be inside a UNC name (most likely, we'll need to require square brackets around the address).

That's sort of a separate problem, however...
Comment 5 David Holder 2009-03-20 13:13:16 UTC
(In reply to comment #4)
> We'll need to standardize how IPv6 addresses should be inside
> a UNC name (most likely, we'll need to require square brackets around the
> address).
> That's sort of a separate problem, however...

Jeff, this is true but not as easy as adding a square bracket. We can't use square brackets in UNCs. They can be used for URLs and URIs RFC2732.

This is why MS have used the special domain names that contain IPv6 addresses as they cannot use the URL notation in UNCs. The domain is ipv6-literal.net and is a way of representing IPv6 addresses in UNCs. See my talk http://www.ipv6consultancy.com/ipv6blog/wp-content/uploads/global-ipv6-summit-taiwan-2008-ipv6-enabling-unix-linux-and-windows-integration.pdf for details.

Hope this helps,
David


 
Comment 6 David Holder 2009-03-20 13:28:33 UTC
(In reply to comment #3)

> The part I'm not sure about is how we turn that interface name into a
> sin6_scope_id field in the sockaddr_in6 that we pass to the connect op.

Jeff, this is not a problem as if you specify a scoped address to getaddrinfo() it does the right thing and sets the scope_id for you. Easy :-)

David
Comment 7 Debian samba package maintainers (PUBLIC MAILING LIST) 2009-04-04 05:18:55 UTC
*** Bug 6159 has been marked as a duplicate of this bug. ***
Comment 8 Jeff Layton 2009-04-04 05:52:24 UTC
I take it that this ipv6-literal.net convention is microsoft-only and isn't handled by getaddrinfo() automatically. Correct?

So we'd have to open-code an implementation of this ourselves. There's also a problem with that scheme. According to wikipedia:

"If the IPv6 address contains a zone index, it is appended to the address portion after an 's' character:"

    fe80--1s4.ipv6-literal.net.

...the problem is that our scopeid's are interface names. How do we distinguish an "s" in an interface name from the "s" delimiter that microsoft uses here?

Thoughts?
Comment 9 Jeff Layton 2009-04-04 05:54:44 UTC
FWIW, if MS' notation won't work for us and we have to invent our own anyway, then I'd just as soon make it so that we use square brackets in the UNC and be done with it.
Comment 10 Jeff Layton 2009-04-04 06:23:57 UTC
Hmmm... "%" doesn't seem to be forbidden in UNC's. I also don't see where square brackets are forbidden in a UNC:

    http://msdn.microsoft.com/en-us/library/aa365247.aspx

David can you elaborate on why we can't use a square bracket in a UNC?
Comment 11 David Holder 2009-04-04 06:43:22 UTC
Jeff,

You are correct. I'm not sure where I got that from now - I'll have to check through my notes. The problem is actually that : is not allowed. This means that any form of IPv6 address in a UNC is not possible.

David

Comment 12 David Holder 2009-04-04 06:46:48 UTC
(In reply to comment #8)
> I take it that this ipv6-literal.net convention is microsoft-only and isn't
> handled by getaddrinfo() automatically. Correct?
True. I have been thinking that it would be better to handle this as an NSS module.

> So we'd have to open-code an implementation of this ourselves. There's also a
> problem with that scheme. According to wikipedia:
> "If the IPv6 address contains a zone index, it is appended to the address
> portion after an 's' character:"
>     fe80--1s4.ipv6-literal.net.
> ...the problem is that our scopeid's are interface names. How do we distinguish
> an "s" in an interface name from the "s" delimiter that microsoft uses here?
> Thoughts?
This is handled by always writing the scope_id as an integer rather than using its name.

Comment 13 Simo Sorce 2009-04-05 11:55:04 UTC
I created a small NSS module to resolve ipv6-literal.net names on Linux.
It's just a hack, but I had fun and may help in this case:
http://samba.org/~idra/code/nss-ipv6literal/README.html
Comment 14 David Holder 2009-04-07 01:45:06 UTC
(In reply to comment #13)
> I created a small NSS module to resolve ipv6-literal.net names on Linux.

Simo,

This is great! Thanks. I will try and break it and let you know if there are problems.

David

Comment 15 Jeff Layton 2009-06-21 14:28:52 UTC
Kernel patchset proposed upstream and most of it has now been committed to Steve's tree. Once that's in place, I'll commit the userspace mount.cifs patch and that should wrap this up.

Comment 16 Jeff Layton 2009-06-29 07:11:13 UTC
Support for this is now in Steve's kernel tree and in mount.cifs in samba master branch. Closing case.
Comment 17 Jeff Layton 2009-09-10 07:30:41 UTC
Created attachment 4676 [details]
patch -- mount.cifs: add support for sending IPv6 scope ID to kernel

This is the patch that was added to the samba master branch for this. For it to actually do anything, you'll of course need a kernel that understands the address format (2.6.31 and maybe 2.6.30).