Prefix delegation is a somewhat different animal than your average DHCP lookup. It
only makes sense in routers, not hosts. In fact, it is unclear whether the DHCP server
for prefix delegation should be the same as the DHCP server for DNS configuration. I
think we should leave prefix delegation out of this discussion.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ralph
> Droms
> Sent: Monday, May 10, 2004 9:40 AM
> To: JINMEI Tatuya / [EMAIL PROTECTED]@C#:H
> Cc: [EMAIL PROTECTED]
> Subject: Re: the protocol for the O flag
>
> Yes, your original analysis is correct...
>
> Seems like the protocol associated with the 'O' bit should be RFC 3736;
> there is no particular advantage to using the 4 message exchange of RFC
> 3315
> for "other configuration information". The only potential advantage would
> be if there is ever a need for "other configuration information" that
> needs
> atateful assignment; we've never found a need for such assignment in
> DHCPv4.
>
> Although exactly where prefix delegation falls is a little unclear...
>
> - Ralph
>
> At 12:42 AM 5/11/2004 +0900, JINMEI Tatuya /
> =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
> >(changing the subject)
> >
> > >>>>> On Sat, 08 May 2004 23:39:20 +0900,
> > >>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> >
> > >> I think the O flag (if we keep it!) should simply specify DHCPv6,
> with no
> > >> implication about the way in which DHCPv6 is used.
> >
> > >> "Stateless DHCPv6" is simply a way to use some of the messages from
> > the full
> > >> specification in RFC 3315. RFC 3376 is a guideline to the
> > implementation of
> > >> DHCPv6 that uses just Information-request/Reply messages. A client
> can
> > >> choose to use the Request/Reply or the Information-request/Reply
> message
> > >> exchange to obtain other configuration information without address
> > assignment.
> >
> > > Before going to further details, please let me clarify one thing about
> > > RFC3736 (you should have meant RFC3736 by "RFC 3376" BTW).
> >
> > > In my understanding, RFC3736 defines a certain class of implementation
> > > that is a subset of RFC3315, even though RFC3736 is basically a
> > > "guideline". Specifically, RFC3736 defines the implementation class
> > > in its Section 5.
> >
> > > So, there can be four types of servers and clients:
> >
> > > A. servers that conform to RFC3315. (These servers also conform to
> > > RFC3736)
> > > B. clients that conform to RFC3315 (These servers also conform to
> > ^^^^^^^should be "clients"
> > > RFC3736)
> > > C. servers that only conform to RFC3736 (and do not implement the rest
> > > of RFC3315)
> > > D. clients that only conform to RFC3736 (and do not implement the rest
> > > of RFC3315)
> >
> > > Is the above understanding correct?
> >
> >No responses...so, assuming the understanding is correct, I believe
> >the best protocol for the O flag is the subset of RFC3315 as defined in
> >RFC3736 (aka "stateless DHCPv6"). The rationale is as follows:
> >
> >As long as we need to care about type D clients (which do not support
> >full RFC3315), servers must be configured to enable RFC3736, whether
> >they can also support full RFC3315 or not.
> >
> >But then, I don't see the reason for leaving flexibility by specifying
> >a larger set (i.e., RFC3315) as the protocol for the O flag.
> >
> >If we specify RFC3736 as the protocol,
> >
> >- type A servers will be configured to act as RFC3736 servers (they
> > may also act as full RFC3315 servers, but that doesn't matter here).
> >- type B clients will perform RFC3736 to get the "other" configuration
> > information, as a subset of their full ability.
> >- type C servers will simply act as RFC3736 servers
> >- type D clients will simply act as RFC3736 clients
> >
> >On the other hand, if we just specify RFC3315 as the protocol, we'll
> >be bothered about combination issues. In the following discussion,
> >I'll call other configuration by request/reply exchanges "stateful
> >other configuration".
> >
> >- type A servers will at least need to be configured to enable
> > RFC3736, as explained above. They may or may not enable the rest of
> > RFC3315.
> >- type B clients may perform RFC3736 only, stateful other
> > configuration only, or both.
> > + if the client only tries RFC3736, it will be happy, since type A
> > servers should act as RFC3736 servers (type C servers can of
> > course serve for the client).
> > + if the client only tries stateful other configuration, the
> > configuration will fail when type A servers do not enable stateful
> > other configuration or there are only type C servers.
> > + if the client tries both RFC3736 and stateful other configuration,
> > what happens depends on the ordering. If it first tries RFC3736
> > or performs both concurrently, it will be happy. If it first
> > tries stateful other configuration, the client can see a long
> > delay before the configuration completes when type A servers do
> > not enable stateful other configuration or there are only type C
> > servers.
> >- type C servers will simply act as RFC3736 servers. If there are
> > type B clients that do not try RFC3736, the servers cannot serve for
> > the clients.
> >- type D clients will simply act as RFC3736 clients. The clients will
> > be happy, since type A servers should act as RFC3736 servers (type C
> > servers can of course serve for the client).
> >
> >As shown above, a type B client can easily get stuck unless it is very
> >carefully configured; to be able to configure itself in all the
> >possible scenarios, the client will need to perform RFC3736 only,
> >tries RFC3736 first (which should succeed), or tries both RFC3736 and
> >stateful other configuration concurrently (at least the former should
> >succeed). Then, why can't we simply specify RFC3736 as the protocol?
> >
> >Meanwhile, leaving the flexibility may make sense if it has a clear
> >advantage comparing to specify RFC3736 clearly. Regarding other
> >configuration information, however, I don't see such an advantage that
> >outweighs the complexity shown above.
> >
> >Comments?
> >
> > 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
> >--------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
