>>>>> On Thu, 28 Jul 2005 01:37:48 +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
--------------------------------------------------------------------
