Subject: [dhcwg] a summary of M/O flags requirements

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 26 Jul 2005 23:22:49 +0900

Hello,

I've (re)read the whole big thread on the recent discussion about the
RA M/O flags starting at around end of May.  We even had a meta-level
discussion about whether those flags might better be removed
altogether (again!), but it looks we agreed that we need at least some
kind of indication in RA.

While opinions on the details so varied, we seem to have agreed that
we need to fix the requirements for those flags (or something
similar/replacement in RA) first.

Based on a nice initial attempt by Ralph...

http://www1.ietf.org/mail-archive/web/ipv6/current/msg05141.html

...I'd summarize the requirements raised in the thread as follows:

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') Some people (one person?) also wanted the ability to indicate
   to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not
   available on this link"  (This is probably a combination like
   M=0&&O=1 would currently indicate)

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

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)

Am I missing anything?  Note that I'm not saying we need all of them;
I'm currently trying to list all major points raised in the past
discussion.  Some of those may turn out to be a non-requirement.

Once we can fix the list, we'll then start the main discussion of
which is really necessary and how to do that.  (And I'd like to not
start that type of discussion at the moment so that we can move
forward step-by-step, avoiding further confusion or divergence).

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

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 26 Jul 2005 17:16:46 +0200

>   (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or

Can't remember HCB and ICB stand for right now, so maybe I'm missing  
some of the finer points...

Anyway, I believe it's important that clients know that they should  
ask for addresses + other info over DHCPv6, or other information  
only. (I'll be happy to explain why at length in private email or in  
person next week if anyone cares.)

Someone implmenting or deploying DHCPv6 would probably want to know  
whether they should have stateful or stateless servers or both, and  
stateful or stateless clients or both.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Jul 2005 01:55:59 +0900

>>>>> On Tue, 26 Jul 2005 17:16:46 +0200, 
>>>>> Iljitsch van Beijnum <[email-masked]> said:

> stateful or stateless clients or both.

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

HCB: getting address (and possible other) configuration information
     by Solicit/Advertise/Request/Reply exchanges
ICB: getting other configuration than addresses (excluding addresses)
     by Information-request/Reply exchanges

So the above requirement of yours seems to be (almost) identical to
the following requirement just represented differently:

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Tue, 26 Jul 2005 20:50:52 -0400

Your summary looks right to me...

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Jul 2005 11:01:48 +0900

>>>>> On Wed, 27 Jul 2005 11:16:08 +1000, 
>>>>> Brett Pentland <[email-masked]> said:

> Are 1) and 3) mutually exclusive, or is the requirement to have some
> M/O combination that says "There is no DHCP, do not try to find it"
> and another combination that says "I make so representation about the
> DHCP status so you're free to have a look for it"?  Or have I completely
> missed the point?

Requirement 1 simply says "DHCP is not available"; it doesn't say "do
not try to find it".  So I don't think 1 and 3 are mutually exclusive.
Note, however, that we've not fully discussed what these requirements
exactly mean, perhaps with RFC2119 keywords (MUST or SHOULD or ...).
I think that part is a subject of the next phase of this discussion,
where the result may make some combination mutually exclusive.

But it's not surprising even if some combinations are (or will be)
exclusive.  As I said in the first message, I just tried to catch up
all requirements from various people we've seen so far, in order to
make sure that we don't miss anything at the start point.  Succeeding
discussion in the second phase may reveal exclusive relationships.
(But, again, I don't want to go to that level of discussion at the
moment.)

					JINMEI, Tatuya

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Jul 2005 09:21:55 +0200

> not try to find it".

I disagree. On some networks it's inappropriate to try to use DHCPv6.

And if hosts are going to look for DHCPv6 servers regardless of the  
value of the M/O bits, what's the point of this whole discussion??
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Jul 2005 16:44:57 +0900

>>>>> On Wed, 27 Jul 2005 09:21:55 +0200, 

> I disagree. On some networks it's inappropriate to try to use DHCPv6.

You can disagree about anything, but please remember that we are (or
at least I'm) currently concentrating on listing points raised so far,
without discussing whether each point is valid or not.  And, in fact,
there has actually been an opposite opinion to yours in the past
discussion.

Can we hold off expressing opinions on the possible requirements a bit
while, please?  Otherwise, we'll soon see a strom of different
opinions as we've seen in the previous threads.  (Such a storm is
perhaps inevitable in the next phase of this discussion though).

Thanks,

					JINMEI, Tatuya

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Jul 2005 09:56:29 +0200

> there has actually been an opposite opinion to yours in the past

Hence the discussion. There have also been others who agree with me.  
The trouble is, that you weakened the requirement by saying "it  
doesn't say "do not try to find it"."

> perhaps inevitable in the next phase of this discussion though).

Perhaps it's possible to get together in person with a small group of  
people with strong opinions about the subject to see if there is some  
way to work all of this out? I really don't see how why this would be  
unsolvable, but for some reason we can't seem to get past this.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Jul 2005 17:23:07 +0900

>>>>> On Wed, 27 Jul 2005 09:56:29 +0200, 

> doesn't say "do not try to find it"."

Okay.  However, not including the intent of "do not try to find it",
while there is the *expectation* that the host won't send any DHCP
messages, was actually my understanding of Ralph's original summaryn
(http://www1.ietf.org/mail-archive/web/ipv6/current/msg05141.html).

If my interpretation was incorrect, I'm happy to be corrected.  Even
if others, I see some people (one person?) wants to include the
stronger implication.  So, I'd revise the requirement list as follows:

   1') Some people also wanted to indicate a stronger message of "do
       not try to find it" in requirement 1.

   1'') Some people (one person?) also wanted the ability to indicate
   to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not
   available on this link" (This is probably a combination like
   M=0&&O=1 would currently indicate).
   [Note: requirement 1'' can also have two variations: with or
   without the intent of "do not try to find it".  But since the "some
   people" seem to be the same group, there is probably no version of
   1'' without the intent]

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)
  [Note: this requirement contradicts requirement 1'.  We'll need to
  determine which one should be honored or whether there is an
  intermediate compromise.]

Is this better?

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Jul 2005 12:28:39 +0300 (EEST)

> I disagree. On some networks it's inappropriate to try to use DHCPv6.

For the purposes of this (requirements) dicussion, I think it would be 
useful if you could describe these "some networks" and elaborate why 
trying to use DHCPv6 would be inappropriate.

That would allow us to have more beef to the requirements, for the 
next steps when we'll evaluate these requirements.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Jul 2005 12:01:12 +0200

> For the purposes of this (requirements) dicussion, I think it would  
> be useful if you could describe these "some networks" and elaborate  
> why trying to use DHCPv6 would be inappropriate.

It wastes bandwidth, which may be an issue on some link types. (I  
think someone mentioned 3G here.) It also uses up other resources  
needlessly, such as multicast slots in NICs. Doing DHCPv6 when there  
is no legitimate DHCPv6 server makes it easier for attackers to use  
rogue DHCPv6 servers to inject false configuration information into  
hosts.

---

From: Syam Madanapalli <[email-masked]>
Date: Wed, 27 Jul 2005 16:28:02 +0530

The flags are just hints, the host can always ignore
them. If it is inappropriate to try to use DHCP when flags
are zero, let it be so. Similarly if the flag(s) is (are) set, 
the host can always ignore. 

Otherwise we need to say that the M/O flags are triggers
of DHCP. So we need to agree if the flags are hints or triggers.

-Syam

---

From: "Mark K. Thompson" <[email-masked]>
Date: Wed, 27 Jul 2005 12:02:30 +0100

> of DHCP. So we need to agree if the flags are hints or triggers.

I would add that if they are hints, then we are not mandating any  
signalling between DHCPv6 relays or servers  and routers sending RAs.  
If they are triggers, then I would suggest that we should specify the  
nature of the tighter coupling of these disparate processes.

Mark/

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Jul 2005 23:27:09 +0900

>>>>> On Wed, 27 Jul 2005 16:28:02 +0530, 
>>>>> Syam Madanapalli <[email-masked]> said:

> the host can always ignore. 

Yes, this is my understanding, too, and I think we don't have to
revisit this agreement.  However, at this stage of listing
requirements, I'd rather be open to any possibilities, including
those which could be regarded as a trigger.  In fact, the next stage
where we'll discuss how to implement those, we may reject some of the
requirements if we cannot find any way of realizing them without
breaking the base consensus.

					JINMEI, Tatuya

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Jul 2005 17:39:37 +0200

> revisit this agreement.

Are we having this discussion now, or later/somewhere else? If so,  
when/where?

If we're going to have the discussion, we need to bite the bullet and  
arrive at some solid conclusions. Passing arguments back and forth  
for a while and then leaving it up in the air doesn't help.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Jul 2005 00:45:52 +0900

>>>>> On Wed, 27 Jul 2005 17:39:37 +0200, 

> Are we having this discussion now, or later/somewhere else? If so,  

My hope is soon (but not right now) and here.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Jul 2005 01:37:48 +0900

>>>>> On Tue, 26 Jul 2005 23:22:49 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> similar/replacement in RA) first.

With some minor updates after clarification discussions, here is the
latest version of the requirement list:

   1') Some people also wanted 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.

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)
  [Note: this requirement may contradict requirement 1'.  We'll need
  to determine which one should be honored or whether there is an
  intermediate compromise.]

Terminology:
  HCB: getting address (and possible other) configuration information
       by Solicit/Advertise/Request/Reply exchanges
  ICB: getting other configuration than addresses (excluding
       addresses) by Information-request/Reply exchanges

I hope the above summary correctly covers major points we've seen.

Now, at the risk of causing another cycle of opinion storm, the
followings are related notes on each point from the past discussion.
(I'm trying to be just an editor aside from my own opinion, but, of
course, I cannot 100% escape from that)

Requirement 2 seems least controversial.  In my understanding, this is
basically for removing redundant probe packets or hopeless timeouts
for unavailable service.  In particular, we wanted to avoid scenario
where an HCB client continues sending Solicits even if there is no HCB
server but an ICB-only server, and even if the client can somehow
benefit from the "ICB part" excluding addresses.  Such a case is most
likely a result from temporary dead servers or configuration errors,
but we seem to have agreed that we want to deal with such cases.

Requirement 2 can be met through some extensions to RFC3315 and
RFC3736.  The obvious question is whether we can accept such extensions
in terms of standardization and compatibility with existing
implementations.  In particular, some people expressed concern about
requiring changes to ICB-only (RFC3736) server implementations.  In
general, however, my understanding is that people were positive about
upgrading the DHCPv6 specifications, considering the
specification/implementation maturity.

Requirement 1 generally comes from some types of networks such as
cellular networks where network bandwidth or buttery consumption of
end stations is sensitive issues.  I think people generally understood
the point and agreed that the appropriate mechanism for implementing
this is flag(s) in RAs.

However, opinions on the details appeared to vary, causing lots of
confusion.  The major controversial points are probably summarized in
the succeeding sub-requirements:

  - whether we need to prohibit the use of DHCPv6 more strongly and
    explicitly (e.g., with a 'MUST NOT'), which corresponds to
    Requirement 1'.

    I know there is a strong opinion for this requirement, but I'm not
    sure if that was a majority.  On the other hand, if we adopt this
    requirement with the strongest wording such as 'MUST NOT', it will
    contradict with Requirement 3 (if we agree that it has some valid
    points).  Additionally, as we briefly talked very recently, such
    strongest text would also break our general agreement that the RA
    flag(s) are just a trigger without containing mandatory
    requirements.

    We'll probably need to seek some middle ground by, e.g., wording
    compromise.  I don't have a specific idea about how to do that
    right now, though.

  - whether we need to separate the 'ability' for HCB and ICB, which
    corresponds to Requirement 1''.

    If we need to separate the two types of ability, it would likely
    be implemented through the two flags currently defined in RA
    (i.e., the M/O flags).

    The main motivation of separating the two flags appear to be the
    ability to suppress HCB (however strictly) by default, expecting
    ICB is more common.

    On the other hand, we now know combinations of these flags turn
    out to be a confusing issue than we originally thought and can
    cause weird corner for implementors.  So, some people rather
    wanted to unify those flags into a single bit, indicating whether
    DHCPv6 service is available (whether it's HCB or ICB), and solve
    HCB vs ICB issues through extensions to DHCPv6.

    I've seen lots of opinions from many people for either side, and
    their points are almost orthogonal.  I'd not expect one side can
    fully convince the other through further discussion.  In my
    understanding, however, people who preferred the single bit could
    also live with the two bits.  Also, possible extensions to DHCPv6
    may make the combinations issues easier to handle.  So, possible
    compromise here is to keep the two flags, and to clarify (or
    perhaps mitigate) the combination issues with DHCPv6 extensions.
    (I don't have a specific idea about how that can be done at this
    moment though).

Requirement 3 is basically a trivial requirement unless we use very
strong prohibition (e.g., MUST NOT) for Requirement 1', and perhaps we
don't have to do anything about this.  As some people pointed out,
users/implementations would always ignore specifications when they
want to do so.  A minor issue is how we should be explicit about the
flexibility in a specification (or any document that comes from this
discussion).  Perhaps we need to clarify the possibility explicitly in
order to avoid confusion, or perhaps we should not even mention that
since this is trivial and 'not IETF's business'.  I guess this is
pretty minor, and we can postpone the decision until the other bigger
issues are resolved.

I hope this lengthy message can be a helpful and constructive source
of the next step for this discussion.

					JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Jul 2005 10:27:46 -0700

> value of the M/O bits, what's the point of this whole discussion??

It's the difference between policy and mechanism.   We can say that  
when the M/O bits say there is no DHCPv6 service on the network, the  
client SHOULD NOT try to do DHCPv6.   Or we can say that when the M/O  
bits say there is no DHCPv6 on the network, the client MUST NOT try  
to do DHCPv6.   The latter statement leaves us with a lot less wiggle  
room, and is hard to justify in any but the most resource-constrained  
context.   A client implemented for such a context benefits from  
following the SHOULD NOT, so there is probably no need for a MUST NOT.

I should note that I don't actually care one way or another whether  
it's a SHOULD NOT or a MUST NOT, because I don't think we have enough  
operational experience to understand what the problems will be either  
way.   So I suspect that whatever is said on this in the next draft  
of any document that comes out, it will not be the last word.   On  
that basis, I think we should try our best to get it right, but not  
freak out about getting it right.   :'}

---

From: Brett Pentland <[email-masked]>
Date: Wed, 27 Jul 2005 11:16:08 +1000

Brett.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Jul 2005 08:34:44 +0300 (EEST)

>       as 3G?) and the case where attacks of rogue DHCPv6 messages are
[,,,]
>  intermediate compromise.]
[...]
>    explicitly (e.g., with a 'MUST NOT'), which corresponds to

Let me try to offer a point here (and sorry if this is too early) why 
I don't think a MUST NOT is not a requirement.

Specifically, I'm not sure if there are valid scenarios where these 3G 
or other devices, which must conserve bandwidth, would implement 
requirement 3, specifically in the interfaces associated with 
conserved bandwidth?  (This question could be asked differently: "Are 
there networks where the network must tell that the hosts must 
conserve bandwidth, otherwise the hosts don't know it?".)

It seems to me that those 3G vendors probably won't implement 
requirement 3 (unless explicitly configured otherwise) at least on 
their 3G interface, and then the whole problem goes away, because even 
if the hosts implemented DHCPv6, they wouldn't use it on the interface 
unless the network gives a sign they should.  On the other hand, if a 
vendor does implement it, and the user has to pay for the wasted 
bandwidth, I guess the user is going to complain about it and it'll 
get fixed.

I'm not sure if there are some cornercases wrt. the security argument 
where this can't be as easily solved.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Jul 2005 15:30:11 +0900

>>>>> On Thu, 28 Jul 2005 08:34:44 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> Let me try to offer a point here (and sorry if this is too early)

If my analysis captured the past discussion correctly, I think we can
now start the next phase, including which ones are valid requirements.

> why 

Difficult to parse...so you mean you think 'MUST NOT' is a
requirement:-)

> bandwidth, I guess the user is going to complain about it and it'll 

I generally agree with this view.  This issue here is, I think, how we
should reflect that in the document/specification we are going to
produce (if any):

  - simply saying 'MUST NOT invoke DHCPv6 if the signal (whatever it
    is) is off' is overkilling, unless we also agree this rule should
    be applied not only to some special type of network like 3G but
    also to any type of networks.

  - then should we say something like this? "...MUST NOT invoke DHCPv6
    if the signal is off for such networks as 3G, where bandwidth is
    scarce commodity and/or consuming client's buttery is
    unacceptable."  Can we sufficiently and correctly specify 'such
    networks' to which the 'MUST NOT" is applied?

  - personally, I'd make this as a side-note for some specific types
    of networks, e.g., "for some types of networks, clients may not
    want to start DHCPv6 unless the availablity of the service is
    explicitly signaled via RA.  An examples of such networks is 3G,
    where bandwidth is scarce commodity and/or consuming client's
    buttery is unacceptable."

> where this can't be as easily solved.

??? I don't understand how this relates to the 'MUST NOT'
discussion (or even what this sentence really means)...could you
elaborate?

					JINMEI, Tatuya

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 28 Jul 2005 16:04:06 +0900

>  (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or

Let me clarify here, are you saying DHCP client invokes
its HCB and/or ICB regardless of RA (or in case where RA
is not available) ?

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

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 28 Jul 2005 16:41:52 +0900

>[omitted] On the other hand, if a 

I see and that is an important point to vendors, however a host
already configures its address can invoke at least ICB to get its 
information regardless of RA indication.

Regards,

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Jul 2005 16:48:00 +0900

>>>>> On Thu, 28 Jul 2005 16:04:06 +0900, 
>>>>> Soohong Daniel Park <[email-masked]> said:

> its HCB and/or ICB regardless of RA (or in case where RA

In the example, yes.

The requirement itself might be met by other solutions, but I could
not find any alternatives in the past discussions.

					JINMEI, Tatuya

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Jul 2005 11:19:06 +0100

On Wed, Jul 27, 2005 at 05:39:37PM +0200, Iljitsch van Beijnum wrote:
> On 27-jul-2005, at 16:27, JINMEI Tatuya / ???????????? wrote:
> 

There is a 15 min slot in the IPv6 WG agenda for Tuesday, and then a
small slot in DHC on Thursday where the result (assuming we get one) of
Tuesday can be discussed in the DHC context.

-- 
Tim/::1

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 01 Aug 2005 06:39:12 +0900

>>>>> On Thu, 28 Jul 2005 01:37:48 +0900, 

>    - if a host wants ICB, it sends an ICB request (Information-request) 

(snip)

> RFC3736.

Assuming we basically agreed that the basic analysis I showed in my
previous message, I'd like to discuss more details about 'solutions'.

The followings are possible extensions to DHCPv6 I've seen so far:

A. make an ICB-only server reply to Solicit with an Advertise
   including NoAddrsAvail and other configuration information (just
   like a Reply to Information-request)
B. make an HCB client accept an Advertise even if it includes
   NoAddrsAvail, if it gets no other Advertise including addresses,
   the Advertise also includes other configuration information, and
   the client can benefit from that information
C. allow an HCB client to fallback from HCB to ICB after some timeout
D. allow an HCB client to perform HCB and ICB concurrently

Extensions A and B help when the RA signal indicates the availability
of HCB (whether the signal is "1-bit" or "2-bit (for HCB and ICB)")
but no HCB server is actually available for some reason.  One
debatable point is that Extension A requires a modification (an
additional feature) to ICB-only servers, which are expected to be
light-weight (note, however, that the ICB-only servers will still be
stateless even with the extension).

Extensions C and D concern an HCB client for which there is only an
ICB-only server that does not support extension A (i.e., it's a kind
of backward compatibility).  We have multiple choices about these
extensions.
 - If our consensus is we don't have to care about such compatibility,
   we don't need either of those. 
 - If we really need something like those, then Extensions C and D are
   almost exclusive with some tradeoffs:
   + Extension C does not consume redundant bandwidth since ICB is not
     invoked if a working HCB server exists.
   + But it takes more time for the client to get other configuration
     information via ICB if no HCB server but ICB server exists.
   + Extension D ensures that the client can always get at least other
     configuration information as quickly as possible.
   + However, it consumes more bandwidth since the client will always
     send ICB requests regardless of the existence of an HCB server.

The followings are my personal conclusions regarding the extensions.

I believe we can agree that extension B is acceptable.

Whether extension A is also acceptable or not probably depends on
whether we can accept "complicating" ICB-only servers.  I guess we
need inputs from implementors, but, as one implementor of DHCPv6, I
think this is an acceptable modification.

Regarding extensions C and D, I can live with either: extension C
only, extension D only, or none of those, expecting we can introduce
extensions A and B (then newer implementations don't need either
extension C or D).  But I'd slightly prefer introducing extension C.
This can be suboptimal (in terms of fallback delay) compared to
extension D, but I guess the advantage of less consumption of
bandwidth would be preferred because this is just a workaround with
older (without extension A) ICB-only servers.  And I still believe
providing the workaround will help.

					JINMEI, Tatuya