IPv6 Deployment for the LAN
Iljitsch van Beijnum
iljitsch at muada.com
Thu Oct 22 15:44:48 UTC 2009
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.
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.
>> 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.
> 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.
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.
> 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.
More information about the NANOG