David W. Hankins wrote: >The fundamental problem is that DHCPv6 does not supply a prefix length >along with the configured address. It is just an address, so the >advertised prefix length in this sense could be said is /128. >From what I came to understand the received address should be matched against prefixes received by means of RA for their network mask. The network scenario here is as follows: public IPv4 subnet with /21 mask, IPv6 subnet with /117 mask (matching length, so the addresses can be easily mapped on each other), and none of the solutions (netmasks /64 or /128) work correctly. with netmask /128 I would be able to use the Internet (as the default-route uses link-local addressing), but I won't be able to connect to other computers in the network (for FTP filesharing for instance). with netmask /64 I would be able to connect to the Internet and other computers on local network, but I won't be able to connect to computers using other parts of the /64 network (used for easy and consistent mapping between v4 and v6 addresses and not because of lack of v6 addresses) but physically being behind a router. as mentioned in the original mail, I understand the use of /64 prefix length in case of not having received a prefix info in RA for address received from DHCPv6 (this covers the case where there are no received RAs, when the router is dead for whatever reason) the only solution I see (apart from specifying netmask in DHCP reply, that is) is to remember the prefixes (in kernel, as no userspace daemon like NetworkManager should be required for network configuration) and give the user a way to retrieve this information (like fBSD has, with "ndp -p"). DHCPv6 client can then use this tool to get a prefix length for received address before setting it (eg. in dhclient-script in case of ISC dhclient). As dhclient-script is already platform-specific, there is no problem in having different tools for different OSes, but in an ideal world there should be a shared network API across UNIX-like systems so that there would be no need for platform-specific "glue layers" like dhclient-script. in the case of aformentioned NetworkManager (referred to as NM further on), this task is easier, as NM already has seen the prefix information (and used it only to determine whether to use DHCPv6 client or not, throwing it away afterwards) and uses a custom dhclient-script. However, due to NM code being mostly crazy sending of dbus messages, I have not been able to determine the code responsible of receiving the information from NMs custom dhclient-script. As mentioned before, Linux should be able to use DHCPv6 without having to use NM. as for sending prefix length in DHCP reply by default, this would work if the server was using ISC DHCP server (which in my case is, but is not guaranteed to be the case), and the network administrator has to use the new version and not disable the prefix length information (which in my case is a problem, because he is a little too keen on not doing anything unnecessary, when a working implementation without it exists, in this case windows7) so again, just to be perfectly clear, the main question: does Linux store prefix information received by form of RAs? if so, how to access this data from user-space? if not, where should this data-store be implemented? from what I can tell the answers are "no" and "probably somewhere in net/ipv6/addrconf.c", but I am hoping for answer from someone with more knowledge in this area than me. Thanks, Pavel PS: sorry for late reply, I am not subscribed to the list, please CC me on this thread -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
