Subject: RE: [dhcwg] Re: purpose of m/o bit

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 1 Jun 2005 08:25:59 -0400

> 4 Ability to do DHCP without having to configure routers

I'm not sure I'd draw that conclusion. I think the point was that hosts
*MAY* ignore any RA "hints" and do what they are manually configured to
do - whether that is to run DHCPv6 always or never. But this is not
something that needs to be explicitly stated - it is implicit in the
current definition of the bits because they are SHOULD, not MUST.

> 3 Ability to limit DHCP use to other configuration only

This can be accomplished in two ways - have clients only send
Information-Request OR allow them to send Solicits and "fix" DHCPv6 to
allow only other configuration parameters to be communicated in an
Advertise. Of course, the latter has come interoperatability issues with
existing implementations.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Iljitsch van Beijnum
> Sent: Wednesday, June 01, 2005 8:05 AM
> To: Ralph Droms (rdroms)
> Cc: [email-masked]; IETF IPv6 Mailing List
> Subject: [dhcwg] Re: purpose of m/o bit
> 
> On 1-jun-2005, at 13:31, Ralph Droms wrote:
> 
> > We need to agree on requirements before we try to engineer 
> solutions.
> 
> :-)
> 
> > Here is what I've heard as requirements:
> 
> > 1) Ability to indicate to a host "DHCP is not available on 
> this link",
> 
> > 2) Ability for a host to get all desired and available DHCP
> >    configuration with a single DHCP message exchange
> 
> > Comments?
> 
> 3 Ability to limit DHCP use to other configuration only
> 
> And, apparently:
> 
> 4 Ability to do DHCP without having to configure routers
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Jun 2005 18:24:17 +0200

> do

Treating RA information that DHCPv6 servers aren't available as a  
hint and ignoring the hint is an implementation of the ability to do  
DHCP without having to configure routers.

> - whether that is to run DHCPv6 always or never. But this is not

Doing DHCPv6 when there is positive knowledge that there is no DHCPv6  
server is suboptimal, and may have nasty security implications.  
(Especially when we get SEND for secure RAs.) It is also very  
wasteful in bandwidth constrained environments. It is of course  
possible to implement all kinds of heuristics to determine where and  
when we can do DHCPv6 when the hints say "don't do it", but I think  
upgrading from "yes / no" to "yes / default behavior / no" makes more  
sense.

> existing implementations.

Right.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 2 Jun 2005 00:27:26 +0200

On 1-jun-2005, at 18:24, Iljitsch van Beijnum wrote:

[always cool following up on your on posts...]

Because I fell in the middle of this discussion, and there seems to  
be a rather substantial disconnect between my views and those of many  
others, I decided to read up on earlier posts a bit.

I must say that I'm somewhat concerned by what I saw. A prevalent  
position was "let the administrators figure it out, this isn't the  
IETF's business".

I strongly disagree here. We're talking about AUTOconfiguration here.  
Obviously, administrators should always be free to configure their  
networks in any way that pleases them. However, in order for good  
things to happen AUTOMATICALLY, it's necessary that administrators  
can predict the default out of the box behavior of hosts, so that  
they can set up their equipment to make those hosts work well in  
their network.

The fundamental issue here is the question whether it's ok to ALWAYS  
do DHCPv6. I don't think that the position that this is the case is a  
reasonable one, because:

- it wastes bandwidth which is harmful in bandwidth and/or power  
constrained environments
- it makes it impossible to get consistent behavior from a set of  
hosts that include hosts that do implement DHCPv6 and hosts that  
don't implement DHCPv6
- it allows the introduction of rogue DHCPv6 servers in otherwise  
secure environments (rogue DHCP servers are a big problem in ad-hoc  
IPv4 networks)
- it makes it harder to contain the bad effects of incorrectly  
operating DHCPv6 servers (I believe it's very easy for DHCPv6 servers  
to assign addresses that are inconsistent with router configurations  
and thus not routable)

So if doing DHCPv6 in all cases isn't acceptable, we clearly need  
very specific guidelines about when DHCPv6 MAY or SHOULD be used and  
when it MUST NOT be used.

We desperately need to avoid the situation where people are forced to  
filter out DHCPv6 packets because it's the only way from stopping  
hosts from doing DHCPv6 out of the box.

Note that any comparison to DHCP in IPv4 is meaningless as there is  
no stateless autoconfiguration in IPv4. DHCP is ubiquitous in IPv4,  
but it's almost inconceivable that it will attain the same status in  
IPv6. This means the protocol has to know when to bow out gracefully.

In the mean time, the dhc working group has come up with two  
variations of DHCPv6 which aren't interoperable: the stateful version  
that uses Solicit messages, and the stateless version that uses  
Information-Request messages. It is obviously harmful to have a  
network that only has servers that support the stateful variant and  
then have hosts that only use the stateless variant, or the other way  
around. The situation where both variants are executed  
simultaneously, or when one is tried first and the other afterwards,  
are also problematic because of unnecessary extra bandwidth use or  
additional delays. Mandating that servers forever support both  
variations is probably the least harmful solution, but it's still  
less than optimal.

Clear guidelines about which DHCPv6 variation MUST be used in which  
situation is clearly beneficial here.