Re: IPv6 Deployment for the LAN

[Iljitsch van Beijnum <iljitsch () muada com>]

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.