>>>>> On Thu, 28 Jul 2005 08:34:44 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
>> 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.]
> [...]
>> 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'.
> 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
> I don't think a MUST NOT is not a requirement.
Difficult to parse...so you mean you think 'MUST NOT' is 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 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."
> I'm not sure if there are some cornercases wrt. the security argument
> 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
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
--------------------------------------------------------------------
