Subject: M & O bit discussion today

From: "Tony Hain" <[email-masked]>
Date: Tue, 2 Aug 2005 15:41:08 +0200

I choose not to try to get to the mic, but on the debated requirement point
3; why is there a belief that the DHCP relay information is correctly
configured if the simpler set of 2 bits is improperly configured? 

I agree that point 1 & 3 are in direct conflict and that 1 is the real
requirement.

Hosts should never try to outguess the specific instructions from the
router... This means that even the case of M & O clear without a prefix
should not result in a DHCP request. This only invites rouge DHCP servers as
a DOS attack. One valid case for M & O clear without a prefix would be a
router retracting the delegated prefix when the link associated with that
prefix fails. When all such upstream links fail there should be no prefix
unless the network manager has configured a ULA prefix. The lack of a prefix
is not a configuration error, and hosts should not go off randomly doing
something they have been instructed not to do. 

Tony 

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

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 03 Aug 2005 00:15:52 +0900

As I pointed out, all requirement doesn't have any
explicit conclusion, rather just refering them to make
more shape requirement.

Several guys from IPv6 meeting room (and mailing list)
are saying that we don't need to care about Requirement 3.
Also, Requirement 1 is at least acceptable and Requirement 2
remains without any decision...

1) Ability to indicate to a host "DHCP is not available on this link",
   with the expectation that the host won't send any DHCP messages

2) Ability for a host to get all desired and available DHCP
   configuration with a single DHCP message exchange

3) Ability to do DHCP without having to configure routers
  (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or
  ICB anyway)

I am asking some questions like below;

1) Which requirement is acceptable (and which is not acceptable) ?
2) Other requirements to be considered ?

Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Lab., SAMSUNG Electronics.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Aug 2005 23:20:11 +0200

> configured if the simpler set of 2 bits is improperly configured?

I think a case can be made for the notion that most routers and most  
networks don't implement the bits today, so seeing MO==00 doesn't  
really authoratively say there is no DHCP service, but just that the  
routers operate in a default configuration.

So it would be useful to redefine MO==00 to mean "no opinion" and  
come up with a new value that indicates authoritative information  
that DHCPv6 is unavailable and/or shouldn't be used.

> I agree that point 1 & 3 are in direct conflict and that 1 is the real

In the scenario above that wouldn't be the case.

(Having DHCPv6=Y/unknown/DHCPv6=N also increases the likelihood that  
OS vendors will be prepared to enable DHCPv6 when MO==00 by default,  
they may / hopefully will not want to do this if there is no other  
way to indicate the absence of DHCPv6 servers.)

> router...

Agree, especially in this case where it leads to continuous extra  
multicast traffic (don't forget that multicast takes up much more  
bandwidth than unicast on wifi, a reason why we should think twice  
about draft-pashby-ipv6-network-discovery-00.txt).

> This means that even the case of M & O clear without a prefix
> is not a configuration error,

I believe it is: the router is still advertising itself as a router,  
implying it can reach the rest of the world. This is harmful. (I  
think there is a need to study the permutations of different prefix  
and RA timeouts and their effects, I'll bring that up in v6ops.)

---

From: Stig Venaas <[email-masked]>
Date: Wed, 3 Aug 2005 09:50:20 +0200

> routers operate in a default configuration.

This sounds like a good suggestion to me.

> that DHCPv6 is unavailable and/or shouldn't be used.

I believe they should indicate whether DHCPv6 is available or not
(possibly also stateful/stateless). Clients should then generally not
do DHCP when they are told it isn't available (in particular with the
"no opinion" option, there shouldn't be a need to try). If clients are
told DHCP is available they could still choose not to use DHCP based
on the client configuration, type of client etc.

I don't want the bits to tell clients to do or not do DHCP request,
because on a link there may be some clients that should not do DHCP
at all, while others that need DHCP to function.

> way to indicate the absence of DHCPv6 servers.)

Without the "no info", vendors may have to set the default to say DHCP
is available. I would rather see "no info".

Stig

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Aug 2005 10:53:29 +0200

> 2) Other requirements to be considered ?

As someone who gets called when the day-to-day admins can't figure it  
out, I feel it's important that all of this is as predictable as  
possible. That means that I want to know whether hosts are going to  
get addresses from a DHCPv6 server or just other configuration  
information. Waiting to see what the DHCPv6 server is in the mood for  
today makes me very uncomfortable.

So what I'd like to require is that hosts only ask for and/or accept  
addresses when the right RA bits are set, and don't ask for addresses  
and reject them if they get them anyway while RAs indicate that  
DHCPv6 should only be used for other configuration.

---

From: Syam Madanapalli <[email-masked]>
Date: Wed, 3 Aug 2005 10:59:16 +0200

> routers operate in a default configuration.

Does this mean that the current implementations always do the DHCPv6
irrespective of the bits?

> that DHCPv6 is unavailable and/or shouldn't be used.

If we define the 00=No Opinion, then we may need to use 11 to convey
unavailability of DHCPv6, may not be good symantics.

If we agree that we need to convey 'availability', 'unavailability' and 
'no opinion; then how about the following combination

M    O

0      0     -  DHCPv6 Not avaialble
0      1     -  Only DHCP6v lite
1      0     -  Full DHCPv6
1      1     -  No opinion (router does not know if the DHCPv6 avaialble or not)

-Syam

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 3 Aug 2005 05:43:27 -0400 (EDT)

Hi Tony,

> I agree that point 1 & 3 are in direct conflict and that 1 is the real

This is my real problem as I said at the mic. I personally like 
Requirement 1 more than requirement 3. If requirement 3 is absolute, 
we might as well have these flags removed altogether as the 
hosts do not care.

Cheers
Suresh

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Aug 2005 12:34:44 +0200

> irrespective of the bits?

I only know a limited number of DHCPv6 implementations (KAME, Cisco)  
but those don't consider the bits. Apparently, they assume the daemon  
is only run when the bits are set in some way, and/or when the daemon  
is run, DHCPv6 should be done period.

> unavailability of DHCPv6, may not be good symantics.

I agree that it's contrary to the existing definition of the bits,  
and it no longer allows considering either bit individually.

Actually on rereading RFC 2462:

                        In addition, when the value of the  
ManagedFlag is
                        TRUE, the value of OtherConfigFlag is  
implicitely
                        TRUE as well. It is not a valid configuration  
for
                        a host to use stateful address autoconfiguration
                        to request addresses only, without also  
accepting
                        other configuration
                        information.

it seems that the "unused" bit combination would be MO==10.

> 1      1     -  No opinion (router does not know if the DHCPv6  

This requires that routers are explicitly configured to allow DHCPv6.  
Personally, that doesn't bother me, but this goes against requirement  
3 on Jinmei's now infamous list of three requirements.

It's probably better to have a value that authoratively indicates  
that DHCPv6 MUST NOT be used rather than use the current 00 value  
that is present on all routers out of the box, so 00 can easily be  
interpreted as laziness rather than the desire to not run DHCPv6.

Answering points brought up by others in other messages: requiring  
hosts to know which interfaces they should and shouldn't run DHCPv6  
on by default seems very unattractive to me, to say the least. This  
doesn't allow for bridges between different network types and it also  
doesn't address the desire to avoid running DHCP for various reasons  
other than resource conservation.

---

From: Tim Chown <[email-masked]>
Date: Wed, 3 Aug 2005 11:47:02 +0100

> we might as well have these flags removed altogether as the 

Yes, advance 1 and discard 3.  Explore ramifications of 2 in dhc WG.

-- 
Tim/::1

---

From: Perry Lorier <[email-masked]>
Date: Thu, 04 Aug 2005 00:43:53 +1200

Iljitsch van Beijnum wrote:
> possible. That means that I want to know whether hosts are going to  get
> addresses from a DHCPv6 server or just other configuration  information.
> Waiting to see what the DHCPv6 server is in the mood for  today makes me
> very uncomfortable.

What worries me more is machines going off and using some other random
DHCPv6 server that some monkey has plugged into the network.  Sure this
situation shouldn't occur, but how many times have you seen it take a
currently functioning network down?

If a network is designed to not need dhcpv6, then having a client decide
to do dhcpv6 can only end in pain and suffering.