Subject: resuming M/O discussion...

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 07 Nov 2005 02:54:46 +0900

Perhaps too delayed, but I'm going to re-invoke the hibernating
discussion of the RA M/O flags, hoping it's better than nothing.

The following is the requirements we might seek regarding these flags,
derived from the previous discussion with slight modification based on
the intermediate discussion results:

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

   1') we may also want to indicate a stronger message of "do not try
       to find it" for some networks in requirement 1.  Possible
       scenarios include bandwidth-sensitive networks (such as 3G?)
       and the case where attacks of rogue DHCPv6 messages are
       concerned.

2) Ability for a host to get all desired and available DHCP
   configuration with a single DHCP message exchange
   - if a host wants HCB, it sends an HCB request (Solicit) and receives
     HCB and/or ICB replies
   - if a host wants ICB, it sends an ICB request (Information-request) 
     and receives ICB replies

(There was another 'requirement' about the flexibility of host/client
behavior, but I believe we should remove or separate it, at least for
now)

Ability 2 can be done through some modifications/extensions to DHCPv6.
I think I had some level of agreement on the extensions.  But since
the detail will also depend on requirement 1, we first need
concentrate on requirement 1.

On one hand, requirement 1 can be regarded as already achieved by
saying M=0 indicates HCB is not available and O=0 indicates ICB is not
available.  Also, if we want to make a stronger indication, we may add
"SHOULD NOT" to the host's behavior in this case (I think the general
sense of the previous discussion was "SHOULD NOT" is the most
appropriate term if we needed to specify one).

On the other hand, there will still be a host which invokes HCB or ICB
regardless of the M or O flag in RAs.  In fact, since the M and O are
set to 0 by default, these flags being 0 could simply be regarded as
"no information".  And since the ICB is currently the only
standardized mechanism that can provide some essential configuration
information such as recursive DNS server addresses, an implementation
of autoconfiguring host may try ICB anyway, just like today's many
IPv4 host implementations keep trying DHCPv4 for address
configuration.

If we can simply ignore such implementations as 'buggy' or
'non-compliant', the discussion is probably almost over.  But I saw
some opinions that we should provide stronger and non-default
indication of "non-availability" of DHCPv6 services so that (e.g.,) a
network administrator can suppress attempts of HCB or ICB with
stronger confidence.

So my first question toward the possible next step is: do we need the
"stronger and non-default indication of non-availability"?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

Note: HCB and ICB are defined in draft-ietf-ipv6-ra-mo-flags-01.txt.
In short:

HCB: Host Configuration Behavior
     getting address (and possible other) configuration information
     by Solicit/Advertise/Request/Reply exchanges
ICB: Information Configuration Behavior
     getting other configuration than addresses (excluding addresses)
     by Information-request/Reply exchanges
("HCB" or "ICB" may not be the most appropriate terminology, but
 "stateless" vs "stateful" can be confusing either in that "stateless"
 can mean either stateless addrconf or stateless subset of DHCP)

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Nov 2005 04:27:43 +0200 (EET)

As there have been no follow-ups, let me just say I agree with all of 
what you wrote here, and (IMHO) I'd answer "No, I don't see 
sufficiently strong justification" to the following:

On Mon, 7 Nov 2005, JINMEI Tatuya / ¿ÀÌÀÃ£ºÈ wrote:
[...]

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings