IPv6 Deployment for the LAN

Thu Oct 22 18:10:10 UTC 2009

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