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!
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?
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?
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.
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...
(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
(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
*** Bug 6159 has been marked as a duplicate of this bug. ***
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?
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.
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?
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
(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.
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
(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
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.
Support for this is now in Steve's kernel tree and in mount.cifs in samba master branch. Closing case.
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).