Re: [mif] Route option for DHCPv6 - next steps?

["Tony Hain" <[e-mail]>]

Ted Lemon wrote:
> > I agree that you don't do something just because it was done in IPv4,
> >but  your response is exactly the same as your complaint about the
> >public  lynching. Just because your local network is not using this
> >mechanism is no reason to deny others from having it for theirs.
> 
> Lynching was a poor choice of words.   In any case, my point is that if
you
> have a real need for this functionality on your network, you should be
able to
> articulate that in a convincing way, and there should be some reason why
> DHCPv6 is a better solution than RA.   It shouldn't be the case that you'd
just
> rather use DHCPv6.

It appears you missed my point that my personal preference is to avoid using
DHCPv6 for this single function, because I have no other ongoing need. At
the same time, as I said my personal preference doesn't matter, and I will
defend the right of others to have the tools they expect. Like it or not,
there are people that wouldn't know what to do with their network without
the centralized point of all operational knowledge in their DHCP server. In
some cases this is due to internal politics, where the end system
administrators operate the DHCP service, and they refuse to turn over
control to the evil network ops team and whatever they might do.  In other
cases the network ops team operates DHCP with the explicit intent to assert
some control over those evil end systems. 

> 
> > people do operate VPNs with split tunneling, and need a way to push
> > the internal routes to the client. The operational pain will occur
> > when there is no option 121 for those networks that use it for IPv4.
> > The alternative is what I am doing; manually running a static route
> > script every time the vpn goes up and another when it goes down to
> > pull them back out.
> 
> What's missing from this description is "RA doesn't work well in this
situation
> because..."

One size does not fit all ...  The reason that operations is such a mess
right now is the ongoing and unnecessary war about which operational model
is "right", resulting in the absurd need to do logically associated things
in different places. There should be a mechanism that makes this work well
via RA, but that does not mean the DHCP approach is wrong. The IETF needs to
create a complete tool set for operating networks both with and without
DHCP. Again, one size does not fit all ...

When we started this IPv6 effort DHCP was just getting started, and going
through growing pains. At this point an entire generation of network
operators don't know any different and would be lost if you told them their
point of control in DHCP is gone. While a well-functioning RA mechanism is
needed, that is simply inadequate for people that don't know anything but
DHCP.

> 
> > Widespread deployment requires that people have the tools they want to
> > use for managing their local network.
> 
> Widespread deployment requires that people have tools that work well to
> manage their local network.  If the tools that we have given them thus far
do
> not work well, it should be easy to say why.   It's not the IETF's job,
nor
> should it be, to give them specific tools just because those are the ones
they
> want, any more than the building code should allow you to use deck screws
> in a shear wall just because you happen to prefer an impact driver to a
nail
> gun.=

Following that analogy, a large percentage of the network operators out
there have a hammer. It doesn't matter if you give them screws or nails,
they are going to  use the hammer they know. At the end of the day one of
those choices is more efficient and less frustrating than the other, but
both can get the job done. At the same time, leaving the screws and a
screwdriver laying alongside the nails will lead many to realize there may
be a better fit for their needs. When you meet people where they are
mentally, you have a better chance of discussing alternatives than if you
insist they leave their comfort zone and follow your 'one true way' into the
vast unknown. 

Tony