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

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 03 Aug 2005 00:18:57 +0900

It was unfortunate we happened to concentrate on 'requirement 3' in
today's discussion...whether or not the motivation behind the
'requirement', it's definitely a minor point, compared to requirement
1 (see below).  In that sense, I agree that the requirement 1 is the
'real requirement'.

So, can we now concentrate on requirement 1 (see below also), rather
than playing with 'requirement 3' further?  If we reach consensus on
requirement 1, then it will likely solve issues around requirement 3
(if any) automatically.

I think the major points are:
  a. whether we need the 2 bits or 1 bit is just enough
  b. how strict we should be about the case where the flag(s) is OFF
     (say MUST NOT invoke DHCPv6, say SHOULD NOT invoke DHCPv6, just
     make informative note without RFC2119 keywords, others...?)

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

>>>>> On Thu, 28 Jul 2005 01:37:48 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

>> 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.

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

> 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 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.

>    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]

> 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)
>   [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
> 					Communication Platform Lab.
> 					Corporate R&D Center, Toshiba Corp.
> 					[email-masked]

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

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 03 Aug 2005 00:27:00 +0900

(This is mainly a matter of dhc wg, so I listed the ipv6 list in the
cc field).

Does anyone have an opinion on possible extensions to the DHCPv6
protocol (see below for more details)?  Aside from the extension
details, if we can accept introducing some extensions to meet the
corresponding requirement, I think we can start working on the details
in the dhc wg independently from the M/O flags discussion.  At the
very bottom line, my understanding is that we can accept some level of
extensions to the current protocol...is that correct?

					JINMEI, Tatuya

>>>>> On Mon, 01 Aug 2005 06:39:12 +0900, 

> (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.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Aug 2005 09:28:14 +0200

On Aug 2, 2005, at 5:27 PM, JINMEI Tatuya / 神明達哉 wrote:
>  At the

Yes, I think that's correct.   The one extension I heard proposed,  
which made stateless DHCP more compatible with stateful, seemed  
pretty low-impact.   So I think it's okay.

As for the MUST vs. SHOULD issue (item 3), I think it should be a  
SHOULD, not a MUST.   I think that there are environments (e.g.,  
possibly cell phone) where it should be a MUST, but that is something  
that should be dealt with in the standards bodies that talk about  
cell phones, not in the IETF.

There was also some question in the past of what to do when the M and  
O bits *change* between router advertisements.   I can't remember who  
brought it up.   I don't recall seeing any resolution to this.    
While secure RA sounds really neat, I suspect it will not be widely  
usable on networks where ad-hoc connection is the norm (e.g., SOHO  
and WiFi hotspots).   If my gut feeling on this is correct, then how  
we deal with the case where we get an RA with bad information really  
is important.   If a bad RA kills my IP connectivity, that's a big  
problem.

---

From: Syam Madanapalli <[email-masked]>
Date: Wed, 3 Aug 2005 14:09:05 +0200

> is important.   If a bad RA kills my IP connectivity, that's a big

This can happen in the following cases.
1. Temporary unavaialbility of DHCPv6 server
2. Inconsistency of Routers configuration
3. Host changes the subnet and the new subnet may not support
    DHCPv6

The 3rd case can be handled gracefully as there is a link changes,
so the bits will be reset.

First two cases may be difficult to handle as the host does not know
exactly the reason could be for the bits transition. Even if SEND is used,
the inconsistency in router configuration can cause a problem.

Nay be a host can do one of the two following.
1. Host keeps the state for all routers for the M/O bits: if the same router 
is sending the bits with different values then host can accept the change.

2. When the host see the transition of bits 1 to 0 then it can check the 
availability of DHCPv6 server by explicity sending a solicit  (?) message
to reconfirm the bits transition.

-Syam

Bits may go from  1 to 0