I'm very much opposed to extending RA for this purpose. Having 2 ways to do the 
same thing serves to increase complexity of the overall ecosystem. Unless you 
can guarantee that the 2nd method will only ever be used in a closed system 
(network manager consciously knows that this is the mechanism all installed 
devices support and will use, so that interoperability is guaranteed). If you 
cannot guarantee that it will only exist in a closed system and that no user 
will ever be confused, then by introducing a 2nd method, you are increasing 
complexity (more than doubling it, for this function) for the majority of 
devices (that will have to implement both to be assured of interoperability, 
and will have to implement "tie-breaker" functionality as well). Doubled 
complexity for the majority in order to achieve increased simplicity for a 
minority is a Bad Idea.

 

Whenever there are 2 ways to do the same thing, decisions must be made 
regarding the positioning of both methods in the marketplace. Specific to this 
proposal, the following scenarios are possible outcomes:

1. Clients that consumers (residential, small, and medium business) expect to 
interoperate in an open (not single vendor, no "check for special 
restrictions") environment are unpredictable and will do one or the other. 
Therefore, routers that expect to interoperate in an open environment must do 
both. This outcome successfully doubles the complexity of providing NTP info 
via a router, because the router must support both DHCP and RA methods. This 
happened with DNS. Most routers are supporting both ways. Ugh. But it is what 
it is. So with DNS the router people bit the bullet and did double the 
complexity. 

2. Routers that consumers expect to interoperate in an open environment are 
unpredictable and will do one or the other. Therefore clients that expect to 
interoperate in an open environment must do both. This outcome successfully 
doubles the complexity of a client who needs to get NTP. Also a bad thing. 

3. The people who ask for the special RA capability say that the RA capability 
is only for use in special closed environments, and consumers will never find 
themselves confused by trying to use these devices in an open environment. 
Really, it will be ok, and it will never morph into outcome 1 or 2 above. Or 
outcome 4 below. We promise.

4. [my favorite] Neither clients nor routers can predict whether they will find 
themselves in an environment where only one or the other is supported. So both 
clients and routers that expect to be fully interoperable must support both. 
The majority gets to double their complexity. So that a minority can simplify 
just a little bit.

 

Barbara

 

From: [email protected] [mailto:[email protected]] On Behalf Of Roger 
Jørgensen
Sent: Sunday, December 25, 2011 9:06 AM
To: Doug Barton
Cc: 6man Mailing List; Brian E Carpenter
Subject: Re: IPv6 Router Advertisement Option for Foobar Configuration

 


On Dec 23, 2011 8:57 AM, "Doug Barton" <[email protected]> wrote:
<snip>
> What I *am* saying is that extending RA is always the *wrong* answer.

Yes it is. Keep RA simple and lets solve "problems" elsewhere, dhcp is the 
current tool.

--- Roger J ---

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to