On Oct 22, 2009, at 8:44 AM, Iljitsch van Beijnum wrote:
On 22 okt 2009, at 17:03, Kevin Loch wrote:
If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.
In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see.
Lots of people "need" a gun. If I were living in a place where bears walk around loose I might "need" one, too. But most guns are used to shoot the owner in the foot most of the time. The world would be a better place without them.
As a strong proponent of the second amendment, it is now clear to me that we have a fundamental disagreement on how society should interoperate which is unlikely to ever be resolved between us.
Like I said, if there's a bunch of routers announcing their presence and you want a DHCP option to provide guidance to a host as to which one to choose, that would be fine. But pointing to a potentially non- existing address in the hopes that there will magically be a router residing at that address would a serious regression in robustness.
It really isn't a serious regression in robustness in the real world. It really is functioning today. Most DHCP servers are not used to shoot users in the head, despite your claims to the contrary.
There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways.
Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility.
What does that have to with anything? IPv6 stateless autoconfig predates the widespread use of DHCPv4.
Hmmm... Perhaps you should be asking yourself why IPv6 SLAAC was not used as the model for address assignment in IPv4 instead of DHCPv4 in that case?
Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap.
Absolutely not. Give users the choice between something good that suits their needs 83% and a piece of crap tht suits their needs 84% and they'll choose the latter each and every time.
Yes... As well they should. Meeting their needs 84% of the time is actually vastly superior.
Users get to say what they need. They don't get to design the solution by committee any more than they get to design bridges or airplanes by committee, although of course they do get to choose which ones to use.
Depends on how you define users. If you don't think that airlines have a substantial amount of technical input into how airliners are designed, you are vastly mistaken.
At conferences I keep hearing "It would be great if the IETF had more operator input." Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work.
How do we fix that?
Tell the IETF your real requirements, don't try to do back seat protocol design. Protocol design is hard, the IETF gets it wrong most of the time (and they do better than some of their colleagues, still). Suggesting specific changes to a protocol as a solution to an unstated real requirement wastes everyone's time.
With writing, they tell you "listen when people say there is a problem, but ignore them when they tell you what the problem is". Same thing here. Users know their needs, but generally they don't know the best way to meet those needs.
OK... Here's the real requirement: Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to: 1. Default Router 2. DNS Resolver information 3. Host can provide name to server so server can supply dynamic DNS update 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) 5. NTP servers 6. Boot server 7. Site specific attribute/value pairs (ala DHCPv4 Options) These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured. Owen