[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 5006 status
On Fri, 19 Mar 2010 09:26:29 -0400
"STARK, BARBARA H (ATTLABS)" <bs7652@att.com> wrote:
> My sense of what's going on in the industry is that there is a lot of
> momentum around RFC5006 being used inside home networks. It is widely
> stated and believed that clients and OSs exist that only support RFC5006
> and not DHCPv6 for DNS (v6 server) acquisition. Therefore, most router
> manufacturers and ISPs seem to be leaning towards putting RFC5006 inside
> the routers anyway, no matter the status of the RFC.
>
One possible explanation is that RAs have been supported by all IPv6
implementations since they were originally released, however DHCPv6
clients, relays and servers have only become available in the last 5 or
so years. Now there is at least one implementation available, for all
major end-node OSes. However, if people who you're getting opinions from
are still making the assumption of the lack of DHCPv6 implementations,
then they're quite predictably going to say that RAs should carry
everything, because all IPv6 implementations support processing RAs,
despite existing RA processing not currently supporting any of the
option they'd like to put in RAs.
> I say acknowledge the inevitable and make it a standard. There's no way
> to put this genie back in the bottle.
>
> Beyond RFC5006, I really, really hope that the IETF doesn't try to
> duplicate all DHCPv6 stateless config in RA (and I would have preferred
> not having DNS in RA -- but, like I said, what's done is done, and the
> inevitability of RFC5006 just has to be accepted).
>
> My concerns are centered around operations, testing devices to make sure
> they work, and troubleshooting customer configuration problems.
>
> When clients are given the ability to choose among multiple ways to do
> the same thing, this means that the router/server has to support *all*
> of these ways. Even if each is simple on its own, the complexity of
> supporting all methods is additive (at a minimum). All methods have to
> be coded, and all have to be tested. This doubles the effort of
> coding/testing on the routers.
>
> When a customer calls to complain that something isn't working, and it
> turns out something didn't get configured, we'll have to figure out
> first how it was expecting to get configured. This increases the
> complexity of troubleshooting.
>
> What I need, operationally, is predictability. All this discussion
> around "let's create half a dozen ways to do the same thing so hosts can
> choose the one they like best" is a recipe for failure. Every time the
> IETF creates a new way to do something that can already be easily done,
> you're introducing complexity and make it that much more likely that
> things will go wrong for the average consumer. Please, please, please
> -- Keep It Simple, for every device in the ecosystem.
> Barbara
>
>