(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
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
>>>>> On Mon, 01 Aug 2005 06:39:12 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> 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
> (snip)
>> 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.
> 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
> 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
--------------------------------------------------------------------
