On 2011-05-23, at 23:56 , Mark Smith wrote: >> Christopher Morrow <christopher.mor...@gmail.com> writes: >> >> Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use >> whatever is available. That would have been simple and >> predictable. (And avoided 10GB of mailing list discussion!)
I'm totally with Christopher here. A flag is actually not necessary at al IMHO. Considering the huge address space and the fact that an IPv6 node usually has multiple addresses per interface anyway, one or two additional addresses make no difference for the node or the network at a whole. > What if both are available, Then a node has both, a SLAAC address and a DHCPv6 address. Where is the problem? The only problem I can think of is the issue I was trying to discuss here a couple of weeks ago: An address collision between SLAAC addresses and non-SLAAC addresses. Normal SLAAC should never collide with DHCP, since the 'u' bit is always 1 for a SLAAC address (globally unique) but should be '0' for a DHCP address (not globally unique). Only SLAAC with Privacy Extension could collide with DHCP (since it also has a 'u' bit of 0) and I was told on this list "Don't worry, the address space is so huge, this is probably never going to happen". I personally would have preferred if the standards reserved an address range within each /64 network that must not be used by SLAAC (regardless what kind of SLAAC, it is taboo) and thus is safe for DHCP pools or manual assigned addresses; however most people here seem to reject such an address range (for reasons I cannot really understand, since it would not hurt anyone in any way, but it could be pretty useful in real world scenarios). > Conflict > resolution in these sorts of situations isn't always simple and > predictable. Conflict resolution is not really necessary. What kind of conflict do you have to solve? If a network runs a DHCPv6 server that also hands out addresses, the network operators probably want people to use DHCPv6 over SLAAC, so if a host obtains both, an interface address via SLAAC and DHCPv6, then it should prefer the DHCPv6 address for all outgoing traffic, since if it uses the SLAAC address, a router may not forward their traffic or a firewall may drop it. If a network runs a DHCPv6 server, that does not hand out addresses (but possibly other useful information), then the operators probably want you to use SLAAC to obtain an address - in that case the system may use SLAAC or it may use SLAAC with Privacy Extension for outgoing traffic. If no DHCP server is present at all, SLAAC is your only option anyway. If there is a DHCP server but it refuses to talk to you or hand out an address to you, it is the same situation as if no such server was present. > I'm not particularly pro-SLAAC, however I sit back and wonder what is > missing from it that makes DHCP essential? The possibility to assign a specific address to a specific host, e.g. so that forward and reverse DNS resolution works for this host and so that you can create firewall rules on IP level. The same works with SLAAC, if you can for sure predict the interface identifier, but it will fail if privacy extension enters the game and also it means you have to update lots of configs whenever the interface ID of a node changes (e.g. NIC being replaced), in case of DHCP though, it is enough to store the new MAC address in the DHCP config and still assign the same IP as before to this host and everything will work as it used to. Sure, you can do the same thing by manually assigning IP addresses and not use DHCP or SLAAC at all but being able to manage all this from a central place (a single server that is DHCP server and DNS server at the same time, for example) is much simpler and a lot less error-prone(!); further if you want/have to change the assigned IP address of a single host or group of hosts, it will be much easier. > It seems to me that the > functional reason people want DHCP is that they think it will track > address use - but it won't if end-nodes are manually assigned static > addresses. However, on most systems you need admin/root access to do any such thing and normal computer users on those networks may not have those access rights to their systems. Also intentionally breaking thinks like forward/reverse DNS resolution has no advantages to the user, it only has disadvantages, so why would he want to do so? The only reason I could think of is bypassing firewall rules and for this, as mentioned before, the user must have admin/root access and even that may not really buy him something, since the firewall may drop any traffic from an IP address that has not been assigned by DHCP. So the only thing the user could do is manually assigning the DHCP address of another node to his node... and this will fail, ND will prevent that from succeeding. Sure, you can argue "what if a user uses a custom Linux system, with a custom kernel, that does not perform ND at all?"... but honestly, let's not go too deep into the topic security, security is certainly not the main argument for or against DHCP; I also doubt anyone ever said so. High security networks are the 0.01% case of all IPv6 networks and they may even require nodes to establish an IPSec tunnel to allow this host to send any traffic anywhere at all and/or shield network ports through VLANs and so on. Regards, Markus -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
