On Oct 16, 2008, at 7:18 AM, Iljitsch van Beijnum wrote:
Anyone in the cellular industry reading this? What about firing up
transmitters and using up battery every 120 seconds for a protocol
that you KNOW isn't going to do anything useful?
In order for this to be a valid rejoinder, it would have to be the
case that the cellular industry was planning to use IPv6 autoconf
combined with RAs to get IPv6 addresses. It's not my understanding
that this is the case. In fact, we added the DHCPv6 rapid commit
option specifically for low-power applications like the cell phones.
It's true that a low-power device that wants to use a network where
autoconfiguration is the only option would waste a lot of batteries
trying to do DHCP. But it's not required to do so. I would expect
the implementation to take into account the circumstances under which
it was being used.
The only time I have trouble with RAs is when there are rogue routers
on a subnet. But this happens with rogue DHCP (v4) servers as well so
no difference there.
The good thing about RAs is that my systems always get the same
address without having to configure stuff and/or have a server keep
track of leases. RAs also react to changes in addresses or presence of
routers in a reasonable way, which DHCP can't. RAs also share fate,
which you can only do with DHCP if the server runs on the router.
I actually agree with your conclusion that RAs don't suck, but I will
point out one flaw in your reasoning here. RAs follow a push model.
A server sends out an RA, and recipients are expected to change their
network configuration on that basis. DHCP follows a handshake model,
where the client asks a question, and the server answers it.
In the push model, if you have no pre-established authentication,
anybody can push out a new network configuration change, and if it's a
bad configuration, your network is dead until you can track down the
miscreant and disconnect it. In the handshake model, there are very
restricted circumstances under which you can change the configuration
of the client - only when the client asks you a question can you give
a wrong answer. And in doing so you are competing with the
legitimate answer, and the client will typically see both answers and
prefer the same answer it heard before.
So a network that uses DHCP for configuration will be much harder to
DoS. And more to the point of your reasoning, DHCP and RA do not
share the equivalence that you claim they share in the first
paragraph. The behavior of a rogue DHCP server is very different
than the behavior of a rogue RA server.
IPv4 doesn't have and can't have stateless autoconfig. It could have
RAs for default gateways and dead neighbor detection so VRRP is
unnecessary, but the current stuff works well enough that it's not
worth the trouble to try to upgrade the entire IPv4 internet. That
doesn't mean that a 25 year old protocol with 15 year old extensions
should be the blueprint for the future.
Actually, there is Bonjour, which works quite nicely for stateless
IPv4 address configuration. And we used to use RIP on IPv4
networks. RIP is a lot like RA. I haven't seen RIP in use anywhere
in a long time - not since the mid-nineties. Why not? DHCPv4 is
preferable. By preferable, I mean that that's what everybody's
chosen to use, even though they are free to use RIP. I don't mean
"hypothetically better."
Whether the same relationship holds with RAs and DHCPv6, I couldn't say.
Bob Hinden pointed out that RAs are modeled after IPX. I find this
observation quite interesting - I used to work at a bank where we had
large networks with IPX. The network was virtually unusable half the
time because of the wild packet storms that would occur due to IPX
broadcast traffic. I don't mean to say that a network operated with
RAs would have the same characteristics, but the fact that IPX was
widely used in corporate environments in the nineties is not a reason
to consider it a good model. IPX has been almost completely replaced
by IPv4. Why? We could speculate that it's because it works
better, but we don't really need to do that. The market has spoken.
So why isn't there a subnet length field in DHCPv6 address assignment?
Because every time it comes up, non-DHC people say "just use router
advertisements to figure out the prefix length."
The whole notion that we need
to specify a binary format for every new piece of data that may need
to be configured and then wait until both clients and servers are
updated is completely outdated.
Updating an XML schema every time you get a new option is no different
than updating a server configuration or client configuration to
understand a new option. Most existing DHCP clients and servers are
able to be so updated by the user, without any requirement for a
software update, just as would be the case with XML/HTTP.
The internet isn't your personal playground where you get to change
stuff just because you don't like it anymore. Changing stuff costs
money, a tiny bit for vendors and huge amounts for operators. It's not
yours to spend.
That's right. But we are discussing a real problem here, not a
hypothetical problem. We need to solve the real problem. All these
digressions on which protocol is better are fascinating, but not to
the point, unless the solution is to deprecate one protocol or the
other, which I think is unlikely.
So we need to come up with some actual guidance as to what
implementors should do.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
