Re: How to extract IPv6 RAs?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux