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 PROTECTED]
>>>>> On Thu, 28 Jul 2005 01:37:48 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> 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 PROTECTED]
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
