>>>>> On Tue, 26 Jul 2005 23:22:49 +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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
