It is not that DHCPv6 cannot be made secure, it is that the M/O bits are
an automatic and insecure way to trigger an external configuration mechanism.
So you object to the security level of DHCPv6 rather than that of the M and O bits?
You should read what I just said above before commenting too quickly.
"It is not that DHCPv6 cannot be made secure" doesn't sound like a whole-hearted recommendation to me.
I have nothing against DHCPv6, but against insecure commands that trigger a configuration mechanism, any configuration mechanisms.
Ok.
So what is the alternative? If there are no M and O bits, people implementing DHCPv6 will have to perform DHCP *always* so there is no protection against a rogue DHCPv6 server over the situation you describe.
Again you commented without reading what I wrote.
I don't think so.
People who run DHCPv4 on the client side decide to do so, it is not that DHCPv4 client is triggered by a remote mechanism.
As I explained in my message, even though DHCPv4 and DHCPv6 in themselves are pretty much the same thing, their place in the order of things is very different because IPv6 also has stateless address configuration and IPv4 doesn't.
I never said that if you implement DHCPv6 you MUST always turn it on.
This is a decision that has to be made by the person configuring the host.
I agree in principle. I'm afraid that if DHCPv6 becomes widespread it will be turned on out of the box, though. So we should be prepared for that.
If you want people to enable DHCPv6 manually: ok, no problem. But why would the M and O bits be in the way in that case? Just ignore them.
Because the specs says I should (lower case) obey M & O. Read what I wrote.
So then we make the spec not say that.
Maybe because the IETF has no business to tell people in which way they should run their network, but only to provide them guidance on how a certain task can be performed in an interoperable way IF and WHEN the operator decides they want this task to be performed in the first place.
This is a general statement that nobody can disagree with but has no relevance to the discussion.
Sorry.
It has a lot of relevance. Obviously, when someone wants their hosts to be configured through RAs or through DHCP, then the implementation should follow the respective rules of the protocol in question. But which protocol (if any) someone wants to use to configure their hosts isn't something that should be standardized. This goes directly to your objection that when the M/O bits are set you should (lower case) do DHCP.
To give a hint that DHCPv6 is present?
Don't you consider this useful?
Ah, this is a very good question, actually, at the core of the discussion.
Thank you for asking it.
I'm not sure this is useful. You seem to think it is. Please tell me which problem it solves.
Ever since I got myself an IPv6-capable laptop I hardly leave the house without it. :-)
Now at present, it doesn't support DHCPv6. But suppose in the next version of my favorite OS DHCPv6 is supported, and I decide I want to run it. So far so good. But if I now take my laptop to a place where there is no DHCPv6 server, I either have to reconfigure my network settings (always a drag) or I have to wait for DHCP to time out.
It gets more complex when I really want hosts to use DHCP exclusively and not use stateless address configuration. Simple solution would be to turn off RAs, but then hosts that don't support DHCPv6 don't work anymore (and I don't have anything to fall back on when the DHCP server(s) are down). So in these cases I want RAs to be present, but have them be ignored by hosts that support DHCP.
This can all be accommodated by changing the meaning of the M and O bits slightly (in a backward compatible manner) as I outlined in a message a few days ago.
And even if we don't want to do this here and now, it's more useful to leave the bits in place and revisit the issue later in another document rather than remove or deprecate them.
Host should not blindly believe this unless the RA are secured.
So what kind of bad stuff is going to happen when hosts start querying a rogue DHCPv6 server? I think the main problem is that traffic can be redirected through a rogue router which then has the opportunity to perform man in the middle attacks. However, the rogue system can just as easily perform the same thing using just RAs.
Not only that. A host might have been previously configured with the address of a DNS server. There is a risk that the O bit will trigger a query to find out the DNS server, and a corrupt entry will either override or complement
the correct one. This way the attacker could redirect part or all of my web traffic wherever he wants without having to mess with the routers. Of course DNSsec will help, but it is not there yet.
Ok.
However, wouldn't this be an issue that is best addressed in DHCP? I can imagine DHCP info being protected using a certificate, and clients only accepting DHCP information from servers that they have a certificate for.
IPv6 hosts have enjoyed the benefits of stateless address configuration for years and it's very likely that huge numbers of people running IPv6 networks will never want to run DHCPv6. So requiring hosts to always try DHCPv6 doesn't make any sense.
You obviously did not talk to the same IT folks in large enterprises I do.
Probably not, and certainly not about DHCPv6.
I'm not saying DHCPv6 is useless and nobody wants it. What I'm saying is that it's perfectly possible to run an IPv6 network without DHCPv6 and many people will continue to do so. Whether this will be 10/90, 25/75, 50/50, 75/25 or 90/10 % doesn't matter much in the long run as even 10% of the networks running IPv6 is going to be a huge number in the long run.
Many do not like stateless autoconf much and would like to run DHCPv6 for address allocation. There are a number of very good reasons for that, especially for servers.
Sure. There are also good reasons to not want to run DHCPv6, so we'll see people do both. (Quite possibly within a single network, too.)
And again, "requiring hosts to always try DHCPv6" is not what I want.
I'm saying, if a host wants to try DHCPv6 for its configuration, that is fine, but this is a configuration decision, and there are many situations where it is not wise to have DHCPv6 triggered automatically by insecure messages on the network.
I agree. However, there are situations when security isn't the first consideration (it's always _a_ consideration of course) and then having the bits as hints to avoid engaging in a protocol that will only time out will be very useful. Also, RAs are insecure today but that doesn't have to be so in the future.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
