Re: DHCP vs. RA... again.

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 3-aug-2007, at 22:46, Ralph Droms wrote:

> the network operators I was referring to are interested in DHCP- 
> only operation because, in their deployment experience, RAs have  
> proven problematic.

Can you go into detail here, please?

If stateless autoconfig doesn't work the way it should, we should fix  
that if we can.

It's also possible that their deployment causes the problem, and the  
problem may extend to DHCP too.

On 3-aug-2007, at 22:20, Tony Hain wrote:

> The IETF needs to stop trying to
> force the world to go a particular way and just make sure each  
> deployment
> model is complete.

Note that today, all IPv6 implementations (that I know of) support  
stateless autoconfiguration. It seems exceedingly unlikely that any  
vendor is going to remove that capability anytime soon, even if, for  
some strange reason, they decide that stateless autoconfig is never a  
good idea, because it won't be possible to assume the presence of  
DHCPv6 for many years to come.

On 3-aug-2007, at 22:19, Jari Arkko wrote:

> We also care about interoperability and the ability to talk to each  
> other; if we didn't we wouldn't need to work on standards. So far  
> in this thread I have heard people avoiding DHCP completely or  
> using solely DHCP. Its clear that the two extremes would have a  
> problem communicating... The architectural principles of the  
> Internet call for trying to find one solution, even if it is not  
> 100% perfect in all cases.

To me, being able to ignore DHCPv6 and use RAs only would be a  
feature. For other people, the opposite seems to be true. So as long  
as I get to use RAs and they get to use DHCP, we're all happy. Now  
obviously these days we tend to take our computers to "foreign"  
networks where the other configuration mechanism may be in place.  
Figuring out how to handle that would be an essential ingredient in  
any document that comes out of this effort.

I would also like to add that DHCPv6 is basically two different  
protocols that look alike: a stateful one and a stateless one. The  
problem here is that choosing the right variant is up to the client,  
which doesn't know whether the server will be offering stateful or  
statless information. I would like to see a situation where the  
stateless variant goes away and either the client uses full, stateful  
DHCPv6 or it doesn't do DHCPv6 at all and learns all information that  
it needs from RAs.

On 3-aug-2007, at 22:59, Pekka Savola wrote:

> If the host implementation bothers to implement DHCPv6, vendors  
> would be very hard pressed to argue why exactly they shouldn't try  
> running DHCPv6 on every time the host connects to a new network if  
> IPv6 is enabled.

That would be extremely suboptimal, because it leads to  
retransmitting requests. These are multicasts, so they take up _a_  
_lot_ of bandwidth on wifi networks.

Where did we land on the whole M/O bit issue again?

On 3-aug-2007, at 23:13, Ralph Droms wrote:

> Tony - in my opinion, "both are required" is not necessarily a  
> bizarre state.  Each performs a specific task.

I'm with Tony on this one (well, maybe not about the shooting). I  
haven't written a DHCP implementation, so I'll refrain from  
commenting on how complex those are, but rather observe that DHCP  
tends to use more packets than RA and both together certainly use  
more packets, many of them multicasts, which, again, are BAD on  
wireless networks: they're almost always sent at the lowest possible  
speed and as such, take up much, much more than their share of the  
available bandwidth.

> Unless the Chicago network deployed DHCPv6 and found it  
> problematic, I have to say that the Chicago network was in any way  
> instructive to the specific debate about IPv6.
> Lessons learned from misconfigured DHCPv4/DNS services have no  
> bearing on this discussion.

It shows that the DHCP architecture is vulnerable to single points of  
failure. Many things in life are, and this is often unavoidable, but  
telling people they MUST run such a protocol for uses that can just  
as easily be served by protocols that don't suffer from such  
architectural limitations isn't a good thing.

On 3-aug-2007, at 23:16, Tony Hain wrote:

> Get over it and define both mechanisms. Let the operational  
> community decide
> what they will and will not support in their deployments.

[...]

> I am not saying DHCP is wrong, just that forcing a one-size-fits- 
> all answer
> is wrong.

Agree 100%.